Ki tárcsázhat? Az msNPAllowDialin naplózása VPN-hozzáférés előtt

A jelszó helyes, a fiók a VPN-csoportban van, a kapcsolatot mégis elutasítja egy üzenet, amely semmilyen házirendet nem említ. Amikor ez Windows távoli hozzáférési kiszolgálón történik, elsőként nem az NPS-szabályt nézem, hanem egy Active Directory-attribútumot, amelyet senki nem nyit meg: msNPAllowDialin, a Dial-in lap mögötti értéket. Három állapota van, és a harmadik csendben máshová adja a döntést. Legtöbbször senki nem változtatta meg szándékosan: a fiókot sablonból klónozták, vagy olyan szkript hozta létre, amely évekkel ezelőtt kifejezett tiltást írt, és soha nem vizsgálták felül.

Az elutasítás már a házirend olvasása előtt megtörténhet

A Windows a fiók tárcsázási engedélyét az engedélyezési döntés felépítése közben ellenőrzi, ezért egy kifejezett tiltás korán lezárja a beszélgetést. Amit az ügyfélen lát, az általános hitelesítési hiba, néha a tanúsítványcsere befejezése után, és ezért töltenek az emberek egy délutánt olyan hitelesítő adatok tesztelésével, amelyek soha nem voltak a probléma.

A fordított eset ugyanolyan zavaró. Egy fiók, amelyen a jelzőt soha nem állították be, sikeresen csatlakozhat, mert a házirend engedélyezte, majd ugyanaz a fiók abbahagyja a csatlakozást, amikor valaki egy nem kapcsolódó okból szerkeszti az NPS-szabályt. Egyik esemény sem látszik kívülről a tárcsázási engedély változásának.

Három állapot, és a harmadik láthatatlan

TRUE engedélyezi a tárcsázást, FALSE megtagadja, és egy NULL érték azt jelenti, hogy a fiók a válaszát a távoli hozzáférési házirendből vagy az NPS-engedélyezésből örökli. A GUI ezt a harmadik állapotot "Control access through NPS Network Policy" néven jeleníti meg, és inkább bejelöletlen jelölőnégyzetnek, mint döntésnek olvasható.

Ezért az engedélyezett felhasználók konzolról való megszámolása szinte semmit nem mond. Egy örökölt fiók ma engedélyezett, holnap megtagadott lehet anélkül, hogy a fiókhoz nyúlnának, és egy FALSE fiók továbbra is csatlakozhat olyan kiszolgálón, amelynek házirendje figyelmen kívül hagyja a felhasználó tárcsázási tulajdonságait. Olvassa együtt az attribútumot és a házirendet, különben egy döntés felét auditálja.

Exportálja a jelzőket az örökölt fiókok elvesztése nélkül

Futtassa az exportot tartományvezérlőn vagy Active Directory-modullal rendelkező munkaállomáson, és őrizze meg a nyers fájlt bizonyítékként ahelyett, hogy újraírna egy összefoglalót:

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

Egyetlen LDAP-szűrőt könnyebb beilleszteni egy változási rekordba. Ez csak a kifejezett engedélyeket adja vissza:

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

Ezután kérdezzen újra a tárcsázási záradék nélkül, és keressen olyan fiókokat, amelyek értéke hiányzik. Ezek az örököltek, általában a tartomány legnagyobb csoportja, és ha kihagyja őket, az audit a néhány ember listájává válik, akiket valaki emlékezett kézzel beállítani.

Válassza el a jelzőt a csoport-hozzáféréstől és a fiók állapotától

Az attribútum egy kérdésre válaszol: tárcsázhat-e ez a fiók. Semmit nem mond arról, hogy a személy még itt dolgozik-e, a fiók engedélyezett-e, vagy hogy egy megosztott jelszó lapul-e egy ügyfélszolgálati feljegyzésben. Párosítsa az exportot az engedélyezési állapottal, az utolsó bejelentkezés dátumával és azzal a csoporttagsággal, amely hozzáférést ad a kiszolgálóhoz.

A kombinációk azok, amelyekre cselekszik. Egy letiltott fiók TRUE értékkel csak zaj. Egy engedélyezett fiók TRUE értékkel, amely egy éve nem jelentkezett be, eltávolítási jelölt. Egy örökölt fiók a VPN-csoportban, amelyet senki nem tud megmagyarázni, az az igazi lelet, mert egyetlen beállítás sem rögzíti, miért adták.

Olvassa azt a tartományvezérlőről, amely ellen a VPN-kiszolgáló valóban hitelesít. A replikációs késés olyan értéket mutathat, amelyet a kiszolgáló már lecserélt, és az elavult DC-értékre hivatkozó audit ellenállásba ütközik abban a pillanatban, amikor valaki újra megnézi.

Módosítson egy fiókot, és bizonyítsa, hogy a változás megérkezett

A hozzáférés eltávolításához állítsa az attribútumot FALSE értékre a törlése helyett. A törlés visszaadja a fiókot a házirend-öröklésnek, amely a következő kapcsolatnál újra engedélyezheti, és a változás javításnak látszik, miközben valójában más döntés:

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

A második sor az öröklés visszaállítása, szándékosan külön tartva, hogy senki ne keverje össze a két műveletet. Ezután erősítse meg egy második munkamenetből, olvassa újra az attribútumot, és az elutasítás miatt ellenőrizze az NPS-elszámolási eseményeket ahelyett, hogy a konzol frissítésében bízna.

Végül írja le, melyik mechanizmus birtokolja a döntést minden távoli hozzáférési szolgáltatásnál. Ha a házirend figyelmen kívül hagyja a felhasználó tárcsázási tulajdonságait, a csoportfeltétel a mérvadó, és az attribútum csak tanácsadó érvényű arra a szolgáltatásra. Két szolgáltatás ugyanabban a tartományban jogosan válaszolhat másként, és a felülvizsgálati jegyzőkönyvnek ezt szolgáltatásonként egy sorban kell rögzítenie.

Az auditot túlélő kimenet rövid: ki csatlakozhat, milyen mechanizmus szerint, mikor vizsgálták felül, ki által. A tárcsázási jelző adja az első két választ; a többit csak a házirend felülvizsgálata adja.