Domande frequenti su AD FS

È possibile aggiornare/eseguire la migrazione di AD FS completando i passaggi descritti in uno degli articoli collegati riportati di seguito:

• Da AD FS per Windows Server 2012 R2 ad AD FS per Windows Server 2016 o versioni successive. Il processo è lo stesso se si esegue l'aggiornamento da AD FS per Windows Server 2016 ad AD FS per Windows Server 2019.
  • Aggiornamento ad AD FS in Windows Server 2016 con un database interno di Windows
  • Aggiornamento ad AD FS in Windows Server 2016 con un database SQL
• Da AD FS per Windows Server 2012 ad AD FS per Windows Server 2012 R2:
  • Eseguire la migrazione ad AD FS in Windows Server 2012 R2
• Da AD FS 2.0 ad AD FS per Windows Server 2012:
  • Eseguire la migrazione ad AD FS in Windows Server 2012
• Da AD FS 1.x ad AD FS 2.0:
  • Eseguire l'aggiornamento da AD FS 1.x ad AD FS 2.0

Se hai necessità di eseguire l'aggiornamento da AD FS 2.0 o 2.1 (Windows Server 2008 R2 o Windows Server 2012), usa gli script incorporati disponibili in C:\Windows\ADFS.

Il supporto per HTTP/2 è stato aggiunto in Windows Server 2016, ma HTTP/2 non può essere usato per l'autenticazione del certificato client. Molti scenari di AD FS usano l'autenticazione del certificato client. E molti client non supportano la ripetizione dei tentativi tramite HTTP/1.1. La configurazione della farm AD FS riconfigura quindi le impostazioni HTTP del server locale in HTTP/1.1. Questa riconfigurazione richiede un riavvio del server.

Questa configurazione è supportata, ma non sono supportate le nuove funzionalità di AD FS 2016. Questa configurazione deve essere limitata al momento della migrazione da AD FS 2012 R2 ad AD FS 2016. Non deve essere usata per lunghi periodi di tempo.

Sì, ma come effetto collaterale:

• dovrai gestire manualmente gli aggiornamenti dei certificati per la firma di token perché Azure AD non sarà in grado di accedere ai metadati della federazione. Per altre informazioni sull'aggiornamento manuale del certificato per la firma di token, vedi Rinnovare i certificati di federazione per Office 365 e Azure Active Directory.
• Non sarà possibile utilizzare flussi di autenticazione legacy, ad esempio il flusso di autenticazione proxy ExO.

AD FS è un sistema senza stato, quindi il bilanciamento del carico è piuttosto semplice per gli accessi. Ecco alcuni consigli chiave per i sistemi di bilanciamento del carico:

• I servizi di bilanciamento del carico non dovrebbero essere configurati con l'affinità IP. L’affinità IP può generare un carico eccessivo su un subset dei server in determinati scenari di Exchange Online.
• I servizi di bilanciamento del carico non devono terminare le connessioni HTTPS e avviare una nuova connessione al server AD FS.
• I servizi di bilanciamento del carico dovrebbero garantire la conversione dell'indirizzo IP di connessione come IP di origine nel pacchetto HTTP quando sta per essere inviato ad AD FS. Se un servizio di bilanciamento del carico non può inviare l'IP di origine nel pacchetto HTTP, il servizio di bilanciamento del carico deve aggiungere l'indirizzo IP all'intestazione X-Forwarded-For. Questo passaggio è necessario per la corretta gestione di determinate funzionalità correlate all'IP, ad esempio IP vietato e blocco intelligente Extranet. Se questa configurazione non è implementata correttamente, la sicurezza potrebbe essere ridotta.
• I servizi di bilanciamento del carico dovrebbero supportare SNI. In caso contrario, assicurarsi che AD FS sia configurato per creare binding HTTPS al fine di gestire i client che non supportano SNI.
• I servizi di bilanciamento del carico devono usare l'endpoint del probe di integrità HTTP di AD FS per rilevare se i server AD FS o Proxy applicazione Web sono in esecuzione. Se non viene restituita la risposta 200 OK, vanno esclusi.

AD FS supporta più configurazioni multiforesta. Si basa sulla rete trust di Active Directory Domain Services sottostante per autenticare gli utenti in più aree di autenticazione attendibili. È consigliabile impostare trust tra foreste bidirezionali perché sono più facili da configurare, in modo da garantire il corretto funzionamento del sistema di attendibilità.

