Requisiti di AD FS per Windows Server
Di seguito sono illustrati i requisiti che è necessario rispettare i durante la distribuzione di ADFS:
Requisiti del certificato
I certificati rivestono il ruolo più importante nel rendere sicure le comunicazioni tra server federativi, i server proxy applicazione Web, applicazioni in grado di riconoscere attestazioni e client Web. I requisiti per i certificati variano, a seconda se si configura un server federativo o un computer proxy, come descritto in questa sezione.
Certificati dei server federativi
| Tipo di certificato | Requisiti, supporto & informazioni utili |
|---|---|
| Certificato Secure Sockets Layer (SSL): si tratta di un certificato SSL standard che viene utilizzato per proteggere le comunicazioni tra client e server federativi. | - Questo certificato deve essere un certificato X509 v3 pubblicamente attendibile*. -Tutti i client che accedono a qualsiasi endpoint ADFS devono considerare attendibile il certificato. È consigliabile usare certificati emessi da un'autorità di certificazione pubblica (di terzi). È possibile usare correttamente un certificato SSL autofirmato nei server federativi in un ambiente lab di test. Tuttavia, per un ambiente di produzione, si consiglia di ottenere il certificato da una CA pubblica. -Supporta qualsiasi dimensione di chiave supportati da Windows Server 2012 R2 per i certificati SSL. - Non supporta i certificati che usano chiavi CNG. - Quando utilizzato insieme ad Aggiunta alla rete aziendale/Device Registration Service, il nome alternativo del soggetto del certificato SSL per il servizio AD FS deve contenere il valore enterpriseregistration seguito dal suffisso del nome dell'entità utente (UPN) dell'organizzazione, ad esempio, enterpriseregistration.contoso.com. -I certificati con caratteri jolly sono supportati. Quando si crea la farm di AD FS, verrà richiesto di fornire 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. Tuttavia è obbligatorio che siano gli stessi per supportare gli endpoint di autenticazione integrata di Windows tramite il Proxy applicazione Web e quando è abilitata l'autenticazione di protezione estesa (impostazione predefinita). -Il nome del soggetto del certificato viene utilizzato per rappresentare il nome del servizio federativo per ogni istanza di ADFS da distribuire. Per questo motivo, in un nuovo certificato rilasciato da una CA è consigliabile scegliere un nome soggetto che meglio rappresenti il nome della società o dell'organizzazione per i partner. L'identità del certificato deve corrispondere col nome del servizio federativo (ad esempio, fs.contoso.com). L'identità è un'estensione di nome alternativo del soggetto di tipo dNSName o, se non sono presenti voci di nome alternativo del soggetto, il nome del soggetto specificato come nome comune. Più voci di nome alternativo soggetto possono essere presenti nel certificato, purché una di esse corrisponda al nome di servizio federativo. - Importante: è consigliabile utilizzare lo stesso certificato SSL in tutti i nodi della farm AD FS e in tutti i proxy applicazione Web nella farm di AD FS. |
| Certificato di comunicazione del servizio: questo certificato consente la protezione dei messaggi WCF per proteggere le comunicazioni tra server federativi. | : Per impostazione predefinita, il certificato SSL viene utilizzato come certificato per le comunicazioni del servizio. Ma è anche possibile configurare un altro certificato come certificato di comunicazione del servizio. - Importante: se si utilizza il certificato SSL come certificato di comunicazione del servizio, alla scadenza del certificato SSL, 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 ADFS che utilizzano la sicurezza dei messaggi WCF. - È consigliabile usare un certificato di autenticazione server rilasciato da un'autorità di certificazione pubblica (di terzi). - Il certificato di comunicazione del servizio non può essere un certificato che utilizza chiavi CNG. -Questo certificato può essere gestito utilizzando la console di gestione di ADFS. |
| Certificato per la firma di token: questo è un certificato standard X509 utilizzato 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 -Ha rilasciata i certificati CA necessario archiviata & accessibili tramite un Provider di crittografia CSP. - Il certificato per la firma di token non può essere un certificato che utilizza chiavi CNG. - AD FS non richiede certificati registrati esternamente per la firma del token. AD FS rinnova automaticamente questi certificati autofirmati 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 certificati diversi da configurare 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 per la firma dei token usando la console di gestione di AD FS o i cmdlet di PowerShell Set-AdfsCertificate e Get-AdfsCertificate. Quando vengono utilizzati i certificati registrati esternamente per la firma di token, AD FS non esegue il rinnovo automatico del certificato o rollover. Questo processo deve essere eseguito da un amministratore. Per consentire rollover del certificato quando si è prossimi alla scadenza di un certificato, è possibile configurare un certificato di firma di token secondario in ADFS. Per impostazione predefinita, tutti i certificati per la 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. |
| Certificato di decrittografia/crittografia del token: questo è un certificato X509 standard usato per decrittografare/crittografare i token in ingresso. Viene pubblicato anche nei metadati federativi. | - 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 -Ha rilasciata i certificati CA necessario archiviata & 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 autofirmati prima della scadenza. È consigliabile utilizzare l'impostazione predefinita, i certificati generati automaticamente per la decrittografia di token. Se l'organizzazione dispone di criteri che richiedono certificati diversi da configurare 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 del servizio AD FS deve avere accesso alla chiave privata del certificato di firma del token nell'archivio personale del computer locale. Questo viene preso in considerazione dal programma di 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 nel gestire i propri token-firma & token-decrittografare/crittografare i certificati devono assicurarsi che questi certificati vengano sottoposti a backup e siano disponibili in modo indipendente 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 di sicurezza, usare SHA-256 (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 personali del computer locale. È possibile importare i certificati nell'archivio personale con lo snap-in MMC Certificati.
Requisiti hardware
Si applicano i seguenti requisiti hardware minimi e consigliati per i server federativi ADFS in Windows Server 2012 R2:
| Requisito hardware | Requisito minimo | Requisito consigliato |
|---|---|---|
| Velocità di CPU | Processore a 64 bit da 1,4 GHz | quad-core, 2 GHz |
| RAM | 512 MB | 4 GB |
| Spazio su disco | 32 GB | 100 GB |
Requisiti software
I seguenti requisiti di ADFS sono per la funzionalità server che è incorporata nel sistema operativo Windows Server® 2012 R2:
Per l'accesso extranet, è necessario distribuire il servizio ruolo Proxy 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.
Un server federativo e il servizio ruolo Proxy applicazione Web non possono essere installati nello stesso computer.
Requisiti di Active Directory Domain Services
Requisiti del controller di dominio
I controller di dominio in tutti i domini utente e il dominio a cui sono stati aggiunti i server ADFS devono essere in esecuzione Windows Server 2008 o versione successiva.
Nota
Tutto il supporto per gli ambienti con controller di dominio di Windows Server 2003 terminerà dopo l'estesi supportano End Date per Windows Server 2003. I clienti consiglia di aggiornare i controller di dominio appena possibile. Visitare questa pagina Per ulteriori informazioni sul ciclo di vita del supporto tecnico Microsoft. Per problemi rilevati che sono specifiche per ambienti di controller di dominio Windows Server 2003, correzioni verranno generate solo per i problemi di sicurezza e se è possibile emettere una correzione prima della scadenza di estendere il supporto per Windows Server 2003.
Nota
AD FS richiede un controller di dominio scrivibile completo per funzionare anziché un controller di dominio di sola lettura. Se una topologia pianificata include un controller di dominio di sola lettura, il controller di dominio di sola lettura può essere usato per l'autenticazione, ma l'elaborazione delle attestazioni LDAP richiederà una connessione al controller di dominio scrivibile.
Requisiti a livello di funzionalità del dominio
Tutti i domini di account utente e il dominio a cui sono stati aggiunti i server ADFS deve funzionare a livello funzionale di dominio di Windows Server 2003 o versione successiva.
Il corretto funzionamento della maggior parte delle funzionalità di ADFS non richiede modifiche a livello funzionale per Servizi di dominio Active Directory. Tuttavia, per il corretto funzionamento dell'autenticazione del certificato client, se il certificato è mappato in modo esplicito a un account utente in Servizi di dominio Active Directory, sarà necessario il livello di funzionalità del dominio di Windows Server 2008 o superiore.
Requisiti dello schema
AD FS non richiede modifiche dello schema o modifiche a livello di funzionalità in Servizi di dominio Active Directory.
Per utilizzare la funzionalità aggiunta alla rete aziendale, è necessario impostare lo schema dell'insieme di strutture collegati al server ADFS per Windows Server 2012 R2.
Requisiti dell'account del servizio
Qualsiasi account di servizio standard può essere utilizzato come account del servizio per ADFS. 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, ADFS configurerà questo quando si crea una nuova farm ADFS se dispone di autorizzazioni sufficienti per eseguire questa operazione.
L'account del servizio ADFS deve essere considerato attendibile in ogni dominio utente che contiene gli utenti l'autenticazione per il servizio ADFS.
Requisiti di dominio
Tutti i server ADFS devono essere di un dominio di Active Directory.
Tutti i server ADFS all'interno di una farm devono essere distribuiti in un singolo dominio.
Il dominio che fanno parte dei server ADFS deve considerare attendibile ogni dominio dell'account utente che contenga gli utenti l'autenticazione per il servizio ADFS.
Requisiti per più foreste
Ogni dominio dell'account utente o un insieme di strutture che contiene gli utenti l'autenticazione per il servizio ADFS, deve considerare attendibile il dominio che fanno parte dei server ADFS.
L'account del servizio ADFS deve essere considerato attendibile in ogni dominio utente che contiene gli utenti l'autenticazione per il servizio ADFS.
Requisiti del database di configurazione
Di seguito sono i requisiti e limitazioni applicabili in base al tipo di archivio di configurazione:
Database interno di Windows
Una farm WID ha un limite di 30 server federativi se sono presenti 100 o meno trust relying party.
Il profilo di risoluzione degli artefatti in SAML 2.0 non è supportato nel database di configurazione WID. Il rilevamento riproduzione token non è supportato nel database di configurazione database interno di Windows. Questa funzionalità viene solo utilizzata solo in scenari in cui ADFS è funge da provider di federazione e l'utilizzo di token di sicurezza da provider di attestazioni esterno.
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 fornisce un riepilogo di utilizzo di una farm database interno di Windows. Usato per pianificare l'implementazione.
| 1-100 attendibilità della relying party | Più di 100 attendibilità della relying Party |
|---|---|
| 1-30 nodi AD FS: WID supportato | 1-30 nodi AD FS: 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 del browser
Quando viene eseguita l'autenticazione di ADFS tramite un browser o un controllo browser, il browser deve essere conforme ai requisiti seguenti:
È necessario abilitare JavaScript
È necessario attivare i cookie
L'indicazione del nome del server (SNI) deve essere supportata
Per l'autenticazione del certificato dispositivo & certificato utente (funzionalità Workplace Join), il browser deve supportare l'autenticazione del certificato client SSL
Diverse piattaforme e browser chiave sottoposte a livello di convalida per il rendering e funzionalità, i cui dettagli sono elencati di seguito. Browser e dispositivi che non trattate 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 |
| Broker di autenticazione Web di Windows | 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'autenticazione del certificato client SSL utilizzando i certificati di provisioning per l'archivio certificati utente sui client Windows.
Cookies
ADFS crea cookie permanenti e basati su sessione che devono essere archiviati nei computer client per fornire funzionalità di accesso, disconnessione, Single Sign-On (SSO) e altre. Il browser client deve quindi essere configurato in modo da accettare i cookie. I cookie usati per l'autenticazione sono sempre cookie di sessioni HTTPS (Secure Hypertext Transfer Protocol) scritti per il server di origine. Se il browser client non è configurato per abilitare questi cookie, AD FS non potrà funzionare correttamente. I cookie permanenti vengono usati per mantenere la selezione del provider di attestazioni effettuata dall'utente. È possibile disabilitarli usando un'impostazione di configurazione nel file di configurazione relativo alle pagine di accesso di ADFS. Per motivi di sicurezza, è richiesto il supporto per TLS/SSL.
Requisiti Extranet
Per fornire l'accesso extranet al servizio ADFS, è necessario distribuire il servizio ruolo Proxy applicazione Web come ruolo pubblico extranet che le richieste di autenticazione proxy in modo sicuro per il servizio ADFS. 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à, ad esempio il blocco degli Account Extranet Soft richiedono l'utilizzo del Proxy dell'applicazione Web. Per ulteriori informazioni sul Proxy dell'applicazione Web, vedere Proxy applicazione Web. `
Requisiti di rete
Configurazione dei seguenti servizi di rete è essenziale per una corretta distribuzione di ADFS nell'organizzazione:
Configurazione del firewall aziendale
Entrambi i firewall si trova tra il Proxy dell'applicazione Web e la server farm federativa e il firewall tra i client e il Proxy dell'applicazione Web deve avere la porta TCP 443 abilitato 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 del 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) al servizio di bilanciamento del carico per i server proxy applicazione Web o il server proxy applicazione Web.
Per il corretto funzionamento dell'accesso extranet, ogni server proxy applicazione Web nella rete perimetrale deve 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. Ciò può essere ottenuto tramite un server DNS alternativo nella rete Perimetrale o modificando la risoluzione del server locale utilizzando file HOST.
Affinché l'autenticazione integrata di Windows funzioni all'interno della rete e all'esterno della rete per un subset di endpoint esposti tramite il proxy applicazione Web, è necessario usare un record A (non CNAME) per puntare ai servizi di bilanciamento del carico.
Per informazioni sulla configurazione DNS aziendale per il servizio federativo e il servizio DRS, vedere configurare DNS aziendale per il servizio federativo e il servizio DRS.
Per informazioni sulla configurazione del DNS aziendale per i proxy dell'applicazione Web, consultare la sezione "Configurare 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 Bilanciamento carico di rete, consultare Specifica dei parametri del cluster in http://go.microsoft.com/fwlink/?LinkId=75282.
Requisiti dell'archivio attributi
ADFS richiede almeno un archivio di attributi da utilizzare per l'autenticazione degli utenti e l'estrazione delle attestazioni di sicurezza per gli utenti. Per un elenco di attributi di archivi che supportano ADFS, vedere il ruolo degli archivi attributi.
Nota
Per impostazione predefinita, AD FS crea automaticamente un archivio attributi di Active Directory. I requisiti dell'archivio attributi dipendono dal ruolo svolto dall'organizzazione, cioè come partner account (che ospita gli utenti federati) o come partner risorse (che ospita l'applicazione federata).
archivi attributi LDAP
Quando si usano altri archivi attributi basati su LDAP (Lightweight Directory Access Protocol), è necessario connettersi a un server LDAP che supporti l'autenticazione integrata di Windows. Anche la stringa di connessione LDAP deve essere scritta nel formato di URL LDAP, come descritto nella RFC 2255.
È inoltre necessario che l'account del servizio per il servizio AD FS disponga del diritto di recuperare le informazioni utente nell'archivio attributi LDAP.
Archivi attributi di SQL Server
Per ADFS in Windows Server 2012 R2 per il corretto funzionamento, i computer che ospitano l'archivio di attributi di SQL Server devono essere in esecuzione Microsoft SQL Server 2008 o versione successiva. Quando si usano archivi attributi basati su SQL, occorre configurare anche una stringa di connessione.
Archivi di attributi personalizzati
Per abilitare scenari avanzati, è possibile sviluppare archivi attributi personalizzati.
Il linguaggio dei criteri integrato in ADFS consente di fare riferimento ad archivi attributi personalizzati per il miglioramento di uno qualsiasi degli scenari seguenti:
Creazione di attestazioni per un utente autenticato localmente
Integrazione di attestazioni per un utente autenticato esternamente
Autorizzazione di un utente a ottenere un token
Autorizzazione di un servizio a ottenere un token sul comportamento di un utente
Emittente dati aggiuntivi nei token di sicurezza emesso da ADFS per le relying party.
Tutti gli archivi di attributi personalizzati devono essere compilati su .NET 4.0 o versione successiva.
Quando si lavora con un archivio attributi personalizzato, è inoltre necessario configurare una stringa di connessione. In tal caso, è possibile immettere un codice personalizzato di propria scelta che consente la connessione all'archivio di attributi personalizzati. La stringa di connessione in questa situazione è un set di coppie nome/valore interpretate come implementate dallo sviluppatore dell'archivio attributi personalizzato. Per ulteriori informazioni sullo sviluppo e sull'uso di archivi attributi personalizzati, consultare Panoramica dell'archivio attributi.
Requisiti delle applicazioni
AD FS supporta applicazioni in grado di riconoscere attestazioni che usano i protocolli seguenti:
WS-Federation
WS-Trust
Utilizzo dei profili IDPLite, SPLite & eGov1.5 protocollo SAML 2.0.
Profilo di concessione di autorizzazione OAuth 2.0
AD FS supporta anche l'autenticazione e l'autorizzazione per tutte le applicazioni che non supportano attestazioni supportate dal proxy applicazione Web.
Requisiti dell'autenticazione
Autenticazione di Active Directory Domain Services (autenticazione primaria)
Per l'accesso intranet, sono supportati i seguenti meccanismi di autenticazione standard per Active Directory:
Autenticazione integrata di Windows utilizza Negotiate per Kerberos & NTLM
Autenticazione basata su form con nome utente/password
Autenticazione dei certificati utilizzando certificati mappati ad account utente di dominio Active Directory
Per l'accesso extranet, sono supportati i meccanismi di autenticazione seguenti:
Autenticazione basata su form con nome utente/password
Autenticazione dei certificati utilizzando i certificati che sono mappati ad account utente di dominio Active Directory
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 alla smart card che può essere un pin protetto.
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 del servizio di crittografia (CSP) della smart card devono essere in funzione nel computer in cui risiede il browser.
Il certificato della smart card deve conduce a una radice attendibile in tutti i server ADFS e server Proxy applicazione Web.
Il certificato deve essere mappato all'account utente in Servizi di dominio Active Directory con uno dei metodi seguenti:
Il nome soggetto del certificato corrisponde al nome distinto LDAP di un account utente in Servizi di dominio Active Directory.
L'estensione relativa al nome alternativo soggetto (SubjectAltName) del certificato ha il nome dell'entità utente (UPN) di un account utente in Servizi di dominio Active Directory.
Per l'autenticazione integrata di Windows senza problemi utilizzando Kerberos nella rete intranet,
È necessario che il nome del servizio faccia parte dei siti attendibili o dei siti Intranet locali.
Inoltre, l'HOST/<adfs_service_name> SPN deve essere impostato sull'account del servizio su cui viene eseguita la farm AD FS.
Multi-Factor Authentication
AD FS supporta l'autenticazione aggiuntiva (oltre l'autenticazione primaria supportata da Active Directory Domain Services) 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 scheda di autenticazione a più Fattori deve essere compilato in .NET 4.5.
Per ulteriori informazioni sull'autenticazione a più Fattori, vedere gestire i rischi con l'autenticazione a più fattori aggiuntiva per le applicazioni con.
Autenticazione del dispositivo
ADFS supporta l'autenticazione del dispositivo utilizzando i certificati di provisioning dal servizio Registrazione dispositivi di durante l'atto di un'unione di dispositivo all'area di lavoro degli utenti finali.
Requisiti di join all'area di lavoro
Gli utenti finali possono all'area di lavoro i propri dispositivi a un'organizzazione che utilizza ADFS. Questa è supportata dal servizio Registrazione dispositivi di ADFS. Di conseguenza, gli utenti finali ottengono l'ulteriore vantaggio di SSO tra le applicazioni supportate da ADFS. Inoltre, gli amministratori possono gestire i rischi limitando l'accesso alle applicazioni solo ai dispositivi che sono stati aggiunto all'organizzazione all'area di lavoro. Di seguito sono i seguenti requisiti 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à aggiunta alla rete aziendale, lo schema dell'insieme di strutture collegati al server ADFS deve essere Windows Server 2012 R2.
Il nome alternativo 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.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 | Valore predefinito. Algoritmo supportato per crittografare il token di sicurezza. |
| TripleDESKeyWrap - http://www.w3.org/2001/04/xmlenc#kw-tripledes | Tutte le dimensioni di chiave 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 consente di crittografare il token di sicurezza. |
| AES192KeyWrap - http://www.w3.org/2001/04/xmlenc#kw-aes192 | 192 | Algoritmo supportato per crittografare la chiave simmetrica che consente di crittografare il token di sicurezza. |
| AES256KeyWrap - http://www.w3.org/2001/04/xmlenc#kw-aes256 | 256 | Algoritmo supportato per crittografare la chiave simmetrica che consente di crittografare il token di sicurezza. |
| RsaV15KeyWrap - http://www.w3.org/2001/04/xmlenc#rsa-1_5 | 1024 | Algoritmo supportato per crittografare la chiave simmetrica che consente di crittografare 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 consente di crittografare il token di sicurezza. |
| SHA1-http://www.w3.org/PICS/DSig/SHA1_1_0.html | N/D | Usato dal server AD FS nella generazione dell'elemento SourceId: in questo scenario, il servizio token di sicurezza usa SHA1 (in base alla raccomandazione nello standard SAML 2.0) per creare un valore breve a 160 bit per l'elemento sourceiD. Usato anche dall'agente Web AD FS (componente legacy da WS2003) per identificare le modifiche in un valore di ora "ultimo aggiornamento" in modo che sappia quando aggiornare le informazioni dal servizio token di sicurezza. |
| SHA1withRSA- | N/D | Usato nei casi in cui AD FS Server convalida la firma di SAML AuthenticationRequest, firmare la richiesta o la risposta di risoluzione degli artefatti, creare 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 di autorizzazione
L'amministratore che esegue l'installazione e la configurazione iniziale di AD FS deve disporre delle autorizzazioni di amministratore di dominio nel dominio locale (in altre parole, il dominio a cui è aggiunto il server federativo).