W skomplikowanych środowiskach korporacyjnych bardzo często spotyka się aplikacje wielowarstwowe. W większości przypadków jest to front-end (serwer WWW jak np. IIS) i back-end (baza danych SQL, serwer plików). Czasami problematyczne może być zaplanowanie mechanizmów uwierzytelniania do takiej usługi. Systemy Windows począwszy od wersji 2000 udostępniają mechanizm delegacji (inaczej S4U2proxy). Dzięki niemu użytkownik przedstawiając usłudze front-endowej swój bilet Kerberos (TGS) umożliwia jej pobranie od KDC (w tym przypadku kontroler domeny) kolejnego TGS-a do back-endu. Wyłącza to konieczność między innymi przepuszczania ruchu sieciowego od klienta do serwerów bazodanowych. Dokładne działanie mechanizmu jakiś czas temu opisał Net Pyle na Blogu AskDS: http://blogs.technet.com/b/askds/archive/2008/06/13/understanding-kerberos-double-hop.aspx
Niestety niesie on ze sobą kilka ograniczeń:
- Double-Hop – bilet wygenerowany dla back-endu nie może być dalej delegowany. To znaczy, że aplikacje 3- lub więcej-warstwowe nie będą korzystać z delegacji
- Usługi muszą znajdować się w tej samej domenie Active Directory
- Uprawnienia administratora domeny były wymagane do konfiguracji usług, których nie był właścicielem
Wszystkie powyższe zostały wyeliminowane w Windows Server 2012 za pomocą nowego modelu delegacji: a2d2 (Allowed To Delegate To). Dzięki niemu administratorzy serwerów aplikacji, którzy mają prawo do pisania atrybutu msDs-AllowedToDelegateTo na kontach swoich usług (użytkowników lub komputerów) mogą kontrolować skąd pozwalają na delegowane biletu BEZ POTRZEBY ustawiania pola „Trust this computer for delegation” w którymkolwiek miejscu. Wystarczy tylko wywołać 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 użytkownikiem/komputerem, który jest „bliżej” użytkownika. Dla przykładu:
Na powyższym rysunku od lewej mamy kolejno serwery: Server1, Server2 oraz Server3. Na serwerze Server1 jest uruchomiony IIS gdzie *** aplikacyjna jest skonfigurowana, aby działać w kontekście użytkownika Service-user1 na której jest ustawiony SPN http/server1. Na serwerze Server2 mamy middle-tier działający w oparciu o web services, gdzie konto usługi (Service-user2) zostało skonfigurowane, aby przyjmować delegację od Service-user1 poprzez Powershell:
Set-ADUser Service-user2 -PrincipalsAllowedToDelegateToAccount (get-aduser Service-user1)
Następnie dla bazy danych na serwerze Server3 zmodyfikowano użytkownika w kontekście którego działa instancja bazy danych:
Set-ADUser Service-user3 -PrincipalsAllowedToDelegateToAccount (get-aduser Service-user2)
W ten oto sposób dowolny użytkownik podłączający się do front-endu będzie zostawiał za sobą ślad uwierzytelniania przez na trzech serwerach, cały czas wykorzystując po drodze Kerberos.
Co do ograniczeń rozwiązania:
- Serwery Server1 oraz Server2 muszą być w wersji co najmniej 2012 – tylko nowe serwery wiedzą jak „poprosić” KDC o bilet, który będzie mógł być dalej delegowany
- Serwer Server3 musi być w wersji 2003 lub nowszej
- W domenie, do której należy dowolny z serwerów musi być co najmniej jeden kontroler domeny w wersji 2012 (ponieważ zniesione zostało ograniczenie delegacji tylko wewnątrz jednej domeny)
- Schemat lasu/lasów musi zostać rozszerzony do wersji Windows Server 2012
Podsumowując, jeśli chcemy korzystać ze zintegrowanych mechanizmów uwierzytelniania, a nasza aplikacja ma więcej niż dwie warstwy, lub fragmenty architektury są rozsiane pomiędzy wieloma domenami Active Directory, to wdrożenie Windows Server 2012 jest niezbędne.
PS. Konta usługowe można zastąpić nowymi Group Managed Service Account (gMSA), ale to temat na inny wpis.