Кој смее да бира? Ревизија на 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 за одбивањето, наместо да и верувате на конзолата.

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

Излезот што ја преживува ревизијата е краток: кој смее да се поврзе, по кој механизам, кога е прегледано, од кого. Знаменцето за бирање ги дава првите два одговори; остатокот го дава само прегледот на политиката.