Débogage d'erreurs d'authentification Windows

Lorsque vous utilisez l'authentification Windows comme un mécanisme de sécurité, l'interface SSPI (Security Support Provider Interface) gère les processus de sécurité. Lorsque des erreurs de sécurité se produisent au niveau de la couche SSPI, elles sont signalées par Windows Communication Foundation (WCF). Cette rubrique fournit une infrastructure et un ensemble de questions permettant de diagnostiquer les erreurs.

Pour une vue d'ensemble du protocole Kerberos, consultez Explication du protocole Kerberos(page pouvant être en anglais) ; pour une vue d'ensemble de SSPI, consultez SSPI (page pouvant être en anglais).

Pour l'authentification Windows, WCF utilise généralement le fournisseur SSP (Security Support Provider) Negotiate, qui exécute l'authentification mutuelle Kerberos entre le client et le service. Si le protocole Kerberos est non disponible, WCF revient par défaut à NTLM (NT LAN Manager). Toutefois, vous pouvez configurer WCF pour utiliser uniquement le protocole Kerberos (et lever une exception si Kerberos n'est pas disponible). Vous pouvez également configurer WCF pour utiliser des formulaires restreints du protocole Kerberos.

Méthodologie de débogage

La méthode de base est la suivante :

1. Déterminez si vous utilisez l'authentification Windows. Si vous utilisez un autre schéma, cette rubrique ne s'applique pas.
2. Si vous êtes certain d'utiliser l'authentification Windows, déterminez si votre configuration WCF utilise Kerberos direct ou Negotiate.
3. Une fois que vous avez déterminé si votre configuration utilise le protocole Kerberos ou NTLM, vous pouvez comprendre les messages d'erreur dans le contexte correct.

Disponibilité du protocole Kerberos et de NTLM

Le fournisseur SSP Kerberos requiert qu'un contrôleur de domaine se comporte comme un centre de distribution de clés (KDC, Key Distribution Center). Le protocole Kerberos est disponible uniquement lorsque le client et le service utilisent des identités de domaine. NTLM est utilisé dans d'autres combinaisons de comptes, tel qu'indiqué dans le tableau suivant.

Les en-têtes du tableau présentent les types de compte possibles utilisés par le serveur. La colonne de gauche présente les types de compte possibles utilisés par le client.

Plus précisément, les quatre types de comptes incluent :

• Utilisateur local : profil utilisateur, ordinateur uniquement. Par exemple : MachineName\Administrator ou MachineName\ProfileName.
• Système local : compte intégré SYSTEM sur un ordinateur qui n'est pas joint à un domaine.
• Utilisateur de domaine : compte d'utilisateur sur un domaine Windows. Par exemple : DomainName\ProfileName.
• Ordinateur de domaine : processus avec identité d'ordinateur s'exécutant sur un ordinateur joint à un domaine Windows. Par exemple : MachineName\Network Service.

Remarque :
Les informations d'identification du service sont capturées lorsque la méthode Open de la classe ServiceHost est appelée. Les informations d'identification du client sont lues chaque fois que le client envoie un message.

Problèmes courants d'authentification Windows

Cette section présente certains problèmes d'authentification Windows courants et les solutions possibles.

Protocole Kerberos

Problèmes de SPN/UPN rencontrés avec le protocole Kerberos

Si vous utilisez l'authentification Windows, et que le protocole Kerberos est utilisé ou négocié par SSPI, l'URL utilisée par le point de terminaison client doit inclure le nom de domaine complet de l'hôte du service dans l'URL de service. Cela suppose que le compte sous lequel le service s'exécute a accès à la clé SPN (Service Principal Name) par défaut de l'ordinateur créée lorsque celui-ci est ajouté au domaine Active Directory, ce qui s'effectue le plus souvent en exécutant le service sous le compte Service Réseau. Si le service n'a pas accès à la clé SPN de l'ordinateur, vous devez fournir le SPN correct ou un nom d'utilisateur principal (UPN, User Principal Name) du compte sous lequel le service s'exécute dans l'identité de point de terminaison du client. Pour plus d'informations sur sur le fonctionnement de WCF avec les noms SPN et UPN, consultez Identité du service et authentification.

Dans les scénarios d'équilibrage de charge, tels que les batteries de serveurs Web ou les jardins Web, une pratique courante consiste à définir un compte unique pour chaque application, assigner un SPN à ce compte et veiller à ce que tous les services de l'application s'exécutent sous ce compte.

Pour obtenir un SPN pour le compte de votre service, vous devez être administrateur de domaine Active Directory. Pour plus d'informations, consultez Complément technique pour Windows.

Le protocole Kerberos direct requiert l'exécution du service sous un compte d'ordinateur de domaine

Cela se produit lorsque la propriété ClientCredentialType a la valeur Windows et que la propriété NegotiateServiceCredential a la valeur false, tel qu'indiqué dans le code suivant.

Pour y remédier, exécutez le service à l'aide d'un compte d'ordinateur de domaine, tel que Service réseau, sur un ordinateur joint au domaine.

La délégation requiert la négociation d'informations d'identification

Pour utiliser le protocole d'authentification Kerberos avec délégation, vous devez implémenter le protocole Kerberos avec la négociation d'informations d'identification (parfois appelé Kerberos « multi-leg » ou Kerberos « multi-step »). Si vous implémentez l'authentification Kerberos sans négociation d'informations d'identification (parfois appelée Kerberos « one-shot » ou Kerberos « single-leg »), une exception sera levée.

Pour implémenter Kerberos avec la négociation d'information d'identification, procédez comme suit :

1. Implémentez la délégation en affectant Delegation à AllowedImpersonationLevel.
2. Requérez la négociation SSPI :
   1. Si vous utilisez des liaisons standard, affectez true à la propriété NegotiateServiceCredential.
   2. Si vous utilisez des liaisons personnalisées, affectez SspiNegotiated à l'attribut AuthenticationMode de l'élément Security.
3. Requérez que la négociation SSPI utilise Kerberos en interdisant l'utilisation de NTLM :
   1. Effectuez cette opération dans le code, à l'aide de l'instruction suivante : ChannelFactory.Credentials.Windows.AllowNtlm = false
   2. Vous pouvez également effectuer cette opération dans le fichier de configuration en affectant false à l'attribut allowNtlm. Cet attribut est contenu dans <windows> of <clientCredentials> element.

Protocole NTLM

Négociation du retour de SSP à NTLM, mais NTLM est désactivé

La propriété AllowNtlm a la valeur false, ce qui conduit Windows Communication Foundation (WCF) à déployer le meilleur effort pour lever une exception si NTLM est utilisé. Notez que l'affectation de la valeur false à cette propriété peut ne pas empêcher la transmission des informations d'identification NTLM.

La section suivante indique comment désactiver le retour à NTLM.

Échec d'ouverture de session NTLM

Les informations d'identification du client ne sont pas valides sur le service. Vérifiez que le nom d'utilisateur et le mot de passe sont correctement définis et correspondent à un compte connu sur l'ordinateur sur lequel le service s'exécute. NTLM utilise les informations d'identification spécifiées pour se connecter à l'ordinateur du service. Même si les informations d'identification sont valides sur l'ordinateur sur lequel le client s'exécute, cette ouverture de session échouera si elles ne sont pas valides sur l'ordinateur du service.

Une ouverture de session NTLM anonyme se produit, mais les ouvertures de session anonymes sont désactivées par défaut

Lors de la création d'un client, la propriété AllowedImpersonationLevel a la valeur Anonymous, tel qu'indiqué dans l'exemple suivant, mais par défaut, le serveur interdit les ouvertures de session anonymes. En effet, la valeur par défaut de la propriété AllowAnonymousLogons de la classe WindowsServiceCredential est false.

Le code client suivant tente d'activer des ouvertures de session anonymes (notez que la propriété par défaut est Identification).

Le code de service suivant modifie la valeur par défaut afin d'activer des ouvertures de session anonymes par le serveur.

Pour plus d'informations sur l'emprunt d'identité, consultez Délégation et emprunt d'identité avec WCF.

Le client s'exécute également en tant que service Windows, à l'aide du compte intégré SYSTEM.

Autres problèmes

Les informations d'identification du client ne sont pas correctement définies

L'authentification Windows utilise l'instance WindowsClientCredential retournée par la propriété ClientCredentials de la classe ClientBase, et non pas UserNamePasswordClientCredential. Le code suivant présente un exemple incorrect.

Le code suivant présente l'exemple correct.

SSPI n'est pas disponible

Les systèmes d'exploitation suivants ne prennent pas en charge l'authentification Windows lorsqu'elle est utilisée en tant que serveur : Windows XP Édition familiale, Windows XP Media Center Edition et Windows Vista Édition familiale.

Développement et déploiement avec des identités différentes

Si vous développez votre application sur un ordinateur, la déployez sur un autre et utilisez différents types de compte pour vous authentifier sur chaque ordinateur, vous pouvez observer un comportement différent. Par exemple, supposons que vous développiez votre application sur un ordinateur Windows XP Professionnel à l'aide du mode d'authentification SSPI Negotiated. Si vous utilisez un compte d'utilisateur local pour vous authentifier, le protocole NTLM sera alors utilisé. Une fois que l'application est développée, vous déployez le service sur un ordinateur Windows Server 2003 où il s'exécute sous un compte de domaine. À ce stade, le client ne sera pas en mesure d'authentifier le service car il utilisera Kerberos et un contrôleur de domaine.

Voir aussi

Référence

WindowsClientCredential
WindowsServiceCredential
WindowsClientCredential
ClientBase

Concepts

Délégation et emprunt d'identité avec WCF
Scénarios non pris en charge