- PVSM.RU - https://www.pvsm.ru -
Так сложились обстоятельства, что мне пришлось администрировать уже настроенную RADIUS аутентификацию пользователей одного доверенного домена на узле Mikrotik, который либо пропускал в интернет пользователей, либо нет. Раньше такого настраивать не приходилось, был в распоряжении просто уже готовый настроенный «черный ящик». Задача была добавить пользователей еще одного домена в эту схему аутентификации.
Чтобы я помнил эту историю вечно, сюда и описываю процесс.
Итак, начал смотреть как это все работает в текущей схеме. На первый (да и не первый тоже) взгляд все по учебнику:
Все выглядит логично и действительно работает как ожидается.
Вижу цель — не вижу препятствий. Создаю двустороннее доверие DOM1.LOCAL с DOM3.LOCAL (win2003). Создаю в DOM3.LOCAL глобальную группу allow_internet, включаю туда пользователей. Добавляю эту глобальную группу в AUTHSRVallow_internet и радостно пытаюсь авторизоваться.
Конечно же, ничего не заработало. В ответ приходит вот такой ответ:
Причина = Не удается установить подключение из-за отказа в разрешении на удаленный доступ для учетной записи пользователя. Чтобы разрешить удаленный доступ, включите такое разрешение для учетной записи пользователя или, если в ней указано, что управление доступом осуществляется с помощью соответствующей политики удаленного доступа, включите разрешение на удаленный доступ для этой политики.
И т.к. недостаток моих знаний не позволил мне понять, что собственно тут-то и кроется ответ, начались изыскания. Никаких следов в логах на контроллерах доменов DOM3.LOCAL или DOM1.LOCAL от этого события не было. Гугл по такой ошибке выдает вообще что-то к делу не относящееся (сплошной RDP). Поиск в групповых политиках на «рабочем» DOM2.LOCAL ничего не дал.
Я даже попробовал проксирование RADIUS запросов, подняв на DC.DOM3.LOCAL также службу проверки подлинности в интернете и трансляцию туда запросов с именем пользователя вида «DOM3*». Тем не менее в логе прокси-RADIUS сервера была точно такая же ошибка и отказ в доступе.
А причина всегда одна — безблагодатность. Оказывается, потому что DOM3.LOCAL работал в mixed-режиме, то на всех пользователях по-умолчанию на вкладке «Входящие звонки»/«Dial-in» атрибут «Разрешение на удаленный доступ (VPN или модем)» имеет значение «Запретить доступ», в отличие от DOM2.LOCAL.
Сменил режим работы домена DOM3.LOCAL на «native» и изменил на всех пользователях атрибут атрибут «Разрешение на удаленный доступ (VPN или модем)» на значение «Управление на основе политики удаленного доступа» (которое до смены режима работы домена было недоступно) следующим скриптом:
Set objOU = GetObject("LDAP://dc=DOM3,dc=local")
objOU.Filter = Array("user")
For Each objUser In objOU
objUser.PutEx 1,"msNPAllowDialin", vbnull
objUser.SetInfo
Next
После этого все заработало так как должно было.
Автор: v0rdych
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/sistemnoe-administrirovanie/261708
Ссылки в тексте:
[1] Источник: https://habrahabr.ru/post/334904/
Нажмите здесь для печати.