Kven får ringje inn? Revisjon av msNPAllowDialin før VPN-tilgang

msNPAllowDialin har tre tilstandar, og ein NULL overlèt avgjerda til NPS. Eksporter flagga, skil dei frå gruppetilgang, og noter kven som gjekk gjennom kva.

Passordet er rett, kontoen er i VPN-gruppa, og tilkoplinga blir likevel avvist med ei melding som ikkje nemner noko policy i det heile. Når det skjer på ein Windows-tenar for fjernåtkomst, er den første staden eg ser ikkje NPS-regelen, men eitt Active Directory-attributt som ingen opnar: msNPAllowDialin, verdien bak Dial-in-fana. Han har tre tilstandar, og den tredje overlèt avgjerda stille til ein annan stad. Som oftast har ingen endra han med vilje: kontoen vart klona frå ein mal, eller oppretta av eit skript som skreiv ei uttrykkeleg avvising for år sidan og aldri vart gått gjennom igjen.

Avvisinga kan skje før policyen blir lesen

Windows kontrollerer innringingstilgangen til kontoen medan det byggjer autorisasjonsavgjerda, så ei uttrykkeleg avvising avsluttar samtalen tidleg. Det du ser på klienten, er ein generisk autentiseringsfeil, av og til etter at sertifikatutvekslinga er fullført, og difor brukar folk ein ettermiddag på å teste innloggingsinformasjon som aldri var problemet.

Det motsette tilfellet er like forvirrande. Ein konto der flagget aldri er sett, kan kopla til med hell fordi policyen tillét det, og så sluttar den same kontoen å kopla til når nokon redigerer NPS-regelen av ein urelatert grunn. Ingen av dei to hendingane ser utanfrå ut som ei endring av innringingstilgangen.

Tre tilstandar, og den tredje er usynleg

TRUE tillèt innringing, FALSE avviser det, og ein NULL tyder at kontoen arvar svaret sitt frå policyen for fjernåtkomst eller NPS-autorisasjon. GUI viser den tredje tilstanden som "Control access through NPS Network Policy", og han blir lesen som ein umerkt avkryssingsboks snarare enn ei avgjerd.

Difor seier det nesten ingenting å telje tillatne brukarar frå konsollen. Ein arva konto kan vere tillaten i dag og avvist i morgon utan at kontoen blir rørt, og ein FALSE konto kan framleis kopla til på ein tenar der policyen er sett til å ignorere innringingseigenskapane til brukaren. Les attributtet og policyen saman, elles reviderer du halvparten av ei avgjerd.

Eksporter flagga utan å miste dei arva kontoane

Køyr eksporten frå ein domenekontrollar, eller frå ein arbeidsstasjon med Active Directory-modulen, og ta vare på råfila som prov i staden for å skrive eit samandrag på nytt:

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

Eitt enkelt LDAP-filter er lettare å lime inn i ein endringsregistrering. Dette returnerer berre dei uttrykkelege løyva:

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

Spør så igjen utan innringingsklausulen og sjå etter kontoar der verdien manglar. Det er dei arva, vanlegvis den største gruppa i domenet, og hoppar du over dei, blir ein revisjon ei liste over dei få personane nokon hugsa å setje opp for hand.

Skil flagget frå gruppetilgang og kontotilstand

Attributtet svarar på eitt spørsmål: får denne kontoen ringje inn. Det seier ingenting om personen framleis arbeider her, om kontoen er aktivert, eller om eit delt passord ligg i eit notat frå brukarstøtta. Para eksporten med aktiveringsstatus, datoen for siste pålogging og gruppemedlemskapet som gir tilgang til tenaren.

Kombinasjonane er det du handlar på. Ein deaktivert konto med TRUE er støy. Ein aktivert konto med TRUE som ikkje har logga på på eitt år, er ein kandidat for fjerning. Ein arva konto i VPN-gruppa som ingen kan forklare, er funnet som betyr noko, fordi ingen einskild innstilling registrerer kvifor han vart gitt.

Les det frå domenekontrollaren som VPN-tenaren faktisk autentiserer mot. Replikasjonsforsinking kan vise ein verdi som tenaren allereie har erstatta, og ein revisjon som viser til ein utdatert DC-verdi, blir utfordra i det augeblikket nokon sjekkar igjen.

Endre éin konto og prov at endringa kom fram

For å fjerne tilgang, set attributtet til FALSE i staden for å tømme det. Tømming returnerer kontoen til policyarving, som kan tillate han igjen ved neste tilkopling, og endringa ser ut som ei retting medan ho faktisk er ei anna avgjerd:

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

Den andre linja er nullstillinga av arv, halden åtskild med vilje slik at ingen forvekslar dei to operasjonane. Stadfest deretter frå ein annan økt, les attributtet på nytt, og sjekk NPS-rekneskapshendingane for avvisinga i staden for å stole på oppdateringa i konsollen.

Til slutt, skriv ned kva mekanisme som eig avgjerda for kvar fjernåtkomstteneste. Viss policyen ignorerer innringingseigenskapane til brukaren, er gruppevilkåret autoritativt og attributtet berre rådgivande for den tenesta. To tenester i same domene kan med rette svare ulikt, og revisjonsnotatet bør seie det på éi linje per teneste.

Utdataa som overlever ein revisjon, er korte: kven som får kopla til, under kva mekanisme, gått gjennom når, av kven. Innringsflagget gir dei to første svara; berre policygjennomgangen gir resten.

Relaterte artiklar