Wie mag inbel? Oudit van msNPAllowDialin voor VPN-toegang

Die wagwoord is reg, die rekening is in die VPN-groep, en die verbinding word steeds geweier met ’n boodskap wat geen beleid noem nie. Wanneer dit op ’n Windows-afstandtoegangbediener gebeur, is die eerste plek waar ek kyk nie die NPS-reël nie, maar een Active Directory-kenmerk wat niemand oopmaak nie: msNPAllowDialin, die waarde agter die Inbel-oortjie. Dit het drie toestande, en die derde een gee die besluit stilweg aan iets anders oor. Meestal het niemand dit doelbewus verander nie: die rekening is van ’n sjabloon gekloon, of deur ’n script ingerig wat jare gelede ’n eksplisiete weiering geskryf het en nooit weer hersien is nie.

Die weiering kan plaasvind voordat die beleid gelees word

Windows kontroleer die rekening se inbeltoestemming terwyl dit die magtigingsbesluit opbou, so ’n eksplisiete weiering beëindig die gesprek vroeg. Wat jy op die kliënt sien, is ’n generiese verifikasiefout, soms nadat die sertifikaatuitruiling voltooi is, en daarom spandeer mense ’n middag daaraan om geloofsbriewe te toets wat nooit die probleem was nie.

Die omgekeerde geval is net so verwarrend. ’n Rekening wat nooit die vlag gehad het nie, kan suksesvol verbind omdat die beleid dit toegelaat het, en dan hou dieselfde rekening op om te verbind wanneer iemand die NPS-reël om ’n onverwante rede wysig. Nie een van die twee gebeure lyk van buite soos ’n verandering aan inbeltoestemming nie.

Drie toestande, en die derde een is onsigbaar

TRUE laat inbel toe, FALSE weier dit, en ’n NULL waarde beteken die rekening erf sy antwoord van afstandtoegangsbeleid of NPS-magtiging. Die GUI wys daardie derde toestand as "Control access through NPS Network Policy", en dit lyk soos ’n oop merkkassie eerder as ’n besluit.

Daarom sê dit byna niks om toegelate gebruikers uit die konsole te tel nie. ’n Geërfde rekening kan vandag toegelaat en môre geweier word sonder dat die rekening aangeraak word, en ’n FALSE rekening kan steeds verbind op ’n bediener waarvan die beleid ingestel is om gebruikers se inbel-eienskappe te ignoreer. Lees die kenmerk en die beleid saam, anders oudit jy net die helfte van ’n besluit.

Voer die vlae uit sonder om die geërfde rekeninge te laat val

Voer die uitvoer vanaf ’n domeinbeheerder uit, of vanaf ’n werkstasie met die Active Directory-module, en hou die rou lêer as bewyse eerder as om ’n opsomming oor te tik:

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

Een LDAP-filter is makliker om in ’n veranderingsrekord te plak. Hierdie een gee net die eksplisiete toestemmings terug:

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

Vra dan weer sonder die inbel-klousule en soek rekeninge wie se waarde afwesig is. Dit is die geërfde rekeninge, gewoonlik die grootste groep in die domein, en as jy hulle oorslaan, word ’n oudit ’n lys van die paar mense wat iemand onthou het om met die hand op te stel.

Skei die vlag van groeptoegang en rekeninggesondheid

Die kenmerk antwoord op een vraag: mag hierdie rekening inbel. Dit sê niks oor of die persoon steeds hier werk nie, of die rekening geaktiveer is, of daar ’n gedeelde wagwoord in ’n helpdesk-nota lê nie. Pas die uitvoer saam met die geaktiveerde toestand, die laaste aanmeldingdatum en die groepildmaatskap wat toegang tot die bediener gee.

Die kombinasies is waarop jy reageer. ’n Gedeaktiveerde rekening met TRUE is geraas. ’n Geaktiveerde rekening met TRUE wat ’n jaar lank nie aangemeld het nie, is ’n kandidaat vir verwydering. ’n Geërfde rekening in die VPN-groep wat niemand kan verduidelik nie, is die bevinding wat saak maak, want geen enkele instelling teken aan waarom dit toegestaan is nie.

Lees dit van die domeinbeheerder waarteen die VPN-bediener werklik verifieer. Replikasie-agterstand kan ’n waarde wys wat die bediener reeds vervang het, en ’n oudit wat ’n verouderde DC-waarde aanhaal, sal betwis word sodra iemand weer kyk.

Verander een rekening en bewys dat die verandering deurgekom het

Om toegang te verwyder, stel die kenmerk op FALSE in plaas daarvan om dit skoon te maak. Skoonmaak laat die rekening na beleidserfenis terugkeer, wat dit dalk by die volgende verbinding weer toelaat, en die verandering lyk soos ’n regstelling terwyl dit eintlik ’n ander besluit is:

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

Die tweede reël is die herstel van erfenis, doelbewus apart gehou sodat niemand die twee bewerkings verwar nie. Bevestig dan uit ’n tweede sessie, lees die kenmerk weer, en kyk na die NPS-rekeningkundige gebeure vir die weiering eerder as om die konsole se herlaai te vertrou.

Skryf laastens neer watter meganisme die besluit vir elke afstandtoegangdiens besit. As die beleid gebruikers se inbel-eienskappe ignoreer, is die groeptoestand gesaghebbend en is die kenmerk net vir daardie diens raadgewend. Twee dienste op dieselfde domein kan wettig verskillend antwoord, en die hersieningsrekord moet dit in een reël per diens sê.

Die uitset wat ’n oudit oorleef, is kort: wie mag verbind, onder watter meganisme, wanneer nagegaan, deur wie. Die inbelvlag lewer die eerste twee antwoorde; net die beleidshersiening lewer die res.