Delen via

Aanbevolen procedures voor het beveiligen van Active Directory Federation Services

Dit document bevat aanbevolen procedures voor de veilige planning en implementatie van Active Directory Federation Services (AD FS) en Web Application Proxy (WAP). Het bevat aanbevelingen voor aanvullende beveiligingsconfiguraties, specifieke use cases en beveiligingsvereisten.

Dit document is van toepassing op AD FS en WAP in Windows Server 2012 R2, 2016 en 2019. Deze aanbevelingen kunnen worden gebruikt voor een on-premises netwerk of in een in de cloud gehoste omgeving, zoals Microsoft Azure.

Standaardimplementatietopologie

Voor implementatie in on-premises omgevingen raden we een standaardimplementatietopologie aan die bestaat uit:

  • Een of meer AD FS-servers op het interne bedrijfsnetwerk.
  • Een of meer WAP-servers (Web Application Proxy) in een DMZ- of extranetnetwerk.

Bij elke laag worden een hardware- of software-load balancer voor de serverfarm van AD FS en WAP geplaatst, en wordt de verkeersroutering afgehandeld. Firewalls worden indien nodig geplaatst vóór het externe IP-adres van de load balancer.

A-diagram met een standaard A D F S-topologie.

Notitie

AD FS vereist een volledige beschrijfbare domeincontroller om te functioneren in plaats van een Read-Only domeincontroller. Als een geplande topologie een Read-Only domeincontroller bevat, kan de Read-Only domeincontroller worden gebruikt voor verificatie, maar de verwerking van LDAP-claims vereist een verbinding met de beschrijfbare domeincontroller.

Uw AD FS-servers beveiligen

Hier volgt een lijst met best practices en aanbevelingen voor het versterken en beveiligen van uw AD FS-implementatie.

  • Zorg ervoor dat alleen Active Directory-beheerders en AD FS-beheerders beheerdersrechten hebben voor het AD FS-systeem.
  • Verminder het groepslidmaatschap lokale administrators op alle AD FS-servers.
  • Vereisen dat alle cloudbeheerders meervoudige verificatie (MFA) gebruiken.
  • Minimale beheermogelijkheden via agents.
  • Beperk de toegang tot het netwerk via een hostfirewall.
  • Zorg ervoor dat AD FS-beheerders beheerwerkstations gebruiken om hun referenties te beveiligen.
  • Plaats AD FS-servercomputerobjecten in een organisatie-eenheid op het hoogste niveau die niet ook als host fungeert voor andere servers.
  • Alle GPO's die van toepassing zijn op AD FS-servers moeten alleen van toepassing zijn op deze servers en niet op andere servers. Dit beperkt mogelijke escalatie van bevoegdheden via GPO-wijziging.
  • Zorg ervoor dat de geïnstalleerde certificaten worden beveiligd tegen diefstal (sla deze niet op een share op het netwerk op) en stel een agendaherinnering in om ervoor te zorgen dat ze worden vernieuwd voordat ze verlopen (verlopen certificaat breekt federatieverificatie). Daarnaast raden we u aan ondertekeningssleutels/certificaten te beveiligen in een HSM (Hardware Security Module) gekoppeld aan AD FS.
  • Stel logboekregistratie in op het hoogste niveau en verzend de AD FS-logboeken (& beveiliging) naar een SIEM om te correleren met AD-verificatie en AzureAD (of vergelijkbaar).
  • Verwijder overbodige protocollen & Windows- functies.
  • Gebruik een lang (>25 tekens), complex wachtwoord voor het AD FS-serviceaccount. U wordt aangeraden een GMSA- (Group Managed Service Account) te gebruiken als het serviceaccount, omdat hiermee het wachtwoord voor het serviceaccount in de loop van de tijd niet meer hoeft te worden beheerd door het automatisch te beheren.
  • Update naar de nieuwste AD FS-versie voor verbeteringen in beveiliging en logboekregistratie (zoals altijd, test eerst).

Vereiste poorten

