Usługi katalogowe Active Directory są jednym z kluczowych zasobów współczesnych przedsiębiorstw. Od czasu wydania Windows Server 2008 zaczęły w nich zachodzić zmiany (np. AD stało się usługą systemową) niezwykle istotne z punktu widzenia administratora. Najnowsza wersja R2 wniosła kilka interesujących funkcji, o których powinien wiedzieć każdy specjalista IT. Najważniejsze nowości pojawiają się w zakresie zarządzania obiektami i działaniem domeny - dodano moduł dla Windows PowerShell oraz powiązaną z nim funkcję kosza na skasowane obiekty. Większość zmian wprowadzonych w wersji R2 dotyczy działania usługi Active Directory Web Services, która służy jako interfejs programistyczny i pozwala na rozproszone zarządzanie bazami Active Directory Domain Services oraz LDAP (Lightweight Directory Services). To jeden z komponentów umieszczonych w platformie programistycznej WCF (Windows Communication Foundation) umożliwiającej ujednolicenie standardu komunikacji - otwiera drogę do tworzenia własnych interfejsów obsługi AD.

Rys. 1. Usługa ADWS.

Active Directory Module for Windows PowerShell

Język skryptowy PowerShell znajduje coraz szersze zastosowanie w różnych produktach firmy Microsoft. Windows Server 2008 R2 pozwala za jego pomocą zarządzać komponentami środowiska domenowego. Zestaw poleceń jest dostarczany za pośrednictwem modułu Active Directory, który należy ręcznie zaimportować do standardowej konsoli PS lub użyć już przygotowanej konsoli noszącej nazwę Active Directory Module for Windows PowerShell. Moduł ten znajduje swoje zastosowanie m.in. podczas pracy z nową funkcją kosza na obiekty AD (wszystkie operacje wykonuje się za pomocą skryptów). Interesujące jest zapewnienie pracy z kontenerami Active Directory w sposób znany dotychczas z obsługi katalogów. Możliwe staje się przejście do „dysku" AD: zawierającego „katalogi" będące reprezentacją poszczególnych kontenerów. Wszystkie operacje wykonywane są analogicznie jak w przypadku folderów, tj. ma miejsce wyświetlenie zawartości (dir), stworzenie kontenera (md) itd.

Rys. 2. Obsługa Active Directory z poziomu PoweShell.

Active Direcotry Recyle Bin

Wcześniejsze wersje systemów Windows Server nie pozwalały na szybkie i proste przywracanie skasowanych obiektów. Każdy trzeba było przewracać oddzielnie, dokonując modyfikację atrybutu isDeleted. W Windows Server 2008 R2 zaprezentowany został kosz Active Directory oraz zestaw poleceń języka skryptowego PowerShell, co zapewnia prostsze odzyskiwanie usuniętych obiektów. Przed przystąpieniem do praktycznego wykorzystania tej funkcji, trzeba zrozumieć proces usuwania obiektów w różnych wersjach systemów. Zgodnie z przedstawionym dalej schematem wcześniejsze wersje Windows Server modyfikowały atrybut isDeleted i usunięty obiekt otrzymywał tabliczkę nagrobną (tombstone) na okres 60 dni w wersji 2003 i 180 dni w 2008. Na skutek tego podczas replikacji serwery partnerskie także go usuwały. Obecnie obiekt jest przechowywany przez 180 dni w koszu i dopiero później podlega podobnemu procesowi usuwania. Gdy upłynie czas trwania tombstone, obiekt jest ostatecznie kasowany. Poza tym każdy obiekt przeznaczony do skasowania przenoszony jest do kontenera Deteled Objects i traci informacje o części swoich atrybutów, np. członkowstwo w grupach, pola adresowe itp. Kosz Active Directory zachowuje wszystkie atrybuty obiektu i nie wymaga dodatkowych modyfikacji, co jest jego niewątpliwą zaletą.

Parametry związane z czasem istnienia obiektu na każdym etapie usuwania mogą być zmodyfikowane w wyniku zmiany wartości atrybutów msDS-deletedObjectLifetime i tombstoneLifetime. Domyślna wartość obu atrybutów to null, który odwołuje się do zaszytej w konfiguracji systemu wartości 180 dni. Przypisanie własnej liczby powoduje nadpisanie tych ustawień. Można tego dokonać poleceniami (wydłużenie do 365 dni):

Set-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=skalski,DC=info" -Partition "CN=Configuration,DC=skalski,DC=info" -Replace:@{"tombstoneLifetime" = 365}

Set-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=skalski,DC=info" -Partition "CN=Configuration,DC=skalski,DC=info" -Replace:@{"msDS-DeletedObjectLifetime" = 365}

