Зачем и почему это?

Так сложились обстоятельства, что мне пришлось администрировать уже настроенную RADIUS аутентификацию пользователей одного доверенного домена на узле Mikrotik, который либо пропускал в интернет пользователей, либо нет. Раньше такого настраивать не приходилось, был в распоряжении просто уже готовый настроенный «черный ящик». Задача была добавить пользователей еще одного домена в эту схему аутентификации.
Чтобы я помнил эту историю вечно, сюда и описываю процесс.

Как оно работает?

Итак, начал смотреть как это все работает в текущей схеме. На первый (да и не первый тоже) взгляд все по учебнику:

На неком компьютере домена AUTHSRV.DOM1.LOCAL (win2003), поднята «Служба проверки подлинности в интернете».
В ней прописан клиент — Mikrotik, с общим секретом.
Домен DOM1.LOCAL (win2008) имеет двустороннее доверие с DOM2.LOCAL (win2003).
В DOM2.LOCAL создана глобальная группа allow_internet, в которую добавлены пользователи, которые должны успешно проходит аутентификацию на Mikrotik.
На компьютере AUTHSRV.DOM1.LOCAL создана локальная группа allow_internet, в которую включена глобальная группа доверенного домена DOM2.LOCAL\allow_internet.
Соответственно в настройках службы проверки подлинности создана политика удаленного доступа, разрешающая доступ, если пользователь входит в группу AUTHSRV\allow_internet.

Все выглядит логично и действительно работает как ожидается.

Как сделать чтобы заработало?

Вижу цель — не вижу препятствий. Создаю двустороннее доверие DOM1.LOCAL с DOM3.LOCAL (win2003). Создаю в DOM3.LOCAL глобальную группу allow_internet, включаю туда пользователей. Добавляю эту глобальную группу в AUTHSRV\allow_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

После этого все заработало так как должно было.

RADIUS аутентификация пользователей доверенного домена