TUTORIEL: Exchange 2010 SP1 (Beta) - Activer Keberos pour un pool de serveurs CAS (Client Access Array)

Si vous avez implémenté Exchange Server 2010 en production avec un pool de serveurs d'Accès Client (CAS) mis en haute-disponibilité derrière un mécanisme de répartition de charge (HLB ou NLB), vous avez peut-être remarqué que l'accès à votre pool de CAS au travers du MAPI/RPC ou aux Web Services ne s'effectuait pas en Kerberos (pour observer cela, il suffit d'utiliser KerbTray, petit outil disponible dans le Resource Kit Windows Server 2003).

En effet, lorsque vous mettez des serveurs CAS en tolérance, vous créez un Client Access Arrary (CASArray). Ce CASArray devient le point de connexion de vos clients, et un nom d'hôte complet (FQDN) associé. Lorsque Outlook démarre, il ne se connecte donc pas sur le FQDN d'un CAS mais du CASArray (par exemple: CASArray.domaine.local), ce qui a pour effet de tenter de récupérer un jeton Kerberos pour les services suivants:

• exchangeMDB/CASArray.domaine.local
• exchangeRFR/CASArray.domaine.local
• exchangeAB/CASArray.domaine.local

La négociation Kerberos ne fonctionne donc pas et Outlook se rabat donc sur le protocole NTLM, ce qui n'a pas d'effet négatif dans la grande majorité des cas, mais peut causer des ralentissements d'authentification en environnement multi-domaines, en particulier dans de grandes arborescences AD. Cela permet aussi une authentification plus efficace dans le cadre d'une relation bidirectionnelle de forêts s'exécutant en mode fonctionnel 2003 natif ou ultérieur (cas typique d'une Forêt de Ressources).

En mode 'Mono-Forêt/Multi-Domaines', une technique pour palier à l'inefficacité du NTLM est de créer des 'Shortcust Trusts' entre le(s) domaine(s) où se situent les serveurs Exchange et celui(ceux) où se situent les utilisateurs.

Mais le mieux et le plus performant (et le plus sexy) reste l'activation du Kerberos sur le Client Access Array :)~

ÉTAPE 1: Créer un compte d'abstraction Kerberos

Méthode 1:

Il suffit de créer un compte utilisateur activé et n'ayant aucun privilège. Cependant il est plus que conseillé de définir un mot de passe très complexe (ex: de 15 caractères ou +), voire même de restreindre l'ouverture de session sur les serveurs CAS seulement (non testé). Le plus simple à gérer est de définir ce mot de passe comme n'expirant jamais.

Pour l'exemple, ce compte s'appelle 'svcCASArray' dans mon lab, ce qui donne comme nom complet 'CORP\svcCASArrary' ('CORP' étant le nom Netbios de mon domaine).

Méthode 2:

L'alternative est d'utiliser un compte d'ordinateur créé à la main dans Active Directory. Il s'agit en fait de la méthode recommandée mais requiert un peu plus de travail pour sa mise en oeuvre et sa maintenance.

Par exemple, votre CAS Array a normalement un non défini, vous pouvez utilisez celui-ci, ou simplement la première partie de son FQDN ou son nom d'objet (pour l'exemple, le mien s'appelle 'MAPI-MAIN'). Le principe est similaire au principe d'avoir un compte d'ordinateur créé pour un serveur virtuel d'un cluster (tel que votre DAG par exemple).

Cela donnerait dans mon lab:

• Création d'un objet 'Computer' dans l'Active Directory (ex: création de l'ordinateur 'MAPI-MAIN')
• Définition d'un mot de passe pour l'objet 'CORP\MAPI-MAIN$'
• Changement périodique du mot de passe pour l'objet 'CORP\MAPI-MAIN$'

Pour la configuration, le compte a utiliser ne sera donc plus 'CORP\svcCASArrary' mais 'CORP\MAPI-MAIN$'. Le hic dans ce mode est qu'il est préférable de changer régulièrement le mot de passe du compte d'ordinateur. A chaque changement, il faudra mettre à jour les 'credentials' mémorisés sur chaque CAS. Cela requiert 'us peu de scripting...' :)


