[INFO]: Où l'on reparle d'Exchange 2010 SP1 et du Kerberos...

Il y a quelques mois, le 15 juillet 2010 précisément (pfuiiiii que le temps passe vite!), j'avais publié un tutoriel sur ~ Comment activer le protocole Kerberos avec Exchange 2010 SP1 ~

Depuis, la DevTeam Exchange a officialisé la recommendation d'activer Kerberos dans le SP1 et la documentation Technet mise à jour en ce sens.

Mais avant de vous précipiter sur vos claviers et souris pour créer le compte utilisateur ou d'ordinateur requis pour la configuration du AlternateServiceAccount (ASA) sur vos serveurs d'accès client, sachez qu'il existe encore quelques ratés, même dans Exchange Server 2010 SP1... 

Prérequis 

Cher lecteur, l'hypothèse est prise que vous êtes familiers avec la mise en œuvre du Kerberos pour Exchange Server 2010 SP1, avec la définition d'un Client Access Array et avec les commandes Set-xxxVirtualDirectory, qui permettent de définir la propriété InternalURL des services Web. 

Le problème 

Le fait est que pour que l'authentification Kerberos fonctionne, les services Exchange s'exécutent dans le contexte particulier du service MSExchangeServiceHost. C'est ce service qui utilise le fameux AlternateServiceAccount configuré à l'aide de la commande Set-ClientAccessServer et qui permet par conséquent d'utiliser un ou plusieurs noms génériques et/ou associés à une ou plusieurs adresses IP (répartiteur de charge).

Dès lors, lorsque la configuration est effectuée et que les servicePincipalNames sont définis, les accès aux services suivants sont "négociables" en Kerberos:

• Accès via le protocole MAPI sur Rpc (RpcClientAccess) via le Fqdn du Client Access Array
• Accès aux service de carnet d'adresses (AddressBook) via le Fqdn du Client Access Array
• Accès aux services Web (via IIS) via le (ou les) Fqdn des services Web tels que définis dans les propriétés InternalURL des différents WebServices.

Comme je le disais précédemment, tous ces services s'exécutent dans le contexte du MSExchangeServiceHost, tous sauf un. 

Le gagnant est... 

Le service d'Offline Address Book (OAB), qui est part définition un simple répertoire virtuel dans IIS. En effet, lorsque l'on configure l'OAB derrière un répartiteur de charge, un client Outlook 2007 ou 2010 va se connecter à l'URL http(s)://fqdn.domaine.local/OAB/GUID/oab.xml. Or ce fichier n'est accessible qu'aux utilisateurs authentifiés, et dès lors, une négociation est effectuée lors de l'accès à l'URL.

Et alors... ? Le fait est que pour que l'authentification intégrée fonctionne, l'URL http(s)://fqdn.domaine.local est ajoutée dans la zone "Intranet" d'Internet Explorer. Dès lors, l'authentification Kerberos est tentée entre le client et le serveur. Étant donné que le répertoire /OAB est juste un répertoire virtuel comme un autre, c'est le serveur, via le service IIS, qui négocie et valide la requête de service HTTP lors d'un téléchargement de l'OAB... et bien sûr celle-ci échoue puisque le Fqdn présent dans l'InternalURL dans la configuration de l'OAB Virtual Directory (fourni aux clients par l'Autodiscover) n'est pas utilisable. 

Résultat: des popups d'authentification apparaissent sur les postes clients ! Sachez qu’apparemment, cela dépend de la version du système d’exploitation et d'Outlook. Typiquement, des clients WinXP/Outlook 2007 "se plaignent moins" et échouent plus silencieusement (ou réussissent parfois à utiliser les Dossiers Publics, lorsque disponibles), tandis que des clients Win7/Outlook 2010 génèrent des popups systématiquement lors du téléchargement de l'OAB (reproductible). 

La solution 

Il en existe plusieurs:

1. Configurer les OAB Virtual Directories (via Set-OabVirtualDirectory) afin de ne pas utiliser le Fqdn du répartiteur de charge. Loin d'être idéal et souhaité, mais fonctionne. Si HTTPS est utilisé pour l'OAB, complexifie un peu la gestion des certificats.
2. Ne plus utiliser Kerberos (pas vraiment une solution :/ mais si la configuration Kerberos vous semble insurmontable, ne "tentez" pas!)
3. Solution officieuse (pour l'instant), voir ci-dessous :)

La solution "officieuse" est de convertir le répertoire /OAB en Application Web. Il est recommandé de créer un nouvel Application Pool similaire à celui utilisé pour les Exchange Web Services par exemple.

Une communication officielle sera faite par Ross Smith IV bientôt, et la documentation Technet mise à jour en ce sens. Le tout sera accompagné d'un petit script.

[EDIT]: Ceci a été officialisé dans la nuit par Ross, sur le blog de la DevTeam.