In het onderstaande diagram ziet u de firewallpoorten die moeten worden ingeschakeld tussen en onder de onderdelen van de AD FS- en WAP-implementatie. Als de implementatie geen Microsoft Entra-id/Office 365 bevat, kunnen de synchronisatievereisten worden genegeerd.

Notitie

Poort 49443 is alleen vereist als verificatie van gebruikerscertificaten wordt gebruikt, wat optioneel is voor Microsoft Entra-id en Office 365.

een diagram met de vereiste poorten en protocollen voor een A D F S-implementatie.

Notitie

Poort 808 (Windows Server 2012R2) of poort 1501 (Windows Server 2016+) is het net. TCP-poort AD FS gebruikt voor het lokale WCF-eindpunt om configuratiegegevens over te dragen naar het serviceproces en PowerShell. Deze poort kan worden weergegeven door Get-AdfsProperties | selecteer NetTcpPort. Dit is een lokale poort die niet hoeft te worden geopend in de firewall, maar wordt weergegeven in een poortscan.

Communicatie tussen federatieservers

Federatieservers op een AD FS-farm communiceren met andere servers in de farm en de WAP-servers (Web Application Proxy) via HTTP-poort 80 voor configuratiesynchronisatie. Zorg ervoor dat alleen deze servers met elkaar kunnen communiceren en geen andere een diepgaande verdedigingsmaatregel is.

Organisaties kunnen deze status bereiken door firewallregels in te stellen op elke server. De regels mogen alleen binnenkomende communicatie van de IP-adressen van de servers in de serverfarm en van de WAP-servers toestaan. Sommige Netwerk load balancers (NLB) gebruiken HTTP-poort 80 voor het testen van de status op afzonderlijke federatieservers. Zorg ervoor dat u de IP-adressen van de NLB opneemt in de geconfigureerde firewallregels.

Microsoft Entra Connect en Federation Servers/WAP

In deze tabel worden de poorten en protocollen beschreven die vereist zijn voor communicatie tussen de Microsoft Entra Connect-server en federatie-/WAP-servers.

protocol Poorten Beschrijving
HTTP 80 (TCP/UDP) Wordt gebruikt om CRL's (certificaatintrekkingslijsten) te downloaden om SSL-certificaten te verifiëren.
HTTPS 443(TCP/UDP) Wordt gebruikt om te synchroniseren met Microsoft Entra-id.
WinRM 5985 WinRM Listener.

WAP- en Federatieservers

In deze tabel worden de poorten en protocollen beschreven die vereist zijn voor communicatie tussen de federatieservers en WAP-servers.

protocol Poorten Beschrijving
HTTPS 443(TCP/UDP) Wordt gebruikt voor verificatie.

WAP en gebruikers

In deze tabel worden de poorten en protocollen beschreven die vereist zijn voor communicatie tussen gebruikers en de WAP-servers.

protocol Poorten Beschrijving
HTTPS 443(TCP/UDP) Wordt gebruikt voor apparaatverificatie.
TCP 49443 (TCP) Wordt gebruikt voor certificaatverificatie.

Zie Hybride referentiepoortenvoor informatie over vereiste poorten en protocollen die vereist zijn voor hybride implementaties.

Zie het document OFFICE 365-URL en IP-adresbereikenvoor informatie over poorten en protocollen die vereist zijn voor een Microsoft Entra-id en Office 365-implementatie.

Eindpunten ingeschakeld

Wanneer AD FS en WAP zijn geïnstalleerd, wordt een standaardset AD FS-eindpunten ingeschakeld op de federation-service en op de proxy. Deze standaardwaarden zijn gekozen op basis van de meest vereiste en gebruikte scenario's en het is niet nodig om ze te wijzigen.

Minimale set eindpuntenproxy geactiveerd voor Microsoft Entra-ID en Office 365 (optioneel)

