Configuration de l’authentification Kerberos pour les serveurs d’accès au client avec équilibrage de charge

  • Article

 

S’applique à : Exchange Server 2010 SP2, Exchange Server 2010 SP3

Dernière rubrique modifiée : 2016-11-28

Pour pouvoir utiliser l’authentification Kerberos avec un groupe de serveurs d’accès au client à charge équilibrée, vous devez exécuter une procédure de configuration en plusieurs étapes. Pour plus d’informations sur l’utilisation de Kerberos avec un groupe de serveurs d’accès au client ou une solution d’équilibrage de charge, consultez la rubrique Utilisation de Kerberos avec un groupe de serveurs d’accès au client ou une solution d’équilibrage de charge.

Création des informations d’identification d’un compte de service secondaire dans Active Directory

Tous les ordinateurs appartenant au groupe de serveurs d’accès au client doivent partager le même compte de service. En outre, les serveurs d’accès au client qui peuvent être appelés dans un scénario d’activation de centre de données doivent également partager le même compte de service. En règle générale, un seul compte de service par forêt suffit. Ce compte correspond aux informations d’identification du compte de service secondaire (informations d’identification ASA).

RemarqueRemarque :
Si le déploiement est complexe et ne se limite pas aux scénarios présentés ci-dessous, pose des problèmes de délégation d’administrateur ou dispose de plusieurs segments de forêt dans différentes planification de déploiement Exchange, vous devez créer des comptes supplémentaires. Vous devez exécuter le script RollAlternateServiceAccountPasswordl.ps1 séparément pour chaque compte créé.

Type d’information d’identification

Vous pouvez créer un compte d’ordinateur ou un compte d’utilisateur pour le compte de service secondaire. Étant donné qu’un compte d’ordinateur ne permet pas l’ouverture de session interactive, il peut disposer de stratégies de sécurité plus simples que celles d’un compte d’utilisateur et constituer donc une solution préférable pour les informations d’identification ASA. Si vous créez un compte d’ordinateur, le mot de passe n’expire pas. Toutefois, il est recommandé de le mettre régulièrement à jour. La stratégie de groupe locale peut spécifier un âge maximal pour les comptes d’ordinateurs et des scripts peuvent être programmés pour supprimer régulièrement les comptes d’ordinateurs qui ne respectent pas les stratégies en cours. La mise à jour régulière du mot de passe des comptes d’ordinateurs permettra d’éviter la suppression des comptes d’ordinateurs non conformes à la stratégie locale. Votre stratégie de sécurité locale déterminera le moment où le mot de passe devra être changé.

Nom des informations d’identification

Il n’existe aucune exigence particulière pour le nom des informations d’identification ASA. Vous pouvez utiliser n’importe quel nom conforme à votre schéma d’affectation de noms.

Groupes et rôles

Aucun privilège de sécurité spécial n’est nécessaire pour les informations d’identification ASA. Si vous déployez un compte d’ordinateur pour les informations d’identification ASA, cela signifie que le compte doit être uniquement membre du groupe de sécurité Ordinateurs du domaine. Si vous déployez un compte d’utilisateur pour les informations d’identification ASA, cela signifie que le compte doit être uniquement membre du groupe de sécurité Utilisateurs du domaine.

Mot de passe

Le mot de passe que vous fournissez lorsque vous créez le compte ne sera jamais utilisé. C’est le script qui réinitialisera le mot de passe. Par conséquent, lorsque vous créez le compte, vous pouvez utiliser n’importe quel mot de passe conforme aux règles des mots de passe de votre organisation.

Scénarios inter-forêts

Si le déploiement implique plusieurs forêts ou une forêt de ressources et que les utilisateurs se trouvent en dehors de la forêt Active Directory qui contient Exchange, vous devez configurer des approbations inter-forêts et des suffixes de noms de routage entre les forêts. Pour plus d’informations, consultez les rubriques Accès à des ressources sur plusieurs forêts et Routage des suffixes de noms entre les forêts.

Identification des noms principaux de service qui doivent être associés aux informations d’identification d’un compte de service secondaire

