AD FS (Active Directory Federation Services) – co to jest, jak działa i czy nadal warto

AD FS, czyli Active Directory Federation Services, to rola Windows Server, która pozwala użytkownikom z lokalnej usługi Active Directory logować się jednym kontem do aplikacji spoza domeny – w chmurze, u partnerów biznesowych czy w aplikacjach webowych. AD FS uwierzytelnia użytkownika w AD, a następnie wystawia mu podpisany token (SAML, WS-Federation lub OpenID Connect), któremu ufa aplikacja. Tak działa logowanie jednokrotne (SSO) bez przekazywania hasła do aplikacji.

W tym poradniku wyjaśniam, jak działa federacja, z czego składa się wdrożenie AD FS, jak dodać aplikację i jak AD FS współpracuje z Microsoft 365. Opisuję też, dlaczego w 2026 roku wiele firm z niego rezygnuje na rzecz Microsoft Entra ID.

AD FS a AD RMS – dwie różne usługi

Zanim przejdziemy dalej, jedno wyjaśnienie, bo te skróty bywają mylone. AD FS (Federation Services) służy do uwierzytelniania i logowania jednokrotnego. AD RMS (Rights Management Services) służy do ochrony dokumentów – szyfrowania plików i wiadomości oraz kontroli, kto może je otworzyć, wydrukować czy przekazać dalej.

Obie role istnieją w Windows Server, ale rozwiązują zupełnie inne problemy. Funkcje AD RMS w nowych wdrożeniach przejęła chmurowa usługa Microsoft Purview Information Protection (etykiety poufności). Ten artykuł dotyczy wyłącznie AD FS.

Jak działa AD FS – federacja i oświadczenia

AD FS opiera się na uwierzytelnianiu opartym na oświadczeniach (claims-based authentication). Zamiast wpuszczać aplikację do Twojego AD, AD FS wydaje jej token z wybranymi informacjami o użytkowniku – oświadczeniami, np. adresem e-mail, nazwą UPN, członkostwem w grupach.

Typowy przebieg logowania w modelu SAML/WS-Federation:

1. Użytkownik otwiera aplikację (np. portal partnera albo system SaaS).
2. Aplikacja widzi, że nie jest zalogowany, i przekierowuje przeglądarkę do AD FS.
3. AD FS uwierzytelnia użytkownika – w sieci firmowej często bezpiecznie i niewidocznie przez Kerberos (zintegrowane uwierzytelnianie Windows), z zewnątrz formularzem i MFA.
4. AD FS buduje token z oświadczeniami zgodnie z regułami dla tej aplikacji i podpisuje go swoim certyfikatem.
5. Przeglądarka przekazuje token aplikacji, która sprawdza podpis i loguje użytkownika.

Aplikacja nigdy nie widzi hasła, a dostęp do niej można wyłączyć w jednym miejscu. Mechanizm Kerberos, z którego AD FS korzysta w sieci wewnętrznej, opisujemy w artykule o protokole Kerberos, a ogólną budowę katalogu w tekście jak działa Active Directory.

Najważniejsze pojęcia

AD FS obsługuje protokoły SAML 2.0, WS-Federation, WS-Trust oraz – od wersji z Windows Server 2016 – OAuth 2.0 i OpenID Connect, dzięki czemu nadaje się także do nowoczesnych aplikacji webowych i mobilnych.

Architektura wdrożenia AD FS

Produkcyjne wdrożenie AD FS składa się zwykle z:

• farmy co najmniej dwóch serwerów AD FS w sieci wewnętrznej, za load balancerem,
• bazy konfiguracji – wbudowanej Windows Internal Database (WID) dla mniejszych farm lub SQL Server dla dużych,
• co najmniej dwóch serwerów Web Application Proxy w DMZ, które przyjmują żądania z internetu i przekazują je do farmy,
• certyfikatu SSL wystawionego przez publiczny urząd certyfikacji na nazwę usługi federacyjnej,
• konta usługi – najlepiej zarządzanego konta gMSA, które samo zmienia hasło.

Serwerów AD FS nie wystawia się bezpośrednio do internetu – od tego jest WAP. Serwery AD FS traktuj jak kontrolery domeny, czyli jako systemy najwyższego poziomu (tier 0).

Instalacja farmy AD FS krok po kroku

Poniżej skrócona instalacja pierwszego serwera farmy w PowerShell. Zakładam, że masz certyfikat SSL zaimportowany do magazynu komputera i rekord DNS sts.firma.pl wskazujący na load balancer.

1. Utwórz konto gMSA (jednorazowo w domenie, jeśli nie masz jeszcze klucza głównego KDS):

Add-KdsRootKey -EffectiveImmediately
New-ADServiceAccount -Name gmsa_adfs -DNSHostName sts.firma.pl `
  -PrincipalsAllowedToRetrieveManagedPassword "Serwery-ADFS"

2. Zainstaluj rolę na serwerze:

Install-WindowsFeature ADFS-Federation -IncludeManagementTools

3. Skonfiguruj farmę, wskazując odcisk certyfikatu SSL, nazwę usługi i konto gMSA:

$cert = (Get-ChildItem Cert:\LocalMachine\My | Where-Object Subject -like "*sts.firma.pl*").Thumbprint
Install-AdfsFarm -CertificateThumbprint $cert `
  -FederationServiceName "sts.firma.pl" `
  -FederationServiceDisplayName "Logowanie Firma" `
  -GroupServiceAccountIdentifier "FIRMA\gmsa_adfs$"

4. Kolejne serwery dołącz poleceniem Add-AdfsFarmNode, a na serwerach w DMZ zainstaluj rolę Web Application Proxy (Install-WindowsFeature Web-Application-Proxy) i skonfiguruj ją poleceniem Install-WebApplicationProxy.

Po instalacji metadane federacji są dostępne pod adresem https://sts.firma.pl/FederationMetadata/2007-06/FederationMetadata.xml – ten adres podajesz aplikacjom i partnerom. Do szybkiego testu logowania możesz włączyć stronę logowania inicjowanego przez dostawcę tożsamości:

Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
# test: https://sts.firma.pl/adfs/ls/idpinitiatedsignon.aspx

Po testach wyłącz ją z powrotem, jeśli żadna aplikacja jej nie potrzebuje.

Dodanie aplikacji: zaufanie jednostki uzależnionej

Każda aplikacja, która ma logować użytkowników przez AD FS, to osobne zaufanie jednostki uzależnionej. Przykładowo może to być system HR w modelu SaaS albo Portal for ArcGIS – w każdym przypadku procedura jest podobna:

1. W aplikacji włącz logowanie SAML (lub WS-Federation/OIDC) i wskaż jako dostawcę tożsamości metadane AD FS.
2. W konsoli Zarządzanie usługami AD FS wybierz Zaufania jednostek uzależnionych → Dodaj zaufanie jednostki uzależnionej.
3. Wybierz Obsługujące oświadczenia, a następnie podaj adres metadanych aplikacji lub zaimportuj plik metadanych, który aplikacja udostępnia.
4. Wybierz zasady kontroli dostępu, np. „Zezwalaj wszystkim” albo „Zezwalaj określonej grupie” z wymogiem MFA.
5. Dodaj reguły wystawiania oświadczeń – najczęściej szablon „Wysyłaj atrybuty LDAP jako oświadczenia” (np. E-Mail-Addresses → adres e-mail, User-Principal-Name → UPN) oraz regułę przekształcającą na identyfikator nazwy (Name ID), którego wymaga aplikacja.

To samo zrobisz w PowerShell:

Add-AdfsRelyingPartyTrust -Name "Portal HR" `
  -MetadataUrl "https://hr.example.com/saml/metadata" `
  -AccessControlPolicyName "Permit everyone"

Najczęstsze problemy przy integracji to niezgodny format Name ID, różnica w algorytmie podpisu (SHA-1 kontra SHA-256) i nieaktualne metadane po odnowieniu certyfikatu po którejkolwiek stronie. Błędy znajdziesz w dzienniku Dzienniki aplikacji i usług → AD FS → Admin na serwerach farmy.

AD FS i Microsoft 365

Przez lata AD FS był standardowym sposobem logowania do Office 365 kontami z lokalnej domeny. Konfiguracja federacji z Microsoft 365 składa się z kilku etapów:

1. Dodanie i weryfikacja domeny w centrum administracyjnym Microsoft 365 (Ustawienia → Domeny → Dodaj domenę) – zwykle przez rekord TXT w DNS.
2. Dodanie tej domeny jako sufiksu UPN w lokalnym AD, jeśli domena wewnętrzna jest inna (np. firma.local), i ustawienie użytkownikom UPN zgodnego z adresem e-mail.
3. Synchronizacja kont narzędziem Microsoft Entra Connect Sync (dawniej Azure AD Connect).
4. Przełączenie domeny w tryb federacyjny – najprościej w kreatorze Entra Connect, opcja Federacja z AD FS, który sam utworzy zaufanie jednostki uzależnionej dla Microsoft 365.

Po stronie stacji roboczych logowanie jednokrotne z sieci wewnętrznej wymaga, by adres usługi federacyjnej był w strefie Lokalny intranet. Ustawisz to przez GPO: Konfiguracja komputera → Szablony administracyjne → Składniki systemu Windows → Internet Explorer → Panel sterowania internetowego → Strona Zabezpieczenia → Lista przypisań witryn do stref, wpis https://sts.firma.pl z wartością 1. Ustawienie stref działa także dla Edge i Chrome w Windows. Jeśli mimo to przeglądarka pokazuje formularz logowania, sprawdź, czy jej identyfikator jest na liście WIASupportedUserAgents w Get-AdfsProperties.

Bezpieczeństwo AD FS: Golden SAML, spraying i MFA

AD FS jest wystawiony do internetu i przyjmuje hasła domenowe, więc jest częstym celem ataków:

• Password spraying i brute force – atakujący testują popularne hasła na wielu kontach przez stronę logowania. Włącz Extranet Smart Lockout, który blokuje logowanie z nieznanych lokalizacji, nie blokując użytkownika w sieci firmowej. Więcej o samej technice w artykule o password spraying.
• Golden SAML – kto wykradnie certyfikat podpisywania tokenów, może wystawić sobie token dla dowolnego użytkownika i dowolnej aplikacji, z pominięciem haseł i MFA. Technika ta była używana m.in. w ataku na łańcuch dostaw SolarWinds w 2020 r.
• Brak MFA – AD FS obsługuje MFA przez zasady kontroli dostępu i adaptery (np. Microsoft Entra MFA, rozwiązania firm trzecich). Najlepiej postawić na metody odporne na phishing, takie jak klucze FIDO2.

Uwaga: Dostęp administracyjny do serwerów AD FS i konta gMSA daje praktycznie kontrolę nad wszystkimi aplikacjami federacyjnymi. Chroń je jak kontrolery domeny: osobne konta administracyjne, brak logowania z codziennych stacji, aktualizacje i monitorowanie zdarzeń eksportu certyfikatów.

Czy w 2026 roku nadal wdrażać AD FS? Migracja do Microsoft Entra ID

Rola AD FS jest dostępna i wspierana także w Windows Server 2025, ale Microsoft od kilku lat zaleca przeniesienie uwierzytelniania do Microsoft Entra ID. Powody są praktyczne: farma AD FS i serwery WAP to kilka maszyn do utrzymania, certyfikaty do odnawiania i dodatkowa powierzchnia ataku, a Entra ID oferuje SSO do Microsoft 365 i aplikacji SaaS, dostęp warunkowy i ochronę tożsamości bez lokalnej infrastruktury.

Typowa ścieżka migracji wygląda tak:

1. Włącz w Entra Connect synchronizację skrótów haseł (Password Hash Sync), nawet jeśli nadal używasz federacji – to także zabezpieczenie na wypadek awarii AD FS.
2. Przejrzyj zaufania jednostek uzależnionych i raport aktywności aplikacji AD FS w Entra ID, który pokazuje, które aplikacje da się przenieść.
3. Skonfiguruj aplikacje SAML/OIDC jako aplikacje korporacyjne w Entra ID.
4. Przetestuj logowanie chmurowe na grupie pilotażowej funkcją wdrożenia etapowego (Staged Rollout).
5. Przełącz domenę z trybu federacyjnego na zarządzany i po okresie obserwacji wyłącz farmę AD FS.

AD FS nadal ma sens tam, gdzie uwierzytelnianie musi pozostać w całości lokalne (np. środowiska odcięte od internetu lub z wymaganiami regulacyjnymi) albo gdy firma integruje stare aplikacje obsługujące tylko WS-Federation i WS-Trust. W pozostałych przypadkach nowych wdrożeń AD FS raczej się już nie planuje.