antiCisco blogs » Blog Archive » Настройка cisco ACS 4.2 и ACS 5.2 с RSA SecurID

antiCisco blogs


блоги по технологиям и оборудованию cisco от инструкторов

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

RSA+ACS5.2

Как известно, настроить по отдельности каждую систему — полбеды. Самый цинус в настройке сопряжения по-умному 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) достаточно создать нового агента аутентификации


RSA_Auth_Agent.png


RSA_New_Agent.png

Выдумывать ничего не надо: 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 (ну вы поняли, что файл важный :))


ACS_RSA.png

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

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

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


ACS_RSA_AD.png

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

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

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

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

 

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

 

2 комментария “Настройка cisco ACS 4.2 и ACS 5.2 с RSA SecurID”

comment rss - Trackback

  1. P@ve1:

    А если не секрет, почему именно ACS, а не встроенная роль NAP win сервера? Зачем допольнительное сторонее решение для AD? NAP по сути глубоко интегрирован в AD, весьма прост и не обладает упомянутыми недостатками 4-й версии…
    ACS конечно намного удобнее для специфических задач гибкой авторизации управления сетевым оборудованием и.т.д. Но оно не всегда нужно.
    Оч интересно мнение интегратора по сабжу.
    Сам имел небольшой опыт с ACS4.2 — не понравилось категорически. Сейчас на 2-х объектах использую NAP для 802.11, VPN и т.д. — и оч доволен им)

    • Там много еще чего рулится, специфического сетевого: dot1x, авторизация, в частности команд, логгирование.

      Да и заводить еще одно решение (NAP) мне, как неспециалисту МС не хотелось

» Оставить комментарий

Вы должны войти чтобы прокомментировать.