Wie mag inbellen? Audit van msNPAllowDialin vóór VPN-toegang

Het wachtwoord klopt, het account zit in de VPN-groep, en de verbinding wordt toch geweigerd met een melding die geen enkel beleid noemt. Als dat gebeurt op een Windows-server voor externe toegang, is de eerste plek waar ik kijk niet de NPS-regel maar één Active Directory-kenmerk dat niemand opent: msNPAllowDialin, de waarde achter het tabblad Dial-in. Het heeft drie statussen, en de derde draagt de beslissing stil over aan een andere plek. Meestal heeft niemand het met opzet gewijzigd: het account is gekloond van een sjabloon, of aangemaakt door een script dat jaren geleden een expliciete weigering schreef en nooit opnieuw is bekeken.

De weigering kan optreden voordat het beleid wordt gelezen

Windows controleert de inbelrechten van het account terwijl het de autorisatiebeslissing opbouwt, dus een expliciete weigering beëindigt het gesprek vroeg. Wat je op de client ziet is een algemene verificatiefout, soms nadat de certificaatuitwisseling is voltooid, en daarom besteden mensen een middag aan het testen van inloggegevens die nooit het probleem waren.

Het omgekeerde geval is net zo verwarrend. Een account waarop de vlag nooit is gezet kan met succes verbinden omdat het beleid het toestond, en dan stopt hetzelfde account met verbinden wanneer iemand de NPS-regel om een niet-verwante reden aanpast. Geen van beide gebeurtenissen ziet er van buitenuit uit als een wijziging van de inbelrechten.

Drie statussen, en de derde is onzichtbaar

TRUE staat inbellen toe, FALSE weigert het, en een NULL betekent dat het account zijn antwoord erft van het beleid voor externe toegang of van NPS-autorisatie. De GUI toont die derde status als "Control access through NPS Network Policy", en het leest als een niet-aangevinkt vakje in plaats van een beslissing.

Daarom zegt het bijna niets om toegestane gebruikers uit de console te tellen. Een geërfd account kan vandaag toegestaan en morgen geweigerd zijn zonder dat het account wordt aangeraakt, en een FALSE account kan nog steeds verbinden op een server waarvan het beleid is ingesteld om de inbeleigenschappen van de gebruiker te negeren. Lees het kenmerk en het beleid samen, anders controleer je de helft van een beslissing.

Exporteer de vlaggen zonder de geërfde accounts te verliezen

Voer de export uit op een domeincontroller, of op een werkstation met de Active Directory-module, en bewaar het ruwe bestand als bewijs in plaats van een samenvatting over te typen:

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

Eén LDAP-filter is makkelijker in een wijzigingsrecord te plakken. Deze geeft alleen de expliciete toestemmingen terug:

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

Vraag daarna opnieuw zonder de inbelclausule en zoek accounts waarvan de waarde ontbreekt. Dat zijn de geërfde, meestal de grootste groep in het domein, en als je ze overslaat wordt een audit een lijst van de weinige mensen die iemand nog handmatig had ingesteld.

Scheid de vlag van groepstoegang en van de gezondheid van het account

Het kenmerk beantwoordt één vraag: mag dit account inbellen. Het zegt niets over of de persoon hier nog werkt, of het account is ingeschakeld, of er een gedeeld wachtwoord in een helpdesknotitie staat. Koppel de export aan de inschakelstatus, de datum van de laatste aanmelding en het groepslidmaatschap dat toegang tot de server geeft.

De combinaties zijn waarop je handelt. Een uitgeschakeld account met TRUE is ruis. Een ingeschakeld account met TRUE dat een jaar niet heeft aangemeld is een kandidaat voor verwijdering. Een geërfd account in de VPN-groep dat niemand kan verklaren is de bevinding die ertoe doet, omdat geen enkele instelling vastlegt waarom het is toegekend.

Lees het van de domeincontroller waartegen de VPN-server daadwerkelijk verifieert. Replicatievertraging kan een waarde tonen die de server al heeft vervangen, en een audit die een verouderde DC-waarde citeert wordt betwist op het moment dat iemand opnieuw kijkt.

Wijzig één account en bewijs dat de wijziging is aangekomen

Om toegang in te trekken zet je het kenmerk op FALSE in plaats van het te wissen. Wissen brengt het account terug naar beleidsovererving, wat het bij de volgende verbinding weer kan toestaan, en de wijziging lijkt een correctie terwijl het in werkelijkheid een andere beslissing is:

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

De tweede regel is het resetten van de overerving, bewust apart gehouden zodat niemand de twee bewerkingen verwart. Bevestig daarna vanuit een tweede sessie, lees het kenmerk opnieuw en controleer de NPS-accountinggebeurtenissen op de weigering in plaats van de consoleverversing te vertrouwen.

Schrijf ten slotte op welk mechanisme de beslissing bezit voor elke service voor externe toegang. Als het beleid de inbeleigenschappen van de gebruiker negeert, is de groepsconditie gezaghebbend en is het kenmerk alleen adviserend voor die service. Twee services in hetzelfde domein kunnen legitiem verschillend antwoorden, en het beoordelingsverslag zou dat in één regel per service moeten vermelden.

De output die een audit overleeft is kort: wie mag verbinden, onder welk mechanisme, wanneer beoordeeld, door wie. De inbelvlag levert de eerste twee antwoorden; alleen de beleidsbeoordeling levert de rest.