Novità di Active Directory Federation Services

Articolo
02/21/2024

Novità di Active Directory Federation Services per Windows Server 2019

Questo articolo descrive le nuove modifiche apportate ad Active Directory Federation Services (AD FS).

Accessi protetti

I punti seguenti sono un breve riepilogo degli aggiornamenti per gli accessi protetti disponibili in Active Directory Federation Services (AD FS) 2019:

Provider di autenticazione esterni come primario. I clienti possono ora usare prodotti di autenticazione di terze parti come primo fattore e non esporre le password come primo fattore. Nei casi in cui un provider di autenticazione esterno può dimostrare due fattori, può richiedere l’autenticazione MFA.
Autenticazione della password come autenticazione aggiuntiva. I clienti dispongono di un'opzione in-box completamente supportata per usare le password solo come fattore aggiuntivo dopo aver usato un'opzione senza password come primo fattore. Questa opzione migliora l'esperienza del cliente da AD FS 2016 in cui i clienti dovevano scaricare un adattatore GitHub supportato così com'è.
Modulo di valutazione dei rischi collegabile. I clienti possono ora creare moduli plug-in personalizzati per bloccare determinati tipi di richieste durante la fase di preautenticazione. Questa funzionalità consente di semplificare l'uso dell'intelligenza del cloud da parte dei clienti, ad esempio la protezione dell'identità, per bloccare l'accesso a utenti e transazioni a rischio. Per altre informazioni, vedi Creare plug-in con il modello di valutazione dei rischi di AD FS 2019.
Miglioramenti di ESL. Migliora la progettazione di soluzioni tampone (QFE) di ESL nel 2016 aggiungendo le funzionalità seguenti:
- Possibilità per i clienti di trovarsi in modalità di controllo pur essendo protetti dalla funzionalità di blocco extranet "classica", disponibile a partire da AD FS 2012R2. Attualmente i clienti della versione 2016 non avrebbero alcuna protezione in modalità di controllo.
- Abilitazione della soglia di blocco indipendente per le posizioni note. Questa funzionalità consente a più istanze di app in esecuzione con un account del servizio comune di eseguire il rollover delle password con un impatto minimo.

Altri miglioramenti della sicurezza

I miglioramenti della sicurezza seguenti sono disponibili in AD FS 2019:

PowerShell remoto con accesso tramite SmartCard. I clienti possono ora usare le SmartCard per connettersi in remoto ad AD FS tramite PowerShell e usarle per gestire tutte le funzioni PowerShell, tra cui i cmdlet multi-nodo.
Personalizzazione dell'intestazione HTTP. I clienti possono ora personalizzare le intestazioni HTTP generate durante le risposte ad AD FS, tra cui le intestazioni seguenti:
- HSTS: questa intestazione indica che gli endpoint ADFS possono essere usati solo sugli endpoint HTTPS per l’applicazione di un browser conforme.
- x-frame options: consente agli amministratori di AD FS di consentire a relying party specifici di incorporare iFrame per le pagine di accesso interattive di AD FS. Questa intestazione deve essere usata con cautela e solo su host HTTPS.
- Intestazione futura: è possibile configurare anche altre intestazioni future.

Per altre informazioni, vedere Personalizzare le intestazioni di risposta di sicurezza HTTP con AD FS 2019.

Funzionalità dei criteri di autenticazione

In AD FS 2019 sono disponibili le funzionalità di criteri di autenticazione seguenti:

Specificare il metodo di autenticazione per altre autenticazioni per RP. I clienti possono ora usare le regole di richiesta per decidere quale altro provider di autenticazione richiamare per l'autenticazione aggiuntiva. Questa funzionalità è utile per due casi d'uso:
- I clienti stanno passando da un provider di autenticazione aggiuntivo a un altro. In questo modo, durante l'onboarding degli utenti in un nuovo provider di autenticazione, si possono usare i gruppi per controllare quale provider di autenticazione aggiuntivo viene richiamato.
- I clienti necessitano di un provider di autenticazione aggiuntivo specifico (ad esempio un certificato) per alcune applicazioni.
Limitare l'autenticazione del dispositivo basata su TLS (Transport Layer Security) solo alle applicazioni che lo richiedono. I clienti possono ora limitare le autenticazioni dei dispositivi basate su TLS client solo alle applicazioni che eseguono l'accesso condizionale basato su dispositivo. Questa opzione consente di evitare richieste indesiderate di autenticazione dei dispositivi, oppure fallimenti dovuti all'impossibilità di gestire l'applicazione client, nel caso di applicazioni che non richiedono l'autenticazione dei dispositivi basata su TLS.
Supporto per l'aggiornamento dell'autenticazione a più fattori (MFA). AD FS supporta ora la possibilità di ripetere le credenziali del secondo fattore in base all'aggiornamento delle credenziali del secondo fattore. Questa funzionalità consente ai clienti di eseguire una transazione iniziale con due fattori e di richiedere il secondo fattore su base periodica. Questa opzione è disponibile solo per le applicazioni che possono fornire un parametro aggiuntivo nella richiesta e non è un'impostazione configurabile in ADFS. Azure AD supporta questo parametro quando si configura "Remember my MFA for X days" (Ricorda il mio MFA per X giorni) e si imposta il flag 'supportsMFA' su true nelle impostazioni di attendibilità del dominio federato di Azure AD.

Miglioramenti dell'accesso Single Sign-On

In AD FS 2019 sono stati introdotti i miglioramenti seguenti per l'accesso SSO:

Esperienza utente impaginata con tema centrato. AD FS è ora passato a un flusso di esperienza utente impaginata che consente ad AD FS di convalidare e fornire un'esperienza di accesso più fluida. AD FS ora usa un'interfaccia utente centrata, anziché sul lato destro dello schermo. Per allinearsi a questa esperienza potrebbero essere necessari un logo e delle immagini di sfondo più recenti. Questa modifica rispecchia anche le funzionalità offerte in Azure AD.
Correzione di bug: stato SSO persistente per i dispositivi Win10 durante l'autenticazione del token di aggiornamento primario (PRT). Questa modifica risolve un problema a causa del quale lo stato MFA non persisteva durante l'uso dell'autenticazione PRT per i dispositivi Windows 10. Per questo motivo, agli utenti finali veniva richiesto spesso di usare la credenziale di secondo fattore (MFA). La correzione rende l'esperienza coerente anche quando l'autenticazione del dispositivo viene eseguita correttamente tramite TLS sul client e tramite il meccanismo PRT.

Supporto per la creazione di app line-of-business moderne

È stato aggiunto ad AD FS 2019 il supporto seguente per la creazione di app line-of-business moderne:

Flusso/profilo del dispositivo Oauth. AD FS supporta ora il profilo di flusso dei dispositivi OAuth per accedere ai dispositivi che non dispongono di una superficie di attacco dell'interfaccia utente per supportare esperienze di accesso avanzate. Questa funzione consente all'utente di completare l'esperienza di accesso in un dispositivo diverso. Questa funzionalità è necessaria per l'esperienza dell'interfaccia della riga di comando di Azure in Azure Stack e può essere usata in altri casi.
Rimozione del parametro 'Risorsa'. AD FS ha ora rimosso la necessità di specificare un parametro di risorsa, in linea con le specifiche Oauth correnti. I client possono ora indicare l'identificatore di attendibilità del relying party come parametro di ambito, oltre alle autorizzazioni richieste.
Intestazioni della condivisione di risorse di origine incrociata (CORS) nelle risposte AD FS. I clienti possono ora creare applicazioni a pagina singola che consentono alle librerie JavaScript lato client di convalidare la firma di id_token eseguendo una query per le chiavi di firma dal documento di individuazione OpenID Connect (OIDC) in AD FS.
Supporto della chiave di prova per lo scambio di codici (PKCE). ADFS aggiunge il supporto PKCE per fornire un flusso di codice di autenticazione sicuro all'interno di OAuth. Questa funzionalità aggiunge un altro livello di sicurezza a questo flusso per impedire il dirottamento del codice e la riproduzione da un client diverso.
Correzione di bug: inviare le attestazioni x5t e kid. Questa modifica è una correzione di bug secondaria. AD FS invia ora anche l'attestazione "kid" per indicare il suggerimento ID chiave per la verifica della firma. Nelle versioni precedenti, AD FS inviava solo l'attestazione "x5t".

Miglioramenti del supporto

I miglioramenti alla supportabilità seguenti sono ora parte integrante di AD FS 2019:

Inviare i dettagli dell'errore agli amministratori di AD FS. Consente agli amministratori di configurare gli utenti finali per inviare i log di debug relativi a un errore di autenticazione dell'utente finale da archiviare come file compresso per facilitarne l'uso. Gli amministratori possono anche configurare una connessione SMTP (Simple Mail Transfer Protocol) per inviare automaticamente il file compresso a un account e-mail di valutazione o per creare automaticamente un ticket basato sull'e-mail.

Aggiornamenti della distribuzione

Gli aggiornamenti della distribuzione seguenti sono ora inclusi in AD FS 2019:

Livello di comportamento della farm 2019. Come per AD FS 2016, è disponibile una nuova versione del livello di comportamento della farm necessaria per abilitare nuove funzionalità descritte più avanti nell'articolo. Questo aggiornamento consente di passare da:
- AD FS in Windows Server 2012 R2 ad AD FS in Windows Server 2016.
- AD FS in Windows Server 2016 ad AD FS in Windows Server 2019.

Aggiornamenti SAML

L'aggiornamento SAML (Security Assertion Markup Language) seguente è disponibile in AD FS 2019:

Correzione di bug: correggere i bug nella federazione aggregata. Sono state apportate numerose correzioni di bug relative al supporto della federazione aggregata (ad esempio, InCommon). Le aree seguenti hanno ricevuto correzioni:
- Miglioramento del ridimensionamento per un numero elevato di entità nel documento di metadati della federazione aggregata. In precedenza, il ridimensionamento aveva esito negativo con un errore "ADMIN0017".
- Eseguire una query usando il parametro 'ScopeGroupID' tramite il Get-AdfsRelyingPartyTrustsGroup cmdlet di PowerShell.
- Gestione delle condizioni di errore su valori entityID duplicati.

Specifica della risorsa di tipo Azure AD nel parametro di ambito

Nelle versioni precedenti AD FS richiede che la risorsa e l'ambito desiderati siano inclusi in un parametro separato in una richiesta di autenticazione. Ad esempio, la richiesta OAuth seguente potrebbe essere simile a quella in genere inviata:

https:&#47;&#47;fs.contoso.com/adfs/oauth2/authorize?response_type=code&client_id=claimsxrayclient&resource=urn:microsoft:adfs:claimsxray&scope=oauth&redirect_uri=https:&#47;&#47;adfshelp.microsoft.com/
ClaimsXray/TokenResponse&prompt=login

Con AD FS in Server 2019, ora puoi passare il valore della risorsa incorporato nel parametro relativo all'ambito (scope). Questa modifica è coerente con il modo in cui è possibile eseguire l'autenticazione anche con Azure AD.

Il parametro di ambito ora può essere organizzato come un elenco con valori separati da spazi in cui ogni voce è strutturata come risorsa/ambito.

Nota

Nella richiesta di autenticazione è possibile specificare una sola risorsa. Se nella richiesta sono incluse più risorse, AD FS restituirà un errore e l'autenticazione avrà esito negativo.

Supporto di PKCE (Proof Key for Code Exchange) per OAuth

I client OAuth pubblici che usano la concessione del codice di autorizzazione sono a rischio di attacco di intercettazione del codice di autorizzazione. L'attacco è descritto dettagliatamente in RFC 7636. Per l'attenuazione dell'attacco, AD FS in Windows Server 2019 supporta PKCE (Proof Key for Code Exchange) per il flusso di concessione del codice di autorizzazione OAuth.

Per sfruttare il supporto PKCE, questa specifica aggiunge altri parametri alle richieste di token di autorizzazione e di accesso OAuth 2.0.

Diagramma della relazione PKCE tra il client e AD FS 2019.

A. Il client crea e registra un segreto denominato "code_verifier" e ne ricava una versione trasformata "t(code_verifier)" (denominata "code_challenge"). Il segreto viene inviato nella richiesta di autorizzazione OAuth 2.0 insieme al metodo di trasformazione "t_m".

B. L'endpoint di autorizzazione risponde come di consueto, ma registra "t(code_verifier)" e il metodo di trasformazione.

C. Il client invia quindi il codice di autorizzazione nella richiesta del token di accesso come di consueto, ma include il segreto "code_verifier" generato nel passaggio (A).

