Authentification Kerberos pour la connexion du client MAPI à un tableau de serveurs d’accès au client

Résumé

Pour les déploiements Microsoft Exchange Server 2010 qui ont plusieurs serveurs d’accès au client dans un site Active Directory, la topologie nécessite souvent un tableau de serveurs d’accès au client et une solution d’équilibrage de charge pour répartir le trafic entre tous les serveurs d’accès au client du site. En raison des modifications apportées à Exchange Server 2010, les clients de messagerie MAPI ne peuvent pas utiliser l’authentification Kerberos pour se connecter à une boîte aux lettres lorsqu’un tableau de serveurs d’accès au client est utilisé. Pour contourner ce comportement, Microsoft Exchange Server Service Pack 1 (SP1) inclut de nouvelles fonctionnalités qui vous permettent de configurer l’authentification Kerberos pour les clients de messagerie MAPI dans un tableau de serveurs d’accès au client.

Pour plus d’informations sur le fonctionnement de l’authentification Kerberos dans les versions antérieures de Exchange Server et sur les modifications apportées à Exchange Server 2010 qui empêchent l’authentification Kerberos de fonctionner avec les clients de messagerie MAPI, consultez le billet de blog suivant sur le blog de l’équipe Exchange :

Recommandation : Activation de l’authentification Kerberos pour les clients MAPI

Informations supplémentaires

Le service Hôte de service Microsoft Exchange qui s’exécute sur le rôle serveur d’accès au client (CAS) est étendu dans Exchange Server 2010 SP1 pour utiliser les informations d’identification d’un compte de service secondaire partagé (ASA) pour l’authentification Kerberos. Cette extension d’hôte de service surveille l’ordinateur local. Lorsque des informations d’identification sont ajoutées ou supprimées, le module d’authentification Kerberos sur le système local et dans le contexte du service réseau est mis à jour. Lorsque des informations d’identification sont ajoutées au module d’authentification, tous les services d’accès au client peuvent les utiliser pour l’authentification Kerberos. Le serveur d’accès au client peut également authentifier les demandes de service traitées directement en plus de pouvoir utiliser les informations d’identification ASA. Cette extension, appelée servicelet, s’exécute par défaut et ne nécessite aucune configuration ni aucune action pour s’exécuter.

Vous devrez peut-être utiliser l’authentification Kerberos pour votre Exchange Server 2010 organization pour les raisons suivantes :

• L’authentification Kerberos est requise pour votre stratégie de sécurité locale.

• Vous rencontrez ou attendez des problèmes de scalabilité NTLM, tels que la connectivité MAPI directe au service d’accès au client RPC, provoquant des échecs NTLM intermittents.

  Dans les déploiements clients à grande échelle, NTLM peut entraîner des goulots d’étranglement sur les serveurs d’accès au client. Cela peut entraîner des échecs d’authentification intermittents. Les services qui utilisent l’authentification NTLM sont plus sensibles aux problèmes de latence Active Directory. Celles-ci entraînent des échecs d’authentification lorsque le taux de demandes serveur d’accès au client augmente.

Pour configurer l’authentification Kerberos, vous devez être familiarisé avec Active Directory et comment configurer des tableaux de serveurs d’accès au client. Vous devez également avoir une connaissance pratique de l’authentification Kerberos.

Pour déployer les informations d’identification ASA pour l’authentification Kerberos, procédez comme suit.

Créer un compte à utiliser comme informations d’identification ASA

Tous les ordinateurs du groupe de serveurs d’accès au client doivent partager le même compte de service. Cela inclut tous les serveurs d’accès au client qui peuvent démarrer dans le cadre d’un basculement de centre de données. En règle générale, un compte de service par forêt suffit.

Créez un compte d’ordinateur au lieu d’un compte d’utilisateur pour le compte de service secondaire (ASA), car un compte d’ordinateur n’autorise pas l’ouverture de session interactive. Par conséquent, un compte d’ordinateur peut avoir des stratégies de sécurité plus simples qu’un compte d’utilisateur et est la solution préférée pour les informations d’identification ASA.

Pour plus d’informations sur la création d’un compte d’ordinateur, consultez Créer un compte d’ordinateur.

Il n’existe aucune exigence particulière pour le nom des informations d’identification ASA. Vous pouvez utiliser n’importe quel nom qui suit votre schéma de nommage. Les informations d’identification ASA n’ont pas besoin de privilèges de sécurité spéciaux. Si vous déployez un compte d’ordinateur pour les informations d’identification ASA, cela signifie que le compte doit uniquement être membre du groupe de sécurité Ordinateurs de domaine. Si vous déployez un compte d’utilisateur pour les informations d’identification ASA, cela signifie que le compte doit uniquement être membre du groupe de sécurité Utilisateurs du domaine.

