Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Di seguito sono riportati i vari requisiti che è necessario soddisfare durante la distribuzione di AD FS:
Requisiti dei certificati
I certificati svolgono il ruolo più critico nella protezione delle comunicazioni tra server federativi, proxy di applicazioni Web, applicazioni in grado di riconoscere attestazioni e client Web. I requisiti per i certificati variano a seconda che si stia configurando un server federativo o un computer proxy, come descritto in questa sezione.
Certificati di server di federazione
| Tipo di certificato | Requisiti, supporto e cose da conoscere |
|---|---|
| Certificato SSL (Secure Sockets Layer): Si tratta di un certificato SSL standard usato per proteggere le comunicazioni tra server federativi e client. | - Questo certificato deve essere un certificato attendibile pubblicamente* X509 v3. - Tutti i client che accedono a qualsiasi endpoint AD FS devono considerare attendibile questo certificato. È consigliabile usare certificati emessi da un'autorità di certificazione pubblica (di terze parti). È possibile usare correttamente un certificato SSL autofirmato nei server federativi in un ambiente lab di test. Tuttavia, per un ambiente di produzione, è consigliabile ottenere il certificato da una CA pubblica. - Supporta qualsiasi dimensione della chiave supportata da Windows Server 2012 R2 per i certificati SSL. - Non supporta i certificati che usano chiavi CNG. - Se usato insieme al servizio registrazione dispositivi/aggiunta all'area di lavoro, il nome alternativo del soggetto del certificato SSL per il servizio AD FS deve contenere il valore enterpriseregistration seguito dal suffisso NOME entità utente (UPN) dell'organizzazione, ad esempio, enterpriseregistration.contoso.com. - Sono supportati i certificati con caratteri jolly. Quando si crea la farm AD FS, verrà richiesto di specificare il nome del servizio per il servizio AD FS, ad esempio adfs.contoso.com. - È consigliabile usare lo stesso certificato SSL per il proxy applicazione Web. Questa operazione è tuttavia necessaria per essere la stessa quando si supportano gli endpoint di autenticazione integrata di Windows tramite il proxy applicazione Web e quando l'autenticazione di protezione estesa è attivata (impostazione predefinita). - Il nome del soggetto di questo certificato viene usato per rappresentare il nome del Servizio federativo per ogni istanza di AD FS che distribuisci. Per questo motivo, è consigliabile scegliere un nome soggetto in tutti i nuovi certificati rilasciati dalla CA che rappresentano meglio il nome della società o dell'organizzazione ai partner. L'identità del certificato deve corrispondere al nome del servizio federativo, ad esempio fs.contoso.com. L'identità è un'estensione del nome alternativo del soggetto di tipo dNSName o, se non sono presenti voci del nome alternativo del soggetto, il nome soggetto specificato come nome comune. Nel certificato possono essere presenti più voci di nome alternativo del soggetto, a condizione che una di esse corrisponda al nome del servizio federativo. - Importante: è consigliabile usare lo stesso certificato SSL in tutti i nodi della farm AD FS, nonché tutti i proxy dell'applicazione Web nella farm AD FS. |
| Certificato di comunicazione del servizio: Questo certificato abilita la sicurezza dei messaggi WCF per proteggere le comunicazioni tra server federativi. | - Per impostazione predefinita, il certificato SSL viene usato come certificato di comunicazione del servizio. È anche possibile configurare un altro certificato come certificato di comunicazione del servizio. - Importante: se si usa il certificato SSL come certificato di comunicazione del servizio, quando il certificato SSL scade, assicurarsi di configurare il certificato SSL rinnovato come certificato di comunicazione del servizio. Questo non avviene automaticamente. - Questo certificato deve essere considerato attendibile dai client di AD FS che usano WCF Message Security. - È consigliabile usare un certificato di autenticazione server rilasciato da un'autorità di certificazione pubblica (di terze parti). - Il certificato di comunicazione del servizio non può essere un certificato che usa chiavi CNG. - Questo certificato può essere gestito tramite la console di gestione di AD FS. |
| Certificato di firma del token: Si tratta di un certificato X509 standard usato per firmare in modo sicuro tutti i token che il server federativo rilascia. | - Per impostazione predefinita, AD FS crea un certificato autofirmato con chiavi a 2048 bit. - Sono supportati anche i certificati rilasciati dalla CA e possono essere modificati tramite lo snap-in Gestione AD FS - I certificati rilasciati dalla CA devono essere archiviati e accessibili tramite un provider di crittografia CSP. - Il certificato di firma del token non può essere un certificato che usa chiavi CNG. - AD FS non richiede certificati registrati esternamente per la firma del token. AD FS rinnova automaticamente questi certificati autofirmato prima della scadenza, configurando prima di tutto i nuovi certificati come certificati secondari per consentire ai partner di utilizzarli, quindi di passare al database primario in un processo denominato rollover automatico dei certificati. È consigliabile usare i certificati predefiniti generati automaticamente per la firma del token. Se l'organizzazione dispone di criteri che richiedono la configurazione di certificati diversi per la firma del token, è possibile specificare i certificati in fase di installazione usando PowerShell (usare il parametro –SigningCertificateThumbprint del cmdlet Install-AdfsFarm). Dopo l'installazione, è possibile visualizzare e gestire i certificati di firma dei token usando la console di gestione di AD FS o i cmdlet di PowerShell Set-AdfsCertificate e Get-AdfsCertificate. Quando i certificati registrati esternamente vengono usati per la firma del token, AD FS non esegue il rinnovo automatico o il rollover dei certificati. Questo processo deve essere eseguito da un amministratore. Per consentire il rollover del certificato quando un certificato è vicino alla scadenza, è possibile configurare un certificato di firma del token secondario in AD FS. Per impostazione predefinita, tutti i certificati di firma dei token vengono pubblicati nei metadati della federazione, ma solo il certificato di firma del token primario viene usato da AD FS per firmare effettivamente i token. |
| Token-decryption/encryption certificate (Certificato di decrittografia/crittografia token): Si tratta di un certificato X509 standard usato per decrittografare/crittografare i token in ingresso. Viene pubblicato anche nei metadati della federazione. | - Per impostazione predefinita, AD FS crea un certificato autofirmato con chiavi a 2048 bit. - Sono supportati anche i certificati rilasciati dalla CA e possono essere modificati tramite lo snap-in Gestione AD FS - I certificati rilasciati dalla CA devono essere archiviati e accessibili tramite un provider di crittografia CSP. - Il certificato di decrittografia/crittografia del token non può essere un certificato che usa chiavi CNG. - Per impostazione predefinita, AD FS genera e usa i propri certificati generati internamente e autofirmati per la decrittografia dei token. AD FS non richiede certificati registrati esternamente a questo scopo. INOLTRE, AD FS rinnova automaticamente questi certificati autofirmato prima della scadenza. È consigliabile usare i certificati predefiniti generati automaticamente per la decrittografia dei token. Se l'organizzazione dispone di criteri che richiedono la configurazione di certificati diversi per la decrittografia dei token, è possibile specificare i certificati in fase di installazione usando PowerShell (usare il parametro –DecryptionCertificateThumbprint del cmdlet Install-AdfsFarm). Dopo l'installazione, è possibile visualizzare e gestire i certificati di decrittografia dei token usando la console di gestione di AD FS o i cmdlet di PowerShell Set-AdfsCertificate e Get-AdfsCertificate. Quando i certificati registrati esternamente vengono usati per la decrittografia dei token, AD FS non esegue il rinnovo automatico del certificato. Questo processo deve essere eseguito da un amministratore. - L'account di servizio AD FS deve avere accesso alla chiave privata del certificato di firma del token nell'archivio personale del computer locale. Questa operazione viene gestita dall'installazione. È anche possibile usare lo snap-in Gestione AD FS per garantire l'accesso se successivamente si modifica il certificato di firma del token. |
Attenzione
I certificati usati per la firma di token e la decrittografia/crittografia dei token sono fondamentali per la stabilità del servizio federativo. I clienti che gestiscono la firma dei token & e i certificati di decrittografia/crittografia dei token devono assicurarsi che questi certificati vengano sottoposti a backup e siano disponibili autonomamente durante un evento di ripristino.
Nota
In AD FS è possibile modificare il livello SHA (Secure Hash Algorithm) usato per le firme digitali in SHA-1 o SHA-256 (più sicuro). AD FS non supporta l'uso di certificati con altri metodi hash, ad esempio MD5 (algoritmo hash predefinito usato con lo strumento da riga di comando Makecert.exe). Come procedura consigliata per la sicurezza, è consigliabile usare SHA-256 (impostato per impostazione predefinita) per tutte le firme. SHA-1 è consigliato per l'uso solo in scenari in cui è necessario interagire con un prodotto che non supporta le comunicazioni tramite SHA-256, ad esempio un prodotto non Microsoft o versioni legacy di AD FS.
Nota
Dopo aver ricevuto un certificato da una CA, assicurarsi che tutti i certificati vengano importati nell'archivio certificati personale del computer locale. È possibile importare certificati nell'archivio personale con lo snap-in MMC "Certificati".
Requisiti hardware
I requisiti hardware minimi e consigliati seguenti si applicano ai server federativi AD FS in Windows Server 2012 R2:
| i requisiti hardware | Requisiti minimi | requisito consigliato |
|---|---|---|
| Velocità CPU | Processore a 64 bit a 1,4 GHz | Quad core, 2 GHz |
| RAM | 512 MB | 4 GB |
| Spazio su disco | 32 GB | 100 GB |
Requisiti software
I requisiti di AD FS seguenti sono relativi alle funzionalità del server integrate nel sistema operativo Windows Server® 2012 R2:
Per l'accesso extranet, è necessario distribuire il servizio ruolo Proxy di applicazione Web, incluso nel ruolo del server Accesso remoto di Windows Server® 2012 R2. Le versioni precedenti di un proxy server federativo non sono supportate con AD FS in Windows Server® 2012 R2.
Il servizio di ruolo Proxy delle applicazioni Web e un server federativo non possono essere installati nello stesso computer.
Requisiti di Active Directory Domain Services (AD DS)
Requisiti del controller di dominio
I controller di dominio in tutti i domini utente e il dominio a cui sono aggiunti i server AD FS devono eseguire Windows Server 2008 o versione successiva.
Nota
Tutto il supporto per gli ambienti con controller di dominio Windows Server 2003 terminerà dopo la data di fine del supporto esteso per Windows Server 2003. I clienti sono fortemente consigliati per aggiornare i controller di dominio il prima possibile. Visitare questa pagina per altre informazioni sul ciclo di vita del supporto Tecnico Microsoft. Per i problemi individuati specifici per gli ambienti controller di dominio windows Server 2003, le correzioni verranno rilasciate solo per problemi di sicurezza e se è possibile emettere una correzione prima della scadenza del supporto esteso per Windows Server 2003.
Nota
AD FS richiede un controller di dominio scrivibile completo per funzionare anziché un controller di dominio Read-Only. Se una topologia pianificata include un controller di dominio Read-Only, il controller di dominio Read-Only può essere usato per l'autenticazione, ma l'elaborazione delle attestazioni LDAP richiederà una connessione al controller di dominio scrivibile.
Requisiti a livello di funzionalità del dominio
Tutti i domini dell'account utente e il dominio a cui vengono aggiunti i server AD FS devono essere operativi a livello funzionale di dominio di Windows Server 2003 o versione successiva.
La maggior parte delle funzionalità di AD FS non richiede modifiche a livello di funzionalità di Active Directory Domain Services per funzionare correttamente. Tuttavia, il livello di funzionalità del dominio di Windows Server 2008 o superiore è necessario affinché l'autenticazione del certificato client funzioni correttamente se il certificato viene mappato in modo esplicito all'account di un utente in Servizi di dominio Active Directory.
Requisiti dello schema
AD FS non richiede modifiche dello schema o modifiche a livello di funzionalità in Servizi di dominio Active Directory.
Per usare la funzionalità Workplace Join, lo schema della foresta a cui sono aggiunti i server AD FS deve essere impostato su Windows Server 2012 R2.
Requisiti dell'account di servizio
Qualsiasi account di servizio standard può essere usato come account del servizio per AD FS. Sono supportati anche gli account del servizio gestito del gruppo. Questo richiede almeno un controller di dominio (è consigliabile distribuire due o più) che esegue Windows Server 2012 o versione successiva.
Affinché l'autenticazione Kerberos funzioni tra client aggiunti a un dominio e AD FS, è necessario registrare "HOST/<adfs_service_name>" come SPN nell'account del servizio. Per impostazione predefinita, AD FS configurerà questa impostazione durante la creazione di una nuova farm AD FS se dispone di autorizzazioni sufficienti per eseguire questa operazione.
L'account del servizio AD FS deve essere considerato attendibile in ogni dominio utente che contiene gli utenti che eseguono l'autenticazione al servizio AD FS.
Requisiti di dominio
Tutti i server AD FS devono essere aggiunti a un dominio di Active Directory Domain Services.
Tutti i server AD FS all'interno di una farm devono essere distribuiti in un singolo dominio.
Il dominio a cui vengono aggiunti i server AD FS deve considerare attendibile ogni dominio dell'account utente che contiene gli utenti che eseguono l'autenticazione al servizio AD FS.
Requisiti per più foreste
Il dominio a cui vengono aggiunti i server AD FS deve considerare attendibile ogni dominio o foresta dell'account utente che contiene gli utenti che eseguono l'autenticazione al servizio AD FS.
L'account del servizio AD FS deve essere considerato attendibile in ogni dominio utente che contiene gli utenti che eseguono l'autenticazione al servizio AD FS.
Requisiti del database di configurazione
Di seguito sono riportati i requisiti e le restrizioni applicabili in base al tipo di archivio di configurazione:
WID
Una farm WID ha un limite di 30 server federativi se hai 100 o meno trust di relying party.
Il profilo di risoluzione degli artefatti in SAML 2.0 non è supportato nel database di configurazione WID. Il rilevamento della riproduzione dei token non è supportato nel database di configurazione WID. Questa funzionalità viene usata solo negli scenari in cui AD FS funge da provider federativo e utilizza token di sicurezza da provider di attestazioni esterni.
La distribuzione di server AD FS in data center distinti per il failover o il bilanciamento del carico geografico è supportata, purché il numero di server non superi i 30.
Nella tabella seguente viene fornito un riepilogo per l'uso di una farm WID. Usarlo per pianificare l'implementazione.
| Trust RP da 1 a 100 | Più di 100 Trust RP |
|---|---|
| Nodi AD FS da 1 a 30: WID supportato | nodi AD FS da 1 a 30: Non supportato con WID - SQL obbligatorio |
| più di 30 nodi AD FS: Non supportato con WID - SQL obbligatorio | più di 30 nodi AD FS: Non supportato con WID - SQL obbligatorio |
SQL Server
Per AD FS in Windows Server 2012 R2, è possibile usare SQL Server 2008 e versioni successive
Requisiti per il browser
Quando l'autenticazione ad AD FS viene eseguita tramite un browser o un controllo browser, il browser deve rispettare i requisiti seguenti:
JavaScript deve essere abilitato
I cookie devono essere attivati
L'indicazione del nome del server (SNI) deve essere supportata
Per l'autenticazione del certificato utente e del certificato del dispositivo (funzionalità di aggiunta all'area di lavoro), il browser deve supportare l'autenticazione del certificato client SSL
Diversi browser e piattaforme chiave sono stati sottoposti a convalida per quanto riguarda il rendering e le funzionalità, i dettagli dei quali sono elencati di seguito. I browser e i dispositivi non trattati in questa tabella sono ancora supportati se soddisfano i requisiti elencati in precedenza:
| Browser | Piattaforme |
|---|---|
| Internet Explorer 10.0 | Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 |
| Internet Explorer 11.0 | Windows7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 |
| Windows Web Authentication Broker | Windows 8.1 |
| Firefox [v21] | Windows 7, Windows 8.1 |
| Safari [v7] | iOS 6, Mac OS-X 10.7 |
| Chrome [v27] | Windows 7, Windows 8.1, Windows Server 2012, Windows Server 2012 R2, Mac OS-X 10.7 |
Importante
Problema noto - Firefox: funzionalità di aggiunta all'area di lavoro che identifica il dispositivo che usa il certificato del dispositivo non è funzionale nelle piattaforme Windows. Firefox non supporta attualmente l'esecuzione dell'autenticazione del certificato client SSL utilizzando i certificati forniti nell'archivio certificati utente sui client Windows.
cookie
AD FS crea cookie persistenti e basati su sessione che devono essere archiviati nei computer client per fornire l'accesso, la disconneszione, l'accesso Single Sign-On (SSO) e altre funzionalità. Pertanto, il browser client deve essere configurato per accettare i cookie. I cookie utilizzati per l'autenticazione sono sempre cookie di sessione HTTPS (Secure Hypertext Transfer Protocol) scritti per il server di origine. Se il browser client non è configurato per consentire questi cookie, AD FS non può funzionare correttamente. I cookie permanenti vengono usati per preservare la selezione effettuata dall'utente del provider di attestazioni. È possibile disabilitarli usando un'impostazione di configurazione nel file di configurazione per le pagine di accesso di AD FS. Il supporto per TLS/SSL è necessario per motivi di sicurezza.
Requisiti extranet
Per fornire l'accesso extranet al servizio AD FS, è necessario implementare il servizio di ruolo Proxy dell'applicazione Web come ruolo rivolto all'extranet, che instrada in modo sicuro le richieste di autenticazione al servizio AD FS. In questo modo si ottiene l'isolamento degli endpoint del servizio AD FS e l'isolamento di tutte le chiavi di sicurezza (ad esempio i certificati di firma del token) dalle richieste provenienti da Internet. Inoltre, le funzionalità come il blocco dell'account Soft Extranet richiedono l'uso del proxy applicazione Web. Per ulteriori informazioni su Proxy delle applicazioni Web, vedere Proxy delle applicazioni Web. `
Requisiti di rete
La configurazione appropriata dei servizi di rete seguenti è fondamentale per la corretta distribuzione di AD FS nell'organizzazione:
Configurazione del firewall aziendale
Sia il firewall che si trova tra il proxy applicazione Web e la server farm federativa e il firewall tra i client e il proxy applicazione Web devono avere la porta TCP 443 abilitata in ingresso.
Inoltre, se è necessaria l'autenticazione del certificato utente client (autenticazione clientTLS con certificati utente X509), AD FS in Windows Server 2012 R2 richiede che la porta TCP 49443 sia abilitata in ingresso nel firewall tra i client e il proxy applicazione Web. Questo non è necessario nel firewall tra il proxy applicazione Web e i server federativi.
Nota
Assicurarsi inoltre che la porta 49443 non venga usata da altri servizi nel server AD FS e proxy applicazione Web.
Configurazione DNS
Per l'accesso Intranet, tutti i client che accedono al servizio AD FS all'interno della rete aziendale interna (Intranet) devono essere in grado di risolvere il nome del servizio AD FS (nome fornito dal certificato SSL) nel servizio di bilanciamento del carico per i server AD FS o il server AD FS.
Per l'accesso extranet, tutti i client che accedono al servizio AD FS dall'esterno della rete aziendale (extranet/Internet) devono essere in grado di risolvere il nome del servizio AD FS (nome fornito dal certificato SSL) verso il load balancer per i server proxy dell'applicazione Web o il server proxy dell'applicazione Web.
Per il corretto funzionamento dell'accesso extranet, ogni server proxy di applicazione Web nella DMZ deve essere in grado di risolvere il nome del servizio AD FS (nome fornito dal certificato SSL) nel bilanciamento del carico per i server AD FS o il server AD FS. A tale scopo, è possibile usare un server DNS alternativo nella rete perimetrale o modificando la risoluzione del server locale usando il file HOSTS.
Affinché l'autenticazione integrata di Windows funzioni nella rete e al di fuori della rete per un sottoinsieme di endpoint esposti tramite il proxy applicazione Web, è necessario usare un record A (non CNAME) per puntare ai bilanciatori di carico.
Per informazioni sulla configurazione del DNS aziendale per il servizio federativo e il servizio Registrazione dispositivi, vedere Configurare DNS aziendale per il servizio federativo e drS.
Per informazioni sulla configurazione del DNS aziendale per i proxy dell'applicazione Web, vedere la sezione "Configurare IL DNS" in Passaggio 1: Configurare l'infrastruttura proxy applicazione Web.
Per informazioni su come configurare un indirizzo IP del cluster o un nome di dominio completo del cluster tramite NLB, vedere Specificare i parametri del cluster in http://go.microsoft.com/fwlink/?LinkId=75282.
Requisiti dell'archivio di attributi
AD FS richiede l'uso di almeno un archivio attributi per l'autenticazione degli utenti e l'estrazione di attestazioni di sicurezza per tali utenti. Per un elenco degli archivi di attributi supportati da AD FS, vedere Ruolo degli archivi di attributi.
Nota
AD FS crea automaticamente un archivio attributi "Active Directory", per impostazione predefinita. I requisiti dell'archivio attributi dipendono dal fatto che l'organizzazione si comporta come partner di account (ospitando gli utenti federati) o partner di risorse (che ospita l'applicazione federata).
Archivi attributi LDAP
Quando si usano altri archivi di attributi basati su LDAP (Lightweight Directory Access Protocol), è necessario connettersi a un server LDAP che supporta l'autenticazione integrata di Windows. La stringa di connessione LDAP deve essere scritta anche nel formato di un URL LDAP, come descritto in RFC 2255.
È inoltre necessario che l'account di servizio per AD FS abbia il diritto di recuperare le informazioni degli utenti dall'archivio degli attributi LDAP.
Archivi attributi di SQL Server
Affinché AD FS in Windows Server 2012 R2 funzioni correttamente, i computer che ospitano l'archivio attributi di SQL Server devono eseguire Microsoft SQL Server 2008 o versione successiva. Quando si lavora con gli archivi di attributi basati su SQL, è necessario configurare anche una stringa di connessione.
Archivi attributi personalizzati
È possibile sviluppare archivi di attributi personalizzati per abilitare scenari avanzati.
Il linguaggio dei criteri integrato in AD FS può fare riferimento a archivi di attributi personalizzati in modo che uno degli scenari seguenti possa essere migliorato:
Creazione di richieste per un utente autenticato in locale
Completamento delle attestazioni per un utente autenticato esternamente
Autorizzazione di un utente a ottenere un token
Autorizzazione di un servizio per ottenere un token sul comportamento di un utente
Emissione di dati aggiuntivi nei token di sicurezza emessi da AD FS alle parti affidate.
Tutti gli archivi di attributi personalizzati devono essere compilati su .NET 4.0 o versione successiva.
Quando si usa un archivio attributi personalizzato, potrebbe essere necessario configurare anche una stringa di connessione. In tal caso, è possibile immettere un codice personalizzato di propria scelta che consente una connessione all'archivio attributi personalizzato. La stringa di connessione in questa situazione è un set di coppie nome/valore interpretate come implementate dallo sviluppatore dell'archivio attributi personalizzato. Per altre informazioni sullo sviluppo e sull'uso di archivi attributi personalizzati, vedere Panoramica dell'archivio attributi.
Requisiti per le applicazioni
AD FS supporta applicazioni consapevoli delle attestazioni e utilizzano i seguenti protocolli:
WS-Federation
WS-Trust
Protocollo SAML 2.0 con i profili IDPLite, SPLite & eGov1.5.
Profilo di concessione di autorizzazioni OAuth 2.0
AD FS supporta anche l'autenticazione e l'autorizzazione per qualsiasi applicazione non riconoscente attestazioni supportata dal proxy applicazione Web.
Requisiti di autenticazione
Autenticazione di Active Directory Domain Services (autenticazione primaria)
Per l'accesso Intranet, sono supportati i meccanismi di autenticazione standard seguenti per Servizi di dominio Active Directory:
Autenticazione integrata di Windows tramite Negotiate per Kerberos & NTLM
Autenticazione basata su form con nome utente/password
Autenticazione tramite certificati mappati agli account utente nei Servizi di dominio Active Directory
Per l'accesso extranet, sono supportati i meccanismi di autenticazione seguenti:
Autenticazione basata su moduli con nome utente e password
Autenticazione tramite certificati mappati agli account utente in Active Directory Domain Services
Autenticazione integrata di Windows tramite Negotiate (solo NTLM) per gli endpoint WS-Trust che accettano l'autenticazione integrata di Windows.
Per l'autenticazione del certificato:
Si estende alle smart card che possono essere protette con un PIN.
L'interfaccia utente grafica per l'immissione del pin non viene fornita da AD FS ed è necessaria per far parte del sistema operativo client visualizzato quando si usa TLS client.
Il lettore e il provider di servizi di crittografia (CSP) per la smart card devono funzionare nel computer in cui si trova il browser.
Il certificato della smart card deve essere concatenato a una radice attendibile in tutti i server AD FS e i server proxy applicazione Web.
Il certificato deve essere mappato all'account utente in Servizi di dominio Active Directory tramite uno dei metodi seguenti:
Il nome soggetto del certificato corrisponde al nome distinto LDAP di un account utente in AD DS.
L'estensione dell'altname del soggetto del certificato include il nome principale utente (UPN) di un account utente nei Servizi di dominio Active Directory.
Per l'autenticazione integrata di Windows senza problemi tramite Kerberos nella intranet,
È necessario che il nome del servizio faccia parte dei siti attendibili o dei siti Intranet locali.
Inoltre, lo SPN HOST/<adfs_service_name> deve essere impostato sull'account del servizio su cui opera la farm AD FS.
Autenticazione a più fattori
AD FS supporta l'autenticazione aggiuntiva (oltre l'autenticazione primaria supportata da Servizi di dominio Active Directory) usando un modello di provider in cui fornitori/clienti possono creare la propria scheda di autenticazione a più fattori che un amministratore può registrare e usare durante l'accesso.
Ogni adattatore MFA deve essere basato su .NET 4.5.
Per altre informazioni su MFA, vedere Gestire i rischi con l'autenticazione a più fattori aggiuntiva per le applicazioni sensibili.
Autenticazione del dispositivo
AD FS supporta l'autenticazione dei dispositivi utilizzando i certificati forniti dal servizio di Registrazione dei dispositivi durante l'associazione del dispositivo da parte dell'utente finale nel proprio ambiente di lavoro.
Requisiti per la connessione all'ambiente di lavoro
Gli utenti finali possono aggiungere i propri dispositivi a un'organizzazione usando AD FS. Questa funzionalità è supportata dal servizio Registrazione dispositivi in AD FS. Di conseguenza, gli utenti finali ottengono il vantaggio aggiuntivo di SSO tra le applicazioni supportate da AD FS. Inoltre, gli amministratori possono gestire i rischi limitando l'accesso alle applicazioni solo ai dispositivi che sono stati registrati o affiliati al network aziendale. Di seguito sono riportati i requisiti seguenti per abilitare questo scenario.
AD FS supporta l'aggiunta all'area di lavoro per dispositivi Windows 8.1 e iOS 5+
Per utilizzare la funzionalità di Join Area di lavoro, lo schema della foresta a cui sono collegati i server AD FS deve essere Windows Server 2012 R2.
Il nome alternativo del soggetto del certificato SSL per il servizio AD FS deve contenere la stringa enterpriseregistration seguita dal suffisso Nome Utente Principale (UPN) dell'organizzazione, ad esempio enterpriseregistration.corp.contoso.com.
Requisiti di crittografia
La tabella seguente fornisce informazioni aggiuntive sul supporto della crittografia per la firma del token AD FS, la funzionalità di crittografia/decrittografia dei token:
| Algoritmo | Lunghezze chiave | Protocolli/applicazioni/commenti |
|---|---|---|
| TripleDES: valore predefinito 192 (supportato da 192 a 256) - http://www.w3.org/2001/04/xmlenc#tripledes-cbc | >= 192 | Algoritmo supportato per decrittografare il token di sicurezza. La crittografia del token di sicurezza con questo algoritmo non è supportata. |
| AES128 - http://www.w3.org/2001/04/xmlenc#aes128-cbc | 128 | Algoritmo supportato per decrittografare il token di sicurezza. La crittografia del token di sicurezza con questo algoritmo non è supportata. |
| AES192 - http://www.w3.org/2001/04/xmlenc#aes192-cbc | 192 | Algoritmo supportato per decrittografare il token di sicurezza. La crittografia del token di sicurezza con questo algoritmo non è supportata. |
| AES256 - http://www.w3.org/2001/04/xmlenc#aes256-cbc | 256 | Predefinito. Algoritmo supportato per crittografare il token di sicurezza. |
| TripleDESKeyWrap - http://www.w3.org/2001/04/xmlenc#kw-tripledes | Tutte le dimensioni delle chiavi supportate da .NET 4.0+ | Algoritmo supportato per crittografare la chiave simmetrica che crittografa un token di sicurezza. |
| AES128KeyWrap - http://www.w3.org/2001/04/xmlenc#kw-aes128 | 128 | Algoritmo supportato per crittografare la chiave simmetrica che crittografa il token di sicurezza. |
| AES192KeyWrap - http://www.w3.org/2001/04/xmlenc#kw-aes192 | 192 | Algoritmo supportato per crittografare la chiave simmetrica che crittografa il token di sicurezza. |
| AES256KeyWrap - http://www.w3.org/2001/04/xmlenc#kw-aes256 | 256 | Algoritmo supportato per crittografare la chiave simmetrica che crittografa il token di sicurezza. |
| RsaV15KeyWrap - http://www.w3.org/2001/04/xmlenc#rsa-1_5 | 1024 | Algoritmo supportato per crittografare la chiave simmetrica che crittografa il token di sicurezza. |
| RsaOaepKeyWrap - http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p | 1024 | Predefinito Algoritmo supportato per crittografare la chiave simmetrica che crittografa il token di sicurezza. |
| SHA1-http://www.w3.org/PICS/DSig/SHA1_1_0.html | Non disponibile | Usato dal server AD FS nella generazione del SourceId: in questo scenario, l'STS usa SHA1 (in base alla raccomandazione dello standard SAML 2.0) per creare un breve valore di 160 bit per il SourceId. Usato anche dall'agente Web AD FS (componente legacy da Windows Server 2003) per identificare le modifiche in un valore temporale di "ultimo aggiornamento" in modo che sappia quando aggiornare le informazioni dal servizio token di sicurezza (STS). |
| SHA1withRSA- | Non disponibile | Usato nei casi in cui AD FS Server convalida la firma di SAML AuthenticationRequest, firma la richiesta o la risposta di risoluzione degli artefatti, crea il certificato di firma del token. In questi casi, SHA256 è l'impostazione predefinita e SHA1 viene usato solo se il partner (relying party) non può supportare SHA256 e deve usare SHA1. |
Requisiti delle autorizzazioni
L'amministratore che esegue l'installazione e la configurazione iniziale di AD FS devono disporre delle autorizzazioni di amministratore di dominio nel dominio locale ( in altre parole, il dominio a cui è aggiunto il server federativo).