D. AD FS trasforma "code_verifier" e lo confronta con "t(code_verifier)" rispetto a (B). L'accesso viene negato se i due valori non sono uguali.

Come scegliere provider di autenticazione aggiuntivi nel 2019

AD FS supporta già l'attivazione di un'autenticazione aggiuntiva basata su criteri di regole di attestazione. Questi criteri possono essere impostati su un determinato punto di reporting o a livello globale. È possibile impostare un criterio di autenticazione aggiuntivo per un determinato punto di reporting utilizzando il cmdlet Set-AdfsRelyingPartyTrust (ADFS) | Microsoft Docs passando il parametro AdditionalAuthenticationRules o AdditionalAuthenticationRulesFile. Per impostarlo a livello globale, un amministratore può usare il cmdlet Set-AdfsAdditionalAuthenticationRule (AD FS) | Microsoft Docs.

Ad esempio, a partire dalla versione 2012 R2 l'amministratore può già scrivere la regola seguente per richiedere un'autenticazione aggiuntiva se la richiesta proviene da extranet.

Set-AdfsAdditionalAuthenticationRule -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = "http://schemas.microsoft.com/claims/multipleauthn" );'

Nel 2019 i clienti possono ora usare le regole delle attestazioni per decidere quale altro provider di autenticazione richiamare per l'autenticazione aggiuntiva. Questa funzionalità è utile per due scenari:

I clienti stanno passando da un provider di autenticazione aggiuntivo a un altro. In questo modo, quando eseguono l'onboarding degli utenti in un provider di autenticazione più recente, possono utilizzare i gruppi per controllare quale provider di autenticazione aggiuntivo viene richiamato.

I clienti hanno bisogno di un provider di autenticazione aggiuntivo specifico (ad esempio, il certificato) per determinate applicazioni, ma di un metodo diverso (Autenticazione a più fattori di Azure A) per altre applicazioni.

Questa configurazione può essere ottenuta eseguendo l'attestazione http://schemas.microsoft.com/claims/authnmethodsproviders da altri criteri di autenticazione. Il valore di questa attestazione deve essere il Nome del provider di autenticazione.

Ora nel 2019 possono modificare la regola di attestazione precedente per scegliere provider di autenticazione in base ai relativi scenari.

Transizione da un provider di autenticazione a un altro: è possibile modificare la regola precedentemente menzionata per scegliere Autenticazione a più fattori di Azure AD per gli utenti che fanno parte del gruppo SID S-1-5-21-608905689-872870963-3921916988-12345. Ad esempio, è possibile usare questa modifica per un gruppo gestito dall'organizzazione, che tiene traccia degli utenti registrati per Autenticazione a più fattori di Azure AD. Questa modifica funziona anche per gli altri utenti per i quali l'amministratore vuole usare il certificato di autenticazione.

'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

 c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-608905689-872870963-3921916988-12345"] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "AzureMfaAuthentication"); 

not exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value=="S-1-5-21-608905689-872870963-3921916988-12345"]) => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "CertificateAuthentication");’

Questo esempio illustra come impostare due provider di autenticazione diversi per due applicazioni diverse:

Impostare l'applicazione A per usare Autenticazione a più fattori di Azure AD come provider di autenticazione aggiuntivo:

Set-AdfsRelyingPartyTrust -TargetName AppA -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "AzureMfaAuthentication");'

Impostare l'applicazione B per l'uso del certificato come provider di autenticazione aggiuntivo:

Set-AdfsRelyingPartyTrust -TargetName AppB -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "CertificateAuthentication");'

Gli amministratori possono anche creare regole per consentire più provider di autenticazione aggiuntivi. In questo caso AD FS mostra i provider di metodi di autenticazione rilasciati e l’utente può sceglierne uno qualsiasi. Per consentire più provider di autenticazione aggiuntivi, è necessario emettere più attestazioni http://schemas.microsoft.com/claims/authnmethodsproviders.

Se la valutazione dell'attestazione non restituisce nessuno dei provider di autenticazione, AD FS esegue il fallback per visualizzare tutti i provider di autenticazione aggiuntivi configurati dall'amministratore in AD FS. L'utente deve quindi selezionare il provider di autenticazione appropriato.