Inoltre:

• Se si dispone di un trust tra foreste unidirezionale, ad esempio una foresta di rete perimetrale (nota anche come DMZ) che contiene identità partner, è consigliabile distribuire AD FS nella foresta aziendale. Considerare la foresta di rete perimetrale come un altro trust del provider di attestazioni locale connesso tramite LDAP. In questo caso, l'autenticazione integrata di Windows non funzionerà per gli utenti della foresta di rete perimetrale. Dovranno utilizzare l'autenticazione password, perché è l'unico meccanismo supportato per LDAP.

  Se non è possibile utilizzare questa opzione, è necessario configurare un altro server AD FS nella foresta di rete perimetrale. Aggiungerlo come attendibilità del provider di attestazioni nel server AD FS della foresta aziendale. Gli utenti dovranno eseguire l'individuazione dell'area di autenticazione principale, ma in quel caso sia l'autenticazione integrata di Windows sia l'autenticazione della password funzioneranno. Apportare le modifiche appropriate nelle regole di rilascio in AD FS nella foresta di rete perimetrale perché AD FS nella foresta aziendale non sarà in grado di ottenere altre informazioni sugli utenti dalla foresta di rete perimetrale.

• I trust a livello di dominio sono supportati e possono funzionare. È tuttavia consigliabile passare a un modello di trust a livello di foresta. Inoltre, è necessario assicurarsi che il routing UPN e la risoluzione dei nomi NetBIOS funzionino correttamente.

Sì, gli indirizzi IPv6 vengono considerati per posizioni note e sconosciute.

AD FS fornisce un meccanismo flessibile per l'integrazione di provider di autenticazione a più fattori di terze parti. A tale scopo, non è disponibile alcun programma di certificazione definito. Si presuppone che il fornitore abbia effettuato le convalide necessarie prima del rilascio.

L'elenco dei fornitori che hanno informato Microsoft è disponibile qui: Provider di autenticazione a più fattori per AD FS. Potrebbero essere disponibili provider di cui non siamo a conoscenza. L'elenco verrà aggiornato man mano che ne verranno individuati di nuovi.

Sì, i proxy di terze parti possono essere posizionati di fronta a AD FS, ma qualsiasi proxy di terze parti deve supportare l'uso del protocollo MS-ADFSPIP al posto del Proxy applicazione Web.

Attualmente siamo a conoscenza dei provider di terze parti seguenti. Potrebbero essere disponibili provider di cui non siamo a conoscenza. Questo elenco verrà aggiornato man mano che ne verranno individuati di nuovi.

• F5 Access Policy Manager
• Citrix Application Delivery Controller (ADC)

È possibile scaricare la versione di AD FS 2016 del foglio di calcolo. Inoltre, è possibile utilizzare questo foglio di calcolo per AD FS in Windows Server 2012 R2.

Apple ha rilasciato un set di requisiti, noto come ATS (App Transport Security), che potrebbe influire sulle chiamate dalle app iOS che eseguono l'autenticazione in AD FS. Puoi verificare che i server AD FS e Proxy applicazione Web di cui disponi siano conformi assicurandoti che supportino i requisiti per la connessione tramite ATS. In particolare, è necessario verificare che:

• I server AD FS e Proxy applicazione Web supportino TLS 1.2.
• La suite di crittografia negoziata della connessione TLS supporterà un inoltro perfettamente secretato.

Per informazioni sull'abilitazione e la disabilitazione di SSL 2.0 e 3.0 e TLS 1.0, 1.1 e 1.2, vedere Gestire i protocolli SSL in AD FS.

Per assicurarti che i server AD FS e Proxy applicazione Web negozino solo pacchetti di crittografia TLS che supportano ATP, puoi disabilitare tutti i pacchetti di crittografia non inclusi nell'elenco dei pacchetti di crittografia conformi ad ATP. Per disabilitarli, usa i cmdlet di Windows TLS PowerShell.

Il valore dell'attestazione "sub" è l'hash dell'ID client e il valore dell'attestazione di ancoraggio.

La durata del token di aggiornamento sarà la durata del token che AD FS ha ottenuto dal trust del provider di attestazioni remoto. La durata del token di accesso sarà la durata del token della relying party per cui viene emesso il token di accesso.

