Metodtips för att skydda Active Directory Federation Services

Det här dokumentet innehåller metodtips för säker planering och distribution av Active Directory Federation Services (AD FS) och Web Application Proxy (WAP). Den innehåller rekommendationer för ytterligare säkerhetskonfigurationer, specifika användningsfall och säkerhetskrav.

Det här dokumentet gäller AD FS och WAP i Windows Server 2012 R2, 2016 och 2019. Dessa rekommendationer kan användas för antingen ett lokalt nätverk eller i en molnbaserad miljö som Microsoft Azure.

Topologi för standarddistribution

För distribution i lokala miljöer rekommenderar vi en standardtopologi för distribution som består av:

• En eller flera AD FS-servrar i det interna företagsnätverket.
• En eller flera WAP-servrar (Web Application Proxy) i ett DMZ- eller extranätnätverk.

På varje lager, AD FS och WAP, placeras en lastbalanserare för maskinvara eller programvara framför servergruppen och hanterar trafikroutning. Brandväggar placeras framför den externa IP-adressen på lastbalanseraren vid behov.

Härdning av AD FS-servrar

Följande är en lista över bästa praxis och rekommendationer för härdning och skydd av din AD FS-distribution:

• Se till att endast Active Directory-administratörer och AD FS-administratörer har administratörsbehörighet till AD FS-systemet.
• Minska gruppmedlemskapet för lokala administratörer på alla AD FS-servrar.
• Kräv att alla molnadministratörer använder multifaktorautentisering (MFA).
• Minimal administrationsmöjligheter via agenter.
• Begränsa åtkomsten i nätverket via värdbrandväggen.
• Se till att AD FS-administratörer använder administratörsarbetsstationer för att skydda sina autentiseringsuppgifter.
• Placera AD FS-serverdatorobjekt i en organisationsenhet på den översta nivån som inte också är värd för andra servrar.
• GPO:er som gäller för AD FS-servrar bör endast tillämpas på dem och inte på andra servrar. Detta begränsar potentiell behörighetseskalering genom GPO-ändring.
• Se till att de installerade certifikaten är skyddade mot stöld (lagra inte dessa i en delad mapp i nätverket) och ange en kalenderpåminnelse för att säkerställa att de förnyas innan de upphör att gälla (utgångna certifikat orsakar fel i federationsautentisering). Dessutom rekommenderar vi att du skyddar signeringsnycklar/certifikat i en maskinvarusäkerhetsmodul (HSM) ansluten till AD FS.
• Ange loggning till den högsta nivån och skicka AD FS-loggarna (& säkerhet) till en SIEM för att korrelera med AD-autentisering samt AzureAD (eller liknande).
• Ta bort onödiga protokoll i Windows-funktioner &.
• Använd ett långt (>25 tecken), komplext lösenord för AD FS-tjänstkontot. Vi rekommenderar att du använder ett grupphanterat tjänstkonto (gMSA) som tjänstkonto, eftersom det tar bort behovet av att hantera lösenordet för tjänstkontot över tid genom att hantera det automatiskt.
• Uppdatera till den senaste AD FS-versionen för säkerhets- och loggningsförbättringar (som alltid testar du först).

Portar som krävs

Diagrammet nedan visar de brandväggsportar som måste aktiveras mellan och mellan komponenterna i AD FS- och WAP-distributionen. Om distributionen inte innehåller Microsoft Entra-ID/Office 365 kan synkroniseringskraven ignoreras.

Kommunikation mellan federationsservrar

Federationsservrar på en AD FS-servergrupp kommunicerar med andra servrar i servergruppen och WAP-servrarna (Web Application Proxy) via HTTP-port 80 för konfigurationssynkronisering. Se till att endast dessa servrar kan kommunicera med varandra och att inget annat är ett mått på skydd på djupet.

Organisationer kan uppnå det här tillståndet genom att konfigurera brandväggsregler på varje server. Reglerna bör endast tillåta inkommande kommunikation från IP-adresserna för servrarna i servergruppen och WAP-servrarna. Vissa nätverksbelastningsbalanserare (NLB) använder HTTP-port 80 för att avsökning av hälsotillståndet på enskilda federationsservrar. Se till att du inkluderar IP-adresserna för NLB i de konfigurerade brandväggsreglerna.

