Debug degli errori di autenticazione di Windows

Quando si utilizza l'autenticazione di Windows come meccanismo di protezione, i processi di protezione vengono gestiti dall'interfaccia SSPI (Security Support Provider Interface). Se si verificano errori di protezione a livello SSPI, questi vengono riportati da Windows Communication Foundation (WCF). In questo argomento viene fornito un framework e un insieme di domande per facilitare la diagnosi degli errori.

Per una panoramica sul protocollo Kerberos, vedere Kerberos Explained (la pagina potrebbe essere in inglese), per una panoramica su SSPI, vedere SSPI.

Per l'autenticazione di Windows, in WCF viene in genere utilizzato Security Support Provider (SSP) negoziato, che esegue l'autenticazione reciproca Kerberos tra il client e il servizio. Se il protocollo Kerberos non è disponibile, per impostazione predefinita WCF esegue il fallback al protocollo NTLM (NT LAN Manager). È tuttavia possibile configurare WCF per utilizzare solo il protocollo Kerberos e viene generata un'eccezione se Kerberos non è disponibile. È inoltre possibile configurare WCF per utilizzare formati con restrizioni del protocollo Kerberos.

Metodologia di debug

Il metodo di base è il seguente:

1. Determinare se si sta utilizzando l'autenticazione di Windows. Se si sta utilizzando qualsiasi altro schema, questo argomento non è applicabile.
2. Se si sta utilizzando con certezza l'autenticazione di Windows, determinare se la configurazione WCF utilizza Kerberos direttamente o Negotiate.
3. Una volta determinato se la configurazione utilizza il protocollo Kerberos o NTLM, è possibile comprendere i messaggi di errore nel contesto giusto.

Disponibilità del protocollo Kerberos e NTLM

Per l'SSP Kerberos è necessario un controller di dominio che agisca da Centro di distribuzione chiave Kerberos (KDC, Kerberos Key Distribution Center). Il protocollo Kerberos è disponibile solo quando sia il client che il servizio utilizzano identità di dominio. In altre combinazioni di account, viene utilizzato il protocollo NTLM, come riepilogato nella tabella seguente.

Nelle intestazioni della tabella vengono riportati i possibili tipi di account utilizzati dal server, mentre nella colonna sinistra vengono indicati i possibili tipi di account utilizzati dal client.

In particolare, i quattro tipi di account includono:

• Utente locale: profilo utente del computer. ad esempio: MachineName\Administrator o MachineName\ProfileName.
• Sistema locale: account predefinito SYSTEM in un computer non associato a un dominio.
• Utente del dominio: account utente in un dominio Windows. Ad esempio: DomainName\ProfileName.
• Computer del dominio: processo con identità di computer in esecuzione in un computer associato a un dominio Windows. Ad esempio: MachineName\Network Service.

Problemi di autenticazione di Windows comuni

In questa sezione vengono illustrati alcuni problemi di autenticazione di Windows comuni e le possibili soluzioni.

Protocollo Kerberos

Problemi SPN/UPN con il protocollo Kerberos

Quando si utilizza l'autenticazione di Windows unitamente al protocollo Kerberos diretto o negoziato mediante SSPI, l'URL utilizzato dall'endpoint client deve includere il nome di dominio completo dell'host del servizio presente nell'URL del servizio. Questo presuppone che l'account utilizzato per l'esecuzione del servizio abbia accesso alla chiave del nome dell'entità servizio (SPN) del computer (impostazione predefinita) creata quando il computer viene aggiunto al dominio di Active Directory, generalmente eseguendo il servizio con l'account Servizio di rete. Se il servizio non ha accesso alla chiave dell'SPN del computer, è necessario fornire l'SPN corretto o il nome dell'entità utente (UPN) dell'account utilizzato per l'esecuzione del servizio nell'identità dell'endpoint del client. Per ulteriori informazioni sul funzionamento di WCF con SPN e UPN, vedere Identità del servizio e autenticazione.

In scenari di bilanciamento del carico, ad esempio Web farm o Web garden, viene comunemente definito un account univoco per ogni applicazione, viene assegnato un SPN a tale account e viene verificato che tutti i servizi dell'applicazione siano eseguiti in tale account.

Per ottenere un SPN per l'account del servizio, è necessario essere amministratore di dominio di Active Directory. Per ulteriori informazioni, vedere Supplemento tecnico Kerberos per Windows.

Per il protocollo Kerberos diretto è necessario che il servizio venga eseguito utilizzando un account di tipo computer del dominio

Questo si verifica quando la proprietà ClientCredentialType è impostata su Windows e la proprietà NegotiateServiceCredential è impostata su false, come illustrato nel codice seguente.

Per risolvere questo problema, eseguire il servizio utilizzando un account di tipo computer del dominio, ad esempio Servizio di rete, in un computer associato al dominio.

