Nowości w Windows Server 2008 R2 - AD DS: Zarządzalne konta usług (Managed Service Accounts)

UWAGA! Artykuł pisany jest na ok. rok przed premierą produktu, dla wersji Windows Server 2008 R2 beta 1 – w wersji finalnej pewne elementy mogą ulec zmianie.

Autor: Nataniel Zieliński

Opublikowano: 17 kwietnia 2009

Zawartość strony

	Scenariusze zastosowania
	Mechanizm w praktyce
	Przydatne linki

Scenariusze zastosowania

Konto usługi było do tej pory wyłącznie sformułowaniem funkcjonalnym – nie istniał specjalny typ konta, działający na specjalnych zasadach. Jest to zwykłe konto użytkownika, które tworzy się w celu reprezentacji usługi a następnie odpowiednio się je konfiguruje, co zazwyczaj sprowadza się do podstawowych elementów:

• uprawnienia specyficzne dla wymagań usługi
• prawo systemowe dla konta „Logon as service”
• (przeważnie) odpowiednio długie i złożone hasło oraz flaga „hasło nie wygasa nigdy”

Tak działają usługi od lat, i mechanizm ten całkiem dobrze sprawdza się w praktyce – po co w takim razie specjalne „zarządzalne konto usługi” (MSA) i co ono zmienia?

Podstawowym powodem, dla którego zostało wymyślone jest eliminacja potencjalnej możliwości włamania na konto usługi – uważny czytelnik, świadomy ogólnie rozumianego „Bezpieczeństwa” na pewno szybko potrafi wskazać słaby punkt obecnie istniejącego podejścia. Hasło – choćby nie wiadomo jak było skomplikowane – zawsze da się złamać. Dużo prostszym sposobem a równie bardzo niebezpiecznym jest po prostu jego zablokowanie, co może prowadzić do zatrzymania krytycznych usług. Bardziej zaradni administratorzy eliminują pierwszy czynnik poprzez wdrożenie mechanizmów, które co określony czas zmieniają hasło dla konta usługi a następnie modyfikują wpisy dla samej usługi. Jak jednak ze wszystkimi rozwiązaniami, które są możliwe ale nie są dostępne wprost z interfejsu – mają niszowe zastosowanie. Konta zarządzalne hasło zmieniają same, zwalniając z tego obowiązku administratorów i eliminując skomplikowane mechanizmy, które stosuje się dzisiaj.

Drugim elementem, który ma ułatwić administratorowi życie jest zarządzanie SPNami usługi. SPN (Service Principal Names), mówiąc bardzo skrótowo, jest to identyfikator usługi, stanowiący podstawę uwierzytelnienia dwustronnego (głównie chodzi o Kerberos) pomiędzy usługą a aplikacją. Nazwy SPN związane są z konkretnymi kontami – np. dla konta komputera rejestrowanych jest od razu kilka SPN. Po szczegółowe informacje odsyłam do stron Technet. Dzięki MSA zarządzanie SPNami będzie prostsze, możliwa również jest delegacja zarządzania rejestracją SPNów.

 Do początku strony

Mechanizm w praktyce

Wymagania

Konto MSA nie jest kontem użytkownika. Stworzony został specjalny typ obiektu AD – msDS‑ManagedServiceAccount, co ma znaczy wpływ na sposób zarządzania i tworzenia takich obiektów. W oczywisty sposób indukuje to wymóg podniesienia wersji schematu do wersji R2. Po otworzeniu Active Directory Users and Computers można zauważyć pojawienie się nowego kontenera „CN=Managed User Accounts”, który jest sugerowanym kontenerem dla tego rodzaju obiektów (choć można z powodzeniem założyć go gdzieindziej).

Aby skorzystać z MSA usługa musi działać na stacji Windows 7 (client lub server). Nie ma natomiast wymagania, aby kontrolery domeny były w wersji 2008 R2 – a co za tym idzie, poziom funkcjonalny może pozostać w trybie w2k3/w2k8. W takim jednak przypadku zarządzać będzie trzeba z serwera członkowskiego z systemem Windows Server 2008 R2 oraz nie będzie działać automatyczna rejestracja SPN dla usługi.

Krok-po-kroku

Przedstawię instrukcję krok-po-kroku w jaki sposób przetestować działanie MSA. Do tego celu potrzebne są dwa systemy z Windows Server 2008 R2 (jeden z nich może być ew. Windows 7 client), na których należy:

1. Zainstalować i skonfigurować usługę Active Directory na jednym z serwerów. Na potrzeby labu przyjąłem nazwę domeny „ w2k8r2.domain ”.

2. Zainstalować SQL Server na drugim z komputerów (przyjąłem nazwę „ memberserver ”). Wystarczy do tego celu mały SQL Express 2005 lub 2008 zainstalowany na standardowych parametrach. Podczas instalacji nie da się od razu podać konta MSA jako konta usługi – wynika to głównie z faktu, iż interfejs w obecnej postaci nie pozwala na wyszukanie obiektu typu msDS-ManagedServiceAccount. W związku z tym na początku można wykorzystać „local system”.