Organisaties die AD FS en WAP alleen implementeren voor Microsoft Entra ID- en Office 365-scenario's kunnen het aantal AD FS-eindpunten dat is ingeschakeld op de proxy beperken om een minimalere kwetsbaarheid voor aanvallen te bereiken. Hieronder ziet u de lijst met eindpunten die moeten worden ingeschakeld voor de proxy in deze scenario's:

Eindpunt Doel
/adfs/ls/ Op browsers gebaseerde verificatiestromen en huidige versies van Microsoft Office gebruiken dit eindpunt voor Microsoft Entra-id en Office 365-verificatie
/adfs/services/trust/2005/usernamemixed Wordt gebruikt voor Exchange Online met Office-clients die ouder zijn dan office 2013-update van mei 2015. Latere clients gebruiken het passieve \adfs\ls-eindpunt.
/adfs/services/trust/13/usernamemixed Wordt gebruikt voor Exchange Online met Office-clients die ouder zijn dan office 2013-update van mei 2015. Latere clients gebruiken het passieve \adfs\ls-eindpunt.
/adfs/oauth2/ Wordt gebruikt voor moderne apps (on-premises of in de cloud) die u hebt geconfigureerd om direct te authenticeren met AD FS (dus niet via Microsoft Entra ID)
/adfs/services/trust/mex Wordt gebruikt voor Exchange Online met Office-clients die ouder zijn dan office 2013-update van mei 2015. Latere clients gebruiken het passieve \adfs\ls-eindpunt.
/federationmetadata/2007-06/federationmetadata.xml Vereiste voor passieve stromen; en wordt gebruikt door Office 365/Microsoft Entra ID om AD FS-certificaten te controleren.

AD FS-eindpunten kunnen worden uitgeschakeld in de proxy met behulp van de volgende PowerShell-cmdlet:

Set-AdfsEndpoint -TargetAddressPath <address path> -Proxy $false

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/13/certificatemixed -Proxy $false

Uitgebreide beveiliging voor verificatie

Uitgebreide beveiliging voor verificatie is een functie die tegen man in het midden (MITM) aanvallen beperkt en is standaard ingeschakeld met AD FS. De instelling kan worden geverifieerd met behulp van de onderstaande PowerShell-cmdlet:

Get-ADFSProperties

De eigenschap is ExtendedProtectionTokenCheck. De standaardinstelling is Toestaan, zodat de beveiligingsvoordelen kunnen worden bereikt zonder de compatibiliteitsproblemen met browsers die de mogelijkheid niet ondersteunen.

Congestiecontrole om de federation-service te beschermen

De federation-serviceproxy (onderdeel van de WAP) biedt congestiecontrole om de AD FS-service te beschermen tegen een overstroming van aanvragen. De webtoepassingsproxy weigert aanvragen voor externe clientverificatie als de federatieserver overbelast is, zoals gedetecteerd door de latentie tussen de webtoepassingsproxy en de federatieserver. Deze functie is standaard geconfigureerd met een aanbevolen drempelwaarde voor latentie. Als u de instellingen wilt controleren, kunt u het volgende doen:

  1. Start op uw webtoepassingsproxycomputer een opdrachtvenster met verhoogde bevoegdheid.
  2. Navigeer naar de AD FS-map op %WINDIR%\adfs\config.
  3. Wijzig de instellingen voor congestiebeheer van de standaardwaarden naar <congestionControl latencyThresholdInMSec="8000" minCongestionWindowSize="64" enabled="true" />.
  4. Sla het bestand op en sluit het.
  5. Start de AD FS-service opnieuw door net stop adfssrv uit te voeren en vervolgens net start adfssrv.

Zie Extranet-toegang configureren voor AD FS op Windows Server 2012 R2voor hulp bij deze mogelijkheid.

Standaard-HTTP-aanvraagcontroles bij de proxy

