Kto może się dodzwonić? Audyt msNPAllowDialin przed dostępem VPN
msNPAllowDialin ma trzy stany, a NULL oddaje decyzję NPS. Wyeksportuj flagi, oddziel je od dostępu grupowego i zapisz, kto co sprawdził.
Hasło jest poprawne, konto należy do grupy VPN, a połączenie nadal jest odrzucane z komunikatem, który nie wspomina żadnej zasady. Gdy dzieje się to na serwerze dostępu zdalnego Windows, pierwszym miejscem, w które patrzę, nie jest reguła NPS, lecz jeden atrybut Active Directory, którego nikt nie otwiera: msNPAllowDialin, wartość ukryta za kartą Dial-in. Ma trzy stany, a trzeci po cichu oddaje decyzję gdzie indziej. Najczęściej nikt nie zmienił go celowo: konto sklonowano z szablonu albo utworzył je skrypt, który lata temu zapisał wyraźną odmowę i nigdy nie został ponownie sprawdzony.
Odmowa może nastąpić, zanim zasada zostanie odczytana
Windows sprawdza uprawnienie konta do dodzwaniania się, budując decyzję autoryzacyjną, więc wyraźna odmowa kończy rozmowę wcześnie. To, co widać na kliencie, to ogólny błąd uwierzytelniania, czasem po zakończeniu wymiany certyfikatów, i dlatego ludzie spędzają popołudnie na testowaniu poświadczeń, które nigdy nie były problemem.
Odwrotny przypadek jest równie mylący. Konto, na którym nigdy nie ustawiono flagi, może połączyć się z powodzeniem, bo zasada na to pozwalała, a potem to samo konto przestaje się łączyć, gdy ktoś edytuje regułę NPS z niepowiązanego powodu. Żadne z tych zdarzeń nie wygląda z zewnątrz jak zmiana uprawnienia do dodzwaniania się.
Trzy stany, a trzeci jest niewidoczny
TRUE zezwala na dodzwanianie się, FALSE odmawia, a NULL oznacza, że konto dziedziczy odpowiedź z zasady dostępu zdalnego albo autoryzacji NPS. GUI pokazuje ten trzeci stan jako "Control access through NPS Network Policy", i czyta się to raczej jak niezaznaczone pole niż decyzja.
Dlatego liczenie dozwolonych użytkowników z konsoli prawie nic nie mówi. Konto dziedziczone może być dozwolone dziś i odrzucone jutro, bez dotykania konta, a FALSE konto nadal może łączyć się z serwerem, którego zasada jest ustawiona tak, by ignorować właściwości dodzwaniania się użytkownika. Czytaj atrybut i zasadę razem, inaczej audytujesz połowę decyzji.
Wyeksportuj flagi bez utraty kont dziedziczonych
Uruchom eksport na kontrolerze domeny albo na stacji roboczej z modułem Active Directory i zachowaj surowy plik jako dowód, zamiast przepisywać podsumowanie:
Get-ADUser -Filter * -Properties msNPAllowDialin, LastLogonDate |
Select-Object SamAccountName, Enabled, msNPAllowDialin, LastLogonDate |
Sort-Object SamAccountName |
Export-Csv -NoTypeInformation .\dialin.csv
Jeden filtr LDAP łatwiej wkleić do zapisu zmiany. Ten zwraca tylko jawne zezwolenia:
dsquery * -Filter "(&(objectCategory=person)(objectClass=user)(msNPAllowDialin=TRUE))" -Attr sAMAccountName
Potem zapytaj ponownie bez klauzuli dodzwaniania się i poszukaj kont, którym brakuje wartości. To są konta dziedziczone, zwykle największa grupa w domenie, a pominięcie ich zamienia audyt w listę kilku osób, które ktoś pamiętał, by ustawić ręcznie.
Oddziel flagę od dostępu grupowego i kondycji konta
Atrybut odpowiada na jedno pytanie: czy to konto może się dodzwonić. Nie mówi nic o tym, czy osoba nadal tu pracuje, czy konto jest włączone albo czy współdzielone hasło leży w notatce pomocy technicznej. Połącz eksport ze stanem włączenia, datą ostatniego logowania i członkostwem w grupie, która daje dostęp do serwera.
Działasz na kombinacjach. Wyłączone konto z TRUE to tylko szum. Włączone konto z TRUE, które nie logowało się od roku, jest kandydatem do usunięcia. Konto dziedziczone w grupie VPN, którego nikt nie potrafi wyjaśnić, to właśnie ten istotny wynik, bo żadne pojedyncze ustawienie nie zapisuje, dlaczego je przyznano.
Czytaj to z kontrolera domeny, wobec którego serwer VPN faktycznie się uwierzytelnia. Opóźnienie replikacji może pokazać wartość, którą serwer już zastąpił, a audyt cytujący nieaktualną wartość DC zostanie zakwestionowany w chwili, gdy ktoś sprawdzi ponownie.
Zmień jedno konto i udowodnij, że zmiana dotarła
Aby odebrać dostęp, ustaw atrybut na FALSE, zamiast go czyścić. Wyczyszczenie przywraca konto do dziedziczenia zasad, które może znów je dopuścić przy następnym połączeniu, a zmiana wygląda jak poprawka, choć w rzeczywistości jest inną decyzją:
dsmod user "CN=Jane Doe,OU=Staff,DC=corp,DC=example" -allowDialin no
Set-ADUser -Identity jdoe -Clear msNPAllowDialin
Druga linia to reset dziedziczenia, celowo trzymany osobno, aby nikt nie pomylił obu operacji. Potem potwierdź z drugiej sesji, przeczytaj atrybut ponownie i sprawdź zdarzenia rozliczeniowe NPS dotyczące odmowy, zamiast polegać na odświeżeniu konsoli.
Na koniec zapisz, który mechanizm posiada decyzję dla każdej usługi dostępu zdalnego. Jeśli zasada ignoruje właściwości dodzwaniania się użytkownika, warunek grupy jest rozstrzygający, a atrybut ma charakter wyłącznie doradczy dla tej usługi. Dwie usługi w tej samej domenie mogą zgodnie z prawem odpowiadać różnie, a zapis przeglądu powinien to podać w jednej linii na usługę.
Wynik, który przetrwa audyt, jest krótki: kto może się połączyć, według jakiego mechanizmu, kiedy sprawdzono i przez kogo. Flaga dodzwaniania się daje dwie pierwsze odpowiedzi; resztę daje tylko przegląd zasady.