Puoi usare un id_token personalizzato per aggiungere informazioni rilevanti nell'id_token stesso. Per altre informazioni, vedere Personalizzare le attestazioni da emettere in id_token.

Per questo scenario, in AD FS 2016 sono stati aggiunti uno speciale ValueType (http://www.w3.org/2001/XMLSchema#json) e un carattere di escape (\x22). Usa gli esempi seguenti per la regola di rilascio e per l'output finale del token di accesso.

Regola di rilascio di esempio:

=> issue(Type = "array_in_json", ValueType = "http://www.w3.org/2001/XMLSchema#json", Value = "{\x22Items\x22:[{\x22Name\x22:\x22Apple\x22,\x22Price\x22:12.3},{\x22Name\x22:\x22Grape\x22,\x22Price\x22:3.21}],\x22Date\x22:\x2221/11/2010\x22}");

Attestazione rilasciata nel token di accesso:

"array_in_json":{"Items":[{"Name":"Apple","Price":12.3},{"Name":"Grape","Price":3.21}],"Date":"21/11/2010"}

Con AD FS in Windows Server 2019, ora puoi passare il valore della risorsa incorporato nel parametro relativo all'ambito (scope). Il parametro di ambito può essere organizzato come un elenco con valori separati da spazi in cui ogni voce è strutturata come risorsa/ambito.

AD FS in Windows Server 2019 supporta PKCE (Proof Key for Code Exchange) per il flusso di concessione del codice di autorizzazione OAuth.

Supportato:

• aza. Se si usano le estensioni del protocollo OAuth 2.0 per i client broker e il parametro di ambito contiene l'ambito aza, il server rilascia un nuovo token di aggiornamento primario e lo imposta nel campo refresh_token della risposta. Il server imposta anche il campo refresh_token_expires_in sulla durata del nuovo token di aggiornamento primario, se ne viene applicato uno.
• openid. Consente a un’applicazione di richiedere l'uso del protocollo di autorizzazione OpenID Connect.
• logon_cert. Consente a un'applicazione di richiedere i certificati di accesso, che possono essere usati per far accedere in modo interattivo gli utenti autenticati. Il server AD FS omette il parametro access_token dalla risposta e fornisce invece una catena di certificati CMS con codifica Base64 o una risposta PKI completa CMC. Per altre informazioni, vedere Dettagli di elaborazione.
• user_impersonation. Obbligatorio se si desidera richiedere un token di accesso on-behalf-of da AD FS. Per ulteriori informazioni su come usare questo ambito, vedere Creare un'applicazione multilivello con OBO (On-Behalf-Of) usando OAuth con AD FS 2016.

Non supportata:

• vpn_cert. Consente a un'applicazione di richiedere certificati VPN, che possono essere usati per stabilire connessioni VPN con l'autenticazione EAP-TLS. Questo ambito non è più supportato.
• email. Consente a un'applicazione di richiedere un'attestazione di posta elettronica per l'utente connesso. Questo ambito non è più supportato.
• profile. Consente a un'applicazione di richiedere attestazioni relative al profilo per l'utente connesso. Questo ambito non è più supportato.

Il certificato SSL di AD FS è diverso dal Certificato di comunicazione del servizio AD FS contenuto nello snap-in Gestione AD FS. Per cambiare il certificato SSL di AD FS è necessario usare PowerShell. Seguire le indicazioni in Gestione dei certificati SSL in AD FS e WAP 2016.

Per informazioni sulla disabilitazione e l'abilitazione di protocolli SSL e pacchetti di crittografia, vedere Gestire i protocolli SSL in AD FS.

• Se viene utilizzato il proxy per le richieste proxy ADFS che utilizzano l'autenticazione integrata di Windows, il certificato SSL del proxy deve utilizzare la stessa chiave del certificato SSL del server federativo.
• Se la proprietà di AD FS ExtendedProtectionTokenCheck è abilitata (l'impostazione predefinita in AD FS), il certificato SSL del proxy deve utilizzare la stessa chiave del certificato SSL del server federativo.
• In caso contrario, il certificato SSL proxy può avere una chiave diversa dal certificato SSL di AD FS. Deve soddisfare gli stessi requisiti.

AD FS visualizza solo un metodo di autenticazione nella schermata di accesso quando un'applicazione richiede in modo esplicito un URI di autenticazione specifico mappato a un metodo di autenticazione configurato e abilitato. Il metodo viene trasmesso nel parametro wauth delle richieste WS-Federation. Viene trasmesso nel parametro RequestedAuthnCtxRef nelle richieste del protocollo SAML. Viene visualizzato solo il metodo di autenticazione richiesto. Ad esempio, l'accesso alla password.

Se usi AD FS con Azure AD, le applicazioni inviano spesso il parametro prompt=login ad Azure AD. Azure AD, per impostazione predefinita, converte questo parametro in una richiesta di un nuovo accesso ad AD FS basato su password. Questo scenario è il motivo più comune per cui è possibile visualizzare un accesso ad AD FS tramite password nella rete o non è possibile visualizzare un'opzione per accedere tramite il proprio certificato. È possibile risolvere facilmente questo problema apportando una modifica alle impostazioni del dominio federato in Azure AD.

Per altre informazioni, vedere Supporto dei parametri di accesso di Active Directory Federation Services.

Per modificare l'account del servizio AD FS, usare il modulo PowerShell dell'account del servizio casella degli strumenti di AD FS. Per istruzioni, vedere Modificare l'account del servizio AD FS.

Vedere Configurare i browser per l'uso dell'autenticazione integrata di Windows con AD FS.

Se non disponi di criteri di controllo di accesso basati sul dispositivo in AD FS o nella registrazione certificato di Windows Hello for Business con AD FS, puoi disattivare BrowserSsoEnabled. BrowserSsoEnabled consente ad AD FS di raccogliere un token di aggiornamento primario (PRT) dal client che contiene informazioni sul dispositivo. Senza questo token, l'autenticazione del dispositivo di AD FS non funzionerà nei dispositivi Windows 10.

Gli amministratori spesso si chiedono per quanto tempo gli utenti ottengono l'accesso Single Sign-On (SSO) senza dover immettere nuove credenziali e in che modo gli amministratori possono controllare tale comportamento. Questo comportamento e le impostazioni di configurazione che lo controllano sono descritte in Impostazioni di Single Sign-on AD FS.

Di seguito sono elencate le durate predefinite dei diversi cookie e token, unitamente ai parametri che controllano la durata:

Dispositivi registrati

• Cookie PRT e SSO: massimo 90 giorni, durata controllata da PSSOLifeTimeMins. (Se il dispositivo viene usato almeno ogni 14 giorni. Questa finestra temporale è controllata da DeviceUsageWindow).

• Token di aggiornamento: calcolato in base ai parametri precedenti per fornire un comportamento coerente.

• access_token: un'ora per impostazione predefinita, in base alla relying party.

• id_token: come il token di accesso.

Dispositivi non registrati

• Cookie SSO: otto ore per impostazione predefinita, durata controllata da SSOLifetimeMins. Quando l'opzione Mantieni l'accesso (KMSI) è abilitata, il valore predefinito è 24 ore. Questa impostazione predefinita è configurabile tramite KMSILifetimeMins.

• Token di aggiornamento: otto ore per impostazione predefinita. 24 ore se l'opzione KMSI è abilitata.

• access_token: un'ora per impostazione predefinita, in base alla relying party.

• id_token: come il token di accesso.

AD FS non supporta i flussi impliciti per client riservati. L'autenticazione client è abilitata solo per l'endpoint del token e AD FS non rilascia un token di accesso senza autenticazione client. Se il client riservato necessita di un token di accesso e richiede anche l'autenticazione utente, sarà necessario usare il flusso del codice di autorizzazione.

HSTS è un meccanismo di criteri di sicurezza per il web. Consente di attenuare gli attacchi di downgrade del protocollo e l’hijacking dei cookie per i servizi con endpoint HTTP e HTTPS. Consente ai server web di dichiarare che i browser web (o altri agenti utente conformi) possono interagire con loro usando esclusivamente il protocollo HTTPS e mai tramite il protocollo HTTP.

Tutti gli endpoint AD FS per il traffico di autenticazione Web vengono aperti esclusivamente su HTTPS. AD FS riduce quindi le minacce create dal meccanismo dei criteri HSTS. Per impostazione predefinita, non esiste alcun downgrade a HTTP perché non sono presenti listener in HTTP. AD FS inoltre impedisce l'invio dei cookie a un altro server con endpoint del protocollo HTTP contrassegnando tutti i cookie con il flag sicuro.

Non è quindi necessario HSTS in un server AD FS perché non è possibile effettuare il downgrade di HSTS. I server AD FS soddisfano i requisiti di conformità perché non possono usare HTTP e perché i cookie sono contrassegnati come sicuri.

Infine, AD FS 2016 (con le patch più aggiornate) e AD FS 2019 supportano l'emissione dell'intestazione HSTS. Per configurare questo comportamento, vedere Personalizzare le intestazioni di risposta di sicurezza HTTP con AD FS.

Non è consigliabile eseguire la terminazione SSL prima del server proxy applicazione Web. Se viene eseguita davanti al server proxy applicazione Web, X-MS-Forwarded-Client-IP conterrà l'IP del dispositivo di rete davanti al server proxy applicazione Web. Qui è riportata una breve descrizione delle diverse attestazioni correlate all'IP supportate da AD FS:

• X-MS-Client-IP. IP di rete del dispositivo connesso al servizio token di sicurezza. Per le richieste extranet, questa attestazione contiene sempre l'indirizzo IP del server proxy applicazione Web.
• X-MS-Forwarded-Client-IP. Attestazione multivalore che contiene i valori inoltrati ad AD FS da Exchange Online. Contiene anche l'indirizzo IP del dispositivo connesso al server proxy applicazione Web.
• Userip. Per le richieste Extranet, questa attestazione contiene il valore di X-MS-Forwarded-Client-IP. Per le richieste Intranet, questa attestazione contiene lo stesso valore di X-MS-Client-IP.

Inoltre, in AD FS 2016 (con le patch più aggiornate) e versioni successive è supportata anche l'acquisizione dell'intestazione X-Forwarded-For. Qualsiasi servizio di bilanciamento del carico o dispositivo di rete che non esegue l'inoltro al livello 3 (l'IP viene mantenuto) deve aggiungere l'IP client in ingresso all'intestazione X-Forwarded-For standard del settore.

L'endpoint UserInfo AD FS restituisce sempre l'attestazione dell'oggetto come specificato negli standard OpenID. AD FS non supporta altre attestazioni richieste tramite l'endpoint UserInfo. Se sono necessarie più attestazioni in un token ID, vedere Token ID personalizzati in AD FS.

Questo gruppo viene creato solo quando nel dominio è presente un controller di dominio Windows 2016 con il ruolo PDC FSMO. Per risolvere l'errore, è possibile creare il gruppo manualmente. Seguire questa procedura per aggiungere le autorizzazioni necessarie dopo aver aggiunto l'account del servizio come membro del gruppo:

1. Aprire Utenti e computer di Active Directory.
2. Fare clic con il pulsante destro del mouse sul nome di dominio nel riquadro sinistro, quindi selezionare Proprietà.
3. Seleziona Sicurezza. (Se la scheda Sicurezza è mancante, attivare Funzionalità avanzate nel menu Visualizza).
4. Selezionare Avanzate, Aggiungi e quindi Selezionare un'entità.
5. Viene visualizzata la finestra di dialogo Seleziona utente, computer, account di servizio o gruppo. Nella casella di testo Immettere il nome dell'oggetto da selezionare, inserire Key Admin Group. Selezionare OK.
6. Nella casella di riepilogo Si applica a, selezionare Oggetti utente discendenti.
7. Scorrere fino alla fine della pagina e selezionare Cancella tutto.
8. Nella sezione Proprietà seleziona Lettura msDS-KeyCredentialLink e Scrittura msDS-KeyCredentialLink.

Per le app che usano la libreria Android ADAL, l'autenticazione in Azure AD potrebbe non riuscire per gli utenti federati. L'app riceverà un'eccezione AuthenticationException quando tenterà di visualizzare la pagina di accesso. Nel browser Chrome, la pagina di accesso ad AD FS potrebbe essere descritta come non sicura.

In tutte le versioni e in tutti i dispositivi, Android non supporta il download di certificati aggiuntivi dal campo authorityInformationAccess del certificato. Questa limitazione si applica anche al browser Chrome. Questo errore verrà causato da qualsiasi certificato di autenticazione server privo dei certificati intermedi se l'intera catena di certificati non viene passata da AD FS.

È possibile risolvere questo problema configurando i server AD FS e Proxy applicazione Web per inviare i certificati intermedi necessari insieme al certificato SSL.

Quando si esporta il certificato SSL da un computer per importarlo nell'archivio personale del computer dei server AD FS e Proxy applicazione Web, assicurarsi di esportare la chiave privata e selezionare Scambio di informazioni personali - PKCS #12.

Assicurarsi inoltre di selezionare Includi tutti i certificati nel percorso del certificato, se possibile ed Esporta tutte le proprietà estese.

Esegui certlm. msc nei server Windows e importa *.pfx nell'archivio certificati personale del computer. In questo modo, il server passerà l'intera catena di certificati alla libreria ADAL.

AD FS non supporta le richieste HEAD. Le applicazioni non devono usare le richieste HEAD sugli endpoint AD FS. L'uso di queste richieste potrebbe causare risposte di errore HTTP impreviste o posticipate. È anche possibile che vengano visualizzati eventi di errore imprevisti nel registro eventi di AD FS.

Non viene rilasciato un token di aggiornamento se il token rilasciato da IdP ha una validità inferiore a un’ora. Per essere certi che venga rilasciato un token di aggiornamento, estendi a più di un’ora la validità del token rilasciato da IdP.

La crittografia del token RP è impostata su AES256. Non è possibile modificarlo in alcun altro valore.

Le farm AD FS in modalità mista devono essere temporanee. Durante la pianificazione è consigliabile eseguire il rollover del certificato SSL prima del processo di aggiornamento oppure completare il processo e aumentare il livello di comportamento della farm prima di aggiornare il certificato SSL. Se tale raccomandazione non è stata seguita, usare le istruzioni riportate di seguito per aggiornare il certificato SSL.

Nei server Proxy applicazione Web è comunque possibile usare Set-WebApplicationProxySslCertificate. Nei server AD FS è necessario usare netsh. Seguire questa procedura:

1. Selezionare un subset di server AD FS 2016 per la manutenzione.

2. Nei server selezionati nel passaggio precedente, importare il nuovo certificato tramite MMC.

3. Eliminare i certificati esistenti:

   a. netsh http delete sslcert hostnameport=fs.contoso.com:443

   b. netsh http delete sslcert hostnameport=localhost:443

   c. netsh http delete sslcert hostnameport=fs.contoso.com:49443

4. Aggiungere i nuovi certificati:

   a. netsh http add sslcert hostnameport=fs.contoso.com:443 certhash=THUMBPRINT appid="{5d89a20c-beab-4389-9447-324788eb944a}" certstorename=My verifyclientcertrevocation=Enable sslctlstorename=AdfsTrustedDevices

   b. netsh http add sslcert hostnameport=localhost:443 certhash=THUMBPRINT appid="{5d89a20c-beab-4389-9447-324788eb944a}" certstorename=My verifyclientcertrevocation=Enable

   c. netsh http add sslcert hostnameport=fs.contoso.com:49443 certhash=THUMBPRINT appid="{5d89a20c-beab-4389-9447-324788eb944a}" certstorename=My verifyclientcertrevocation=Enable clientcertnegotiation=Enable

5. Riavviare il servizio AD FS nel server selezionato.

6. Rimuovere un subset di server Proxy applicazione Web per la manutenzione.

7. Nei server Proxy applicazione Web selezionati, importare il nuovo certificato tramite MMC.

8. Impostare il nuovo certificato nel server Proxy applicazione Web usando questo cmdlet:

   • Set-WebApplicationProxySslCertificate -Thumbprint " CERTTHUMBPRINT"

9. Riavviare il servizio nei server proxy applicazione Web selezionati.

10. Inserire nuovamente i server Proxy applicazione Web e AD FS selezionati nell'ambiente di produzione.

Aggiornare gli altri server AD FS e Proxy applicazione Web nello stesso modo.

I server ADFS e i server applicazioni Web supportano i firewall che non eseguono la terminazione SSL sull'endpoint. Inoltre, i server Proxy applicazione Web/AD FS dispongono di meccanismi predefiniti per:

• Impedire attacchi Web comuni, ad esempio scripting tra siti.
• Eseguire il proxy AD FS.
• Soddisfare tutti i requisiti definiti dal protocollo MS-ADFSIP.

In AD FS 2016, l'associazione di token viene abilitata automaticamente e causa più problemi noti con scenari di proxy e federazione. Questi problemi causano questo evento. Per correggerlo, esegui il comando PowerShell seguente per rimuovere il supporto per il binding del token:

Set-AdfsProperties -IgnoreTokenBinding $true

Dopo un aggiornamento a Windows Server 2019, la versione della configurazione del Proxy applicazione Web continuerà a essere visualizzata come Windows Server 2016. Il Proxy applicazione Web non dispone di nuove funzionalità specifiche nella versione per Windows Server 2019. Se il livello di comportamento della farm è stato elevato in AD FS, il Proxy applicazione Web continuerà a essere visualizzato come Windows Server 2016. Questo comportamento dipende dalla progettazione.

Quando si abilita ESL, AD FS tiene traccia dell'attività dell'account e dei percorsi noti per gli utenti nel database ADFSArtifactStore. Le dimensioni di questo database variano in base al numero di utenti e di percorsi noti di cui viene tenuta traccia. Quando si prevede di abilitare ESL, è possibile stimare che il database ADFSArtifactStore crescerà fino a 1 GB per 100.000 utenti.

Se la farm AD FS usa Database interno di Windows, il percorso predefinito per i file di database è C:\Windows\WID\Data. Per evitare di riempire tale unità, assicurarsi di avere almeno 5 GB di spazio di archiviazione gratuito prima di abilitare ESL. Oltre che dello spazio di archiviazione su disco, esegui la pianificazione tenendo conto che la memoria di elaborazione totale dopo l'abilitazione di ESL si espanderà fino a un ulteriore GB di RAM per popolazioni di un massimo di 500.000 utenti.

Ecco il testo dell'evento:

Active Directory trust enumeration was unable to enumerate one of more domains due to the following error. Enumeration will continue but the Active Directory identifier list may not be correct. Validate that all expected Active Directory identifiers are present by running Get-ADFSDirectoryProperties.

Questo evento si verifica se le foreste non sono attendibili quando AD FS prova a enumerare e a connettersi a tutte le foreste di una catena di foreste attendibili. Si supponga, ad esempio, che la foresta A e la foresta B di AD FS siano attendibili e che la foresta B e la foresta C siano attendibili. AD FS enumererà tutte e tre le foreste e tenterà di trovare una relazione di trust tra la foresta A e la foresta C. Se gli utenti della foresta in errore devono essere autenticati da AD FS, configura una relazione di trust tra la foresta AD FS e la foresta in errore. Se gli utenti della foresta in errore non devono essere autenticati da AD FS, ignorare questo evento.

Ecco il testo dell'evento:

Microsoft.IdentityServer.AuthenticationFailedException: MSIS5015: Authentication of the presented token failed. Token Binding claim in token must match the binding provided by the channel.

In AD FS 2016, l'associazione di token viene abilitata automaticamente e causa più problemi noti con scenari di proxy e federazione. Questi problemi causano questo evento. Per correggerlo, esegui il comando PowerShell seguente e rimuovi il supporto per il binding del token:

Set-AdfsProperties -IgnoreTokenBinding $true

Ecco il testo dell'evento:

System.ServiceModel.FaultException: The formatter threw an error while trying to deserialize the message: There was an error while trying to deserialize parameter schemas.microsoft.com/ws/2009/12/identityserver/protocols/policystore:maxBehaviorLevel". The InnerException message was "Invalid enum value 'Win2019' cannot be deserialized into type 'Microsoft.IdentityServer.FarmBehavior'. Ensure that the necessary enum values are present and are marked with EnumMemberAttribute attribute if the type has DataContractAttribute attribute.

Questo evento è previsto quando entrambe le istruzioni sono vere:

• È disponibile una farm in modalità mista.
• AD FS 2019 fornisce le informazioni sul livello di comportamento massimo della farm al server federativo primario e non viene riconosciuto dalla versione 2016 del server federativo.

AD FS 2019 continua a tentare di condividere nella farm il valore MaxBehaviorLevel Win2019 fino a quando non diventa obsoleto, dopo due mesi, e viene rimosso automaticamente dalla farm. Per evitare di ricevere questo evento, eseguire la migrazione del ruolo federativo primario al server federativo con la versione più recente. Seguire le istruzioni in Per aggiornare la farm AD FS al livello di comportamento della farm di Windows Server 2019.