Condividi tramite

Procedure consigliate per la protezione di Active Directory Federation Services

Questo documento fornisce le procedure consigliate per la pianificazione e la distribuzione sicure di Active Directory Federation Services (AD FS) e proxy applicazione Web (WAP). Contiene raccomandazioni per configurazioni di sicurezza aggiuntive, casi d'uso specifici e requisiti di sicurezza.

Questo documento si applica ad AD FS e WAP in Windows Server 2012 R2, 2016 e 2019. Queste raccomandazioni possono essere usate per una rete locale o in un ambiente ospitato nel cloud, ad esempio Microsoft Azure.

Topologia di distribuzione standard

Per la distribuzione in ambienti locali, è consigliabile una topologia di distribuzione standard costituita da:

  • Uno o più server AD FS nella rete aziendale interna.
  • Uno o più server Proxy applicazione Web (WAP) in una rete perimetrale o extranet.

A ogni livello, AD FS e WAP, un servizio di bilanciamento del carico hardware o software viene posizionato davanti alla server farm e gestisce il routing del traffico. I firewall vengono posizionati davanti all'indirizzo IP esterno del servizio di bilanciamento del carico in base alle esigenze.

Diagramma che illustra una topologia A D F S standard.

Nota

AD FS richiede un controller di dominio scrivibile completo per funzionare anziché un controller di dominio di sola lettura. Se una topologia pianificata include un controller di dominio di sola lettura, il controller di dominio di sola lettura può essere usato per l'autenticazione, ma l'elaborazione delle attestazioni LDAP richiederà una connessione al controller di dominio scrivibile.

Protezione avanzata dei server AD FS

Di seguito è riportato un elenco di procedure consigliate e consigli per la protezione avanzata e la protezione della distribuzione di AD FS:

  • Assicurarsi che solo gli amministratori di Active Directory e gli amministratori di AD FS dispongano dei diritti di amministratore per il sistema AD FS.
  • Ridurre l'appartenenza al gruppo Amministratore locale in tutti i server AD FS.
  • Richiedere a tutti gli amministratori del cloud di usare l'autenticazione a più fattori (MFA).
  • Funzionalità di amministrazione minima tramite agenti.
  • Limitare l'accesso in rete tramite il firewall host.
  • Assicurarsi che gli amministratori di AD FS usino workstation di amministrazione per proteggere le credenziali.
  • Posizionare oggetti computer server AD FS in un'unità organizzativa di primo livello che non ospita anche altri server.
  • Tutti gli oggetti Criteri di gruppo che si applicano ai server AD FS devono essere applicati solo ad essi e non ad altri server. Questo limita la potenziale escalation dei privilegi tramite la modifica dell'oggetto Criteri di gruppo.
  • Assicurarsi che i certificati installati siano protetti dal furto (non archiviare i certificati in una condivisione in rete) e impostare un promemoria del calendario per assicurarsi che vengano rinnovati prima della scadenza (i certificati scaduti non sono conformi all’autenticazione di federazione). È inoltre consigliabile proteggere le chiavi o i certificati di firma in un modulo di protezione hardware (HSM) collegato ad AD FS.
  • Impostare la registrazione al livello più alto e inviare i log di AD FS (& sicurezza) a un SIEM per correlarli con l'autenticazione di Active Directory e AzureAD (o simili).
  • Rimuovere i protocolli & le funzionalità di Windows non necessari.
  • Usare una password lunga (>25 caratteri), complessa per l'account del servizio AD FS. È consigliabile usare un account del servizio gestito di gruppo (gMSA) come account del servizio, perché rimuove la necessità di occuparsi della password dell'account del servizio nel tempo gestendola automaticamente.
  • Eseguire l'aggiornamento alla versione più recente di AD FS per i miglioramenti della sicurezza e della registrazione (come sempre, eseguire prima un test).

Porte necessarie

Il diagramma seguente illustra le porte del firewall che devono essere abilitate tra i componenti della distribuzione di AD FS e WAP. Se la distribuzione non include Microsoft Entra ID/Office 365, i requisiti di sincronizzazione possono essere ignorati.

Nota

La porta 49443 è necessaria solo se viene utilizzata l'autenticazione del certificato utente, che è facoltativa per Microsoft Entra ID e Office 365.