Une fois que le compte de service secondaire est créé, vous devez déterminer les noms principaux de service (SPN) Exchange qui seront associés aux informations d’identification ASA. La liste des noms SPN Exchange peut varier en fonction de votre configuration, mais elle doit contenir au minimum les éléments suivants :

  • http Utilisez ce SPN pour les services Web Exchange, les téléchargements de carnets d’adresses en mode hors connexion et le service de découverte automatique.

  • exchangeMDB Utilisez ce SPN pour l’accès au client RPC.

  • exchangeRFR Utilisez ce SPN pour le service Carnet d’adresses.

  • exchangeAB Utilisez ce SPN pour le service Carnet d’adresses.

Les valeurs SPN doivent être configurées de façon à correspondre au nom du service utilisé dans l’équilibrage de charge réseau et non pas sur les serveurs individuels.

Pour planifier les valeurs SPN à déployer, prenez en compte les scénarios conceptuels suivants :

  1. Site Active Directory unique

  2. Sites Active Directory multiples

  3. Sites Active Directory multiples avec résilience du site de groupe de disponibilité de base de données

Dans chacun de ces scénarios, on suppose que les noms de domaine complets avec équilibrage de charge ont été déployés pour les URL internes, les URL externes et les URI internes de découverte automatique utilisés par les membres du serveur d’accès au client. Pour plus d'informations, consultez la rubrique Présentation de la transmission par proxy et de la redirection.

Site Active Directory unique

Si vous disposez d’un seul site Active Directory, votre environnement ressemble peut-être à celui illustré dans le schéma suivant.

Selon les noms de domaine complets utilisés par les clients Outlook internes de l’illustration précédente, les SPN suivants doivent être déployés avec les informations d’identification ASA :

  • http/mail.corp.contoso.com

  • http/autod.corp.contoso.com

  • exchangeMDB/outlook.corp.contoso.com

  • exchangeRFR/outlook.corp.contoso.com

  • exchangeAB/outlook.corp.contoso.com

Les clients externes ou basés sur Internet qui utilisent Outlook Anywhere n’utiliseront pas l’authentification Kerberos. Par conséquent, les noms de domaine complets qui sont utilisés par ces clients n’ont pas à être ajoutés en tant que SPN aux informations d’identification ASA.

ImportantImportant :
Si vous déployez une infrastructure DNS partagée, les clients externes et internes utilisent les mêmes noms de domaine complets et ces noms doivent être représentés en tant que SPN avec les informations d’identification ASA.

Sites Active Directory multiples

Si vous disposez de plusieurs sites Active Directory, votre environnement ressemble peut-être à celui illustré dans le schéma suivant.

Selon les noms de domaine complets utilisés par les clients Outlook internes dans l’illustration précédente, les noms SPN suivants doivent être déployés avec les informations d’identification ASA qui sont utilisées par le groupe de serveurs d’accès au client avec le site Active Directory ADSite1 :

  • http/mail.corp.contoso.com

  • http/autod.corp.contoso.com

  • exchangeMDB/outlook.corp.contoso.com

  • exchangeRFR/outlook.corp.contoso.com

  • exchangeAB/outlook.corp.contoso.com

Selon les noms de domaine complets utilisés par les clients Outlook internes dans l’illustration précédente, les noms SPN suivants doivent être déployés avec les informations d’identification ASA qui sont utilisées par le groupe de serveurs d’accès au client au sein du site Active Directory ADSite2 :

  • http/mailsdc.corp.contoso.com

  • http/autodsdc.corp.contoso.com

  • exchangeMDB/outlooksdc.corp.contoso.com

  • exchangeRFR/outlooksdc.corp.contoso.com

  • exchangeAB/outlooksdc.corp.contoso.com

RemarqueRemarque :
Cet exemple montre que vous pouvez utiliser de multiples informations d’identification ASA pour ce scénario particulier. Toutefois, vous pouvez vous servir d’une information d’identification ASA unique pour tous les sites Active Directory qui hébergent les groupes de serveurs d’accès au client où vous souhaitez déployer l’authentification Kerberos.

Sites Active Directory multiples avec résilience du site de groupe de disponibilité de base de données

Si vous disposez de plusieurs sites Active Directory avec résilience du site de groupe de disponibilité de base de données, votre environnement ressemble peut-être à celui illustré dans le schéma suivant.

Du fait que cette architecture inclut un groupe de disponibilité de base de données étendu entre les deux sites Active Directory, vous devez déployer une information d’identification ASA unique à utiliser par les membres des groupes de serveurs d’accès au client dans ADSite1 et ADSite2. Si vous ne recourez pas à une information d’identification ASA unique, les clients seront confrontés à des problèmes d’authentification Kerberos lorsque vous procédez à un basculement de centre de données car les membres du groupe de serveurs d’accès au client ne pourront pas déchiffrer le ticket de session Kerberos. Pour plus d’informations sur l’activation du centre de données secondaire, voir Switchovers de centre de données.

