Есть такая функция логирования, при которой для аутентификации берется имя пользователя и пароль от входа в Windows. Если компьютер в домене, то и доменное имя будет приставлено к логину в формате «DOMAIN_NAME\user_name». Если используется протокол 802.1x, то это имя (именно в таком формате) будет перенаправлено на сервер. Возникает вопрос: если сервер аутентификации ничего не знает о домене, то может ли iMaster NCE «отсечь» доменное имя и корректно обработать такой запрос, не создавая лишней головной боли? Оказалось, что может, но есть в этом решении какая-то костыльность, и головная боль вместе с ней.

Еще раз. Использовалась стандартная схема аутентификации 802.1x: коммутатор в роли посредника (supplicant), iMaster в роли контроллера AAA, который решал куда и с какими правами будет допущен пользователь, RADIUS сервер в роли базы данных логинов и паролей. На ПК работал протокол EAP-PEAP-MSCHAPv2 и в настройках 802.1x на нем было включено «Automatically use my Windows logon name and password (and domain if any)». После этого при попытке залогиниться на какое-нибудь сетевое устройство, ПК не просил никакой информации от нас — он формировал и отправлял запрос, использовав домен+имя пользователя+пароль для входа в Windows. В результате в логах RADIUS сервера мы получали неудачную аутентификацию:

Account is not found.DOMAIN_NAME\user_name

В дебаг-логах коммутатора Huawei S:

[Reply-Message] [115] [iMaster Error Reason is Incorrect user name or password,data source,key on the access control device.ErrCode:4101]

(

Чтобы такой лог собрать, было включено:

RADIUS event debugging switch is on.
RADIUS message debugging switch is on.
RADIUS error debugging switch is on.
RADIUS info debugging switch is on.
RADIUS brief send packet debugging switch is on.
RADIUS detail send packet debugging switch is on.
RADIUS brief receive packet debugging switch is on.
RADIUS detail receive packet debugging switch is on.

Здесь важно не забыть про terminal debugging, чтобы дебаг-сообщения выводились в терминале сессии (все отключается командами: undo debugging all, undo t d).

)

То есть аутентификация неуспешна, потому что логин «DOMAIN_NAME\user_name» в базе данных не существует. Вместо него есть «user_name», но это совсем не одно и то же.

Как решается эта проблема? Она решается с помощью Policy Element в настройках Authentication and Authorization на iMaster. Механика очень простая: мы указываем «что» и «где» искать, и что с этим делать дальше. В данном случае мы указали, что нас интересует начало строки (start from -> string) в имени пользователя (User-Name) и сочетание символов «DOMAIN_NAME\»:

И далее добавили этот полисер в правила аутентификации Authentication Rules в Custom Condition:

Теперь аутентификация прошла успешно. Но пользователь получил доступ ко всем внутренним ресурсам, а должен был получить только к тем, что определены для его группы и для его роли.

Иными словами, аутентификация прошла, а правила авторизации не отработали: галочки в Authentication Rules, указывающие на роли и группы пользователей (Match user groups, Match roles) не сработали. Так произошло потому, что в Authentication Rules может работать либо User Information (группы и роли), либо Custom Condition (полисер-костылёк): одно исключает другое. Как же тогда управлять правами пользователей, как настроить авторизацию для этих доменных пользователей?

Группы пользователей и роли пользователей мы можем (и должны) активировать теперь не в Authentication Rules, а в Authorization Rules. Тогда доменный пользователь получит только тот уровень доступа, который определен для его группы/роли:

Важно отметить, что во всех этих действиях нет нужды, если ПК использует протокол PAP, а не MS-CHAPv2. То есть 802.1x аутентификация с доменным именем пройдет через iMaster и без костылей при использовании PAP. Но мы пока не разобрались почему так. Постараюсь разобраться в этом и рассказать в следующий раз.

Итак, чтобы автологин на Windows прошел при 802.1x аутентификации нужно:

1. Создать полисер, который будет мачить начало строки (string) в имени пользователя.

2. Добавить этот полисер (костылёк) в правила аутентификации.

3. Помним про головную боль, что в Authentication Rules может работать либо User Information (группы и роли), либо Custom Condition (полисер). Поэтому авторизацию настраиваем с помощью групп пользователей и ролей в правилах авторизации, а не в правилах аутентификации.

—

Другие кейсы по iMaster Huawei для головной боли.

—