Managed Service Accounts

Jednym z najwazniejszych pojec w przypadku bezpieczenstwa systemów Windows jest "kontekst". Pojecie to ma podstawy w obowiazujacym w calym systemie zalozeniu, ze jezeli cos sie dzieje, to musi istniec mozliwosc okreslenia kto to zrobil i dlaczego. Dlatego proces zawsze ma "swojego" uzytkownika, dzieki któremu wiadomo ile mu wolno i na którego rachunek zapisywane sa wykonane dzialania.

Dla procesów uzytkownika sprawa jest dosc oczywista. Uzytkownik X uruchamia notepad.exe i proces ten moze otworzyc te pliki, do których uzytkownik X ma dostep. Jezeli wlaczone jest rejestrowanie dostepu do plików – do dziennika zdarzen trafi informacja, ze do pliku siegnal uzytkownik X. Ciekawiej jednak robi sie w sytuacji, gdy w systemie cos "dzieje sie samo" i to system a nie zywy uzytkownik inicjuje dzialania. Przykladem moga byc uslugi systemowe (services). Tam, gdzie maja one postac procesu musza miec swojego uzytkownika. Zazwyczaj jest to specjalny uzytkownik "SYSTEM", który ma ogromne uprawnienia na danym komputerze, ale siegajac gdzies przez siec – juz niekoniecznie. Fakt, ze konto SYSTEM jest równoczesnie potezne i ograniczone sprawia, ze nie zawsze nadaje sie ono do uslug systemowych majacych mniej standardowe zadania. Dobra praktyka w takim przypadku nakazywala utworzenie specjalnego, serwisowego uzytkownika w Active Directory i uruchamianie uslugi w kontekscie jego konta. Mimo, ze podejscie to wielu lat jest powszechnie stosowane, ma jedna bardzo istotna wade: konto serwisowe jest tak naprawde zwyklym kontem uzytkownika, a jego haslo ma kluczowe znaczenie dla dzialania uslugi.

• Po pierwsze: niezgodnosc hasla na komputerze z haslem w AD uniemozliwi dzialanie uslugi.
• Po drugie: odczytanie hasla uslugi jest technicznie mozliwe (polecam doskonaly artykul Michala Grzegorzewskiego).
• Po trzecie: hasla powinny byc okresowo zmieniane, aby zapewnic ich skutecznosc.

W efekcie, poprawne zarzadzanie kontami uslug wymaga ogromnej dyscypliny a ewentualne pomylki moga spowodowac niedostepnosc waznych uslug zapewnianych przez system informatyczny przedsiebiorstwa.

Dlatego, w Windows Server 2008 R2 wprowadzony zostal nowy mechanizm Managed Service Accounts. Z punktu widzenia komputera uruchamiajacego usluge jest to mozliwe do wykorzystania konto, podczas gdy po stronie Active Directory zamiast uzytkownika (obiektu User) przechowywany jest obiekt typu msDS-ManagedServiceAccount.

Aby wszystko dzialalo, koniecznie jest poinformowanie komputera, ze ma uzywac takiego konta dla swoich uslug oraz utworzenie samego obiektu w Active Directory. Od strony komputera uruchamiajacego usluge wymagania sa proste: Windows 7 / 2008 R2 lub nowszy. Od strony domeny mozna niby uzyc nawet poziomu funkcjonalnego 2003, ale dopiero na 2008 R2 caly mechanizm rozwija skrzydla i w pelni automatycznie zarzadza haslami i SPNami.

Zakladam, ze usluge juz mamy. Teraz, zeby uzyc MSA, nalezy wykonac nastepujace dzialania:

• Zalozyc MSA w Active Directory. Najlepiej przez PowerShella z modulem do zarzadzania Active Directory, uzywajac cmdlet New-ADServiceAccount. Nazwa obiektu powinna byc taka jak nazwa serwisu, czyli w moim przypadku GTSvc. Domyslny kontener to specjalnie w tym celu istniejacy "Managed Service Accounts".
  
• Przygotowac hostujacy usluge serwer do uzycia MSA. PowerShellem mozna to zrobic instalujac moduly do AD i uzywajac cmdletu Install-ADServiceAccount. Pominiecie tego kroku uniemozliwi start uslugi.
• Skonfigurowac serwis tak, aby uzywal konta nazwa_domeny\nazwa_msa$ i nie podawac zadnego hasla.
  

Gotowe. Mozna uruchomic serwis i podejrzec na przyklad Process Explorerem, ze nie jest zwiazany z zadnym uzytkownikiem.

Na koniec jedna wazna uwaga dotyczaca ogólnie serwisów a nie samego mechanizmu MSA. Jezeli uzytkownik ma prawa zapisu do folderu, w którym znajduja sie binaria serwisu (plik exe), moze zmienic nazwe oryginalnego pliku i wgrac swój. Przy najblizszym restarcie serwisu (najpózniej przy okazji restartu systemu) zostanie uruchomiony plik uzytkownika i moze narobic sporo zlych rzeczy lacznie z przejeciem pelnej kontroli nad serwerem. Dlatego, przechowujac binaria serwisów w niestandardowych miejscach nalezy bardzo dokladnie zweryfikowac uprawnienia do folderów. MSA moze pozwolic na ograniczenie skutków ataku (na pewno jest bezpieczniej niz z kontem SYSTEM) ale to dalej moze byc wiecej niz prawowity administrator ma ochote pozwolic.

Autor: Grzegorz Tworek [MVP]

Comments

• Anonymous
  January 01, 2003
  To zależy. Ale w samodzielnym serwerze (bez klastra), od Denali wzwyż - tak. Możesz też spojrzeć na blogs.technet.com/.../sql-server-code-name-denali-adds-support-for-managed-service-accounts.aspx

• Anonymous
  February 20, 2012
  Dzięki za ten tekst - jak zwykle u Ciebie na blogu czegoś nowego można się nauczyć, a przy tym mam temat na kolejny mały research :)

• Anonymous
  February 24, 2012
  Z uwag praktycznych - są ograniczenia w korzystaniu z MSA oczywiście, w szczególności nie da się tego konta używać między maszynami, więc tam gdzie by się naprawdę przydało czyli np w web apps ... się nie da. Ale Windows 8 comes to rescue :) ... i już się da.

• Anonymous
  May 31, 2012
  Nie wiem czy wcześniejszy post mój został poprawnie przesłany. Czy opisana przez Ciebie funkcjonalność możę być wykorzystana do tworzenie kont, na których będą uruchamiane np. usługi SQL Servera? Dzięki za ciekawy wpis!