Pianificare l'autenticazione Kerberos in SharePoint Server
SI APPLICA A:
2013 2016 2019 Subscription Edition 
SharePoint in Microsoft 365
Il protocollo Kerberos supporta un metodo di autenticazione che prevede l'utilizzo di ticket forniti da un'origine attendibile. I ticket Kerberos indicano che le credenziali di rete di un utente associato a un computer client sono state autenticate. Il protocollo Kerberos definisce il modo in cui gli utenti interagiscono con un servizio di rete per accedere alle risorse di rete. Dal Centro distribuzione chiavi Kerberos viene emesso un ticket di concessione ticket (TGT) a un computer client per conto di un utente. In Windows il computer client è membro del dominio Servizi di dominio Active Directory e il ticket di concessione ticket è la prova che le credenziali utente sono state autenticate dal controller di dominio.
Prima di stabilire una connessione di rete a un servizio di rete, il computer client presenta il ticket di concessione ticket al Centro distribuzione chiavi e richiede un ticket di servizio. In base al ticket di concessione ticket emesso in precedenza, che conferma che il computer client è stato autenticato, dal Centro distribuzione chiavi viene emesso un ticket di servizio per il computer client. Il ticket di servizio viene quindi inviato dal computer client al servizio di rete. Il ticket di servizio deve anche contenere un nome dell'entità di servizio che identifica il servizio. Per consentire l'autenticazione Kerberos, i computer client e server devono già disporre di una connessione trusted al Centro distribuzione chiavi. I computer client e server devono inoltre essere in grado di accedere a Servizi di dominio Active Directory.
Autenticazione Kerberos e SharePoint Server
I motivi per cui considerare la possibilità di utilizzare l'autenticazione Kerberos sono i seguenti:
Kerberos è il protocollo di autenticazione integrata di Windows più sicuro e supporta caratteristiche di sicurezza avanzate, tra cui la crittografia AES (Advanced Encryption Standard) e l'autenticazione reciproca di client e server.
Il protocollo Kerberos consente la delega delle credenziali client.
Di tutti i metodi di autenticazione sicura disponibili, Kerberos richiede la quantità minore di traffico di rete verso i controller di dominio Servizi di dominio Active Directory. Kerberos può ridurre la latenza delle pagine in alcuni scenari o aumentare il numero di pagine che un server Web front-end può gestire in determinati scenari. Kerberos può inoltre ridurre il carico nei controller di dominio.
Kerberos è un protocollo aperto supportato da molte piattaforme e numerosi fornitori.
I motivi per cui l'autenticazione Kerberos potrebbe non essere appropriata sono i seguenti:
A differenza degli altri metodi di autenticazione, per un corretto funzionamento l'autenticazione Kerberos richiede ulteriori passaggi di configurazione dell'infrastruttura e dell'ambiente. In molti casi, è necessaria l'autorizzazione di amministratore del dominio per configurare l'autenticazione Kerberos, che può risultare complessa da impostare e gestire. Una configurazione errata di Kerberos può impedire la corretta autenticazione nei siti.
L'autenticazione Kerberos richiede la connettività del computer client a un Centro distribuzione chiavi e a un controller di dominio Servizi di dominio Active Directory. In una distribuzione di Windows e SharePoint, il Centro distribuzione chiavi è un controller di dominio Servizi di dominio Active Directory. Questa è una configurazione di rete comune in una rete Intranet di un'organizzazione, mentre le distribuzioni con connessione Internet in genere non sono configurate in questo modo.
Delegazione Kerberos
L'autenticazione Kerberos supporta la delega dell'identità client. Questo significa che un servizio può rappresentare l'identità di un client autenticato. La rappresentazione consente a un servizio di passare l'identità autenticata ad altri servizi di rete per conto del client. Per delegare le credenziali client è anche possibile utilizzare l'autenticazione basata sulle attestazioni, la quale però richiede che l'applicazione back-end sia in grado di riconoscere attestazioni.
Utilizzata insieme a SharePoint Server, la delega Kerberos consente a un servizio front-end di autenticare un client e quindi di utilizzare l'identità di tale client per eseguire l'autenticazione in un sistema back-end. Quest'ultimo esegue quindi la propria autenticazione. Quando un client utilizza l'autenticazione Kerberos per eseguire l'autenticazione in un servizio front-end, la delega Kerberos può essere utilizzata per passare l'identità di un client a un sistema back-end. Il protocollo Kerberos supporta due tipi di delega:
Delega di base Kerberos (senza vincoli)
Delega vincolata Kerberos
Delega di base Kerberos e delega vincolata Kerberos
La delega di base Kerberos può oltrepassare i limiti del dominio all'interno della stessa foresta, ma non i limiti di una foresta. La delega vincolata Kerberos non può oltrepassare i limiti del dominio o della foresta, ad eccezione di quando si utilizzano controller di dominio che eseguono Windows Server 2012.
A seconda delle applicazioni di servizio che fanno parte di una distribuzione di SharePoint Server, l'implementazione delle autenticazioni Kerberos con SharePoint Server può richiedere l'utilizzo della delega vincolata Kerberos.
Importante
Per distribuire l'autenticazione Kerberos con una delle applicazioni di servizio seguenti, SharePoint Server e tutte le origini dati esterne devono risiedere nello stesso dominio di Windows: > Excel Services > PerformancePoint Services > InfoPath Forms Services > Visio Services > Queste applicazioni di servizio non sono disponibili in SharePoint Foundation 2013. Excel Services non è disponibile in SharePoint Server 2016.
Per distribuire l'autenticazione Kerberos con uno qualsiasi dei prodotti o delle applicazioni di servizio seguenti, in SharePoint Server può venire utilizzata la delega di base Kerberos oppure la delega vincolata Kerberos:
servizio di integrazione applicativa dei dati (questa applicazione di servizio non è disponibile in SharePoint Foundation 2013)
Access Services (questa applicazione di servizio non è disponibile in SharePoint Foundation 2013)
SQL Server Reporting Services (SSRS) (prodotto distinto)
Project Server 2016 (prodotto distinto)
I servizi abilitati per l'autenticazione Kerberos possono delegare l'identità più volte. Quando un'identità passa da un servizio all'altro, il metodo di delega può passare da Kerberos di base a Kerberos vincolato. Tuttavia, il contrario non è possibile. Il metodo di delega non può passare da Kerberos vincolato a Kerberos di base. È quindi importante prevedere e pianificare se un servizio back-end richiederà la delega Kerberos di base. Ciò può influire sulla pianificazione e la progettazione dei limiti di dominio.
In un servizio abilitato per Kerberos può venire utilizzata la transizione di protocollo per convertire un'identità non Kerberos in un'identità Kerberos delegabile ad altri servizi abilitati per Kerberos. Questa funzionalità può essere utilizzata, ad esempio, per delegare un'identità non Kerberos da un servizio front-end a un'identità Kerberos in un servizio back-end.
Importante
La transizione del protocollo richiede la delega vincolata Kerberos. Pertanto, le identità sottoposte a transizione del protocollo non possono superare i limiti del dominio.
L'autenticazione basata sulle attestazioni può essere usata come alternativa alla delega Kerberos. L'autenticazione basata sulle attestazioni consente di passare l'attestazione di autenticazione di un client tra servizi diversi se i servizi soddisfano tutti i criteri seguenti:
Deve esistere una relazione di trust tra i servizi.
Entrambi i servizi devono essere in grado di riconoscere attestazioni.
Per ulteriori informazioni sull'autenticazione Kerberos, vedere le risorse seguenti:
Autenticazione Kerberos e autenticazione basata sulle attestazioni
SharePoint 2013 e SharePoint Server 2016 supportano l'autenticazione basata sulle attestazioni. Questa è basata su Windows Identity Foundation (WIF), ovvero un set di classi di .NET Framework utilizzate per implementare l'identità basata sulle attestazioni. È inoltre basata su standard quali WS-Federation e WS-Trust. Per ulteriori informazioni sull'autenticazione basata sulle attestazioni, vedere le risorse seguenti:
Quando si crea un'applicazione Web di UNRESOLVED_TOKEN_VAL(SharePoint Server) utilizzando Amministrazione centrale, è necessario selezionare uno o più tipi di autenticazione basata sulle attestazioni. Quando si crea un'applicazione Web di UNRESOLVED_TOKEN_VAL(SharePoint Server) utilizzando il cmdlet New-SPWebApplication Microsoft PowerShell, è possibile specificare l'autenticazione delle attestazioni e i tipi di autenticazione delle attestazioni oppure l'autenticazione in modalità classica. L'autenticazione delle attestazioni è consigliata per tutte le applicazioni Web di UNRESOLVED_TOKEN_VAL(SharePoint Server). Se si utilizza l'autenticazione delle attestazioni, per le applicazioni Web sono disponibili tutti i tipi di autenticazione supportati ed è possibile utilizzare l'autenticazione delle app e da server a server. Per ulteriori informazioni, vedere What's new in authentication for SharePoint Server 2013.
Importante
The following service applications in SharePoint Server require the translation of claims-based credentials to Windows credentials. Questo processo di traduzione usa le attestazioni al servizio token Windows (C2WTS): >Excel Services>PerformancePoint Services>InfoPath Forms Services>Visio Services>> Queste applicazioni di servizio non sono disponibili in SharePoint Foundation 2013. Excel Services is not available in SharePoint Server 2016.
Le applicazioni di servizio che richiedono C2WTS devono usare la delega vincolata Kerberos perché C2WTS richiede la transizione di protocollo, supportata solo dalla delega vincolata Kerberos. Per le applicazioni di servizio nell'elenco precedente, C2WTS converte le attestazioni all'interno della farm in credenziali di Windows per l'autenticazione in uscita. È importante comprendere che queste applicazioni di servizio possono usare C2WTS solo se il metodo di autenticazione in ingresso è attestazioni di Windows o modalità classica di Windows. Le applicazioni di servizio a cui si accede tramite applicazioni Web e che usano attestazioni SAML (Security Assertion Markup Language) o attestazioni di autenticazione basata su moduli non usano C2WTS. Pertanto, non possono convertire le attestazioni in credenziali di Windows.
Autenticazione Kerberos e il nuovo modello di app di SharePoint
Se si usa la modalità attestazioni di Windows per l'autenticazione utente e l'applicazione Web è configurata per usare solo l'autenticazione Kerberos senza tornare a NTLM come protocollo di autenticazione, l'autenticazione dell'app non funziona. Per altre informazioni, vedere Pianificare l'autenticazione delle app in SharePoint Server.
Vedere anche
Concetti
Pianificare i metodi di autenticazione degli utenti in SharePoint Server