Добрый день.Есть инфраструктура на базе Microfoft AD.
Необходимо для начала организовать аутентификацию при входе по ssh на сетевое оборудование (роутеры, свичи Cisco) использую базу AD.
Т.е. я создаю в AD группу net_admins и хочу, чтобы все ее пользователи могли логиниться на роутерах.На текущий момент добился только успешной аутентификации пользователей из внутренней базы ACS. Использовать базу AD не получается.
На текущий момент имеется:
Сервер в домене с установленным ACS 4.2 (не домен контроллер).
Создана в домене фиктивная учетка компьютера cisco, как просят в мануале по инсталяции.
Создан специальный юзер ACSuser, от имени которого запущены все службы ACS.
Сам ACS домен вроде как видит, и в настройках external database->Windows Database позволяет его добавить.
Установлен mapping между внутренней группой ACS и требуемой группой в AD net_admins.Работоспособности добиться при этом так и не получилось.
Самое плохое - я толком не понимаю концепцию механизма, с помощью которого ACS в данном случае обращается в базу AD. После прочтения всех имеющихся мануалов - ясности не прибавилось. Правильно ли я понимаю, что различные разновидности EAP-а и т.д. в данном случае не используются?
К сожалению я не отличаюсь глубокими знаниями в устройстве AD, в моей организации этим занимаюсь не я.
Но задачу надо решать.Буду очень благодарен за помощь. Хотя бы в виде концептуальных советов.
P.S. Вчера создал аналогичную тему с косячным заголовком - описался оч глупо((( Поэтому создаю заново. Модераторов прошу удалить старую.
После удаления настроек во вкладке External User Databases, и настройки unknown user policy аутентификация заработала!При этом сложилась забавная ситуация, что любой пользователь домена может залогиниться на оборудовании. Теперь буду разбираться с этим...)
Остался все же концептуальный вопрос. Каков механизм данного процесса? Правильно ли я понимаю, что:
1. Когда ACS понимает, что в его базе нет пользователя, он обращается к домен контроллеру от имени пользователя (от которого запущены службы ACS) через Kerberos (механизм аутентификации по умолчанию в текущем домене)? или используется другой механизм?
2. Если я для 802.1x использую EAP-TLS - то EAP-TLS тунель поднимается между хостом и ACS, и факт использования внешней базы для этого процесса прозрачен? Установление тунеля EAP-TLS и подтверждение верности логина/пароля от домен-контроллера - процессы не взаимосвязанные?
>[оверквотинг удален]
>Остался все же концептуальный вопрос. Каков механизм данного процесса? Правильно ли я
>понимаю, что:
>1. Когда ACS понимает, что в его базе нет пользователя, он обращается
>к домен контроллеру от имени пользователя (от которого запущены службы ACS)
>через Kerberos (механизм аутентификации по умолчанию в текущем домене)? или используется
>другой механизм?
>2. Если я для 802.1x использую EAP-TLS - то EAP-TLS тунель поднимается
>между хостом и ACS, и факт использования внешней базы для этого
>процесса прозрачен? Установление тунеля EAP-TLS и подтверждение верности логина/пароля от домен-контроллера
>- процессы не взаимосвязанные?Смотри в логи АЦС саксед атемптс и файлуре атемптс.
Как АЦС обращается в АД понятия не имею, но подозреваю, что просто пытается залогинится на комп CISCO с логином\пассом, как это делает МС - не знаю.Если юзается EAP (для доступа по ССХ он не юзается), то поднимается EAPoL (over LAN) между суппликантом (клиентским устройством) и аутентификатором (свичом, точкой доступа), а между аутентификатором и АЦС юзается EAPoR (over RADIUS). Радиус собственно каким-то магическим образом узнает клиент фэйл или вин - и после этого шлёт по EAPoR либо Accept-Success или Accept-Reject аутентификатору, который в свою очередь решает пускать ли суппликанта в сеть.
Каким образом АЦС узнаёт о фэйле это его личное дело и аутентификатора и тем более суппликанта не касается.не плодите тем, а лучше дописывате в существующие
По итогам сегодняшнего дня наиболее актуален вопрос:Как установить отдельной группе ACS множетво AAA клиентов.
Т.е. чтобы WIFI могли получить пользователи группы ACS wifi_users
А достоп к настройке активки по ssh - у пользователей группы ACS net_admins\По умолчанию ACS разрешает все всем(((
Чтение мануала толку не дало...
>[оверквотинг удален]
>
>Как установить отдельной группе ACS множетво AAA клиентов.
>
>Т.е. чтобы WIFI могли получить пользователи группы ACS wifi_users
>А достоп к настройке активки по ssh - у пользователей группы ACS
> net_admins\
>
>По умолчанию ACS разрешает все всем(((
>
>Чтение мануала толку не дало...Ну по умолчанию ACS никому ничего не разрешает.
Если для wifi_users нет разрешений на шел - то они не смогут управлять железкой.ИМХО NAR вам должен помочь + задать группе нужные права доступа (в части шела и т.п.).
Можно так же при необходимости задать соответствие пользователь-ссид.
>Ну по умолчанию ACS никому ничего не разрешает.
>Если для wifi_users нет разрешений на шел - то они не смогут
>управлять железкой.
>
>ИМХО NAR вам должен помочь + задать группе нужные права доступа (в
>части шела и т.п.).
>Можно так же при необходимости задать соответствие пользователь-ссид.Но ведь уровень privilege level 0 - все равно всем будет давать... - а мне надо чтобы вообще к cli и близко не подпускал и отказывал в аутентификации.
Если мне понадобится группа админов ограниченными правами - то логично ее сделать. А не давать доступ к cli всем подряд не зависимо от уровня доступа.
Наверняка так, или иначе - проблема решается.
Про NAR попробую почитать.