Cine poate apela? Auditul msNPAllowDialin înainte de accesul VPN

Parola este corectă, contul este în grupul VPN, iar conexiunea este totuși refuzată cu un mesaj care nu menționează nicio politică. Când se întâmplă pe un server de acces la distanță Windows, primul loc unde mă uit nu este regula NPS, ci un atribut Active Directory pe care nimeni nu îl deschide: msNPAllowDialin, valoarea din spatele filei Dial-in. Are trei stări, iar a treia predă discret decizia altundeva. De cele mai multe ori nimeni nu l-a schimbat intenționat: contul a fost clonat dintr-un șablon sau creat de un script care a scris o interdicție explicită acum ani și nu a mai fost revizuit.

Refuzul poate apărea înainte ca politica să fie citită

Windows verifică permisiunea de apelare a contului în timp ce construiește decizia de autorizare, așa că o interdicție explicită încheie conversația devreme. Ceea ce vedeți pe client este o eroare generică de autentificare, uneori după ce schimbul de certificate s-a încheiat, și de aceea oamenii petrec o după-amiază testând credențiale care nu au fost niciodată problema.

Cazul invers este la fel de confuz. Un cont la care indicatorul nu a fost niciodată setat se poate conecta cu succes pentru că politica permitea, iar apoi același cont încetează să se conecteze când cineva editează regula NPS dintr-un motiv fără legătură. Niciunul dintre cele două evenimente nu arată din exterior ca o schimbare a permisiunii de apelare.

Trei stări, iar a treia este invizibilă

TRUE permite apelarea, FALSE o refuză, iar un NULL înseamnă că contul moștenește răspunsul din politica de acces la distanță sau din autorizarea NPS. Interfața afișează acea a treia stare ca "Control access through NPS Network Policy", iar ea se citește mai degrabă ca o casetă nebifată decât ca o decizie.

De aceea numărarea utilizatorilor permisiți din consolă nu spune aproape nimic. Un cont moștenit poate fi permis azi și refuzat mâine fără ca nimeni să atingă contul, iar un FALSE se poate conecta în continuare pe un server a cărui politică este configurată să ignore proprietățile de apelare ale utilizatorului. Citiți atributul și politica împreună, altfel auditați jumătate dintr-o decizie.

Exportați indicatorii fără a pierde conturile moștenite

Rulați exportul de pe un controler de domeniu, sau de pe o stație de lucru cu modulul Active Directory, și păstrați fișierul brut ca dovadă în loc să rescrieți un rezumat:

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

Un singur filtru LDAP este mai ușor de lipit într-o înregistrare de modificare. Acesta returnează doar permisiunile explicite:

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

Apoi interogați din nou fără clauza de apelare și căutați conturile cărora le lipsește valoarea. Acelea sunt cele moștenite, de obicei cel mai mare grup din domeniu, iar omiterea lor transformă un audit într-o listă cu puținii oameni pe care cineva și-a amintit să îi configureze manual.

Separați indicatorul de accesul pe grupuri și de starea contului

Atributul răspunde la o singură întrebare: poate acest cont să apeleze. Nu spune nimic despre dacă persoana mai lucrează aici, dacă contul este activat sau dacă o parolă partajată stă într-o notă a serviciului de asistență. Asociați exportul cu starea de activare, data ultimei autentificări și apartenența la grupul care acordă acces la server.

Combinațiile sunt cele pe care acționați. Un cont dezactivat cu TRUE este doar zgomot. Un cont activat cu TRUE care nu s-a autentificat de un an este candidat la eliminare. Un cont moștenit din grupul VPN pe care nimeni nu îl poate explica este constatarea care contează, pentru că nicio setare unică nu înregistrează de ce a fost acordat.

Citiți-l de pe controlerul de domeniu față de care serverul VPN se autentifică efectiv. Întârzierea replicării poate arăta o valoare pe care serverul a înlocuit-o deja, iar un audit care citează o valoare DC învechită va fi contestat în momentul în care cineva verifică din nou.

Modificați un cont și demonstrați că modificarea a ajuns

Pentru a retrage accesul, setați atributul la FALSE în loc să îl goliți. Golirea readuce contul la moștenirea politicii, care îl poate permite din nou la următoarea conexiune, iar modificarea pare o corectare deși în realitate este o decizie diferită:

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

A doua linie este resetarea moștenirii, ținută separat intenționat pentru ca nimeni să nu confunde cele două operațiuni. Apoi confirmați dintr-o a doua sesiune, recitiți atributul și verificați evenimentele de contabilitate NPS pentru refuz în loc să vă bazați pe reîmprospătarea consolei.

În final, notați care mecanism deține decizia pentru fiecare serviciu de acces la distanță. Dacă politica ignoră proprietățile de apelare ale utilizatorului, condiția de grup este autoritară și atributul este doar consultativ pentru acel serviciu. Două servicii din același domeniu pot răspunde legitim diferit, iar înregistrarea revizuirii ar trebui să spună asta pe o linie pentru fiecare serviciu.

Rezultatul care supraviețuiește unui audit este scurt: cine se poate conecta, prin ce mecanism, când a fost revizuit și de către cine. Indicatorul de apelare oferă primele două răspunsuri; doar revizuirea politicii oferă restul.