Le gros avantage cependant est la sécurité. En effet, même si le mot de passe du compte d'ordinateur est 'piraté', il ne sera pas possible d'ouvrir une session interactive, et serait dans l'absolu moins facile à exploiter.

ÉTAPE 2: Attribuer les Service Principal Names (SPN) au compte de service pour le MAPI/RPC

Il s'agit ici d'associer au compte de service (ou compte d'ordinateur) les identifiants de service du CASArray.
Cela s'effectue sans peine avec la commande SetSPN.exe (disponible dans l'OS depuis Windows Server 2008):

• setspn.exe -F -S "exchangeMDB/CASArray.domaine.local" "CORP\svcCASArray" (ou "CORP\MAPI-MAIN$")
• setspn.exe -F -S "exchangeRFR/CASArray.domaine.local" "CORP\svcCASArray" (ou "CORP\MAPI-MAIN$")
• setspn.exe -F -S "exchangeAB/CASArray.domaine.local" "CORP\svcCASArray" (ou "CORP\MAPI-MAIN$")

Bien sûr, il faut remplacer 'CASArray.domaine.local' par le FQDN de votre Client Access Array.

Notes:

• SetSPN.exe -S permet d'ajouter un Service Principal Name (SPN) en vérifiant préalablement les doublons (avec le switch -F cherche les doubloins dans toute la forêt). Important car si un doublon existe, Kerberos échouera purement et simplement.
• SetSPN.exe -C permet de vérfier si le SPN est déjà défini sur un objet 'User' ou 'Computer'. Avec l'option -F cela permet de rechercher dans toute la forêt et avec -P dans un ou plusieurs domaines (le switch -P peut être specifié plusieurs fois).

ÉTAPE 3: Attribuer les Service Principal Names (SPN) au compte de service pour les WebServices

L'idée est la même que ci-dessus, cependant ces SPNs seront de la forme "HTTP/WebService.domaine.local", où 'WebService' pourra être le même, ou différent pour chaque service Web. Dans un premier temps, ajoutez les noms d'hôte correspondant aux "Internal URL" de vos répertoires virtuels Exchange (Get-XXXXXVirtualDirectory). Il est inutile de tenter d'ajouter deux fois le même FQDN, donc si comme dans ma config vous n'avez qu'un FQDN pour tous les services Web, cela donnera quelque chose comme:

• setspn.exe -F -S "HTTP/WebService.domaine.local" "CORP\svcCASArray" (ou "CORP\MAPI-MAIN$")

Note: il est tout à fait possible d'utiliser le même FQDN pour le MAPI/RPC et les Services Web.

ÉTAPE 4: Configurer le compte de service