Déterminer les spN à associer aux informations d’identification du compte de service secondaire

Après avoir créé le compte de service secondaire, vous devez déterminer les noms de principal du service Exchange (SPN) qui seront associés aux informations d’identification ASA. Les valeurs du SPN doivent être configurées pour correspondre au nom du service utilisé sur l’équilibreur de charge réseau plutôt que sur des serveurs individuels. La liste des SPN Exchange peut varier en fonction de votre configuration, mais la liste doit inclure au moins les éléments suivants :

• http Utilisez ce SPN pour les services Web Exchange, les téléchargements de carnet 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.

Pour une petite entreprise, vous n’aurez probablement rien de plus grand qu’un seul site Active Directory. Par exemple, votre site Active Directory unique peut ressembler au diagramme suivant.

Pour déterminer les SPN que vous utiliseriez dans cet exemple, nous devons examiner les noms de domaine complets (FQDN) utilisés par les clients Outlook internes dans l’illustration précédente. Dans cet exemple, vous déployez les spN suivants sur 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

Si votre site est plus grand qu’un seul site Active Directory, vous pouvez voir d’autres exemples dans la rubrique Configuration de l’authentification Kerberos pour Load-Balanced serveurs d’accès au client .

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

Le répertoire virtuel du carnet d’adresses en mode hors connexion n’est pas une application web. Par conséquent, il n’est pas contrôlé par le service Hôte de service Microsoft Exchange. Par conséquent, les informations d’identification ASA ne peuvent pas déchiffrer les demandes d’authentification Kerberos dans le répertoire virtuel du carnet d’adresses en mode hors connexion.

Pour convertir le répertoire virtuel du carnet d’adresses en mode hors connexion en application web IIS, exécutez le script ConvertOABVDir.ps1 sur chaque membre du site d’administration centrale. Le script crée également un pool d’applications nommé MSExchangeOabAppPool pour le répertoire virtuel OAB. Pour télécharger le script, accédez à la page ConvertOABDir.ps1 du Centre de scripts Microsoft.

Déployer les informations d’identification ASA sur les membres du site d’administration centrale

Exchange Server 2010 SP1 inclut un script pour activer le déploiement des informations d’identification ASA. Le script est nommé RollAlternateServiceAccountPassword.ps1 et se trouve dans le répertoire Scripts.

Pour utiliser le script afin d’envoyer les informations d’identification à tous les serveurs d’accès au client de la forêt pour la première installation, procédez comme suit :

1. Exécutez la commande suivante dans l'Environnement de ligne de commande Exchange Management Shell :

   .\RollAlternateserviceAccountPassword.ps1 -ToEntireForest -GenerateNewPasswordFor "Your_Domain_Name\Computer_Account_Name$" -Verbose
   

2. Exécutez la commande suivante pour planifier une tâche planifiée de substitution de mot de passe automatisée une fois par mois appelée « Exchange-RollAsa ». Cette tâche planifiée par commande met à jour les informations d’identification ASA pour tous les serveurs d’accès au client dans la forêt avec un nouveau mot de passe généré par script. La tâche planifiée est créée, mais le script n'est pas exécuté. Lors de l'exécution de la tâche planifiée, le script s'exécute en mode sans assistance.

   .\RollAlternateServiceAccountPassword.ps1 -CreateScheduledTask "Exchange-RollAsa" -ToEntireForest -GenerateNewPasswordFor "Your_Domain_Name\Computer_Account_Name$"
   

Pour plus d’informations sur l’utilisation du script RollAlternateserviceAccountPassword.ps1, consultez Utilisation du script RollAlternateserviceAccountPassword.ps1 dans l’interpréteur de commandes .

Vérifier le déploiement des informations d'identification ASA

Dans Exchange Management Shell, exécutez la commande suivante pour case activée les paramètres sur les serveurs d’accès au client :Get-ClientAccessServer -IncludeAlternateServiceAccountCredentialStatus | fl name,*alter*

Le résultat de cette commande ressemble à ceci :

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>

Associer des SPN aux informations d’identification ASA