3. Teoretycznie interfejs pozwala na założenie konta MSA z GUI – po kliknięciu na kontenerze i wybraniu opcji „ new ” pojawia się na liście nowy typ obiektu. W wersji beta nie jest to jeszcze prawidłowo zaimplementowane i należy skorzystać ze skryptów PowerShell (informacja od AD Documentation Team) – należy więc potraktować ten sposób jako zapowiedź dla wersji finalnej.

   

   Rysunek 1: Widok ADUaC - zakładanie obiektu msDSMangedServiceAccount

   Zakładanie konta z PowerShell:

   • ten krok można pominąć, jeśli uruchomiło się „Active Directory PowerShell”:

     import-module ActiveDirectory

   • konta powinny być tworzone przyjmując odpowiednią konwencję nazewniczą – przyjąłem, że jest to <nazwa usługi>SA_<nazwa serwera>. Ostatni element, zapisany w nawiasach klamrowych i definiujący hasło dla konta, można pominąć – i tak zostanie za chwilę automatycznie zmienione, a podczas konfiguracji usługi można wpisać cokolwiek.

     New-ADSeviceAccount SQLSA_memberserver –Enabled $true –Path „CN=Managed Service Accounts,DC=w2k8r2,DC=domain” –ServicePrincipalNames “MSSQLSVC/memberserver.w2k8r2.domain” {–AccountPassword (Convertto-SecureString “P@ssw0rd” –asPlainText –force)}

4. Następnie konto trzeba zainstalować na komputerze docelowym - to dość nietypowy krok. W PowerShellv2 można wykonać komendę zdalnie, po odpowiedniej konfiguracji WinRM. W przykładzie jednak proponuję standardowe podejście:

   • zainstalować na serwerze usługi „AD PowerShell” dostępne jako „Feature” z Server Managera ( Add Features -> Remote Server Administration Tools -> AD DS and AD LDS tools -> AD PowerShell snap-in )

   • uruchomić AD PowerShell i wykonać:

     install-ADServiceAccount SQLSA_memberserver

     Polecenie sprawdza, czy lokalny komputer jest w stanie wykorzystać konto MSA oraz dokonuje odpowiednich modyfikacji w LSA oraz NetLogon tak, aby hasło było automatycznie zmieniane, podczas zmiany hasła komputera. Polecenie to również ustawia wstępne hasło dla konta.

5. Pozostaje skonfigurować usługę SQL aby działała w kontekście utworzonego konta MSA. W tym celu należy:

   • skorzystać ze snap-ina do zarządzania usługami – „ services.msc ”

   • wyedytować właściwości usługi „ SQL Server (SQLEXPRESS)” i w zakładce „Log On” wpisać nazwę konta: „ w2k8r2\SQLSA_memberserver$ ”. Znak dolara na końcu nie jest przypadkowy – podobnie jak w przypadku kont komputera, tak zapisuje się nazwę konta MSA. Jako hasło można nie wpisywać nic lub wpisać cokolwiek – nie ma to znaczenia (taka ciekawostka).

     

     Rysunek 2: ustawianie konta usługi

6. Brakuje jeszcze jednego elementu – odpowiednich uprawnień dla konta SQLSA_memberserver wynikających z uprawnień wymaganych przez usługę SQL – należy dodać je do grupy administratorów lokalnych. Ponieważ grupa lokalna nie potrafi obsłużyć takiego obiektu, należy:

   • założyć grupę globalną w domenie
   • dodać do niej konto MSA
   • dodać tą grupę do lokalnej grupy „Administrators” na komputerze, gdzie działa usługa

Teraz można uruchomić usługę.

Weryfikacja poprawności

Pozostaje sprawdzić, czy faktycznie hasło zostaje zmieniane automatycznie. Po wyświetleniu właściwości obiektu MSA w domenie okaże się, że nie ma tam praktycznie żadnych opcji czy możliwości konfiguracji obiektu. Należy włączyć widok zaawansowany w ADUaC ( view ->Advanced Features) – od wersji Windows Server 2008 pojawia się dodatkowa zakładka „ Attribute Editor ” – całą konfigurację wykonuje się w ten sposób lub korzystając ze commandletów (skrypty PowerShell). Można również skorzystać z ADSIEdit. Aby sprawdzić czy hasło zostało ustawione podczas dodawania wystarczy zweryfikować wartość parametru pwdLastSet – tuż po założeniu konta atrybut będzie miał wartość „ (never) ” – po wykonaniu komendy install-ADServiceAccount będzie pokazywał datę wykonania operacji.

Aby przeprowadzić test czy hasło modyfikowane jest automatycznie można zmodyfikować polisę GPO dla domeny, ustawiając parametr ważności hasła komputera na 1 dzień (ComputerConfiguration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> Domain Member: Maximum Machine Account Age ), wymusić odświeżenie polisy i... cierpliwie poczekać. Można spróbować również pobawić się datą systemową, chociaż może nie dać to oczekiwanych wyników.

 Do początku strony

Przydatne linki

• ogólne informacje na stronach Technet https://technet.microsoft.com/en-us/library/dd367859.aspx
• czy jest SPN https://technet.microsoft.com/pl-pl/library/cc961723(en-us).aspx
• nie używać GUI w wersji beta https://blogs.technet.com/activedirectoryua/archive/2009/01/29/create-managed-service-accounts-with-powershell-do-not-create-managed-service-accounts-with-active-directory-users-and-computers.aspx

Nataniel Zieliński (konsultant ISCG) Przygodę z komputerem zaczynał na polskich 8-bitowcach Bosman 8 w późnych latach 80-tych. Po bogatych doświadczeniach z licznymi systemami, rozpoczął karierę jako administrator systemów Windows NT w Polsko-Japońskiej Wyższej Szkole Technik Komputerowych, gdzie zgłębiał tajemnice kolejnych wersji Windows NT, zarówno od strony technicznej - administrując, jak teoretycznej - prowadząc kursy MOC w Akademickim Centrum Szkoleniowym. Od kilku lat pracuje w roli konsultanta oraz trenera MCT w firmie ISCG Sp. z o.o., Gold Partnera Microsoft, dalej pogłębiając swoją wiedzę w dziedzinie kolejnych produktów ze stacji Microsoft. Od dłuższego czasu członek elitarnego klubu inżynierów Microsoft - SEClub.

Do początku strony