Toute l'astuce est là. Il suffit de récupérer un objet de type 'PSCredential' en PowerShell et de l'assigner aux serveurs CAS participant au pool. Les commandes suivantes doivent être exécutées sur chaque serveur CAS, localement (NDLR: je n'ai pas essayé en PS Remoting, j'ai fait 'autrement' pour l'automatisation :)).

$cred = Get-Credential "CORP\svcCASArray" ==> vous serez invité à entrer le mot de passe du compte de service

Puis ensuite pour l'assigner:
Set-ClientAccessServer -Identity ServeurCAS -AlternateServiceAccountCredential $cred

Patientez une trentaines de secondes, puis vérifiez que la configuration ait été prise en compte avec:
Get-ClientAccessServer -Identity ServeurCAS -IncludeAlternateServiceAccountCredentialStatus et d'observer la propriété 'AlternateServiceAccountConfiguration'.

Petite astuce: Vous pouvez aussi utiliser le switch -IncludeAlternateServiceAccountCredentialPassword afin de récupérer aussi l'objet PSCredentials du compte d'abstraction. Ensuite, avec un peu d'astuce, il est possible de 'copier' ce compte avec son mot de passe sur d'autres serveurs CAS.

Enfin, effectuez un IISReset afin d'être sûr que les Web Applications soient complètement recyclées. Enfin, redémarrez les services suivants à l'aide de la cmdlet Restart-Service:

• MSExchangeAB
• MSExchangeRPC

ÉTAPE 5: Tester l'authentification Kerberos

Depuis un poste 'de base' avec KerbTray, purgez le tickets en cache. Puis lancez Outlook. Après le lancement d'Outlook, la première visualisation avec KerbTray donne les tickets exchangeMDB, exchangeRFR et exchangeAB récupérés et en cache.

Attendez quelques minutes ou effectuez toute opération faisant appel aux Web Services (tel qu'un Ctrl+Click droit sur l'icône Outlook dans le SysTray ==> Test E-mail Autoconfiguration). Le second visualisation montre qu'un ticket a été ajouté pour le(s) service(s) HTTP/WebService.domaine.local.

Vous pouvez aussi utiliser depuis un serveur Exchange (ou autre ordinateur ayant les outils d'administration installé) en Exchange Management Shell la commande Test-OutlookConnectivity:

$cred = Get-Credential 'DOMAIN\username'
Test-OutlookConnectivity -Identity MailboxIdentity -MailboxCredential $cred

Puis de vérifier avec KerbTray ou KList que le ticket existe.

Si cela ne fonctionne pas, vérifiez les points suivants:

• Réplication AD (les SPNs sur le compte de service doivent avoir été répliqués)
• Attribut 'servicePrincipalName' sur le compte d'abstraction Kerberos (ex: CORP\svcCASArrary)
• Vérifiez qu'il n'existe aucun doublon de SPN dans l'AD (utilisez SetSPN.exe -F -Q Service/FQDN)
• Assurez vous aussi que - pour les Web Services - le(s) FQDN(s) soient présents dans la zone "Local Intranet" dans les paramètres de configuration de sécurité dans Internet Explorer

CONFIGURATION 'DE MASSE'

L'activation du Kerberos peut-être fastidieuse, je vous laisse réfléchir au(x) moyen(s) d'effectuer en masse la configuration des serveurs CAS d'un même pool. Pour ma part, c'est déjà fait - j'ai utilisé une technique permettant de mettre en cache les credentials du compte de service afin de le rendre disponible sur tous mes serveurs d'un même CAS Arrary. La seule exception est lors de la 1ere configuration où je suis bien évidemment obligé de spécifier le mot de passe.

Au passage, si cela ne fonctionne pas et que vous voulez revenir en NTLM, utiliser la commande Set-ClientAccessServer -Identity ServeurCAS -RemoveAlternateServiceAccountCredentials puis supprimez le compte de service, ou moins drastiquement les SPNs qui y étaient associés (via SetSPN.exe ou en 'nettoyant' l'attribut servicePrincipalName du compte utilisateur).

POUR FINIR

Cette procédure n'est pas officiellement documentée par Microsoft et la rumeur dit que l'activation du Kerberos avec Exchange Server 2010 RTM ne serait pas supportée, mais le sera pleinement (ainsi que documentée) avec le SP1. Après vérification, la possibilité de configurer le compte d'abstraction a été implémentée dans l'Update Rollup 2 d'Exchange Server 2010 RTM mais ne sera pleinement supportée seulement dans le SP1. Elle ne sera d'ailleurs pleinement documentée (dans le principe et son implémentation) qu'au moment du SP1.

En parlant du SP1 justement, il apportera aussi de nouvelles possibilité avec l'authentification Kerberos puisqu'il supportera la configuration des mécanismes d'Extended Protection documentés ici: http://www.microsoft.com/technet/security/advisory/973811.mspx et là http://www.iis.net/ConfigReference/system.webServer/security/authentication/windowsAuthentication mais aussi ici:
http://support.microsoft.com/kb/973917

Ce mode permet entre autres de traverser des Proxy plus facilement, et globalement de durcir la securité lors de l'accès aux services en se protégeant un maximum des attaques du type "man in the middle" (ex: spoofing DNS, usurpation d'identité).

Note: l'Extended Protection est native dans Windows Server 2008 R2/Windows 7 mais requiert l'installation d'un correctif pour Windows Server 2008/Windows Vista. A l'heure actuelle, l'installation d'Exchange Server 2010 SP1 ne vérifie pas la présence de ce correctif puisqu'il n'est utile que pour activer ce mode (non obligatoire).