Active Directory upublicznione zostało w 1999 roku. Jest więc znane i powszechnie używane już od ponad 20 lat. Choć wiedza na jego temat jest szeroko dostępna w Internecie, są informacje, do których dotrzeć znacznie trudniej. Możemy się z nimi zapoznać, kiedy wejdziemy głębiej w konkretny temat. Kilka z takich przydatnych ciekawostek, które odkryłam na drodze mojego doświadczenia zawodowego z Active Directory chciałabym tutaj przedstawić.
Widoczność atrybutów obiektu
Rozszerzając treść tytułu: atrybuty obiektu są widoczne, kiedy wyszukujemy go przez grupę/managera, a ukryte, gdy szukamy przez funkcję „Find” w ADUC (Active Directory Users and Computers).
Używając przystawki ADUC, możemy zobaczyć właściwości obiektów znajdujących się w Active Directory. Jeśli włączymy „Advanced Features” widzimy również zakładkę „Attribute Editor”. Jednak szukanie obiektu ręcznie w rozbudowanej strukturze jednostek organizacyjnych nie jest zazwyczaj najszybszym rozwiązaniem, więc warto skorzystać z narzędzia wyszukiwania obiektów.
Niestety, stwarza to drobny problem, ponieważ w przypadku wyszukania obiektu przez „Find”, zakładka „Attribute Editor” nie jest widoczna:

Ryc. 1 Brak zakładki „Attribute Editor” we właściwościach użytkownika wyszukanego przez „Find Users, Contacts and Groups”
Jeśli jednak otworzymy jedną z grup, do których należy użytkownik i z niej wybierzemy jego profil, to zakładka „Attribute Editor” się pojawi:

Ryc. 2 Zakładka „Attribute Editor” widoczna we właściwościach użytkownika wyszukanego przez grupę
Tak samo sytuacja wygląda, gdy wybierzemy użytkownika znajdującego się w polu „Direct reports” lub „Manager”:

Ryc. 3 Zakładka „Attribute Editor” widoczna we właściwościach użytkownika wyszukanego przez „Direct reports” innego użytkownika
Sprawdzenie statusu Zapory Sieciowej
Precyzując: sprawdzenie statusu Zapory Sieciowej komendą „netsh advfirewall” pokazuje ustawienia lokalne maszyny, a przez GUI (Graphical User Interface) połączone (lokalne + domenowe).
Zapora Systemu Windows przechowuje dwa typy konfiguracji – lokalną i zasad grupy. Komenda netsh advfirewall show allprofiles pokazuje ustawienia lokalne.
W przypadku naszego testowego środowiska wskazuje, że zapora jest wyłączona:

Ryc. 4 Komenda „netsh advfirewall show allprofiles state” pokazująca status zapory jako wyłączony
Dla odmiany w Panelu Sterowania widnieje informacja, że Zapora Systemu Windows jest włączona:

Ryc. 5 Panel Sterowania pokazujący status zapory jako włączony
Dzieje się tak, ponieważ w Zasadach Grupy (GPO) podpiętych do tego komputera Windows Firewall został włączony. Panel Sterowania pokazuje rezultat połączonych ustawień lokalnych i zasad grupy. Oczywiście, ustawienia GPO mają priorytet, więc ostatecznym wynikiem jest włączona zapora.
Można również wykorzystać komendę Get-NetFirewallProfile – standardowo wyświetla ona ustawienia lokalne:

Ryc. 6 Komenda „Get-NetFirewallProfile” pokazująca status zapory jako wyłączony
Jednak z przełącznikiem „ActiveStore” widzimy łączne ustawienia lokalne i domenowe jak w przypadku GUI:

Ryc. 7 Komenda „Get-NetFirewallProfile -PolicyStore ActiveStore” pokazująca status zapory jako włączony
Usuwanie obiektów z kosza
Kiedy mierzymy się z aspektem usuwania obiektów z kosza, jest to niemożliwe przez GUI, ale wykonalne przez Powershell. Z nieznanego mi powodu nie da się usunąć obiektów z kosza w Active Directory poprzez interfejs graficzny:

Ryc. 8 Kosz Active Directory z nieaktywnym polem „delete”
Można to jednak zrobić z użyciem Powershella np. używając komendy:
Get-ADObject -Filter {isDeleted -eq $True -and Name -like '*Test*'} -IncludeDeletedObjects| Remove-ADObject

Ryc. 9 Komenda „Remove-ADObject” użyta w celu usunięcia obiektu z kosza
Seize ról FSMO
Wspomniany w tytule Seize ról FSMO najpierw próbuje wykonać transfer, a dopiero po nieudanej próbie przechodzi do przechwytywania. Narzędzie ntsdutil usiłuje wykonać transfer, nawet jeśli użyliśmy parametru seize.
Dopiero kiedy transfer się nie uda, wykonywane jest przechwycenie roli:

Ryc. 10 Komenda „ntdsutil” próbujący wykonać transfer przed przechwyceniem roli
Dodatkowa porada: w przypadku wykonywania operacji przechwytywania roli RID Master zalecane jest użycie komendy Powershell Move-ADDirectoryServerOperationMasterRole zamiast ntdsutil.
Przyczyną takich zaleceń jest fakt, że narzędzie ntdsutil zwiększa następny dostępny identyfikator RID w puli o 10 000 po przechwyceniu roli w celu uniknięcia duplikatów SID-ów w domenie. Potencjalnie może to spowodować tak zwany „RID burn” czyli zużycie całego dostępnego zakresu wartości RID w lesie. Natomiast w przypadku komendy Powershell nie jest zwiększany następny dostępny identyfikator RID więc zjawisko to nie występuje.
Pobieranie biletu Kerberosowego
Wymuszenie pobierania biletu Kerberosowego z wybranego Kontrolera Domeny wiąże się z komendą klist add_bind, pozwalającą na określenie preferowanego kontrolera domeny dla autentykacji Kerberosowej. Standardowo kontroler domeny wybierany jest automatycznie.
Po użyciu komendy klist add_bind określony kontroler domeny zostaje zapisany na liście preferowanych kontrolerów domeny. Listę możemy podejrzeć poleceniem klist query_bind:

Ryc. 11 Komenda „klist add_bind” użyta w celu zapisania kontrolera domeny na liście preferowanych kontrolerów domeny
Jak widać, przy okazji pobierania nowego biletu zapytanie zostało wysłane do określonego kontrolera domeny, który następnie dostarczył klientowi bilet.
Podsumowanie
Mam nadzieję, że przedstawione w tym artykule informacje okażą się dla was przydatne. Pewnie część z nich (lub nawet wszystkie) jest już wam znana, ale myślę, że dla wielu osób będą to nowe i przydatne informacje.
Dla mnie najbardziej użyteczne w codziennej pracy jest otwieranie obiektów przez grupę/managera w celu uwidocznienia zakładki „Attribute Editor”. Jest to ciekawostka, którą poznałam na samym początku mojej kariery, a stosuje regularnie do dzisiaj.
A czy wy znacie jakieś ciekawostki związane z Active Directory, którymi chcielibyście się podzielić w komentarzach?
***
Jeśli interesuje Was temat Active Directory w różnym kontekście, zachęcamy do przeczytania artykułów naszych ekspertów: OAuth 2.0 On Behalf flow in Azure Active Directory and .NET Core oraz Uwierzytelnianie za pomocą JWT w ASP .NET Core 2.2.