Avant de configurer les SPN, assurez-vous que les SPN cibles ne sont pas déjà configurés sur un autre compte dans la forêt. Les informations d’identification ASA doivent être le seul compte de la forêt à laquelle ces noms de service sont associés. Vous pouvez vérifier qu’aucun autre compte de la forêt n’est associé aux SPN en ouvrant une invite de commandes et en exécutant la commande setspn avec les paramètres –q et –f . L’exemple suivant montre comment exécuter cette commande. La commande ne doit retourner aucune donnée. S’il retourne une valeur, un autre compte est déjà associé au SPN que vous souhaitez utiliser.

Setspn -q -f exchangeMDB/outlook.**domain.domain.domain_root**

Dans cette commande, exchangeMDB/outlook.domain.domain.domain_root est le SPN du spn pour l’accès au client RPC, par exemple exchangeMDB/outlook.corp.contoso.com.

La commande suivante montre comment définir les spN sur les informations d’identification ASA partagées. Vous devez exécuter la commande setspn avec cette syntaxe une fois pour chaque SPN cible que vous identifiez.

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

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

Setspn -L contoso\newSharedServiceAccountName

Une fois que vous avez correctement configuré Kerberos et déployé le script RollAlternateServiceAccountPasswordl.ps1, vérifiez que les ordinateurs clients peuvent s’authentifier correctement.

Vérifiez que le service Hôte de services Microsoft Exchange est en cours d'exécution

Vérifiez que vous avez installé Exchange Server correctif cumulatif 2010 SP1 3 ou une version ultérieure sur tous les serveurs d’accès au client de votre environnement. Le service Hôte de service Microsoft Exchange sur les serveurs d’accès au client est responsable de la gestion des informations d’identification ASA. Si ce service n’est pas en cours d’exécution, l’authentification Kerberos ne fonctionnera pas. Par défaut, le service est configuré pour démarrer automatiquement au démarrage de l’ordinateur. Pour vérifier que le service est en cours d’exécution, procédez comme suit :

1. Ouvrez Services sur le site d’administration centrale. Pour ouvrir les Services, cliquez sur Démarrer, puis sur Panneau de configuration, double-cliquez sur Outils d'administration, puis sur Services.
2. Dans la liste des services, recherchez service hôte de service Microsoft Exchange.
3. Dans la colonne État, vérifiez que le status est Démarré. Si le service n’est pas démarré, cliquez avec le bouton droit sur Service Hôte de service Microsoft Exchange, puis cliquez sur Démarrer. Pour configurer le service pour qu’il démarre automatiquement, cliquez avec le bouton droit sur Service Hôte de service Microsoft Exchange, cliquez sur Propriétés, cliquez sur Automatiquedans la liste Type de démarrage , puis cliquez sur OK.
   Valider l’authentification à partir d’Outlook

Pour vérifier qu’Outlook peut utiliser l’authentification Kerberos pour se connecter aux serveurs d’accès au client, procédez comme suit :

1. Vérifiez qu’Outlook est configuré pour pointer vers le tableau de serveurs d’accès au client à charge équilibrée.
2. Configurez les paramètres de sécurité du serveur du compte de messagerie pour utiliser la sécurité réseau de connexion Négocier l’authentification. RemarqueVous pouvez configurer le client pour qu’il utilise l’authentification par mot de passe Kerberos, mais si les SPN sont supprimés, les ordinateurs clients ne pourront pas s’authentifier tant que vous n’aurez pas modifié le mécanisme d’authentification pour négocier l’authentification.
3. Assurez-vous qu’Outlook Anywhere n’est pas activé pour l’ordinateur client. Si Outlook ne peut pas s’authentifier à l’aide de l’authentification par mot de passe Kerberos, il tente de revenir à Outlook Anywhere. Outlook Anywhere doit donc être désactivé pour ce test.
4. Redémarrez Outlook.
5. Si votre ordinateur de bureau exécute Windows 7, vous pouvez exécuter klist.exe pour voir quels tickets Kerberos sont accordés et utilisés. Si vous n’exécutez pas Windows 7, vous pouvez obtenir klist.exe à partir du Kit de ressources Windows Server 2003.

Ressources supplémentaires

Pour plus d’informations sur ce problème et son fonctionnement, consultez l’article TechNet suivant :

Utilisation de Kerberos avec un groupe de serveurs d’accès au client ou une solution d’équilibrage de charge

Pour plus d’informations sur l’utilisation de l’authentification Kerberos sur des serveurs d’accès client à charge équilibrée, consultez l’article TechNet suivant :

Configuration de l’authentification Kerberos pour Load-Balanced serveurs d’accès au client