Кой може да се свърже? Одит на msNPAllowDialin преди достъп през VPN

Паролата е вярна, акаунтът е във VPN групата, а връзката все още се отказва със съобщение, което не споменава никаква политика. Когато това се случи на сървър за отдалечен достъп с Windows, първото място, което проверявам, не е правилото на NPS, а един атрибут на Active Directory, който никой не отваря: msNPAllowDialin, стойността зад раздела Dial-in. Той има три състояния и третото тихо предава решението на друго място. Повечето пъти никой не го е променил нарочно: акаунтът е клониран от шаблон или е създаден от скрипт, който е записал явна забрана преди години и никога не е преглеждан отново.

Отказът може да се случи преди политиката да бъде прочетена

Windows проверява разрешението за набиране на акаунта, докато изгражда решението за оторизация, така че явната забрана прекратява разговора рано. Това, което виждате на клиента, е обща грешка при удостоверяване, понякога след завършване на обмена на сертификати, и затова хората прекарват следобеда в тестване на идентификационни данни, които никога не са били проблемът.

Обратният случай е също толкова объркващ. Акаунт, на който флагът никога не е задаван, може да се свърже успешно, защото политиката го е позволявала, а после същият акаунт спира да се свързва, когато някой редактира правилото на NPS по несвързана причина. Нито едно от двете събития не изглежда отвън като промяна на разрешението за набиране.

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

TRUE разрешава набиране, FALSE го забранява, а стойност NULL означава, че акаунтът наследява отговора си от политиката за отдалечен достъп или оторизацията на NPS. GUI показва това трето състояние като "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 за отказа, вместо да се доверявате на опресняването на конзолата.

Накрая запишете кой механизъм притежава решението за всяка услуга за отдалечен достъп. Ако политиката игнорира свойствата за набиране на потребителя, груповото условие е авторитетно и атрибутът е само съвещателен за тази услуга. Две услуги в един домейн могат законно да отговарят различно и записът от прегледа трябва да го каже в един ред за всяка услуга.

Резултатът, който издържа одит, е кратък: кой може да се свързва, по кой механизъм, кога е прегледано, от кого. Флагът за набиране дава първите два отговора; останалото дава само прегледът на политиката.