Microsoft Entra Connect och federationsservrar/WAP

I den här tabellen beskrivs de portar och protokoll som krävs för kommunikation mellan Microsoft Entra Connect-servern och Federation/WAP-servrar.

WAP- och federationsservrar

I den här tabellen beskrivs de portar och protokoll som krävs för kommunikation mellan federationsservrarna och WAP-servrarna.

WAP och användare

Den här tabellen beskriver de portar och protokoll som krävs för kommunikation mellan användare och WAP-servrarna.

Information om nödvändiga portar och protokoll som krävs för hybriddistributioner finns i Hybrid-referensanslutningsportar.

Information om portar och protokoll som krävs för en Microsoft Entra-ID och Office 365-distribution finns i dokumentet URL- och IP-adressintervall för Office 365.

Slutpunkter aktiverade

När AD FS och WAP installeras aktiveras en standarduppsättning AD FS-slutpunkter på federationstjänsten och på proxyn. Dessa standardvärden valdes baserat på de vanligaste scenarierna som krävs och används och det är inte nödvändigt att ändra dem.

Minsta uppsättning slutpunktsproxy aktiverad för Microsoft Entra ID och Office 365 (valfritt)

Organisationer som distribuerar AD FS och WAP endast för Microsoft Entra ID- och Office 365-scenarier kan ytterligare begränsa antalet AD FS-slutpunkter som är aktiverade på proxyn för att uppnå en mer minimal attackyta. Nedan visas en lista över slutpunkter som måste aktiveras på proxyn i följande scenarier:

AD FS-slutpunkter kan inaktiveras på proxyn med hjälp av följande PowerShell-cmdlet:

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

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

Utökat skydd för autentisering

Utökat skydd för autentisering är en funktion som minimerar mot mitm-attacker (man i mitten) och som är aktiverad som standard med AD FS. Inställningen kan verifieras med hjälp av PowerShell-cmdleten nedan:

Get-ADFSProperties

Egenskapen är ExtendedProtectionTokenCheck. Standardinställningen är Tillåt, så att säkerhetsfördelarna kan uppnås utan kompatibilitetsproblem med webbläsare som inte stöder funktionen.

Överbelastningskontroll för att skydda federationstjänsten

Federationstjänstproxyn (en del av WAP) ger överbelastningskontroll för att skydda AD FS-tjänsten från en flod av begäranden. Webbprogramproxyn avvisar externa klientautentiseringsbegäranden om federationsservern överbelastas enligt svarstiden mellan webbprogramproxyn och federationsservern. Den här funktionen konfigureras som standard med en rekommenderad tröskelvärdesnivå för svarstid. För att verifiera inställningarna kan du göra följande:

1. Starta ett förhöjt kommandofönster på din webbprogramproxydator.
2. Gå till AD FS-katalogen på %WINDIR%\adfs\config.
3. Ändra inställningarna för överbelastningskontroll från standardvärdena till <congestionControl latencyThresholdInMSec="8000" minCongestionWindowSize="64" enabled="true" />.
4. Spara och stäng filen.
5. Starta om AD FS-tjänsten genom att köra net stop adfssrv och sedan net start adfssrv.

Mer information om den här funktionen finns i Konfigurera extranätsåtkomst för AD FS på Windows Server 2012 R2.

Standardkontroller av HTTP-begäranden vid proxyn

Proxyn utför också följande standardkontroller mot all trafik:

• Själva FS-P autentiserar till AD FS via ett kortlivat certifikat. I ett scenario med misstänkt kompromettering av dmz-servrar kan AD FS "återkalla proxyförtroende" så att det inte längre litar på inkommande begäranden från potentiellt komprometterade proxyservrar. När proxyförtroendet återkallas, återkallas varje proxys eget certifikat så att det inte kan autentisera sig framgångsrikt för något syfte mot AD FS-servern.
• FS-P avslutar alla anslutningar och skapar en ny HTTP-anslutning till AD FS-tjänsten i det interna nätverket. Detta ger en buffert på sessionsnivå mellan externa enheter och AD FS-tjänsten. Den externa enheten ansluter aldrig direkt till AD FS-tjänsten.
• FS-P utför verifiering av HTTP-begäranden som specifikt filtrerar bort HTTP-huvuden som inte krävs av AD FS-tjänsten.

