Delegacja Kerberos w Windows Server 2012

  • Article

W skomplikowanych srodowiskach korporacyjnych bardzo czesto spotyka sie aplikacje wielowarstwowe. W wiekszosci przypadków jest to front-end (serwer WWW jak np. IIS) i back-end (baza danych SQL, serwer plików). Czasami problematyczne moze byc zaplanowanie mechanizmów uwierzytelniania do takiej uslugi. Systemy Windows poczawszy od wersji 2000 udostepniaja mechanizm delegacji (inaczej S4U2proxy). Dzieki niemu uzytkownik przedstawiajac usludze front-endowej swój bilet Kerberos (TGS) umozliwia jej pobranie od KDC (w tym przypadku kontroler domeny) kolejnego TGS-a do back-endu. Wylacza to koniecznosc miedzy innymi przepuszczania ruchu sieciowego od klienta do serwerów bazodanowych. Dokladne dzialanie mechanizmu jakis czas temu opisal Net Pyle na Blogu AskDS: https://blogs.technet.com/b/askds/archive/2008/06/13/understanding-kerberos-double-hop.aspx

Niestety niesie on ze soba kilka ograniczen:

  • Double-Hop – bilet wygenerowany dla back-endu nie moze byc dalej delegowany. To znaczy, ze aplikacje 3- lub wiecej-warstwowe nie beda korzystac z delegacji
  • Uslugi musza znajdowac sie w tej samej domenie Active Directory
  • Uprawnienia administratora domeny byly wymagane do konfiguracji uslug, których nie byl wlascicielem

Wszystkie powyzsze zostaly wyeliminowane w Windows Server 2012 za pomoca nowego modelu delegacji: a2d2 (Allowed To Delegate To). Dzieki niemu administratorzy serwerów aplikacji, którzy maja prawo do pisania atrybutu msDs-AllowedToDelegateTo na kontach swoich uslug (uzytkowników lub komputerów) moga kontrolowac skad pozwalaja na delegowane biletu BEZ POTRZEBY ustawiania pola „Trust this computer for delegation” w którymkolwiek miejscu. Wystarczy tylko wywolac jeden z cmd-letów:

  • New-ADUser -PrincipalsAllowedToDelegateToAccount
  • Set-ADUser -PrincipalsAllowedToDelegateToAccount
  • New-ADServiceAccount -PrincipalsAllowedToDelegateToAccount
  • Set-ADServiceAccount -PrincipalsAllowedToDelegateToAccount
  • New-ADComputer -PrincipalsAllowedToDelegateToAccount
  • Set-ADComputer –PrincipalsAllowedToDelegateToAccount

PrincipalsAllowedToDelegateToAccount jest uzytkownikiem/komputerem, który jest „blizej” uzytkownika. Dla przykladu:

clip_image002

Na powyzszym rysunku od lewej mamy kolejno serwery: Server1, Server2 oraz Server3. Na serwerze Server1 jest uruchomiony IIS gdzie *** aplikacyjna jest skonfigurowana, aby dzialac w kontekscie uzytkownika Service-user1 na której jest ustawiony SPN http/server1. Na serwerze Server2 mamy middle-tier dzialajacy w oparciu o web services, gdzie konto uslugi (Service-user2) zostalo skonfigurowane, aby przyjmowac delegacje od Service-user1 poprzez Powershell:

Set-ADUser Service-user2 -PrincipalsAllowedToDelegateToAccount (get-aduser Service-user1)

Nastepnie dla bazy danych na serwerze Server3 zmodyfikowano uzytkownika w kontekscie którego dziala instancja bazy danych:

Set-ADUser Service-user3 -PrincipalsAllowedToDelegateToAccount (get-aduser Service-user2)

W ten oto sposób dowolny uzytkownik podlaczajacy sie do front-endu bedzie zostawial za soba slad uwierzytelniania przez na trzech serwerach, caly czas wykorzystujac po drodze Kerberos.

Co do ograniczen rozwiazania:

  • Serwery Server1 oraz Server2 musza byc w wersji co najmniej 2012 – tylko nowe serwery wiedza jak „poprosic” KDC o bilet, który bedzie mógl byc dalej delegowany
  • Serwer Server3 musi byc w wersji 2003 lub nowszej
  • W domenie, do której nalezy dowolny z serwerów musi byc co najmniej jeden kontroler domeny w wersji 2012 (poniewaz zniesione zostalo ograniczenie delegacji tylko wewnatrz jednej domeny)
  • Schemat lasu/lasów musi zostac rozszerzony do wersji Windows Server 2012

Podsumowujac, jesli chcemy korzystac ze zintegrowanych mechanizmów uwierzytelniania, a nasza aplikacja ma wiecej niz dwie warstwy, lub fragmenty architektury sa rozsiane pomiedzy wieloma domenami Active Directory, to wdrozenie Windows Server 2012 jest niezbedne.

PS. Konta uslugowe mozna zastapic nowymi Group Managed Service Account (gMSA), ale to temat na inny wpis.