De proxy voert ook de volgende standaardcontroles uit op al het verkeer:

  • De FS-P zelf wordt geverifieerd bij AD FS via een kortlevend certificaat. In een scenario van vermoedelijke inbreuk op dmz-servers kan AD FS 'proxyvertrouwen intrekken' zodat deze geen binnenkomende aanvragen van mogelijk aangetaste proxy's meer vertrouwt. Als u de proxyvertrouwensrelatie intrekt, wordt het eigen certificaat van elke proxy ingetrokken, zodat het niet kan worden geverifieerd voor enig doel op de AD FS-server.
  • De FS-P beëindigt alle verbindingen en maakt een nieuwe HTTP-verbinding met de AD FS-service op het interne netwerk. Dit biedt een buffer op sessieniveau tussen externe apparaten en de AD FS-service. Het externe apparaat maakt nooit rechtstreeks verbinding met de AD FS-service.
  • De FS-P voert HTTP-aanvraagvalidatie uit die specifiek HTTP-headers filtert die niet vereist zijn voor de AD FS-service.

Zorg ervoor dat alle AD FS- en WAP-servers de meest recente updates ontvangen. De belangrijkste beveiligingsaanbieding voor uw AD FS-infrastructuur is ervoor te zorgen dat u een middel hebt om uw AD FS- en WAP-servers actueel te houden met alle beveiligingsupdates, evenals die optionele updates die zijn opgegeven als belangrijk voor AD FS op deze pagina.

De aanbevolen manier voor Microsoft Entra-klanten om hun infrastructuur te bewaken en bij te houden, is via Microsoft Entra Connect Health voor AD FS, een functie van Microsoft Entra ID P1 of P2. Microsoft Entra Connect Health bevat monitors en waarschuwingen die worden geactiveerd als een AD FS- of WAP-computer een van de belangrijke updates mist die specifiek zijn bedoeld voor AD FS en WAP.

Zie Microsoft Entra Connect Health-agentinstallatievoor meer informatie over statuscontrole voor AD FS.

Aanbevolen procedure voor het beveiligen en bewaken van de AD FS-vertrouwensrelatie met Microsoft Entra-id

Wanneer u uw AD FS federeert met Microsoft Entra ID, is het van cruciaal belang dat de federatieconfiguratie (vertrouwensrelatie die is geconfigureerd tussen AD FS en Microsoft Entra ID) nauw wordt bewaakt en eventuele ongebruikelijke of verdachte activiteiten worden vastgelegd. Hiervoor raden we u aan waarschuwingen in te stellen en een melding te ontvangen wanneer er wijzigingen worden aangebracht in de federatieconfiguratie. Zie Wijzigingen in de federatieconfiguratie controlerenvoor meer informatie over het instellen van waarschuwingen.

Aanvullende beveiligingsconfiguraties

De volgende aanvullende mogelijkheden kunnen worden geconfigureerd om meer beveiliging te bieden.

Beveiliging tegen 'zachte' vergrendeling van extranets voor accounts

Met de functie extranetvergrendeling in Windows Server 2012 R2 kan een AD FS-beheerder een maximaal toegestaan aantal mislukte verificatieaanvragen (ExtranetLockoutThreshold) en een observation window periode (ExtranetObservationWindow) instellen. Wanneer dit maximumaantal verificatieaanvragen (ExtranetLockoutThreshold) is bereikt, stopt AD FS met het proberen te verifiëren van de opgegeven accountinloggegevens tegen AD FS voor de ingestelde periode (ExtranetObservationWindow). Deze actie beveiligt dit account tegen een AD-accountvergrendeling, met andere woorden, het beschermt dit account tegen verlies van toegang tot bedrijfsresources die afhankelijk zijn van AD FS voor verificatie van de gebruiker. Deze instellingen zijn van toepassing op alle domeinen die de AD FS-service kan verifiëren.

U kunt de volgende Windows PowerShell-opdracht gebruiken om de AD FS-extranetvergrendeling in te stellen (voorbeeld):

Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 15 -ExtranetObservationWindow ( new-timespan -Minutes 30 )

Zie AD FS Extranet Lockout configureren voor meer informatie over deze functie.

Schakel WS-Trust Windows-eindpunten in de proxy uit vanuit het extranet