Per ottenere tutti gli altri provider di autenticazione consentiti, l'amministratore può usare il cmdlet Get-AdfsGlobalAuthenticationPolicy. AdditionalAuthenticationProvider. Il valore dell'attestazione http://schemas.microsoft.com/claims/authnmethodsproviders deve essere uno dei nomi di provider restituiti dal cmdlet indicato in precedenza.

Non è disponibile alcun supporto per attivare un provider di autenticazione aggiuntivo specifico se il punto di reporting usa Criteri di controllo degli accessi in AD FS Windows Server 2016 | Microsoft Docs. Quando si sposta un'applicazione dai criteri di controllo degli accessi, AD FS copia i criteri corrispondenti da Criteri di controllo degli accessi a AdditionalAuthenticationRules e IssuanceAuthorizationRules. Pertanto, se un amministratore vuole usare un provider di autenticazione specifico, può non usare i criteri di controllo degli accessi e quindi modificare AdditionalAuthenticationRules per attivare un provider di autenticazione specifico.

Domande frequenti

Come risolvere l'errore dei registri eventi dell'amministratore di AD FS, "Ricevuta richiesta OAuth non valida. Il client 'NAME' non è autorizzato ad accedere alla risorsa con ambito 'ugs'”?

Per risolvere il problema, seguire la procedura seguente:

Avvia la console di gestione AD FS. Passare a Servizi > Descrizioni ambiti.
Selezionare altre opzioni in "Descrizioni ambito e quindi selezionare Aggiungi descrizione ambito.
In nome, immettere "ugs" e selezionare Applica > OK.
Avviare PowerShell come amministratore.
Eseguire il comando Get-AdfsApplicationPermission. Cercare l'oggetto ScopeNames :{openid, aza} con il ClientRoleIdentifier. Prendere nota di ObjectIdentifier.
Eseguire il comando Set-AdfsApplicationPermission -TargetIdentifier <ObjectIdentifier from step 5> -AddScope 'ugs'.
Riavviare il servizio AD FS.
Nel client, riavviare il client. Verrà richiesto di configurare Windows Hello for Business (WHFB).
Se la finestra di configurazione non viene visualizzata, è necessario raccogliere i log di traccia e risolvere altri problemi.

Posso passare un valore della risorsa come parte del valore dell'ambito nello stesso modo in cui le richieste vengono eseguite in Azure AD?

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

AD FS supporta l'estensione PKCE?

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

Novità di Active Directory Federation Services per Windows Server 2016

Per informazioni sulle versioni precedenti di AD FS, vedere gli articoli seguenti: AD FS in Windows Server 2012 o 2012 R2 e AD FS 2.0.

AD FS fornisce controllo di accesso e single sign-on in un'ampia gamma di applicazioni, tra cui Office 365, cloud basato su applicazioni SaaS e le applicazioni nella rete aziendale.

Per l'organizzazione IT, consente di fornire l'accesso e il controllo degli accessi sia alle applicazioni moderne che a quelle legacy su qualsiasi computer, in base allo stesso set di credenziali e criteri.
Per l'utente fornisce un accesso semplice usando le credenziali di account familiari.
Per lo sviluppatore fornisce un modo semplice per autenticare gli utenti la cui identità si trovano nelle directory dell'organizzazione in modo che è possibile concentrare l'attenzione su applicazione, non l'autenticazione o identità.

Eliminare le password dalla rete Extranet

AD FS 2016 consente tre nuove opzioni per l'accesso senza password, consentendo alle organizzazioni di evitare il rischio di compromissione della rete a causa di password falsificate, divulgate o rubate.

AD FS 2016 si basa sulle funzionalità di autenticazione a più fattori (MFA) di AD FS in Windows Server 2012 R2. È ora possibile consentire l'accesso usando solo un codice di autenticazione a più fattori di Azure AD, senza dover prima immettere un nome utente e una password.

Con l’autenticazione a più fattori di Azure AD come metodo di autenticazione principale, all'utente viene richiesto il nome utente e il codice OTP dall'app Azure Authenticator.
Con l’autenticazione a più fattori di Azure AD come metodo di autenticazione secondario o aggiuntivo, l'utente fornisce le credenziali di autenticazione primarie. È possibile eseguire l'accesso tramite Autenticazione integrata di Windows, usando il nome utente e la password, la smart card o il certificato dell'utente o del dispositivo. Viene quindi visualizzata una richiesta di accesso ad Autenticazione a più fattori di Azure AD basata su testo, voce o OTP.
Grazie al nuovo adattatore di Autenticazione a più fattori di Azure AD integrato, l'installazione e la configurazione di Autenticazione a più fattori di Azure AD con AD FS non sono mai state così semplici.
Le organizzazioni possono usufruire di Autenticazione a più fattori di Azure AD senza dover disporre di un server di Autenticazione a più fattori di Azure AD locale.
Autenticazione a più fattori di Azure AD può essere configurato per Intranet o Extranet, o come parte di qualsiasi criterio di controllo degli accessi.

