Цитата:
Если попробовать телнетом (ssh) к АСАшке прицепиться, применяя это правило ААА, получится?
к аса(ssh) подключиться этой учеткой не получится, т.к. на аса:
aaa authentication ssh console LOCAL
Цитата:
А как сам ACS настроен?
жалко что в acs не сделать полноценный sh run) попытаюсь кратко описать то, что я наворотил в вебморде:
1. id. store.
1.1. сконфигурировано подключение к АД(Users and Identity Stores > ... > External Identity Stores > Active Directory), указано конкретное directory group, где происходит поиск юзеров, directory attributes не заданы.
1.2. созданы несколько ident. groups и заведены несколько internal users, к которым прикручены ident. groups
1.3 Создано Identity Store Sequences, где определен Authentication and Attribute Retrieval Search List(то есть где ищем пользователей и их атрибуты):
Internal users(внутренние юзеры)
AD1(так acs обозвал привязку к домену)
2. Policy elements.
тут созданы несколько authoriz. profiles. загружаемые листы(donwloadable acl) пока нигде не накатываются.
authoriz. profiles дефолтовые, используется только проверка
ietf radius att. 25 - Class
3. Access Policies.
3.1 создан и включен всего один access service, который срабатывает если Protocol = Radius
3.2 identity установлен в режим single mode selection, которые всегда отсылает в ident store из п.1.3, Advanced Options установлено в режим Reject для всех предлагаемых условий.
3.3 в group mapping создано одно правило следующего содержания:
Если AD-AD1:ExternalGroups contains all ASD1.local/Служебные/ServiceGroup/gVPNUser, Тогда
Ident group = All Groups:ASD1:gVPNUser (если группа AD соответвтвующая пользователю равна той, что указана в directory group из п.1.1, то мапим этого пользователя во внутреннюю группу(internal ident group, одна из созданных в п.1.2)
3.4 в authorization созданы Exception Policy, правила такого вида:
Если System:IdentityGroup in All Groups:ASD1:gVPNUser, тогда использовать определенный authoriz. profile.
как происходит процесс:
11001 Received RADIUS Access-Request
11017 RADIUS created a new session
Evaluating Service Selection Policy
15004 Matched rule ( п.3.1)
15012 Selected Access Service - asd1 (п.3.1)
Evaluating Identity Policy
15006 Matched Default Rule (п.3.2)
15013 Selected Identity Store - AD1 (учетка уходит проверяться по списку из 1.3)
24210 Looking up User in Internal Users IDStore - Putty.VW
24216 The user is not found in the internal users identity store
24430 Authenticating user against Active Directory
24416 User's Groups retrieval from Active Directory succeeded
24402 User authentication against Active Directory succeeded
22037 Authentication Passed
Evaluating Group Mapping Policy
15004 Matched rule (отработала привязка доменной группы к внутренней группе п.3.3 )
Evaluating Exception Authorization Policy
15004 Matched rule ( сработало правило определяющее autoriz. profile для пользователей внутренней базы, куда смаплены доменные юзеры)
15016 Selected Authorization Profile - (применяется профиль(autiriz. profile) из п.2 и на циску улетает IETF 25 атрибут накатывающий нужную group-policy к впн-сессии)
11002 Returned RADIUS Access-Accept
Цитата:
Базы РАДИУС и AD, получается, объединены?
Помнится, что в 4.2 надо было заволить пользователя, такого же как в АД, и явно указывать, что его надо аутентифицировать в Микрософтовской базе.
нет, базы отдельные. да в четверке была такая тема, причем интересно, что в параллель(но на других tunnel-group) работает старый добрый acs4.2, там часть юзеров тоже привязана в части аутентификации паролей к домену, тоже все работает, но в только в логи там падает только success записи, нету такого, чтоб было что доступ есть а запись логов утверждает обратное.