Hvem må ringe op? Revision af msNPAllowDialin før VPN-adgang

Adgangskoden er rigtig, kontoen er i VPN-gruppen, og forbindelsen afvises stadig med en meddelelse, der slet ikke nævner nogen politik. Når det sker på en Windows-server til fjernadgang, er det første sted, jeg kigger, ikke NPS-reglen, men ét Active Directory-attribut, som ingen åbner: msNPAllowDialin, værdien bag fanen Dial-in. Den har tre tilstande, og den tredje overdrager stille beslutningen til et andet sted. Det meste af tiden har ingen ændret den med vilje: kontoen blev klonet fra en skabelon eller oprettet af et script, der skrev et udtrykkeligt afslag for år siden og aldrig blev gennemgået igen.

Afvisningen kan ske, før politikken læses

Windows kontrollerer kontoens tilladelse til at ringe op, mens den bygger autorisationsbeslutningen, så et udtrykkeligt afslag afslutter samtalen tidligt. Det, du ser på klienten, er en generisk godkendelsesfejl, nogle gange efter at certifikatudvekslingen er fuldført, og derfor bruger folk en eftermiddag på at teste legitimationsoplysninger, der aldrig var problemet.

Det omvendte tilfælde er lige så forvirrende. En konto, hvor flaget aldrig er sat, kan godt forbinde, fordi politikken tillod det, og så holder samme konto op med at forbinde, når nogen redigerer NPS-reglen af en urelateret årsag. Ingen af de to hændelser ser udefra ud som en ændring af opkaldstilladelsen.

Tre tilstande, og den tredje er usynlig

TRUE tillader opkald, FALSE afviser det, og en NULL betyder, at kontoen arver sit svar fra politikken for fjernadgang eller NPS-autorisation. GUI’en viser den tredje tilstand som "Control access through NPS Network Policy", og den læses som en umarkeret afkrydsningsboks snarere end en beslutning.

Derfor fortæller det næsten intet at tælle tilladte brugere fra konsollen. En arvet konto kan være tilladt i dag og afvist i morgen, uden at kontoen røres, og en FALSE konto kan stadig forbinde på en server, hvis politik er sat til at ignorere brugerens opkaldsegenskaber. Læs attributten og politikken sammen, ellers reviderer du halvdelen af en beslutning.

Eksportér flagene uden at tabe de arvede konti

Kør eksporten fra en domænecontroller eller fra en arbejdsstation med Active Directory-modulet, og behold den rå fil som bevis i stedet for at skrive et resumé igen:

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

Et enkelt LDAP-filter er lettere at indsætte i en ændringsregistrering. Dette returnerer kun de udtrykkelige tilladelser:

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

Forespørg så igen uden opkaldsklausulen, og led efter konti, hvor værdien mangler. Det er de arvede, normalt den største gruppe i domænet, og springer du dem over, bliver en revision til en liste over de få personer, nogen huskede at konfigurere manuelt.

Adskil flaget fra gruppeadgang og kontoens sundhed

Attributten svarer på ét spørgsmål: må denne konto ringe op. Den siger intet om, hvorvidt personen stadig arbejder her, om kontoen er aktiveret, eller om en delt adgangskode ligger i en note fra supporten. Par eksporten med aktiveringstilstanden, datoen for sidste logon og det gruppemedlemskab, der giver adgang til serveren.

Det er kombinationerne, du handler på. En deaktiveret konto med TRUE er støj. En aktiveret konto med TRUE, der ikke har logget på i et år, er kandidat til fjernelse. En arvet konto i VPN-gruppen, som ingen kan forklare, er det fund, der betyder noget, fordi ingen enkelt indstilling registrerer, hvorfor den blev givet.

Læs det fra den domænecontroller, som VPN-serveren faktisk godkender mod. Replikeringsefterslæb kan vise en værdi, som serveren allerede har erstattet, og en revision, der citerer en forældet DC-værdi, vil blive udfordret i det øjeblik, nogen tjekker igen.

Ændr én konto, og bevis at ændringen nåede frem

For at fjerne adgang skal du sætte attributten til FALSE i stedet for at rydde den. Rydning returnerer kontoen til politikarvede indstillinger, som måske tillader den igen ved næste forbindelse, og ændringen ligner en rettelse, mens den i virkeligheden er en anden beslutning:

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

Den anden linje er nulstillingen af arv, holdt adskilt med vilje, så ingen forveksler de to operationer. Bekræft derefter fra en anden session, læs attributten igen, og tjek NPS-regnskabshændelserne for afvisningen i stedet for at stole på konsollens opdatering.

Skriv til sidst ned, hvilken mekanisme der ejer beslutningen for hver fjernadgangstjeneste. Hvis politikken ignorerer brugerens opkaldsegenskaber, er gruppebetingelsen autoritativ, og attributten er kun rådgivende for den tjeneste. To tjenester i samme domæne kan med rette svare forskelligt, og revisionsnotatet bør sige det på én linje pr. tjeneste.

Det output, der overlever en revision, er kort: hvem må forbinde, under hvilken mekanisme, gennemgået hvornår, af hvem. Opkaldsflaget leverer de første to svar; kun politikgennemgangen leverer resten.