Per altre informazioni su Autenticazione a più fattori di Azure AD con AD FS, vedere Configurare AD FS 2016 e Autenticazione a più fattori di Azure AD.

Password senza accesso da dispositivi compatibili

AD FS 2016 si basa sulle funzionalità di registrazione dei dispositivi precedenti abilitazione dell'accesso e controllo di accesso in base allo stato di conformità del dispositivo. Gli utenti possono accedere usando la credenziale del dispositivo e la conformità viene rivalutata ogni volta che gli attributi del dispositivo vengono modificati, in modo che sia sempre possibile garantire l'applicazione dei criteri. Questa funzionalità abilita criteri come:

Abilitare l'accesso solo da dispositivi gestiti e/o conformi.
Abilitare l'accesso Extranet solo da dispositivi gestiti e/o conformi.
Richiedere l'autenticazione a più fattori per computer non gestiti/non conformi.

ADFS fornisce il componente locale dei criteri di accesso condizionale in uno scenario ibrido. Quando si registrano i dispositivi con Azure AD per l'accesso condizionale alle risorse cloud, l'identità del dispositivo può essere utilizzata per nonché i criteri di ADFS.

Diagramma di una soluzione ibrida e delle relazioni tra utenti e Active Directory locale.

Per altre informazioni sull'uso dell'accesso condizionale basato su dispositivo nel cloud, vedere Accesso condizionale di Azure Active Directory.

Per ulteriori informazioni sull'utilizzo di dispositivi basati su accesso condizionale con AD FS

Nota

Attualmente, Google Chrome e i nuovi browser di progetti open source Microsoft Edge basati su Chromium non sono supportati per l'accesso Single Sign-On (SSO) basato su browser con Windows Hello for Business. Usa Internet Explorer o una versione precedente di Microsoft Edge.

I dispositivi Windows 10 introducono Windows Hello e Windows Hello for Business, sostituendo le password degli utenti con credenziali utente sicure associate ai dispositivi protette da movimenti dell'utente (un PIN, una credenziale biometrica come l'impronta digitale o il riconoscimento facciale). AD FS 2016 supporta queste nuove funzionalità di Windows 10 in modo che gli utenti possano accedere alle applicazioni di AD FS dalla rete Intranet o Extranet senza la necessità di fornire una password.

Per altre informazioni sull'uso di Windows Hello for Business nell'organizzazione, vedere Abilitare Windows Hello for Business nell'organizzazione.

Proteggere l'accesso alle applicazioni

Le modifiche seguenti influiscono sull'accesso sicuro alle applicazioni in AD FS.

Autenticazione moderna

AD FS 2016 supporta i più recenti protocolli moderni che offrono una migliore esperienza utente per Windows 10 e per i più recenti dispositivi e app iOS e Android.

Per altre informazioni, vedere Scenari di AD FS per gli sviluppatori.

Configurare criteri di controllo di accesso senza conoscere language regole attestazione

In precedenza, gli amministratori di AD FS dovevano configurare i criteri usando il linguaggio delle regole di attestazione di AD FS, rendendo difficile la configurazione e la gestione dei criteri. Con i criteri di controllo di accesso, gli amministratori possono utilizzare i modelli incorporati per applicare i criteri comuni, ad esempio

Consentire solo l'accesso intranet.
Consentire tutti gli utenti e richiedere l'autenticazione a più fattori da Extranet.
Consentire tutti gli utenti e richiedere l'autenticazione a più fattori da un gruppo specifico.

I modelli sono facilmente personalizzabili grazie a una procedura guidata che consente di aggiungere eccezioni o regole aggiuntive ai criteri. Inoltre, possono essere applicati a una o più applicazioni in modo da garantire un'applicazione coerente dei criteri.