Diagramma che mostra le porte e i protocolli necessari per una distribuzione di A D F S.

Nota

La porta 808 (Windows Server 2012R2) o la porta 1501 (Windows Server 2016+) è Net. AD FS usa la porta TCP per l'endpoint WCF locale al fine di trasferire i dati di configurazione al processo del servizio e PowerShell. Questa porta può essere visualizzata eseguendo Get-AdfsProperties, quindi selezionare NetTcpPort. Si tratta di una porta locale che non dovrà essere aperta nel firewall, ma verrà visualizzata in un'analisi delle porte.

Comunicazione tra server federativi

I server federativi in una farm AD FS comunicano con altri server nella farm e i server Proxy applicazione Web (WAP) tramite la porta HTTP 80 per la sincronizzazione della configurazione. Assicurarsi che solo questi server possano comunicare tra loro e che nessuno sia una misura di difesa approfondita.

Le organizzazioni possono eseguire questo stato configurando le regole del firewall in ogni server. Le regole devono consentire solo la comunicazione in ingresso dagli indirizzi IP dei server nella farm e nei server WAP. Alcuni servizi di bilanciamento del carico di rete (NLB) usano la porta HTTP 80 per eseguire il probe dell'integrità nei singoli server federativi. Assicurarsi di includere gli indirizzi IP del bilanciamento carico di rete nelle regole del firewall configurate.

Microsoft Entra Connect e server federativi/WAP

Questa tabella descrive le porte e i protocolli necessari per la comunicazione tra il server Microsoft Entra Connect e i server federativi/WAP.

Protocollo Porte Descrizione
HTTP 80 (TCP/UDP) Usato per il download di CRL (Certificate Revocation List) per verificare i certificati SSL.
HTTPS 443 (TCP/UDP) Utilizzato per la sincronizzazione con Microsoft Entra ID.
WinRM 5985 Listener WinRM.

Server WAP e federativi

Questa tabella descrive le porte e i protocolli necessari per la comunicazione tra i server federativi e i server WAP.

Protocollo Porte Descrizione
HTTPS 443 (TCP/UDP) Usato per l'autenticazione.

WAP e utenti

Questa tabella descrive le porte e i protocolli necessari per la comunicazione tra gli utenti e i server WAP.

Protocollo Porte Descrizione
HTTPS 443 (TCP/UDP) Usato per l'autenticazione del dispositivo.
TCP 49443 (TCP) Usato per l'autenticazione del certificato.

Per informazioni sulle porte e i protocolli necessari per le distribuzioni ibride, vedere Porte di connessione ibride di riferimento.

Per informazioni sulle porte e sui protocolli necessari per una distribuzione di Microsoft Entra ID e Office 365, consultare il documento Intervalli di URL e indirizzi IP di Office 365.

Endpoint abilitati

Quando vengono installati AD FS e WAP, nel servizio federativo e nel proxy viene abilitato un set predefinito di endpoint AD FS. Queste impostazioni predefinite sono state scelte in base agli scenari più comuni richiesti e usati e non è necessario modificarle.

Set minimo di proxy endpoint abilitato per Microsoft Entra ID/Office 365 (facoltativo)

Le organizzazioni che distribuiscono AD FS e WAP solo per gli scenari Microsoft Entra ID e Office 365 possono limitare ulteriormente il numero di endpoint AD FS abilitati nel proxy per ottenere una superficie di attacco più minima. Di seguito è riportato l'elenco degli endpoint che devono essere abilitati nel proxy in questi scenari:

Endpoint Ambito
/adfs/ls/ I flussi di autenticazione basati su browser e le versioni correnti di Microsoft Office usano questo endpoint per Microsoft Entra ID e l'autenticazione di Office 365
/adfs/services/trust/2005/usernamemixed Usato per Exchange Online con i client Office precedenti all'aggiornamento di Office 2013 di maggio 2015. I client successivi usano l'endpoint passivo \adfs\ls.
/adfs/services/trust/13/usernamemixed Usato per Exchange Online con i client Office precedenti all'aggiornamento di Office 2013 di maggio 2015. I client successivi usano l'endpoint passivo \adfs\ls.
/adfs/oauth2/ Usato per tutte le app moderne (locali o nel cloud) configurate per l'autenticazione direttamente in ADFS (ad esempio, non tramite Microsoft Entra ID)
/adfs/services/trust/mex Usato per Exchange Online con i client Office precedenti all'aggiornamento di Office 2013 di maggio 2015. I client successivi usano l'endpoint passivo \adfs\ls.
/federationmetadata/2007-06/federationmetadata.xml Requisito di eventuali flussi passivi e usato da Office 365/Microsoft Entra ID per controllare i certificati AD FS.