Rekommenderade säkerhetskonfigurationer

Se till att alla AD FS- och WAP-servrar får de senaste uppdateringarna. Den viktigaste säkerhetsrekommenderingen för DIN AD FS-infrastruktur är att se till att du har ett sätt att hålla DINA AD FS- och WAP-servrar aktuella med alla säkerhetsuppdateringar, samt de valfria uppdateringar som anges som viktiga för AD FS på den här sidan.

Det rekommenderade sättet för Microsoft Entra-kunder att övervaka och hålla sin infrastruktur uppdaterad är via Microsoft Entra Connect Health för AD FS, en funktion i Microsoft Entra ID P1 eller P2. Microsoft Entra Connect Health innehåller övervakare och aviseringar som utlöses om en AD FS- eller WAP-dator saknar en av de viktiga uppdateringarna specifikt för AD FS och WAP.

Mer information om hälsoövervakning för AD FS finns i Microsoft Entra Connect Health-agentinstallation.

Bästa praxis för att skydda och övervaka AD FS-förtroendet med Microsoft Entra-ID

När du federerar din AD FS med Microsoft Entra-ID är det viktigt att federationskonfigurationen (förtroenderelationen som konfigurerats mellan AD FS och Microsoft Entra ID) övervakas noggrant och att ovanlig eller misstänkt aktivitet registreras. För att göra det rekommenderar vi att du konfigurerar aviseringar och får aviseringar när eventuella ändringar görs i federationskonfigurationen. Information om hur du konfigurerar aviseringar finns i Övervaka ändringar i federationskonfigurationen.

Ytterligare säkerhetskonfigurationer

Följande ytterligare funktioner kan konfigureras för att ge mer skydd.

Extranäts "mjuk" utelåsningsskydd för konton

Med funktionen extranätsutelåsning i Windows Server 2012 R2 kan en AD FS-administratör ange ett maximalt antal misslyckade autentiseringsbegäranden (ExtranetLockoutThreshold) och en observation window tidsperiod (ExtranetObservationWindow). När det här maximala antalet (ExtranetLockoutThreshold) för autentiseringsbegäranden har nåtts, slutar AD FS att försöka autentisera de angivna kontoautentiseringsuppgifterna mot AD FS för den angivna tidsperioden (ExtranetObservationWindow). Den här åtgärden skyddar det här kontot från en AD-kontoutelåsning, det vill säga att det skyddar det här kontot från att förlora åtkomst till företagsresurser som förlitar sig på AD FS för autentisering av användaren. De här inställningarna gäller för alla domäner som AD FS-tjänsten kan autentisera.

Du kan använda följande Windows PowerShell-kommando för att ange AD FS extranätsutelåsning (exempel):

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

Mer information om den här funktionen finns i Konfigurera AD FS Extranet Lockout.

Inaktivera WS-Trust Windows-slutpunkter på proxyn från extranätet

WS-Trust Windows-slutpunkter (/adfs/services/trust/2005/windowstransport och /adfs/services/trust/13/windowstransport) är endast avsedda att vara intranätuppkopplade slutpunkter som använder WIA-bindning på HTTPS. Om de exponeras för extranätet kan begäranden mot dessa slutpunkter kringgå utestängningsskydd. Dessa slutpunkter bör inaktiveras på proxyn (dvs. de inaktiveras från extranät) för att skydda AD-kontolåsning med hjälp av följande PowerShell-kommandon. Det finns ingen känd slutanvändarpåverkan genom att inaktivera dessa slutpunkter på proxyn.

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

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

Differentiera åtkomstprinciper för intranät- och extranätåtkomst

