Почему и почему это? Обстоятельства так сложились, что мне пришлось на узле Микротика администрировать уже настроенную RADIUS-аутентификацию пользователей одного доверенного домена, которая либо разрешала пользователям доступ в Интернет, либо нет. Раньше не было необходимости настраивать это; В моем распоряжении просто был готовый, настроенный «черный ящик».
Задача была добавить в эту схему аутентификации пользователей другого домена.
Чтобы я запомнил эту историю навсегда, описываю процесс здесь.
Как это работает?
Итак, я начал смотреть, как всё это работает в нынешней схеме.На первый (и не первый) взгляд все по учебнику:
- На определенном компьютере в домене АУТСРВ.
ДОМ1.ЛОКАЛЬНЫЙ (win2003), поднимается «Служба Интернет-аутентификации».
- В нем есть клиент — Микротик, с общим секретом.
- Домен ДОМ1.МЕСТНЫЙ (win2008) имеет двустороннее доверие с ДОМ2.ЛОКАЛЬНЫЙ (вин2003).
- В ДОМ2.ЛОКАЛЬНЫЙ была создана глобальная группа разрешить_интернет , который добавил пользователей, которым необходимо успешно пройти аутентификацию на Микротике.
- На компьютере АУТСРВ.
ДОМ1.ЛОКАЛЬНЫЙ локальная группа создана разрешить_интернет , включающий глобальную группу доверенного домена DOM2.LOCAL\allow_internet .
- Соответственно, в настройках службы аутентификации была создана политика удаленного доступа, разрешающая доступ, если пользователь является членом группы.
АУТСРВ\allow_internet .
Как я могу заставить это работать?
Я вижу цель, но я не вижу препятствий.Создайте двустороннее доверие ДОМ1.МЕСТНЫЙ С ДОМ3.ЛОКАЛЬНЫЙ (вин2003).
Я создаю в ДОМ3.ЛОКАЛЬНЫЙ глобальная группа разрешить_интернет , я включаю туда пользователей.
Я добавляю эту глобальную группу в АУТСРВ\allow_internet и с радостью пытаюсь войти в систему.
Конечно, ничего не получилось.
В ответ приходит следующий ответ:
Причина = Соединение не может быть установлено, поскольку для учетной записи пользователя отказано в разрешении удаленного доступа.А т. к.Чтобы разрешить удаленный доступ, включите разрешение для учетной записи пользователя или, если учетная запись указывает, что доступ контролируется соответствующей политикой удаленного доступа, включите разрешение удаленного доступа для этой политики.
недостаток моих знаний не позволил мне понять, что именно здесь, собственно, и кроется ответ, поэтому начались исследования.
Отсутствие следов в журналах на контроллерах домена ДОМ3.ЛОКАЛЬНЫЙ или ДОМ1.МЕСТНЫЙ такого события не было.
Из-за этой ошибки гугл показывает что-то совершенно неактуальное (все RDP).
Поиск в групповых политиках по «работе» ДОМ2.ЛОКАЛЬНЫЙ ничего не дал.
Я даже пробовал проксировать запросы RADIUS, поднимая DC.DOM3.LOCAL также служба интернет-аутентификации и широковещательные запросы туда с именем пользователя вида «DOM3*».
Однако журнал прокси-сервера RADIUS показал точно такую же ошибку и отказ в доступе.
Причина всех бед
И причина всегда одна – отсутствие благодати.Оказывается, потому что ДОМ3.ЛОКАЛЬНЫЙ работал в смешанном режиме, то для всех пользователей по умолчанию на вкладке «Входящие вызовы»/«Дозвон» атрибут «Разрешение на удаленный доступ (VPN или модем)» имеет значение «Запретить доступ», в отличие от ДОМ2.ЛОКАЛЬНЫЙ .
Изменен режим работы домена ДОМ3.ЛОКАЛЬНЫЙ на «родной» и изменил атрибут у всех пользователей «Разрешение на удаленный доступ (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
Теги: #Системное администрирование #Администрирование сервера #radius #домен Windows в смешанном режиме #политика дозвона
-
Google Оспаривает Иск Viacom
19 Oct, 24 -
Хостинг Для Умных Людей
19 Oct, 24