Requisito di negoziazione della credenziale in caso di delega

Per poter essere utilizzato con la funzionalità di delega, il protocollo di autenticazione Kerberos deve essere implementato con la negoziazione della credenziale. Questa versione di Kerberos è nota come Kerberos multifase o multipassaggio. Se si implementa l'autenticazione Kerberos senza negoziazione della credenziale (ovvero una versione di Kerberos anche nota come "monofase" o "monopassaggio), verrà generata un'eccezione.

Per implementare Kerberos con negoziazione della credenziale, eseguire le operazioni seguenti:

1. Implementare la delega impostando AllowedImpersonationLevel su Delegation.
2. Richiedere la negoziazione SSPI:
   1. Se si utilizzano associazioni standard, impostare la proprietà NegotiateServiceCredential su true.
   2. Se si utilizzano associazioni personalizzate, impostare l'attributo AuthenticationMode dell'elemento Security su SspiNegotiated.
3. Richiedere che la negoziazione SSPI utilizzi Kerberos impedendo l'utilizzo di NTLM:
   1. È possibile eseguire questa operazione nel codice utilizzando l'istruzione seguente: ChannelFactory.Credentials.Windows.AllowNtlm = false
   2. In alternativa, è possibile operare nel file di configurazione impostando l'attributo allowNtlm su false. Questo attributo è contenuto in <windows> of <clientCredentials> element.

Protocollo NTLM

Il provider SSP Negotiate esegue il fallback a NTLM, ma NTLM è disattivato

Poiché la proprietà AllowNtlm è impostata su false, Windows Communication Foundation (WCF) tenta di generare un'eccezione se viene utilizzato NTLM. Si noti che l'impostazione di questa proprietà su false potrebbe non impedire l'invio di credenziali NTLM nella rete.

Nel codice seguente viene illustrato come disattivare il fallback a NTLM.

Impossibile accedere a NTLM

Le credenziali client non sono valide per il servizio. Verificare che il nome utente e la password siano impostati correttamente e che corrispondano a un account noto al computer in cui viene eseguito il servizio. Per accedere al computer del servizio, NTLM utilizza le credenziali specificate. Anche se le credenziali possono essere valide nel computer in cui il client è in esecuzione, l'accesso non riuscirà se le credenziali non sono valide nel computer del servizio.

Si verifica un accesso NTLM anonimo, ma gli accessi anonimi sono disattivati per impostazione predefinita

Quando si crea un client, la proprietà AllowedImpersonationLevel viene impostata su Anonymous, come illustrato nell'esempio seguente, ma per impostazione predefinita il server impedisce gli accessi anonimi. Tale situazione si verifica perché il valore predefinito della proprietà AllowAnonymousLogons della classe WindowsServiceCredential è false.

Nel codice client seguente viene tentata l'attivazione degli accessi anonimi (si noti che la proprietà predefinita è Identification).

Nel codice del servizio seguente viene modificata l'impostazione predefinita per consentire gli accessi anonimi.

Per ulteriori informazioni sulla rappresentazione, vedere Delega e rappresentazione con WCF.

In alternativa, il client viene eseguito come un servizio Windows, utilizzando l'account predefinito System.

Altri problemi

Le credenziali client non sono impostate correttamente

L'autenticazione di Windows utilizza l'istanza WindowsClientCredential restituita dalla proprietà ClientCredentials della classe ClientBase, non l'istanza UserNamePasswordClientCredential. Nel codice seguente viene illustrato un esempio non corretto.

Nel codice seguente viene illustrato l'esempio corretto.

L'interfaccia SSPI non è disponibile

I sistemi operativi seguenti non supportano l'autenticazione di Windows se utilizzati come server: Windows XP Home Edition, Windows XP Media Center Edition e Windows Vista Home edition.

Sviluppo e distribuzione con identità diverse

Se l'applicazione viene sviluppata in un computer e distribuita in un altro e si utilizzano diversi tipi di account per l'autenticazione in ogni computer, potrebbe verificarsi un comportamento diverso. Si supponga, ad esempio, di sviluppare l'applicazione in un computer Windows XP Pro utilizzando la modalità di autenticazione SSPI Negotiated. Se si utilizza un account utente locale per l'autenticazione, verrà utilizzato il protocollo NTLM. Una volta sviluppata l'applicazione, il servizio viene distribuito in un computer Windows Server 2003 in cui è in esecuzione un account di dominio. A questo punto il client non è in grado di autenticare il servizio poiché utilizza Kerberos e un controller di dominio.

Vedere anche

Riferimenti

WindowsClientCredential
WindowsServiceCredential
WindowsClientCredential
ClientBase

Concetti

Delega e rappresentazione con WCF
Scenari non supportati