AD FS har möjlighet att särskilja åtkomstprinciper för begäranden som kommer från det lokala företagsnätverket jämfört med begäranden som kommer in från Internet via proxyn. Den här differentiering kan göras per program eller globalt. För program med högt affärsvärde eller program med känslig information bör du överväga att kräva multifaktorautentisering. Multifaktorautentisering kan konfigureras via snapin-modulen för AD FS-hantering.

Kräv multifaktorautentisering (MFA)

AD FS kan konfigureras för att kräva stark autentisering (till exempel multifaktorautentisering) specifikt för begäranden som kommer in via proxyn, för enskilda program och för villkorlig åtkomst till både Microsoft Entra ID/Office 365 och lokala resurser. MFA-metoder som stöds omfattar både Microsoft Azure MF och tredjepartsleverantörer. Användaren uppmanas att ange ytterligare information (till exempel en SMS-text som innehåller en engångskod) och AD FS fungerar med providerspecifikt plugin-program för att tillåta åtkomst.

Externa MFA-leverantörer som stöds innehåller de som anges på sidan Konfigurera ytterligare autentiseringsmetoder för AD FS.

Aktivera skydd för att förhindra förbiströmning av molnbaserad Microsoft Entra-multifaktorautentisering när den federeras med Microsoft Entra-ID

Aktivera skydd för att förhindra förbiströmning av molnbaserad Microsoft Entra-multifaktorautentisering när den federeras med Microsoft Entra-ID och använder Microsoft Entra multifaktorautentisering som multifaktorautentisering för dina federerade användare.

Om du aktiverar skyddet för en federerad domän i din Microsoft Entra-klientorganisation ser du till att Microsoft Entra multifaktorautentisering alltid utförs när en federerad användare får åtkomst till ett program som styrs av en princip för villkorlig åtkomst som kräver MFA. Detta inkluderar att utföra Microsoft Entra multifaktorautentisering även när federerad identitetsprovider har angett (via federerade tokenanspråk) att lokal MFA har utförts. Framtvinga Microsoft Entra multifaktorautentisering varje gång säkerställer att ett komprometterat lokalt konto inte kan kringgå Microsoft Entra multifaktorautentisering genom att imitera att en multifaktorautentisering redan har utförts av identitetsprovidern och rekommenderas starkt om du inte utför MFA för dina federerade användare med hjälp av en MFA-provider från tredje part.

Skyddet kan aktiveras med hjälp av en ny säkerhetsinställning, federatedIdpMfaBehavior, som är tillgänglig som en del av interfederations MS Graph API eller MS Graph PowerShell cmdlets. Inställningen federatedIdpMfaBehavior avgör om Microsoft Entra-ID accepterar MFA som utförs av den federerade identitetsprovidern när en federerad användare får åtkomst till ett program som styrs av en princip för villkorsstyrd åtkomst som kräver MFA.

Administratörer kan välja något av följande värden:

Du kan aktivera skydd genom att ange federatedIdpMfaBehavior till rejectMfaByFederatedIdp med hjälp av följande kommando.

API FÖR MS-DIAGRAM

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

{ 

"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp" 

} 

Example:

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

{ 

"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp" 

Example:

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

Example:

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

Maskinvarusäkerhetsmodul (HSM)

I sin standardkonfiguration lämnar de nycklar som AD FS använder för att signera tokenen aldrig federationsservrarna i intranätet. De finns aldrig i DMZ eller på proxydatorerna. Om du vill ge mer skydd rekommenderar vi att du skyddar dessa nycklar i en maskinvarusäkerhetsmodul (HSM) som är kopplad till AD FS. Microsoft producerar inte en HSM-produkt, men det finns flera på marknaden som stöder AD FS. För att implementera den här rekommendationen följer du leverantörsvägledningen för att skapa X509-certifikaten för signering och kryptering och använder sedan POWERShell-installationskommandona för AD FS-installationen och anger dina anpassade certifikat på följande sätt:

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

where:

• CertificateThumbprint är ditt SSL-certifikat
• SigningCertificateThumbprint är ditt signeringscertifikat (med HSM-skyddad nyckel)
• DecryptionCertificateThumbprint är ditt krypteringscertifikat (med HSM-skyddad nyckel)