Selon les noms de domaine complets utilisés par les clients Outlook internes dans l’illustration précédente, les noms SPN suivants doivent être déployés avec les informations d’identification ASA qui sont utilisées pour les groupes de serveurs d’accès au client dans ADSite1 et ADSite2 :

  • http/mail.corp.contoso.com

  • http/autod.corp.contoso.com

  • exchangeMDB/outlook.corp.contoso.com

  • exchangeRFR/outlook.corp.contoso.com

  • exchangeAB/outlook.corp.contoso.com

  • http/mailsdc.corp.contoso.com

  • http/autodsdc.corp.contoso.com

  • exchangeMDB/outlooksdc.corp.contoso.com

  • exchangeRFR/outlooksdc.corp.contoso.com

  • exchangeAB/outlooksdc.corp.contoso.com

Conversion du répertoire virtuel du carnet d’adresses en mode hors connexion en application

Prêt à l’emploi, le répertoire virtuel du carnet d’adresses en mode hors connexion n’est pas une application Web. Il n’est donc pas contrôlé par le service d’hôte de service Microsoft Exchange. Par conséquent, les demandes d’authentification Kerberos envoyées au répertoire virtuel du carnet d’adresses en mode hors connexion ne peuvent pas être déchiffrées par les informations d’identification ASA.

Pour convertir le répertoire virtuel du carnet d’adresses en mode hors connexion en application Web, exécutez le script ConvertOABDir.ps1 sur chaque membre du serveur d’accès au client. Ce script créera également un nouveau pool d’applications pour le répertoire virtuel du carnet d’adresses en mode hors connexion. Le script est situé dans le répertoire Scripts d’Exchange 2010 SP2. Vous pouvez également le télécharger ici.

Déploiement des informations d’identification d’un compte de service secondaire

Une fois que vous avez généré les informations d’identification ASA, vérifiez que le compte a été répliqué sur tous les contrôleurs de domaine au sein des sites Active Directory contenant les serveurs d’accès au client qui utiliseront ces informations.

Vous pouvez alors exécuter le script des informations d’identification AlternateServiceAccount dans l’environnement de ligne de commande Exchange Management Shell. Pour plus d’informations, voir la rubrique Utilisation du script RollAlternateserviceAccountCredential.ps1 dans l’environnement de ligne de commande Exchange Management Shell. Une fois le script exécuté, il est recommandé de vérifier que tous les serveurs cible ont été correctement mis à jour.

RemarqueRemarque :
Le script est uniquement disponible en anglais.

Pour obtenir de l’aide sur la résolution des erreurs de script, consultez la rubrique Dépannage des problèmes liés au script RollAlternateServiceAccountCredential.ps1.

L’exemple de sortie du script RollAlternateServiceAccountPassword.ps1 suivant utilise un compte d’ordinateur créé pour fournir les informations d’identification ASA. Le compte est nommé contoso/newSharedServiceAccountName. Dans l’exemple suivant, le script applique les paramètres d’identification à chaque membre d’un groupe de serveurs d’accès au client appelé outlook.corp.contoso.com.

Pour exécuter le script, utilisez la commande suivante :

RollAlternateServiceAccountPassword.ps1 -ToArrayMembers outlook.corp.contoso.com -GenerateNewPasswordFor contoso\newSharedServiceAccountName$

Vous devez recevoir la sortie suivante après avoir exécuté le script. Une invite demande votre approbation pour changer de mot de passe.

