antiCisco blogs

Опубликовано Fedia 9 Август , 2011

Как известно, настроить по отдельности каждую систему — полбеды. Самый цинус в настройке сопряжения по-умному interoperability. И стройная поначалу картинка начинает разваливаться по частям, погребая под себя план сдачи проекта…

Поэтому, сжав волю в кулак под знаменами благородной миссии облегчения труда тем, кто пойдет за мной, продолжаю серию публикаций об одном очень … медленном и трудном для меня проекте. Напомню, речь идет о создании красивой системы с удаленных подключений с аутентификацией пользователей с одноразовыми ключами RSA, с фильтрацией контента, с унифицированным управлением пользователями из единой точки (AD) и прочая и прочая…

В рамках проекта сначала настраивался ACS версии 4.2 – простой и понятный, но не достаточно гибкий сервер. Но обо всем по порядку.

Сама настройка ACS 4.2 для работы с SecurID сложности не представляет. Если вы настраиваете софтовую версию, установленную на Win 2000 Server или Win 2003 Server, то необходимо соответствующий клиент RSA (для W2K Server или Win2K3 Server соответственно) сначала установить, указав ему, где локально лежит волшебный файл sdconf.rec . И после этого автоматически в настройках внешних баз появится RSA SecurID.

Если же вы настраиваете железяку (appliance 1113), то в соответствующей закладке настройки внешних баз пользователей создаете конфигурацию для RSA SecurID и подсовываете созданный ранее файл с настройками (sdconf.rec).

На самом RSA Auth Manager (https://RSA_SERVER_NAME:7004/console-ims) достаточно создать нового агента аутентификации

Выдумывать ничего не надо: ACS проходит как стандартный агент (бывает еще web-agent, но он нас не касается)

Проверить, установилась ли связь, можно попытавшись аутентифицироваться при помощи пользователя на RSA. После первого обращения вырабатывается уникальный сессионный пароль для связи с агентом.

После этого вы должны настроить обращение к данному серверу. Возможно несколько вариантов:

1. Пропускать всех пользователей, которые не указаны явно в группах ACS (unknown users) на RSA. Это удобно, если все пользователи должны иметь токены.

2. Явно указывать, что конкретный пользователь ACS (созданный ручками), аутентифицируется во внешней базе данных RSA. Это удобно, когда лишь несколько пользователей надо явно загнать на RSA

Но ни в одном случае красоты не получается, потому что в проекте все пользователи заведены в AD и рассортированы по группам. И токены сопоставляются далеко не всем, а только некоторым, но эти некоторые тоже рассортированы по разным группам с разными правами доступа и туннельными протоколами. На ACS же можно привязать одну группу AD к группе ACS, но не более. Как вариант мы рассматривали возможность создания на AD множества групп с заданными параметрами (например, пускать в SSL, но не пускать в IPSec, пускать на одни ресурсы и не пускать на другие). Но, как учит нас математическая наука, при количестве атрибутов хотя бы 5, количество групп разрастается до 5! (это не громкое пять, а страшное слово
ФАКТОРИАЛ :))

Поэтому была предпринята попытка применить дополнительно к аутентификации в RSA авторизацию (раскидывание по группам) при помощи LDAP внешней базы, которая синхронизирована с доменом.

Попытка провалилась, наверно по моей вине – мне не удалось провести авторизацию при помощи внешней LDAP базы (хотя такой вариант предлагает ASC4.2 – RSA+LDAP), т.к. по всей видимости схема (LDAP SCHEMA), заложенная для работы с внешней LDAP базы не совпадает со схемой LDAP в AD.

Поэтому была предпринята следующая попытка – настроить аутентификацию пользователей в RSA с авторизацией в AD при помощи ACS5.2

Здесь все гораздо удобнее и гибче. Расскажу поподробнее.

Для настройки на ACS5.2 внешней базы SecurID в cоответствующей закладке с настройкой внешних баз данных подсовываем sdconf.rec (ну вы поняли, что файл важный :))

Важно: RSA SecurID сервер в системе может быть только один. Поэтому в этом окошке нет слова Add. Но когда вы будете создавать первый сервер вместо слова Edit будет заветное Add.

Далее, если вам необходимо, чтобы кроме собственно аутентификации дополнительно присваивались некие параметры исходя из атрибутов AD, есть прекрасный механизм

Identity Store Sequence, в котором можно создать последовательность проверок мест хранения пользователей и что для нас важно, дополнительно задать место хранения атрибутов пользователя.

В данном случае AD1 – это ранее настроенная внешняя база пользователей в AD. К слову сказать, в ACS5.2 не требуется отдельного клиента, к которому бы он цеплялся (как было в  ACS4.2). К базе AD доступ настраивается напрямую, указав пользователя с правами на чтение каталога.

Красным выделено, что мы аутентифицируем пользователей в ранее созданном RSA, а дополнительные атрибуты забираем из ранее настроенного AD1.

Напомню, что сам RSA Authentication Manager прекрасно умеет залезть в AD и забрать оттуда пользователей и их группы, но ничего не отдает ACS, кроме ACCEPT или REJECT. При
этом REJECT может означать как то, что пароль неверный, так и то, что пользователю не привязан токен или вовсе такого пользователя нет. Это очень неудобно. С этим будет связана одна геморройная засада, о которой расскажу позже.

Продолжение следует…

 

Метки: ACS, rsa, SecurID
Опубликовано: Holywar , Безопасность cisco