WS-Trust Windows-eindpunten (/adfs/services/trust/2005/windowstransport en /adfs/services/trust/13/windowstransport) zijn alleen intranetgerichte eindpunten die gebruikmaken van WIA-binding op HTTPS. Door ze bloot te stellen aan een extranet, zou het kunnen toestaan dat aanvragen tegen deze eindpunten de lockoutbescherming omzeilen. Deze eindpunten moeten worden uitgeschakeld in de proxy (d.w.w. uitgeschakeld vanuit extranet) om ad-accountvergrendeling te beveiligen met behulp van de volgende PowerShell-opdrachten. Er is geen bekende impact op de eindgebruiker door het uitschakelen van deze eindpunten op de proxy.

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/2005/windowstransport -Proxy $false

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/13/windowstransport -Proxy $false

Notitie

Als uw AD FS-farm wordt uitgevoerd op Windows Interne databases (WID) en een secundaire AD FS-server heeft, nadat de eindpunten op de primaire server zijn uitgeschakeld, wacht u tot de SYNCHRONISATIE plaatsvindt op secundaire knooppunten voordat u de AD FS-service erop opnieuw start. Gebruik de PowerShell-opdracht Get-AdfsSyncProperties op het secundaire knooppunt om het laatste SYNCHRONISATIEproces bij te houden.

Toegangsbeleid onderscheiden voor intranet- en extranettoegang

AD FS heeft de mogelijkheid om onderscheid te maken tussen toegangsbeleid voor aanvragen die afkomstig zijn uit het lokale, bedrijfsnetwerk versus aanvragen die afkomstig zijn van internet via de proxy. Deze differentiatie kan per toepassing of wereldwijd worden uitgevoerd. Voor toepassingen met hoge bedrijfswaarde of toepassingen met gevoelige informatie kunt u overwegen meervoudige verificatie te vereisen. Meervoudige verificatie kan worden ingesteld via de AD FS-beheermodule.

Meervoudige verificatie (MFA) vereisen

AD FS kan worden geconfigureerd om sterke verificatie (zoals meervoudige verificatie) specifiek te vereisen voor aanvragen die binnenkomen via de proxy, voor afzonderlijke toepassingen en voor voorwaardelijke toegang tot zowel Microsoft Entra ID / Office 365 als on-premises resources. Ondersteunde methoden van MFA omvatten zowel Microsoft Azure MF- als externe providers. De gebruiker wordt gevraagd om de aanvullende informatie op te geven (zoals een sms-tekst met een eenmalige code) en AD FS werkt met de provider specifieke invoegtoepassing om toegang toe te staan.

Ondersteunde externe MFA-providers omvatten de providers die worden vermeld in de Aanvullende verificatiemethoden configureren voor AD FS pagina.

Bescherming inschakelen om te voorkomen dat de cloud-multifactorauthenticatie van Microsoft Entra wordt omzeild wanneer deze is gefedereerd met Microsoft Entra ID.

Schakel beveiliging in om te voorkomen dat microsoft Entra-meervoudige verificatie in de cloud wordt overgeslagen wanneer deze is gefedereerd met Microsoft Entra-id en microsoft Entra-meervoudige verificatie gebruikt als uw meervoudige verificatie voor uw federatieve gebruikers.

Als u de beveiliging inschakelt voor een federatief domein in uw Microsoft Entra-tenant, zorgt u ervoor dat Microsoft Entra-meervoudige verificatie altijd wordt uitgevoerd wanneer een federatieve gebruiker toegang krijgt tot een toepassing die wordt beheerd door een beleid voor voorwaardelijke toegang waarvoor MFA is vereist. Dit omvat het uitvoeren van Microsoft Entra multifactor authenticatie, zelfs wanneer de gefedereerde identiteitsprovider heeft aangegeven (via federatieve tokenclaims) dat plaatselijke MFA is uitgevoerd. Het elke keer afdwingen van Microsoft Entra meervoudige verificatie zorgt ervoor dat een gecompromitteerd on-premises account de Microsoft Entra meervoudige verificatie niet kan omzeilen door te doen alsof er al een verificatie door de identiteitsprovider is uitgevoerd, en het wordt ten zeerste aanbevolen tenzij u MFA uitvoert voor uw gefedereerde gebruikers via een externe MFA-provider.

