Кому разрешено дозваниваться? Аудит msNPAllowDialin перед доступом к VPN

Пароль верный, учётная запись входит в группу VPN, а подключение всё равно отклоняется с сообщением, в котором не упоминается ни одна политика. Когда это происходит на сервере удалённого доступа Windows, первое место, куда я смотрю, — не правило NPS, а один атрибут Active Directory, который никто не открывает: msNPAllowDialin, значение за вкладкой Dial-in. У него три состояния, и третье тихо передаёт решение в другое место. Чаще всего никто не менял его намеренно: запись скопировали из шаблона или создали скриптом, который много лет назад записал явный запрет и больше не пересматривался.

Отказ может произойти раньше, чем политика будет прочитана

Windows проверяет разрешение записи на дозвон, пока строит решение об авторизации, поэтому явный запрет заканчивает разговор рано. На клиенте видна общая ошибка проверки подлинности, иногда уже после завершения обмена сертификатами, и поэтому люди проводят полдня, тестируя учётные данные, которые никогда не были проблемой.

Обратный случай так же сбивает с толку. Запись, на которой флаг никогда не выставлялся, может успешно подключаться, потому что политика это разрешала, а затем та же запись перестаёт подключаться, когда кто-то редактирует правило NPS по несвязанной причине. Ни одно из этих событий снаружи не выглядит как изменение разрешения на дозвон.

Три состояния, и третье невидимо

TRUE разрешает дозвон, FALSE запрещает его, а NULL означает, что запись наследует ответ из политики удалённого доступа или авторизации NPS. Интерфейс показывает третье состояние как "Control access through NPS Network Policy", и оно читается скорее как неотмеченный флажок, чем как решение.

Поэтому подсчёт разрешённых пользователей из консоли почти ничего не даёт. Унаследованная запись может быть разрешена сегодня и отклонена завтра без всякого вмешательства в запись, а FALSE запись всё ещё может подключаться на сервере, политика которого настроена игнорировать свойства дозвона пользователя. Читайте атрибут и политику вместе, иначе вы проводите аудит половины решения.

Экспортируйте флаги, не теряя унаследованные записи

Запустите экспорт на контроллере домена или на рабочей станции с модулем Active Directory и сохраните необработанный файл как доказательство, а не перепечатывайте сводку:

Get-ADUser -Filter * -Properties msNPAllowDialin, LastLogonDate |
  Select-Object SamAccountName, Enabled, msNPAllowDialin, LastLogonDate |
  Sort-Object SamAccountName |
  Export-Csv -NoTypeInformation .\dialin.csv

Один фильтр LDAP проще вставить в запись об изменении. Этот возвращает только явные разрешения:

dsquery * -Filter "(&(objectCategory=person)(objectClass=user)(msNPAllowDialin=TRUE))" -Attr sAMAccountName

Затем запросите снова без условия о дозвоне и поищите записи, у которых значение отсутствует. Это и есть унаследованные, обычно самая большая группа в домене, и если их пропустить, аудит превращается в список тех немногих, кого кто-то вспомнил настроить вручную.

Отделите флаг от группового доступа и состояния записи

Атрибут отвечает на один вопрос: может ли эта запись дозваниваться. Он ничего не говорит о том, работает ли человек здесь до сих пор, включена ли запись и не лежит ли общий пароль в заметке службы поддержки. Сопоставьте экспорт с состоянием включения, датой последнего входа и членством в группе, которая даёт доступ к серверу.

Действовать нужно по комбинациям. Отключённая запись с TRUE — это шум. Включённая запись с TRUE, которая не входила в систему год, — кандидат на удаление. А унаследованная запись в группе VPN, которую никто не может объяснить, — та самая важная находка, потому что ни одна отдельная настройка не фиксирует, почему она была выдана.

Читайте это с того контроллера домена, против которого сервер VPN действительно выполняет проверку подлинности. Задержка репликации может показать значение, которое сервер уже заменил, и аудит, ссылающийся на устаревшее значение DC, будет оспорен в ту же минуту, когда кто-то проверит снова.

Измените одну запись и докажите, что изменение дошло

Чтобы отозвать доступ, установите атрибут в FALSE, а не очищайте его. Очистка возвращает запись к наследованию политики, которая может снова разрешить её при следующем подключении, и изменение выглядит как исправление, хотя на самом деле это другое решение:

dsmod user "CN=Jane Doe,OU=Staff,DC=corp,DC=example" -allowDialin no
Set-ADUser -Identity jdoe -Clear msNPAllowDialin

Вторая строка — сброс наследования, намеренно вынесенный отдельно, чтобы никто не путал две операции. Затем подтвердите из второй сессии, перечитайте атрибут и проверьте события учёта NPS по отказу, вместо того чтобы доверять обновлению консоли.

В конце запишите, какой механизм владеет решением для каждой службы удалённого доступа. Если политика игнорирует свойства дозвона пользователя, условие группы является определяющим, а атрибут носит рекомендательный характер только для этой службы. Две службы в одном домене могут законно отвечать по-разному, и запись проверки должна сказать это одной строкой на службу.

Результат, который переживёт аудит, короток: кто может подключаться, по какому механизму, когда проверено и кем. Флаг дозвона даёт первые два ответа; остальное даёт только проверка политики.