Настройка Security Console.
Теперь мы можем смело заходить в эту закладку. Здесь производятся все настройки сервера от инициализации и управления пользователями, до сброса пин-кода и генерирования отчетов. К слову говоря, если сервер в домене, то зайти на него удаленно по административной ссылке с клиентской машины, если она не в домене. Это происходит в силу перенаправления на одноразовую ссылку с применением SSO КЭШа. Которого нет.
1. Заходим, используя того же суперадмина. По умолчанию есть лишь одна «сущность» (realm), который можно настраивать – System Domain. Там по умолчанию привязаны локальные пользователи. Но мы собираемся управлять пользователями из AD, поэтому проделаем следующие шаги.
2. Создадим еще один realm: Administration->Realms->Add new
3. Создаем realm и самое главное – связываем его с уже настроенным Identity source (именно его мы создали на предыдущем этапе при помощи Security Operations Console): Administration->Security domains->Add new
4. А вот теперь финт ушами: администратор может настраивать только один realm в одной административной сессии. Поэтому
5. Выходим и заходим снова
6. Вводим логин/пароль суперадмина
7. Но теперь нам дают из выпадающего меню выбрать нужную базу пользователей (она связан с realm, а тот в свою очередь с Identity Source)
Вот теперь мы готовы управлять пользователями из AD. Теперь кусочек теории, чтобы понять, как же происходит общение (по умолчанию настраивается связь read-only, т.е. мы только вытягиваем базу из AD, но ничего туда не кладем)
Раньше, как рассказал Борис, инженер Демос, (кстати, большое ему спасибо за консультации), аутентификация доменных пользователей велась прямо на DC. Однако, после многочисленных сбоев, которые происходили в результате обновления Windows, RSA отказалась от прямого перехвата. Теперь необходимо на каждой системе устанавливать Authentication agent. Это сложнее, но надежнее, как уверяет производитель.
В результате, перехват аутентификации (можно также перехватывать разблокировку из скринсейвера и других режимов) происходит следующим образом:
1. Агент перехватывает вызов функции аутентификации
2. Подставляет свое окошко, где просит ввести логин и пасскод
3. Если введен пользователь, который подпадает под правило перехвата (это настраивается), то логин и его пин+одноразовый пароль (или обычный пароль AD) убегает на RSA Authentication Manager, с которым у агента постоянная связь по UDP/5500 (по умолчанию)
4. Если для данного пользователя настроен токен (аппаратный или программный), то сервер сам проверяет эти данные, если же не настроен, то RSA выступает аутентификационным посредником и шлет запрос в AD, где проверяет его обычный пароль.
Теперь, наверно, понятно, какие основные настройки необходимо провести на RSA Authentication Server. Это:
1. Настройка (импорт) токенов в систему.
2. Настройка привязки токенов к пользовалям
3. Настройка адресов агентов на сервере. К слову сказать, здесь можно ограничить агентов, например, части из них не позволять пускать пользователей с определенными атрибутами.
4. Создание настроечного файла, по которому агенты узнают, куда им стучаться. Это довольно неочевидный момент.
Остановимся чуть подробнее:
1. Импорт токенов. Осуществляется при помощи XML файла, который содержит информацию о купленных вами токенах (они все уникальны). Делается в закладке
Authentication->SecurID tokens->Import token jobs->Add new
Там описывается файл, из которого брать описание и, опционально, пароль к этому файлу, если он защищен паролем.
Далее запускаете эту работу (job) и получаете в системе валидные токены (или не получаете, если что-то не так)
2. Привяжем токены к пользователям. Делается в закладке: Identity->Users->Manage existing
Там в выпадающем меню для конкретного пользователя можно выбрать пункт «Привязать токен». В этом пункте вы можете выбрать один из свободных токенов. Можно одному пользователю привязать несколько токенов (не рекомендует производитель – пользователи расхлябанные становятся), но нельзя один токен привязать нескольким пользователям.
3. Настройка адресов агентов делается в закладке: Access->Authentication agents->Add new
Там в менюшке указываете доменное имя и адрес машины (можно прямо там разрезолвить одно в другое), на которую вы потом поставите агента
4. Создание настроечного файла – неочевидный шаг. Это надо сделать один раз и потом этот настроечный файл размножить всем агентам. Помните, что изменение в последствии части настроек (таких как порты доступа или ip-адрес) потребуют пересоздания файла. Делается это в Access->Authentication agents->Generate configuration file
Создастся файл sdconf.rec, почему-то упакованный в архив. Копируете файл, кладете на машину, где будете ставить агента. На агенте нужно указывать именно местонахождение файла sdconf.rec
Конечно, в этой консоли есть еще масса настроек, от более гибких, нежели дефолтные, настроек политик доступа с разграничением по атрибутам, по времени и пр. до создания отчетов (есть живой лог, есть по расписанию) и сброса пин-кодов. Однако, насколько я понимаю, приведенные несколько шагов есть необходимый и достаточный набор настроек RSA Authentication Server для успешной работы системы.
» Оставить комментарий
Вы должны войти чтобы прокомментировать.