Gli endpoint AD FS possono essere disabilitati nel proxy usando il cmdlet di PowerShell seguente:

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

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

Protezione estesa per l'autenticazione

La protezione estesa per l'autenticazione è una funzionalità che attenua gli attacchi Man in the middle (MITM) ed è abilitata per impostazione predefinita con AD FS. L'impostazione può essere verificata usando il cmdlet di PowerShell seguente:

Get-ADFSProperties

La proprietà è ExtendedProtectionTokenCheck. L'impostazione predefinita è Consenti, in modo che i vantaggi di sicurezza possano essere ottenuti senza problemi di compatibilità con i browser che non supportano la funzionalità.

Controllo congestione per proteggere il servizio federativo

Il proxy del servizio federativo (parte del WAP) fornisce il controllo della congestione per proteggere il servizio AD FS da un'inondazione di richieste. Il proxy applicazione Web rifiuterà le richieste di autenticazione client esterne in caso di sovraccarico del server federativo rilevato dalla latenza tra il proxy applicazione Web e il server federativo. Questa funzionalità è configurata per impostazione predefinita con un livello di soglia di latenza consigliato. Per verificare le impostazioni, è possibile eseguire le operazioni seguenti:

  1. Nel computer proxy applicazione Web, aprire una finestra di comando con privilegi elevati.
  2. Passare alla directory AD FS in %WINDIR%\adfs\config.
  3. Cambiare le impostazioni di controllo della congestione predefinite sostituendole con <congestionControl latencyThresholdInMSec="8000" minCongestionWindowSize="64" enabled="true" />.
  4. Salva e chiudi il file.
  5. Riavviare il servizio AD FS eseguendo net stop adfssrv e quindi net start adfssrv.

Per indicazioni su questa funzionalità, vedere Configurare l'accesso extranet per AD FS in Windows Server 2012 R2.

Controlli standard delle richieste HTTP nel proxy

Il proxy esegue anche i controlli standard seguenti su tutto il traffico:

  • FS-P esegue l'autenticazione ad AD FS tramite un certificato di breve durata. In uno scenario di compromissione sospetta dei server dmz, AD FS può "revocare l'attendibilità proxy" in modo che non consideri più come attendibili le richieste in ingresso da proxy potenzialmente compromessi. Revocando l'attendibilità proxy, il certificato di ogni proxy viene revocato in modo che non possa eseguire correttamente l'autenticazione per qualsiasi scopo al server AD FS.
  • FS-P termina tutte le connessioni e crea una nuova connessione HTTP al servizio AD FS nella rete interna. In questo modo viene fornito un buffer a livello di sessione tra i dispositivi esterni e il servizio AD FS. Il dispositivo esterno non si connette mai direttamente al servizio AD FS.
  • FS-P esegue la convalida delle richieste HTTP che filtra in modo specifico le intestazioni HTTP non richieste dal servizio AD FS.

Verificare che tutti i server AD FS e WAP ricevano gli aggiornamenti più recenti. La raccomandazione di sicurezza più importante per l'infrastruttura AD FS consiste nel garantire che sia disponibile un mezzo per mantenere aggiornati i server AD FS e WAP con tutti gli aggiornamenti della sicurezza, nonché gli aggiornamenti facoltativi specificati come importanti per AD FS in questa pagina.

Il modo consigliato per i clienti di Microsoft Entra di monitorare e mantenere aggiornata l'infrastruttura è tramite Microsoft Entra Connect Health per AD FS, una funzionalità di Microsoft Entra ID P1 o P2. Microsoft Entra Connect Health include monitoraggi e avvisi che si attivano se, in un computer AD FS o WAP, manca uno degli aggiornamenti importanti specifici per AD FS e WAP.