Per altre informazioni vedere Criteri di controllo degli accessi in AD FS.

Abilitazione dell'accesso con le directory LDAP non Active Directory

Molte organizzazioni utilizzano una combinazione di Active Directory e le directory di terze parti. Con l'aggiunta del supporto di AD FS per l'autenticazione degli utenti archiviati in directory conformi a Lightweight Directory Access Protocol (LDAP) v3, AD FS può ora essere usato per:

Utenti in directory di terze parte, conformi a LDAP v3
Utenti nelle foreste di Active Directory per i quali non è configurato un trust bidirezionale di Active Directory
Utenti in Active Directory Lightweight Directory Services (AD LDS)

Per altre informazioni, vedere Configure AD FS to authenticate users stored in LDAP directories.

Le modifiche seguenti migliorano l'esperienza di accesso per AD FS.

In precedenza, AD FS in Windows Server 2012 R2 offriva un'esperienza di accesso comune per tutte le applicazioni di terze parti, con la possibilità di personalizzare un sottoinsieme di contenuti testuali per ogni applicazione. Con Windows Server 2016, è possibile personalizzare non solo messaggi, ma le immagini, web e logo tema per ogni applicazione. Inoltre, è possibile creare nuovi temi web personalizzati e applicarli al relying party.

Per altre informazioni vedere Personalizzazione dell'accesso utente di AD FS.

Miglioramenti operativi e di gestione

Nella sezione seguente descrive gli scenari operativi migliorati introdotte con Active Directory Federation Services in Windows Server 2016.

Il controllo di semplice gestione amministrativa semplificata

In AD FS per Windows Server 2012 R2, venivano generati numerosi eventi di controllo per una singola richiesta e le informazioni rilevanti relative a un'attività di accesso o di emissione di un token erano assenti o distribuite su più eventi di controllo. Per impostazione predefinita, ADFS gli eventi di controllo sono disattivati per loro natura dettagliato. Con il rilascio di AD FS 2016, il controllo è diventato più semplice e meno dettagliato.

Per altre informazioni vedere Miglioramenti di controllo per AD FS in Windows Server 2016.

Migliorare l'interoperabilità con SAML 2.0 per la partecipazione a confederations

AD FS 2016 contiene un maggiore supporto del protocollo SAML, tra cui il supporto per l'importazione di trust basati su metadati che contiene più entità. Questa modifica consente di configurare AD FS per partecipare a confederazioni come InCommon Federation e ad altre implementazioni conformi allo standard eGov 2.0.

Per altre informazioni, vedere Interoperabilità migliorata con SAML 2.0.

Gestione semplificata delle password per gli utenti federati di Microsoft 365

È possibile configurare Active Directory Federation Services (ADFS) per inviare le attestazioni di scadenza password per l'attendibilità della relying party (applicazioni) che sono protetti da ADFS. Utilizzo di tali attestazioni dipende dall'applicazione. Ad esempio, con Office 365 come la relying party, gli aggiornamenti sono stati implementati a Exchange e Outlook per notificare agli utenti federati delle password appena-a--scaduto.

Per altre informazioni, vedere Configurazione di AD FS per l'invio di attestazioni di scadenza della password.

Lo spostamento da ADFS in Windows Server 2012 R2 ad ADFS in Windows Server 2016 è più semplice

In precedenza, la migrazione a una nuova versione di ADFS, è necessario esportazione configurazione dalla farm precedente e l'importazione in una farm completamente nuova e parallelo.

A questo punto, il passaggio da AD FS in Windows Server 2012 R2 ad AD FS in Windows Server 2016 è diventato più semplice. Aggiungere un nuovo server Windows Server 2016 a una farm Windows Server 2012 R2 affinché la farm agisca a livello di comportamento della farm Windows Server 2012 R2. II server è ora simile a una farm Windows Server 2012 R2 e si comporta come tale.

Quindi, aggiungere nuovi server di Windows Server 2016 alla farm, verificare la funzionalità e rimuovere i server meno recenti dal bilanciamento del carico. Una volta che tutti i nodi della farm sono in esecuzione con Windows Server 2016, si è pronti per aggiornare il livello di comportamento della farm al 2016 e iniziare a usare le nuove funzionalità.

Per altre informazioni vedere Aggiornamento ad AD FS in Windows Server 2016.