Hvem får ringe inn? Revisjon av msNPAllowDialin før VPN-tilgang

Passordet er riktig, kontoen er i VPN-gruppen, og tilkoblingen avvises likevel med en melding som ikke nevner noen policy i det hele tatt. Når det skjer på en Windows-server for ekstern tilgang, er det første stedet jeg ser ikke NPS-regelen, men ett Active Directory-attributt som ingen åpner: msNPAllowDialin, verdien bak Dial-in-fanen. Den har tre tilstander, og den tredje overlater beslutningen stille til et annet sted. Som oftest har ingen endret den med vilje: kontoen ble klonet fra en mal, eller opprettet av et skript som skrev en uttrykkelig nektelse for år siden og aldri ble gjennomgått igjen.

Avvisningen kan skje før policyen leses

Windows kontrollerer kontoens innringingstillatelse mens det bygger autorisasjonsbeslutningen, så en uttrykkelig nektelse avslutter samtalen tidlig. Det du ser på klienten, er en generisk autentiseringsfeil, noen ganger etter at sertifikatutvekslingen er fullført, og derfor bruker folk en ettermiddag på å teste påloggingsinformasjon som aldri var problemet.

Det motsatte tilfellet er like forvirrende. En konto der flagget aldri er satt, kan koble til med hell fordi policyen tillot det, og så slutter den samme kontoen å koble til når noen redigerer NPS-regelen av en urelatert grunn. Ingen av de to hendelsene ser utenfra ut som en endring av innringingstillatelsen.

Tre tilstander, og den tredje er usynlig

TRUE tillater innringing, FALSE avviser det, og en NULL betyr at kontoen arver svaret sitt fra policyen for ekstern tilgang eller NPS-autorisasjon. GUI viser den tredje tilstanden som "Control access through NPS Network Policy", og den leses som en umarkert avkrysningsboks snarere enn en beslutning.

Derfor sier det nesten ingenting å telle tillatte brukere fra konsollen. En arvet konto kan være tillatt i dag og avvist i morgen uten at kontoen røres, og en FALSE konto kan fortsatt koble til på en server der policyen er satt til å ignorere brukerens innringingsegenskaper. Les attributtet og policyen sammen, ellers reviderer du halvparten av en beslutning.

Eksporter flaggene uten å miste de arvede kontoene

Kjør eksporten fra en domenekontroller, eller fra en arbeidsstasjon med Active Directory-modulen, og behold råfilen som bevis i stedet for å skrive et sammendrag på nytt:

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

Ett enkelt LDAP-filter er lettere å lime inn i en endringsregistrering. Dette returnerer bare de uttrykkelige tillatelsene:

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

Spør så igjen uten innringingsklausulen og se etter kontoer der verdien mangler. Det er de arvede, vanligvis den største gruppen i domenet, og hopper du over dem, blir en revisjon en liste over de få personene noen husket å konfigurere for hånd.

Skill flagget fra gruppetilgang og kontotilstand

Attributtet svarer på ett spørsmål: får denne kontoen ringe inn. Det sier ingenting om hvorvidt personen fortsatt jobber her, om kontoen er aktivert, eller om et delt passord ligger i et notat fra brukerstøtten. Par eksporten med aktiveringsstatus, datoen for siste pålogging og gruppemedlemskapet som gir tilgang til serveren.

Kombinasjonene er det du handler på. En deaktivert konto med TRUE er støy. En aktivert konto med TRUE som ikke har logget på på et år, er en kandidat for fjerning. En arvet konto i VPN-gruppen som ingen kan forklare, er funnet som betyr noe, fordi ingen enkelt innstilling registrerer hvorfor den ble gitt.

Les det fra domenekontrolleren som VPN-serveren faktisk autentiserer mot. Replikasjonsforsinkelse kan vise en verdi som serveren allerede har erstattet, og en revisjon som viser til en utdatert DC-verdi, vil bli utfordret i det øyeblikket noen sjekker igjen.

Endre én konto og bevis at endringen kom frem

For å fjerne tilgang, sett attributtet til FALSE i stedet for å tømme det. Tømming returnerer kontoen til policyarving, som kan tillate den igjen ved neste tilkobling, og endringen ser ut som en rettelse mens den faktisk er en annen beslutning:

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

Den andre linjen er nullstillingen av arv, holdt atskilt med vilje slik at ingen forveksler de to operasjonene. Bekreft deretter fra en annen økt, les attributtet på nytt, og sjekk NPS-regnskapshendelsene for avvisningen i stedet for å stole på konsollens oppdatering.

Til slutt, skriv ned hvilken mekanisme som eier beslutningen for hver ekstern tilgangstjeneste. Hvis policyen ignorerer brukerens innringingsegenskaper, er gruppebetingelsen autoritativ og attributtet bare rådgivende for den tjenesten. To tjenester i samme domene kan med rette svare ulikt, og revisjonsnotatet bør si det på én linje per tjeneste.

Utdataene som overlever en revisjon, er korte: hvem som får koble til, under hvilken mekanisme, gjennomgått når, av hvem. Innringingsflagget gir de to første svarene; bare policygjennomgangen gir resten.