Per maggiori informazioni sul monitoraggio dell'integrità per ADFS, consultare la sezione Installazione dell'agente Microsoft Entra Connect Health.

Procedura consigliata per la protezione e il monitoraggio dell'attendibilità di AD FS con Microsoft Entra ID

Quando si federa AD FS con Microsoft Entra ID, è fondamentale che la configurazione della federazione (relazione di trust configurata tra AD FS e Microsoft Entra ID) venga monitorata attentamente e che vengano acquisite eventuali attività insolite o sospette. A tale scopo, è consigliabile configurare gli avvisi e ricevere una notifica ogni volta che vengono apportate modifiche alla configurazione della federazione. Per informazioni su come configurare gli avvisi, vedere Monitorare le modifiche alla configurazione della federazione.

Configurazioni di sicurezza aggiuntive

Per garantire una maggiore protezione, è possibile configurare le funzionalità aggiuntive seguenti.

Protezione del blocco extranet "soft" per gli account

Con la funzionalità di blocco extranet in Windows Server 2012 R2, un amministratore di AD FS può impostare un numero massimo consentito di richieste di autenticazione non riuscite (ExtranetLockoutThreshold) e un periodo di tempo observation window (ExtranetObservationWindow). Quando viene raggiunto questo numero massimo (ExtranetLockoutThreshold) delle richieste di autenticazione, AD FS smette di tentare di autenticare le credenziali dell'account fornite su AD FS per il periodo di tempo impostato (ExtranetObservationWindow). Questa azione protegge questo account da un blocco dell'account AD, in altre parole, protegge questo account dalla perdita dell'accesso alle risorse aziendali che si basano su AD FS per l'autenticazione dell'utente. Queste impostazioni si applicano a tutti i domini che il servizio AD FS può autenticare.

È possibile usare il comando di Windows PowerShell seguente per impostare il blocco extranet di AD FS (ad esempio):

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

Per informazioni di riferimento, vedere Configurazione del blocco Extranet di AD FS per altre informazioni su questa funzionalità.

Disabilitare gli endpoint di Windows WS-Trust nel proxy da Extranet

Gli endpoint Windows WS-Trust (/adfs/services/trust/2005/windowstransport e /adfs/services/trust/13/windowstransport) sono destinati solo agli endpoint con connessione Intranet che usano l'associazione WIA su HTTPS. L'esposizione a extranet potrebbe consentire alle richieste relative a questi endpoint di ignorare le protezioni di blocco. Questi endpoint devono essere disabilitati nel proxy (ovvero disabilitati da Extranet) per proteggere il blocco dell'account AD usando i comandi di PowerShell seguenti. Non c'è alcun impatto noto sull'utente finale disabilitando questi endpoint nel proxy.

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

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

Nota

Se la farm AD FS viene eseguita su database interni Windows (WID) e dispone di un server AD FS secondario, dopo aver disabilitato gli endpoint nel server primario, attendere che la sincronizzazione si verifichi nei nodi secondari prima di riavviare il servizio AD FS su di essi. Usare il comando PowerShell Get-AdfsSyncProperties nel nodo secondario per tenere traccia dell'ultimo processo SYNC.

Distinguere i criteri di accesso per l'accesso Intranet e Extranet

AD FS ha la possibilità di distinguere i criteri di accesso per le richieste che hanno origine nella rete aziendale locale e nelle richieste provenienti da Internet tramite il proxy. Questa differenziazione può essere eseguita per applicazione o a livello globale. Per le applicazioni ad alto valore aziendale o le applicazioni con informazioni riservate, è consigliabile richiedere l'autenticazione a più fattori. L'autenticazione a più fattori può essere configurata tramite lo snap-in di gestione di AD FS.

Richiedere l'autenticazione a più fattori (MFA)

AD FS può essere configurato per richiedere l'autenticazione avanzata (ad esempio l'autenticazione a più fattori) in modo specifico per le richieste in arrivo tramite il proxy, per le singole applicazioni e per l'accesso condizionale sia a Microsoft Entra ID/Office 365 che alle risorse locali. I metodi supportati di MFA includono Microsoft Azure MF e provider di terze parti. All'utente viene richiesto di fornire le informazioni aggiuntive (ad esempio un testo SMS contenente un codice una tantum), mentre AD FS funziona con il plug-in specifico del provider per consentire l'accesso.