========== Started at 08/02/2010 15:48:09 ==========Destination servers that will be updated:Name----CASACASBCredentials that will be pushed to every server in the specified scope (recent first):UserName                               Password--------                               --------contoso\newSharedServiceAccountName$                System.Security.SecureStringPrior to pushing new credentials, all existing credentials that are invalid or no longer work will be removed from the destination servers.Pushing credentials to server CASAPushing credentials to server CASBSetting a new password on Alternate Service Account in Active DirectoryPassword changeDo you want to change password for contoso\newSharedServiceAccountName$ in Active Directory at this time?[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"): yPreparing to update Active Directory with a new password for contoso\newSharedServiceAccountName$ ...Resetting a password in the Active Directory for contoso\newSharedServiceAccountName$ ...New password was successfully set to Active Directory.Retrieving the current Alternate Service Account configuration from servers in scopeAlternate Service Account properties:StructuralObjectClass QualifiedUserName       Last Pwd Update     --------------------- -----------------       ---------------     computer              contoso\newSharedServiceAccountName$ 8/2/2010 3:49:05 PM SPNs-----Per-server Alternate Service Account configuration as of the time of script completion:   Array: outlook.corp.contoso.comIdentity  AlternateServiceAccountConfiguration--------  ------------------------------------NAE14CAS  Latest: 8/2/2010 3:48:38 PM, contoso\newSharedServiceAccountName$          Previous: <Not set>NAE14CAS2 Latest: 8/2/2010 3:48:51 PM, contoso\newSharedServiceAccountName$          Previous: <Not set>

Deux ID d’événement apparaissent également dans vos journaux d’événements. L’un est associé au lancement du script et l’autre à son exécution réussie. Le texte suivant est un extrait de l’événement d’exécution réussie.

Log Name:      ApplicationSource:        MSExchange Management ApplicationEvent ID:      14002Task Category: KerberosLevel:         InformationDescription:Maintenance of the Alternate Service Accounts succeeded.

Vérification du déploiement des informations d’identification ASA

Dans l’environnement de ligne de commande Exchange Management Shell, exécutez la commande suivante pour vérifier les paramètres sur les serveurs d’accès au client :

Get-ClientAccessServer -IncludeAlternateServiceAccountCredentialStatus | fl name,*alter*

Le résultat de cette commande doit ressembler à ce qui suit.

Name                                 : CASAAlternateServiceAccountConfiguration : Latest: 8/2/2010 3:48:38 PM, contoso\newSharedServiceAccountName$                                       Previous: <Not set>Name                                 : CASBAlternateServiceAccountConfiguration : Latest: 8/2/2010 3:48:51 PM, contoso\newSharedServiceAccountName$                                       Previous: <Not set>

Si vous avez exécuté le script plusieurs fois et apporté des modifications, l’entrée précédente révèle la date de la dernière modification.

Name                                 : NAE14CASAlternateServiceAccountConfiguration : Latest: 8/2/2010 4:32:38 PM, contoso\newSharedServiceAccountName$                                       Previous: 8/2/2010 4:32:24 PM, contoso\sharedkerbacct$Name                                 : NAE14CAS2AlternateServiceAccountConfiguration : Latest: 8/2/2010 4:32:38 PM, contoso\newSharedServiceAccountName$                                       Previous: 8/2/2010 4:32:24 PM, contoso\sharedkerbacct$

Association de noms principaux de service aux informations d’identification d’un compte de service secondaire

Avant de configurer les noms SPN, vérifiez que les noms SPN cible n’existent pas déjà dans un autre compte de la forêt. Les informations d’identification ASA doivent être le seul compte de la forêt auquel ces noms SPN sont associés. Pour vérifier que les noms SPN ne sont associés à aucun autre compte dans la forêt, exécutez la commande setspn avec les paramètres –q et –f à partir de la ligne de commande. L’exemple suivant montre comment exécuter cette commande. La commande ne doit retourner aucune donnée. Si elle renvoie une valeur, c’est qu’un autre compte est déjà associé au nom SPN que vous pensez utiliser.

RemarqueRemarque :
Seul Windows Server 2008 prend en charge le paramètre (-f) de vérification des doublons à l’échelle de la forêt dans la commande setspn. 
Setspn -q -f exchangeMDB/outlook.corp.contoso.com

À titre d’exemple, la commande suivante indique comment définir les SPN avec les informations d’identification ASA. La commande setspn utilisant cette syntaxe doit être exécutée une fois pour chaque nom SPN cible que vous identifiez.

Setspn -S exchangeMDB/outlook.corp.contoso.com contoso\newSharedServiceAccountName$

Après avoir défini les noms SPN, vérifiez qu’ils ont été ajoutés en exécutant la commande suivante.

Setspn -L contoso\newSharedServiceAccountName$

Validation de l’authentification Kerberos des clients Exchange

Après avoir configuré Kerberos et déployé le script RollAlternateServiceAccountPasswordl.ps1, vérifiez que les clients peuvent être correctement authentifiés.

Vérification que le service d’hôte de service de Microsoft Exchange est en cours d’exécution

Le service d’hôte de service de Microsoft Exchange sur les serveurs d’accès au client est responsable de la gestion des informations d’identification ASA. Si ce service ne s’exécute pas, l’authentification Kerberos ne pourra pas être effectuée. Par défaut, le service est configuré pour démarrer automatiquement lorsque l’ordinateur est lancé. Assurez-vous d’avoir installé le Correctif cumulatif 3 d’Exchange Server 2010 SP1 ou une version ultérieure sur tous les serveurs d’accès au client dans votre environnement.

Validation de l’authentification depuis Outlook

Pour vérifier que Outlook peut se connecter aux services d’accès au client avec l’authentification Kerberos, procédez comme suit : 

  1. Vérifiez que Outlook pointe vers le groupe approprié de serveurs d’accès au client à charge équilibrée.

  2. Définissez les paramètres de sécurité du serveur de comptes de messagerie pour utiliser la sécurité de connexion Authentification par négociation. Vous pouvez également configurer le client pour qu’il utilise l’Authentification par mot de passe Kerberos. Toutefois, si les SPN sont supprimés, les clients ne seront pas en mesure de s’authentifier tant que vous n’aurez pas réactivé le mécanisme d’authentification Authentification par négociation.

  3. Vérifiez que Outlook Anywhere n’est pas activé pour le client. Si Outlook ne parvient pas s’authentifier en utilisant Kerberos, il tente de revenir à Outlook Anywhere et Outlook Anywhere doit donc être désactivé pour cette vérification.

  4. Redémarrez Outlook.

  5. Si votre ordinateur de bureau exécute Windows 7, vous pouvez exécuter klist.exe afin de connaître les tickets Kerberos qui ont été accordés et qui sont en cours d’utilisation. Si vous n’exécutez pas Windows 7, vous pouvez utiliser klist.exe à partir du Kit de ressources Windows Server 2003.

Validation à l’aide de la cmdlet Test-OutlookConnectivity

Pour vérifier que Kerberos fonctionne, utilisez la cmdlet Test-OutlookConnectivity. Cette dernière est le meilleur moyen de savoir si la connectivité TCP peut être établie. Par défaut, la cmdlet utilise l’authentification par négociation pour une connexion TCP. Par conséquent, si Kerberos est configuré, il est utilisé. Vous pouvez utiliser le fichier klist.exe pour afficher les tickets Kerberos sur l’ordinateur. Ce dernier peut être exécuté à partir du serveur d’accès au client proprement dit, ainsi qu’à partir d’un outil de contrôle automatisé, tel que SCOM. Lorsque vous utilisez la cmdlet Test-OutlookConnectivity, assurez-vous que la propriété RPCClientAccessServer de la base de données de boîtes aux lettres est définie sur le nom du groupe de serveurs d’accès au client. Sinon, la cmdlet ne testera pas les informations d’identification ASA partagées.

Test-OutlookConnectivity -Identity administrator -MailboxCredential $c -Protocol tcp

Pour vérifier que la connexion est établie en utilisant Kerberos, affichez klist.exe pour déterminer si des tickets Kerberos sont associés aux nouveaux noms SPN ajoutés.

Validation Kerberos depuis le serveur d’accès au client

Pour vérifier que Kerberos fonctionne correctement depuis le serveur d’accès au client, vous pouvez examiner les journaux de protocole pour identifier les connexions Kerberos qui ont abouti. Vous pouvez utiliser ces journaux en plus des autres validations pour vérifier que Kerberos est utilisé.

  • Sur le serveur d’accès au client, examinez les journaux de protocole du carnet d’adresses. Ces journaux se trouvent généralement dans : C:\Program Files\Microsoft\Exchange server\v14\Logging\AddressBook Service.

  • Dans le dernier journal, recherchez le mot Kerberos après avoir exécuté le script. Si vous identifiez un trafic Kerberos, cela implique qu’une connexion a été établie. La ligne dans le fichier journal doit se présenter comme suit.

    2010-06-11T22:58:49.799Z,9,0,/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Administrator,,2001:4898:f0:3031:99f:ce35:750a:8b09,EXCH-A-363,ncacn_ip_tcp,Bind,,6,,,Kerberos,

L’affichage du mot Kerberos signifie que le serveur parvient à créer des connexions authentifiées Kerberos. Pour plus d’informations sur le journal du service de carnet d’adresses, voir la rubrique Présentation du service de carnet d'adresses.

Résolution des problèmes d’authentification

Plusieurs problèmes peuvent se produire lorsque vous configurez l’authentification Kerberos.

Les clients Outlook configurés pour utiliser l’authentification Kerberos uniquement ne peuvent pas se connecter

Si le client Outlook configuré pour utiliser l’authentification Kerberos uniquement ne parvient pas à se connecter, procédez comme suit pour résoudre le problème :

  1. Configurez Outlook pour utiliser l’authentification NTLM uniquement, puis vérifiez la connectivité. Si aucune connexion ne peut être établie, vérifiez que le groupe de serveurs d’accès au client est disponible ou que la connectivité réseau est stable.

    Si la connexion NTLM fonctionne correctement, mais pas Kerberos, vérifiez que les noms SPN ne sont pas enregistrés dans un autre compte que le compte de service secondaire. Vérifiez que les noms SPN Exchange sont enregistrés dans le compte utilisé par le compte de service secondaire partagé en utilisant la commande de requête setSPN, comme indiqué précédemment dans cette section.

  2. Vérifiez que le mot de passe est coordonné entre tous les serveurs d’accès au client et Active Directory. Pour ce faire, exécutez le script en mode sans assistance et demandez-lui de générer un nouveau mot de passe.

  3. Vérifiez que le service de carnet d’adresses Microsoft Exchange est actif sur les serveurs d’accès au client.

  4. Si l’authentification ne fonctionne toujours pas, vérifiez que l’authentification Windows intégrée est activée sur les répertoires virtuels des services auxquels vous voulez accéder avec Kerberos. Vous pouvez utiliser les cmdlets Get-VirtualDirectory pour vérifier les méthodes d’authentification. Pour plus d’informations sur les répertoires virtuels, voir les rubriques Présentation des répertoires virtuels Outlook Web App et Présentation des répertoires virtuels des services Web Exchange.

Échecs du service de découverte automatique

Si le service de découverte automatique génère l’erreur suivante, il est fort probable que l’en-tête de demande du service de découverte automatique contient un ticket d’authentification Kerberos dont la taille est supérieure à la taille maximale définie par le serveur IIS (Internet Information Services). L’erreur se présente comme suit.

HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Tue, 09 Mar 2010 18:06:18 GMT
Connection: close
Content-Length: 346

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""https://www.w3.org/TR/html4/strict.dtd">

<HTML><HEAD><TITLE>Bad Request</TITLE>

<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>

<BODY><h2>Bad Request - Request Too Long</h2>

<hr><p>HTTP Error 400. The size of the request headers is too long.</p>

</BODY></HTML>

Pour éliminer cette erreur, augmentez la limite de taille d’en-tête IIS. Pour plus d’informations, voir la documentation IIS.

Maintenance permanente des informations d’identification ASA

Si le mot de passe local dans les informations d’identification ASA doit être actualisé régulièrement, consultez la rubrique Utilisation du script RollAlternateserviceAccountCredential.ps1 dans l’environnement de ligne de commande Exchange Management Shell qui explique comment définir une tâche planifiée pour effectuer la maintenance régulière du mot de passe. Veillez à contrôler la tâche planifiée pour vérifier le changement en temps opportun du mot de passe et éviter toute erreur d’authentification.

Désactivation de l’authentification Kerberos

Pour rétablir votre groupe de serveurs d’accès au client afin qu’il n’utilise pas Kerberos, supprimez les noms SPN du compte de service partagé. Si les noms SPN sont supprimés, vos clients ne tenteront pas d’effectuer une authentification Kerberos et les clients configurés pour l’authentification Négocier utiliseront l’authentification NTLM. Les clients configurés pour utiliser uniquement Kerberos ne parviendront pas à se connecter. Une fois les noms SPN supprimés, vous devez également supprimer le compte de service partagé. Vous pouvez exécuter le script de maintenance pour effacer toutes les informations d’identification de l’ensemble des membres du groupe de serveurs d’accès au client à l’aide du paramètre toEntireForest et du paramètre de serveur -copy pour spécifier un serveur n’ayant aucune information d’identification Kerberos. En outre, vous devrez finalement redémarrer tous les ordinateurs clients pour effacer le cache du ticket Kerberos.

 © 2010 Microsoft Corporation. Tous droits réservés.