Kiu rajtas alvoki? Aŭdito de msNPAllowDialin antaŭ VPN-aliro

La pasvorto estas ĝusta, la konto estas en la VPN-grupo, kaj la konekto tamen estas rifuzata per mesaĝo, kiu tute ne mencias politikon. Kiam tio okazas sur Windows-servilo por fora aliro, la unua loko, kiun mi rigardas, ne estas la NPS-regulo, sed unu Active Directory-atributo, kiun neniu malfermas: msNPAllowDialin, la valoro malantaŭ la langeto Dial-in. Ĝi havas tri statojn, kaj la tria silente transdonas la decidon aliloken. Plej ofte neniu ŝanĝis ĝin intence: la konto estis klonita el ŝablono aŭ kreita de skripto, kiu antaŭ jaroj skribis eksplicitan malpermeson kaj neniam estis reviziita.

La rifuzo povas okazi antaŭ ol la politiko estas legita

Windows kontrolas la alvokan permeson de la konto dum ĝi konstruas la rajtigan decidon, do eksplicita malpermeso finas la interparolon frue. Tio, kion vi vidas sur la kliento, estas ĝenerala aŭtentiga fiasko, foje post kiam la atestila interŝanĝo finiĝis, kaj tial homoj pasigas posttagmezon testante legitimilojn, kiuj neniam estis la problemo.

La mala kazo estas same konfuza. Konto, ĉe kiu la flago neniam estis agordita, povas sukcese konektiĝi ĉar la politiko permesis tion, kaj poste la sama konto ĉesas konektiĝi, kiam iu redaktas la NPS-regulon pro nerilata kaŭzo. Neniu el la du eventoj ekstere aspektas kiel ŝanĝo de alvoka permeso.

Tri statoj, kaj la tria estas nevidebla

TRUE permesas alvokon, FALSE rifuzas ĝin, kaj NULL signifas, ke la konto heredas sian respondon el la politiko de fora aliro aŭ el la rajtigo de NPS. La GUI montras tiun trian staton kiel "Control access through NPS Network Policy", kaj ĝi legeblas kiel neagordita markobutono prefere ol decido.

Tial nombri permesitajn uzantojn el la konzolo preskaŭ nenion diras al vi. Heredita konto povas esti permesita hodiaŭ kaj rifuzita morgaŭ, sen ke iu tuŝu la konton, kaj FALSE konto ankoraŭ povas konektiĝi sur servilo, kies politiko estas agordita por ignori la alvokajn ecojn de la uzanto. Legu la atributon kaj la politikon kune, alie vi aŭditas duonon de decido.

Eksportu la flagojn sen perdi la hereditajn kontojn

Rulu la eksporton de domajna regilo aŭ de laborstacio kun la Active Directory-modulo, kaj konservu la krudan dosieron kiel pruvon anstataŭ retajpi resumon:

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

Unu sola LDAP-filtro pli facile algluiĝas en ŝanĝregistron. Ĉi tiu redonas nur la eksplicitajn permesojn:

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

Poste denove demandu sen la alvoka kondiĉo kaj serĉu kontojn, kies valoro mankas. Tiuj estas la hereditaj, kutime la plej granda grupo en la domajno, kaj preterpasi ilin transformas aŭditon en liston de la malmultaj homoj, kiujn iu memoris agordi permane.

Apartigu la flagon de grupa aliro kaj de la sano de la konto

La atributo respondas unu demandon: ĉu ĉi tiu konto rajtas alvoki. Ĝi diras nenion pri tio, ĉu la persono ankoraŭ laboras ĉi tie, ĉu la konto estas ebligita aŭ ĉu komuna pasvorto kuŝas en noto de la subtena servo. Parigu la eksporton kun la ebliga stato, la dato de la lasta saluto kaj la grupa membreco, kiu donas aliron al la servilo.

La kombinaĵoj estas tio, sur kio vi agas. Malŝaltita konto kun TRUE estas bruo. Ŝaltita konto kun TRUE, kiu ne salutis dum jaro, estas kandidato por forigo. Heredita konto en la VPN-grupo, kiun neniu povas klarigi, estas la trovaĵo, kiu gravas, ĉar neniu unuopa agordo registras, kial ĝi estis donita.

Legu ĝin de la domajna regilo, kontraŭ kiu la VPN-servilo efektive aŭtentigas. Reprodukta malfruo povas montri valoron, kiun la servilo jam anstataŭigis, kaj aŭdito, kiu citas eksvalidiĝintan DC-valoron, estos defiita en la momento, kiam iu kontrolos denove.

Ŝanĝu unu konton kaj pruvu, ke la ŝanĝo alvenis

Por forigi aliron, agordu la atributon al FALSE anstataŭ viŝi ĝin. Viŝado resendas la konton al politika heredado, kiu eble permesos ĝin denove ĉe la sekva konekto, kaj la ŝanĝo aspektas kiel riparo, dum ĝi efektive estas malsama decido:

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

La dua linio estas la restarigo de heredado, intence tenita aparte, por ke neniu konfuzu la du operaciojn. Poste konfirmu el dua sesio, relegu la atributon kaj kontrolu la NPS-kontadajn eventojn por la rifuzo anstataŭ fidi la refreŝigon de la konzolo.

Fine, notu, kiu mekanismo posedas la decidon por ĉiu fora-alira servo. Se la politiko ignoras la alvokajn ecojn de la uzanto, la grupa kondiĉo estas aŭtoritata kaj la atributo estas nur konsila por tiu servo. Du servoj en la sama domajno povas legitime respondi malsame, kaj la revizia registro devus tion diri per unu linio por servo.

La produktaĵo, kiu postvivas aŭditon, estas mallonga: kiu rajtas konektiĝi, sub kiu mekanismo, reviziita kiam, de kiu. La alvoka flago donas la unuajn du respondojn; nur la revizio de la politiko donas la reston.