Managed Service Accounts

Managed Service Accounts

  • Comments 4
  • Likes

Jednym z najważniejszych pojęć w przypadku bezpieczeństwa systemów Windows jest "kontekst". Pojęcie to ma podstawy w obowiązującym w całym systemie założeniu, że jeżeli coś się dzieje, to musi istnieć możliwość określenia kto to zrobił i dlaczego. Dlatego proces zawsze ma "swojego" użytkownika, dzięki któremu wiadomo ile mu wolno i na którego rachunek zapisywane są wykonane działania.

Dla procesów użytkownika sprawa jest dość oczywista. Użytkownik X uruchamia notepad.exe i proces ten może otworzyć te pliki, do których użytkownik X ma dostęp. Jeżeli włączone jest rejestrowanie dostępu do plików – do dziennika zdarzeń trafi informacja, że do pliku sięgnął użytkownik X. Ciekawiej jednak robi się w sytuacji, gdy w systemie coś "dzieje się samo" i to system a nie żywy użytkownik inicjuje działania. Przykładem mogą być usługi systemowe (services). Tam, gdzie mają one postać procesu muszą mieć swojego użytkownika. Zazwyczaj jest to specjalny użytkownik "SYSTEM", który ma ogromne uprawnienia na danym komputerze, ale sięgając gdzieś przez sieć – już niekoniecznie. Fakt, że konto SYSTEM jest równocześnie potężne i ograniczone sprawia, że nie zawsze nadaje się ono do usług systemowych mających mniej standardowe zadania. Dobra praktyka w takim przypadku nakazywała utworzenie specjalnego, serwisowego użytkownika w Active Directory i uruchamianie usługi w kontekście jego konta. Mimo, że podejście to wielu lat jest powszechnie stosowane, ma jedną bardzo istotną wadę: konto serwisowe jest tak naprawdę zwykłym kontem użytkownika, a jego hasło ma kluczowe znaczenie dla działania usługi.

  • Po pierwsze: niezgodność hasła na komputerze z hasłem w AD uniemożliwi działanie usługi.
  • Po drugie: odczytanie hasła usługi jest technicznie możliwe (polecam doskonały artykuł Michała Grzegorzewskiego).
  • Po trzecie: hasła powinny być okresowo zmieniane, aby zapewnić ich skuteczność.

W efekcie, poprawne zarządzanie kontami usług wymaga ogromnej dyscypliny a ewentualne pomyłki mogą spowodować niedostępność ważnych usług zapewnianych przez system informatyczny przedsiębiorstwa.

Dlatego, w Windows Server 2008 R2 wprowadzony został nowy mechanizm Managed Service Accounts. Z punktu widzenia komputera uruchamiającego usługę jest to możliwe do wykorzystania konto, podczas gdy po stronie Active Directory zamiast użytkownika (obiektu User) przechowywany jest obiekt typu msDS-ManagedServiceAccount.

Aby wszystko działało, koniecznie jest poinformowanie komputera, że ma używać takiego konta dla swoich usług oraz utworzenie samego obiektu w Active Directory. Od strony komputera uruchamiającego usługę wymagania są proste: Windows 7 / 2008 R2 lub nowszy. Od strony domeny można niby użyć nawet poziomu funkcjonalnego 2003, ale dopiero na 2008 R2 cały mechanizm rozwija skrzydła i w pełni automatycznie zarządza hasłami i SPNami.

Zakładam, że usługę już mamy. Teraz, żeby użyć MSA, należy wykonać następujące działania:

  • Założyć MSA w Active Directory. Najlepiej przez PowerShella z modułem do zarządzania Active Directory, używając cmdlet New-ADServiceAccount. Nazwa obiektu powinna być taka jak nazwa serwisu, czyli w moim przypadku GTSvc. Domyślny kontener to specjalnie w tym celu istniejący "Managed Service Accounts".
    msa01
  • Przygotować hostujący usługę serwer do użycia MSA. PowerShellem można to zrobić instalując moduły do AD i używając cmdletu Install-ADServiceAccount. Pominięcie tego kroku uniemożliwi start usługi.
  • Skonfigurować serwis tak, aby używał konta nazwa_domeny\nazwa_msa$ i nie podawać żadnego hasła.
    msa02

Gotowe. Można uruchomić serwis i podejrzeć na przykład Process Explorerem, że nie jest związany z żadnym użytkownikiem.
msa03

Na koniec jedna ważna uwaga dotycząca ogólnie serwisów a nie samego mechanizmu MSA. Jeżeli użytkownik ma prawa zapisu do folderu, w którym znajdują się binaria serwisu (plik exe), może zmienić nazwę oryginalnego pliku i wgrać swój. Przy najbliższym restarcie serwisu (najpóźniej przy okazji restartu systemu) zostanie uruchomiony plik użytkownika i może narobić sporo złych rzeczy łącznie z przejęciem pełnej kontroli nad serwerem. Dlatego, przechowując binaria serwisów w niestandardowych miejscach należy bardzo dokładnie zweryfikować uprawnienia do folderów. MSA może pozwolić na ograniczenie skutków ataku (na pewno jest bezpieczniej niż z kontem SYSTEM) ale to dalej może być więcej niż prawowity administrator ma ochotę pozwolić.

Autor: Grzegorz Tworek [MVP]

Comments
  • 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 :)

  • 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.

  • 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!

  • 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

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment