Кому дозволено дзвонити? Аудит 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 щодо відмови, замість того щоб довіряти оновленню консолі.

Наприкінці запишіть, який механізм володіє рішенням для кожної служби віддаленого доступу. Якщо політика ігнорує властивості дзвінка користувача, умова групи є визначальною, а атрибут має лише дорадчий характер для цієї служби. Дві служби в одному домені можуть законно відповідати по-різному, і запис перевірки має сказати це одним рядком на службу.

Результат, який переживе аудит, короткий: хто може підключатися, за яким механізмом, коли перевірено і ким. Прапорець дзвінка дає перші дві відповіді; решту дає лише перевірка політики.