De beveiliging kan worden ingeschakeld met behulp van een nieuwe beveiligingsinstelling, federatedIdpMfaBehavior, die wordt weergegeven als onderdeel van de interne MS Graph API- of MS Graph PowerShell-cmdlets. De federatedIdpMfaBehavior-instelling bepaalt of Microsoft Entra ID de MFA accepteert die wordt uitgevoerd door de federatieve id-provider wanneer een federatieve gebruiker toegang heeft tot een toepassing die wordt beheerd door een beleid voor voorwaardelijke toegang waarvoor MFA is vereist.

Beheerders kunnen een van de volgende waarden kiezen:

Vastgoed Beschrijving
AccepterenAlsMfaGedaanDoorFederatedIdp Microsoft Entra ID accepteert MFA als deze wordt uitgevoerd door de id-provider. Als dat niet het geval is, voert u Microsoft Entra multifactorauthenticatie uit.
enforceMfaByFederatedIdp Microsoft Entra ID accepteert MFA als deze wordt uitgevoerd door de id-provider. Zo niet, dan wordt de aanvraag omgeleid naar de id-provider om MFA uit te voeren.
rejectMfaByFederatedIdp Microsoft Entra-id voert altijd Meervoudige Verificatie van Microsoft Entra uit en weigert MFA als deze wordt uitgevoerd door de id-provider.

U kunt beveiliging inschakelen door federatedIdpMfaBehavior in te stellen op rejectMfaByFederatedIdp met behulp van de volgende opdracht.

MS GRAPH API

 PATCH /domains/{domainsId}/federationConfiguration/{internalDomainFederationId} 

{ 

"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp" 

}

Voorbeeld:

PATCH /domains/contoso.com/federationConfiguration/2a8ce608-bb34-473f-9e0f-f373ee4cbc5a 

{ 

"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp"

Voorbeeld:

Update-MgDomainFederationConfiguration -DomainId <domainsId> -InternalDomainFederationId <internalDomainFederationId> federatedIdpMfaBehavior "rejectMfaByFederatedIdp"

Voorbeeld:

Update-MgDomainFederationConfiguration -DomainId “contoso.com” -InternalDomainFederationId “2a8ce608-bb34-473f-9e0f-f373ee4cbc5a” federatedIdpMfaBehavior "rejectMfaByFederatedIdp"

Hardware Security Module (HSM)

In de standaardconfiguratie worden de sleutels die AD FS gebruikt om tokens te ondertekenen nooit de federatieservers op het intranet verlaten. Ze zijn nooit aanwezig in de DMZ of op de proxymachines. Als u meer beveiliging wilt bieden, raden we u aan deze sleutels te beveiligen in een HSM (Hardware Security Module) die is gekoppeld aan AD FS. Microsoft produceert geen HSM-product, maar er zijn verschillende op de markt die AD FS ondersteunen. Als u deze aanbeveling wilt implementeren, volgt u de richtlijnen van de leverancier voor het maken van de X509-certificaten voor ondertekening en versleuteling en gebruikt u vervolgens de Ad FS-installatie PowerShell-commandlets, waarbij u uw aangepaste certificaten als volgt opgeeft:

Install-AdfsFarm -CertificateThumbprint <String> -DecryptionCertificateThumbprint <String> -FederationServiceName <String> -ServiceAccountCredential <PSCredential> -SigningCertificateThumbprint <String>

waarbij geldt:

  • CertificateThumbprint is uw SSL-certificaat
  • SigningCertificateThumbprint is uw handtekeningcertificaat (met met HSM beveiligde sleutel)
  • DecryptionCertificateThumbprint is uw versleutelingscertificaat (met met HSM beveiligde sleutel)