Rys. 3. Modyfikacja czasu przechowywania usuniętych obiektów.

By skorzystać ze wspomnianej funkcji, trzeba wcześniej przygotować środowisko:

• wszystkie kontrolery domeny muszą działać na poziomie funkcjonalnym Windows Server 2008 R2,
• las Active Directory musi działać na poziomie funkcjonalnym Windows Server 2008 R2,
• należy włączyć funkcję Active Directory Recycle Bin.

Wszystkie operacje można wykonać za pomocą poleceń PowerShell. By rozpocząć przygotowanie środowiska, należy uruchomić konsolę Active Directory Module for Windows PowerShell lub do standardowej konsoli zaimportować moduł obsługi AD poleceniem Import-Module activedirectory. Najważniejszym korkiem jest włączenie funkcji kosza poleceniem:

 Enable-ADOptionalFeature 'Recycle Bin Feature' -Scope ForestOrConfigurationSet -target 'skalski.info'

UWAGA! Czynność ta jest nieodwracalna!

Rys. 4. Włączenie kosza w Active Directory.

Od tego momentu każdy usunięty obiekt będzie przechodził dwa etapy procesu usuwania: najpierw zostanie przeniesiony do kosza, potem zyska tabliczkę nagrobną. W celu wyszukania usuniętych obiektów, trzeba odwołać się do kontenera Deleted Object, uwzględniając parametr -includeDeletedObjects, dzięki któremu możliwe stanie się zwrócenie w wynikach skasowanych obiektów. Do wyszukiwania wszystkich usuniętych elementów służy polecenie:

 Get-ADObject -SearchBase „CN=Deleted Objects,DC=Skalski,DC=info" -ldapFilter „(objectClass=*)" -includeDeletedObjects

Możliwa jest też zmiana formatu wyniku, by - przykładowo - wyświetlił wyłącznie nazwę obiektu, jego typ oraz globalny identyfikator, przez dodanie do polecenia:

| Format-List Name,ObjectClass,ObjectGuid

Rys 5. Filtrowanie usuniętych obiektów.

Odtworzenia pojedynczego obiektu dokonuje się za pomocą polecenia:

Restore-ADObject -identity <guid>

Odtworzenie wielu obiektów możliwe jest dzięki użyciu kombinacji tych poleceń:

Get-ADObject -SearchBase „CN=Deleted Objects,DC=Skalski,DC=info" -ldapFilter „(objectClass=*)" -includeDeletedObjects | Restore-ADObject

UWAGA! Odtworzenie obiektu jest możliwe wyłącznie, gdy istnieje jego rodzic, np. użytkownik może zostać przywrócony jedynie, gdy istnieje jego jednostka organizacyjna. Jeśli nie, ją także trzeba odtworzyć.

Rys. 6. Przywracanie skasowanych obiektów.

Active Directory Administrative Center

W celu uproszczenia częstych operacji na obiektach domeny wprowadzono konsolę Centrum Administracyjnego Active Directory. Jej głównym zadaniem jest ułatwienie wyszukiwania obiektów i wykonywanie operacji modyfikowania ich atrybutów. Przykładem takiej operacji jest resetowanie haseł użytkowników. Opcja ta domyślnie dostępna jest na panelu głównym (który można swobodnie dostosować do swoich potrzeb). Zadania wyszukiwania zostają uproszczone przez tworzenie filtrów na podstawie dobrze znanych atrybutów i cech, jakie mogą posiadać obiekty, przykładem wyszukiwanie użytkowników, którzy nie logowali się przez określony czas.

Rys. 7. Centrum Administracyjne Active Directory.

Best Practices Analyzer

Dobre praktyki związane z wdrażaniem i utrzymaniem poszczególnych ról serwera są ważnym aspektem poprawnie pracującego środowiska informatycznego. Zwierają one wyznaczniki i sugestie opisujące poprawne wdrożenie i zaprojektowanie danej technologii. Dotychczas większość informacji znajdowała się w licznych dokumentach, a sprawdzenie zgodności konfiguracji z ich postanowieniami wymagało ręcznej analizy lub użycia dodatkowego oprogramowania. Do takich programów należy Best Practices Analyzer, który dotychczas był dostarczany w formie niezależnej aplikacji, a teraz jest jednym ze składników instalowanych ról serwera. Przykładowo, instalacja roli Active Directory Domain Services zawiera jednocześnie BPA dla niej przeznaczony i integruje go z konsolą Server Manager.

Zintegrowany analizator dostępny jest dla ról:

• Active Directory Certificate Services,
• Active Directory Domain Services,
• Domain Name System (DNS),
• Dynamic Host Configuration Protocol (DHCP),
• Internet Information Services (IIS),
• Remote Desktop Services (RDS),
• Network Policy and Access Services.

Skanowania roli dokonuje się, wybierając odpowiednią funkcję „Scan This Role", efektem czego jest wyświetlenie raportu zawierającego informacje o zgodności z poszczególnymi zaleceniami. Zalecenia zostały podzielone na trzy sekcje:

• konfiguracja - czy istnieją poprawne rekordy w DNS, czy wszystkie jednostki organizacyjne są chronione przed przypadkowym usunięciem itp.,
• działanie - czy w środowisku istnieją przynajmniej dwa kontrolery domeny itp.,
• wymogi - czy kontroler może połączyć się z serwerem DNS i odczytać rekordy itp.

Rys. 8. Analiza zgodności z najlepszymi praktykami.

Każdą pozycję raportu można przeanalizować w poszukiwaniu bardziej szczegółowych informacji. W przypadku niespełnienia wymogu istotnymi wskazówkami mogą okazać się sekcje:

• Issue - opis powodu niezgodności z dobrą praktyką,
• Impact - przewidywany skutek ewentualnej awarii oraz jego konsekwencje dla użytkowników i elementów infrastruktury,
• Resolution - opis rozwiązania, jakie należy zastosować w celu poprawy stanu analizowanej roli.

Rys. 9. Raport BPA o niezgodności.

Offline Domain Joining

Proces przygotowania stacji roboczych i serwerów, które zostaną dodane do infrastruktury, da się uprościć, dzięki funkcji: bezpołączeniowe przyłączenia do domeny. Możliwe staje się utworzenie specyficznego pliku odpowiedzi na jednej ze stacji, będących członkami domeny. Zostanie on dostarczony do docelowego komputera i tam uruchomiony w celu dodania informacji o członkostwie. Zastosowanie tego rozwiązania sprawia, że stacja nie musi mieć połączenia z firmową siecią i nie trzeba wykonywać dodatkowych czynności przy pierwszym podłączeniu.

Proces zaczyna się od utworzenia pliku zawierającego m.in. informacje o domenie, kontrolerze domeny, koncie komputera i jego haśle. Jednocześnie zakładane jest konto komputera w Active Directory. By wykonać tę czynność, trzeba posiadać uprawnienia administracyjne i zdefiniować odpowiednie parametry w poleceniu:

DJOIN /PROVISION /DOMAIN: Skalski.info /MACHINEOU „OU=Test Lab,DC=Skalski,DC=info" /MACHINE CL1 /SAVEFILE c:\cl1.djoin

Najważniejszymi parametrami w tym przypadku są:

• PROVISION - określa rezerwacje dla konta komputera w domenie według podanych dalej parametrów;
• DOMAIN - wskazuje domenę, do jakiej zostanie przyłączony komputer;
• MACHINEOU - definiuje położenie konta komputera w strukturze jednostek organizacyjnych;
• MACHINE - nadaje nazwę komputerowi, który zostanie podłączony. Uwaga: przyłączany komputer zmieni swoją nazwę na podaną w tym parametrze;
• SAVEFILE - określa ścieżkę, w jakiej zostanie utworzony plik odpowiedzi służący dalej do podłączenia komputera docelowego.

Rys. 10. Przygotowywanie pliku odpowiedzi Djoin.

Tak przygotowany plik odpowiedzi należy przenieść do stacji docelowej i rozpocząć proces przetwarzania zawartych w nim informacji poleceniem:

DJOIN /REQUESTODJ /LOADFILE c:\off-client1.djoin /LOCALOS /WINDOWSPATH C:\Windows

Najważniejszymi parametrami w tym przypadku są:

• REQUESTODJ - wykonuje żądanie bezpołączeniowego przyłączenia do domeny,
• LOADFILE - wskazuje ścieżkę do pliku odpowiedzi,
• LOCALOS - pozwala na wskazanie jako celu obecnie uruchomionego systemu operacyjnego,
• WINDOWSPATH - wskazuje ścieżkę do folderu systemowego podłączanej stacji.

Rys. 11. Bezpołączeniowe przyłączenie do domeny.

Ostatni krok to ponowne uruchomienie przygotowywanej stacji. Od tego czasu jest ona gotowa do pracy w domenie. Użytkownicy domeny będą mogli się zalogować zaraz pod podłączeniu do sieci firmowej.

Autor:

Kamil Skalski
(MCT, MCITP, MCTS, MCSE+S, MCSA+S, MCP)