antiCisco blogs

Опубликовано Fedia 5 Сентябрь , 2011

Ну вот, настало время описать ту засаду, что обещал в прошлой статье, а заодно расскажу еще про одну хитрость, которую обнаружил «методом тыка» на ACS5.2.
Итак, напомню, что при настройке связки «тройственного союза»: ASA->ACS5.2->RSA SecurID+AD возникает неопределенность. Опишу ее поподробнее.
Запрос от ASA смело уходит через протокол RADIUS на ACS5.2 на котором настроено, что все, что приходит с этой ASA обрабатывается профилем, скажем, VPN_PROFILE. Предположим в этом профиле в качестве сервера аутентификации применен сложный механизм (sequence), состоящий из запроса на RSA Auth Manager и дополнительного запроса атрибутов через LDAP в Active Directory, а в случае неудачи – прямой запрос в AD. Т.е. логика такая: спросить RSA и в случае успеха для данного пользователя запросить атрибуты из AD (например, я использовал memberOf). А если для данного пользователя нет токена, то запросить напрямую AD. Напомню, что по условию задачи все пользователи должны быть в AD.
И вот тут нас и ждет засада!

С первого взгляда все в порядке: при таких настройках пользователи с токеном заходит, используя свой токен, а пользователи из AD, у которых нет токена, заходят с использованием своих доменных паролей. И все довольны, и всё работает, если вдруг, случайно, забывшись, пользователь с токеном не попробует вколотить свой доменный пароль… Тогда он с радостью обнаружит, что со своим доменным паролем он также попадает в сеть! Почему так происходит? Как я уже писал, RSA отвечает нашему ACS одним и тем же ответом как в случае неправильного пароля, так и в случае отсутствия такого пользователя или отсутствия у пользователя токена. И ACS не может разобраться, что происходит. Поэтому на ACS есть настройка для RSA, что делать в случае ответа REJECT. Можно либо продолжить искать (ответ расценивается как «пользователь не найден»), либо возвращать FAIL для ASA (ответ «неправильный пароль»). В первом случае (настройка по умолчанию) будет очевидное понижение безопасности (ведь весь огород с двухфакторной аутентификацией городится ради этого секурного токена), а во втором случае при помощи нашего профиля VPN_PROFILE мы сможем обслужить лишь пользователей с токенами (правда с учетом их групп из AD).
Эта «мелочь» здорово попортила мне нервы, т.к. задача грозила стать нерешаемой. Но тем, кто пойдет по моим следам, намекаю: решение есть! Но увы оно не делается единым обращением на ACS. Я сделал так:
1. Для одного профиля (tunnel-group) в качестве сервера аутентификации указал ACS5.2. Этот профиль позволяет пользователям с токенами из разных групп AD привязывать различные подгружаемые параметры (downloadable ACL, vpn tunnel-protocol, split-tunnel ACL и т.д.)
2. Для нескольких других профилей в качестве сервера аутентификации указал сразу AD (aaa-server protocol ldap). Авторизацию, т.е. применение разным группам AD различных политик (group-policy) сделал при помощи ldap attribute-map. Как настроить подобную конструкцию читайте в статье про ASA (тут). Несколько групп было сделано для того, чтобы можно было для неучтенных в ldap attribute-map групп пользователей применять различные дефолтовые политики (group-policy). Хотя думаю, что было бы достаточно одной с авторизацией. Атрибуты, присылаемые от AD (и привязка политик) более привилегированна, чем явно указанная дефолтовая политика.

Еще одна тонкость, с которой столкнулся в процессе настройки ограничений для групп на ACS – ограничение по разрешенным протоколам туннелирования. С некоторым удивлением обнаружил, что в версии 4.2 есть возможность выбора для атрибута RADIUS CVPN3000/ASA/PIX7.X-Tunneling-protocols только:
1. PPTP (1)
2. L2TP (2)
3. IPSec (4)
4. L2TP/IPSec (8)
и их комбинаций, а также особняком – WebVPN (16). И встал в тупик: как, к примеру, передать WebVPN+SVC? Подумал, что в версии 5.2 уже все поправлено, но не тут-то было! Там даже и WebVPN пропал!
Нарыл несколько доков в гугле про RADIUS атрибуты, но из них не понятно, как запрограммировать сами значения атрибутов и какие они должны быть.
Тогда в ход был пущен тайный механизм: эксперимент 🙂 В оснастке ACS5.2 есть возможность добавлять в раздел «Справочники» (System Administration) пользовательские значения. Был выбран требуемый атрибут RADIUS (из расширенного списка) CVPN3000/ASA/PIX7.X-Tunneling-protocols.

На ASA был запущен debug radius 255 и выловлено несколько передаваемых значений.
Далее был применен запрещенный прием: мозг. Я заметил, что «цифры расположены не просто так» — 1,2,4,8,16. Это, как легко видеть, степень двойки. И я попробовал для SVC – 32. О чудо! Оно заработало. И тогда стало все понятно: чтобы передать список разрешенных протоколов, нужно передать число, которое является суммой нужных значений. Например, для поддержки IPSec, WebVPN и SVC (anyconnect) нужно создать значение атрибута (назовем его IPSec+WebVPN+SVC), равное 32+16+4=52.

Легко видеть, что разным комбинациям всегда будет соответствовать разная сумма. Создав все нужные вам комбинации можно смело идти в авторизационный профиль и указывать в качестве дополнительного атрибута CVPN3000/ASA/PIX7.X-Tunneling-protocols, выбирая ему ранее созданное значение. ASA, получив его, раскодирует в нужный набор протоколов.

Я в интернете не нашел мануала по назначению значений атрибутам RADIUS, а также самих потребных значений, поэтому надеюсь, что облегчил своим дебаггингом кому-нить жизнь 🙂

 

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