Kdo smí vytáčet? Audit msNPAllowDialin před přístupem přes VPN

Heslo je správné, účet je ve skupině VPN a připojení je přesto odmítnuto zprávou, která nezmiňuje žádnou politiku. Když se to stane na Windows serveru vzdáleného přístupu, první místo, kam se dívám, není pravidlo NPS, ale jeden atribut Active Directory, který nikdo neotevírá: msNPAllowDialin, hodnota za kartou Dial-in. Má tři stavy a ten třetí tiše předává rozhodnutí jinam. Většinou ho nikdo nezměnil úmyslně: účet byl zkopírován ze šablony nebo ho vytvořil skript, který před lety zapsal výslovné zamítnutí a už se nikdy nepřezkoumal.

Odmítnutí může přijít dřív, než se politika přečte

Windows kontroluje oprávnění účtu k vytáčení, zatímco sestavuje rozhodnutí o autorizaci, takže výslovné zamítnutí ukončí rozhovor brzy. Na klientovi vidíte obecné selhání ověřování, někdy po dokončení výměny certifikátů, a proto lidé tráví odpoledne testováním přihlašovacích údajů, které nikdy nebyly problémem.

Opačný případ je stejně matoucí. Účet, u kterého příznak nikdy nebyl nastaven, se může úspěšně připojit, protože to politika povolila, a pak se tentýž účet přestane připojovat, když někdo z nesouvisejícího důvodu upraví pravidlo NPS. Ani jedna z těch událostí zvenčí nevypadá jako změna oprávnění k vytáčení.

Tři stavy a ten třetí je neviditelný

TRUE vytáčení povoluje, FALSE ho odmítá a NULL znamená, že účet dědí odpověď z politiky vzdáleného přístupu nebo autorizace NPS. GUI zobrazuje tento třetí stav jako "Control access through NPS Network Policy" a čte se to spíš jako nezaškrtnuté pole než jako rozhodnutí.

Proto vám počítání povolených uživatelů z konzoly neřekne téměř nic. Zděděný účet může být dnes povolen a zítra odmítnut, aniž by se ho někdo dotkl, a FALSE účet se přesto může připojit na server, jehož politika je nastavena tak, aby ignorovala vlastnosti vytáčení uživatele. Čtěte atribut a politiku společně, jinak auditujete polovinu rozhodnutí.

Vyexportujte příznaky, aniž byste ztratili zděděné účty

Spusťte export na řadiči domény nebo na pracovní stanici s modulem Active Directory a ponechte surový soubor jako důkaz, místo abyste přepisovali shrnutí:

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

Jeden filtr LDAP se do záznamu o změně vkládá snáz. Tento vrací jen výslovná povolení:

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

Pak se zeptejte znovu bez klauzule o vytáčení a hledejte účty, u kterých hodnota chybí. To jsou ty zděděné, obvykle největší skupina v doméně, a když je přeskočíte, audit se změní na seznam několika lidí, které někdo nezapomněl nastavit ručně.

Oddělte příznak od skupinového přístupu a stavu účtu

Atribut odpovídá na jednu otázku: smí tento účet vytáčet. Neříká nic o tom, zda tu člověk ještě pracuje, zda je účet povolený nebo zda v poznámce helpdesku neleží sdílené heslo. Spojte export se stavem povolení, datem posledního přihlášení a členstvím ve skupině, která dává přístup k serveru.

Jednáte podle kombinací. Zakázaný účet s TRUE je šum. Povolený účet s TRUE, který se rok nepřihlásil, je kandidátem na odebrání. Zděděný účet ve skupině VPN, který nikdo nedokáže vysvětlit, je ten skutečný nález, protože žádné jediné nastavení nezaznamenává, proč byl udělen.

Čtěte to z řadiče domény, proti kterému se server VPN skutečně ověřuje. Zpoždění replikace může ukázat hodnotu, kterou server už nahradil, a audit, který cituje zastaralou hodnotu z DC, bude napaden ve chvíli, kdy to někdo znovu zkontroluje.

Změňte jeden účet a dokažte, že změna dorazila

Chcete-li přístup odebrat, nastavte atribut na FALSE, místo abyste ho vymazali. Vymazání vrátí účet k dědění politiky, které mu může při dalším připojení znovu povolit přístup, a změna vypadá jako oprava, zatímco je ve skutečnosti jiným rozhodnutím:

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

Druhý řádek je reset dědění, záměrně oddělený, aby si nikdo nepletl dvě operace. Pak to potvrďte z druhé relace, znovu přečtěte atribut a zkontrolujte účetní události NPS kvůli odmítnutí, místo abyste věřili obnovení konzoly.

Nakonec zapište, který mechanismus vlastní rozhodnutí pro každou službu vzdáleného přístupu. Pokud politika ignoruje vlastnosti vytáčení uživatele, je směrodatná podmínka skupiny a atribut je pro tuto službu pouze doporučující. Dvě služby ve stejné doméně mohou legitimně odpovídat různě a záznam o kontrole to má uvést na jednom řádku pro každou službu.

Výstup, který přežije audit, je krátký: kdo se smí připojit, pod jakým mechanismem, kdy zkontrolováno, kým. Příznak vytáčení dodává první dvě odpovědi; zbytek dodá jen kontrola politiky.