Windows автологин и iMaster Huawei: про полисер-костылёк

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Есть такая функция логирования, при которой для аутентификации берется имя пользователя и пароль от входа в 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 для головной боли.

--

Источник: https://habr.com/ru/post/712478/

Интересные статьи

Интересные статьи

Статья расскажет о протоколах в операционной системе Windows и способах взаимодействия с ними. Пройдемся по списку протоколов, опишем их основные задачи и попробуем повзаимодействовать с одним из них ...
Подозреваю, что я не один такой, кто держит дома в режиме 24/7 маленький и тихий системный блок с Windows в качестве сервера, на который можно зайти по RDP (с того же сма...
Мы начали путь к созданию собственного диспетчера пакетов для Windows 10, когда анонсировали предварительную версию диспетчера пакетов Windows на Microsoft Build 2020. Мы...
SWAP (своп) — это механизм виртуальной памяти, при котором часть данных из оперативной памяти (ОЗУ) перемещается на хранение на HDD (жёсткий диск), SSD (твёрдотельный накоп...
С версии 12.0 в Bitrix Framework доступно создание резервных копий в автоматическом режиме. Задание параметров автоматического резервного копирования производится в Административной части на странице ...