I provider di autenticazione a più fattori esterni supportati includono quelli elencati nella pagina Configurare metodi di autenticazione aggiuntivi per AD FS .

Abilitare la protezione per impedire il passaggio dell'autenticazione a più fattori cloud di Microsoft Entra quando è federata con Microsoft Entra ID

Abilitare la protezione per impedire il bypass dell'autenticazione a più fattori Microsoft Entra cloud quando è federato con Microsoft Entra ID e si usa l'autenticazione a più fattori Microsoft Entra come autenticazione a più fattori per gli utenti federati.

L'abilitazione della protezione per un dominio federato nel tenant di Microsoft Entra garantirà che l'autenticazione a più fattori di Microsoft Entra venga sempre eseguita quando un utente federato accede a un'applicazione regolata da un criterio di accesso condizionale che richiede l'autenticazione a più fattori. Questo include l'esecuzione dell'autenticazione a più fattori di Microsoft Entra anche quando il provider di identità federato ha indicato (tramite attestazioni di token federati) che è stata eseguita l'autenticazione a più fattori locale. L'applicazione dell'autenticazione a più fattori di Microsoft Entra ogni volta garantisce che un account locale compromesso non possa ignorare l'autenticazione a più fattori di Microsoft Entra imitando che un'autenticazione a più fattori sia già stata eseguita dal provider di identità ed è altamente consigliata, a meno che non si esegua l'autenticazione a più fattori per gli utenti federati usando un provider di autenticazione a più fattori di terze parti.

La protezione può essere abilitata usando una nuova impostazione di sicurezza, federatedIdpMfaBehavior, esposta come parte dell’API Internal Federation MS Graph o dei cmdlet MS Graph PowerShell. L'impostazione federatedIdpMfaBehavior determina se Microsoft Entra ID accetta l'autenticazione a più fattori eseguita dal provider di identità federato quando un utente federato accede a un'applicazione regolata da criteri di accesso condizionale che richiedono l'autenticazione a più fattori.

Gli amministratori possono scegliere uno dei valori seguenti:

Proprietà Descrizione
acceptIfMfaDoneByFederatedIdp Microsoft Entra ID accetta l'autenticazione a più fattori (MFA) se eseguita dal provider di identità. In caso contrario, esegue l'autenticazione a più fattori di Microsoft Entra.
enforceMfaByFederatedIdp Microsoft Entra ID accetta l'autenticazione a più fattori (MFA) se eseguita dal provider di identità. In caso contrario, reindirizza la richiesta al provider di identità per eseguire l'autenticazione a più fattori.
rejectMfaByFederatedIdp Microsoft Entra ID esegue sempre l'autenticazione a più fattori Microsoft Entra e rifiuta l'autenticazione MFA se eseguita dal provider di identità.

È possibile abilitare la protezione impostando federatedIdpMfaBehavior su rejectMfaByFederatedIdp usando il comando seguente.

API MS GRAPH

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

{ 

"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp" 

}

Esempio:

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

{ 

"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp"

Esempio:

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

Esempio:

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

Modulo di protezione hardware (HSM)

Nella configurazione predefinita, le chiavi usate da AD FS per firmare i token non lasciano mai i server federativi in intranet. Non sono mai presenti nella rete perimetrale o nei computer proxy. Facoltativamente, per garantire una maggiore protezione, è consigliabile proteggere queste chiavi in un modulo di protezione hardware collegato ad AD FS. Microsoft non produce un prodotto HSM, tuttavia ne esistono diversi sul mercato che supportano AD FS. Per implementare questa raccomandazione, seguire le indicazioni del fornitore per creare i certificati X509 per la firma e la crittografia, quindi usare i commandlet di PowerShell per l'installazione di AD FS, specificando i certificati personalizzati come indicato di seguito:

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

dove:

  • CertificateThumbprint è il certificato SSL
  • SigningCertificateThumbprint è il certificato di firma (con chiave protetta HSM)
  • DecryptionCertificateThumbprint è il certificato di crittografia (con chiave protetta HSM)