Translate

mardi 20 novembre 2012

[INFO]: Activer Kerberos pour Outlook Anywhere (clients internes)

Les avantages d'activer Kerberos avec Exchange 2010 ne fait plus de doute pour personne. C'est pleinement supporté depuis Exchange Server 2010 SP1 et fait partie du béa-ba d'une implémentation propre et pouvant monter en charge.

Qu'en est-il d'Outlook Anywhere ou plus précisément du Rpc/HTTP.

Pourquoi faire la distinction? Je m'explique...

Lorsque l'on parle d'Outlook Anywhere, cela représente la fonctionnalité (se connecter sans VPN avec un client lourd, et hors des frontières de l'Entreprise, autrement dit, généralement depuis une connexion Internet lambda et via un Reverse Proxy). La fonctionnalité Outlook Anywhere inclut de facto un ensemble d'aspect techniques: les Web Services (Autodiscover, OAB, EWS) et le fameux Rpc/HTTP.
En mode stricto-sensu Outlook Anywhere, nous n'avons pas accès à l'Active Directory et donc à un "Key Distribution Center" (KDC). La négociation Kerberos ne peut donc se faire. Dès lors, les modes d'authentification possible deviennent "Basic" et "Ntlm". Soit... ça c'était "avant"... :)
Lorsque l'on est en interne, il arrive que l'on veuille forcer l'utilisation du Rpc/HTTP afin de rester dans un mode "Web" et donc passer outre les équipements de sécurité plus facilement. Il arrive aussi que cela soit à des fins de sécurité (un RSSI a plus confiance en SSL qu'en un cryptage MAPI par exemple...). Dès lors, il était donc possible (et recommandé) d'activer le "Ntlm" afin de conserver du Single-Sign On (SSO).

Mais le Kerberos n'était pas disponible... Jusqu'à semble-t-il récemment.

Sachant qu'Exchange 2013 fait seulement du Rpc/HTTP, cela permet de donner un avant goût d'un mode Rpc/HTTP full Kerberos avec Exchange 2010 !
Le principe est simple: il s'agit de permettre à Exchange de répondre au nom de service Outlook Anywhere (un nom généralement externe) et d'activer l'authentification par négociation sur les CAS (ce qui est le cas pour tous les Web Services, mais ne l'est pas par défaut pour le Rpc/HTTP).
  • Pour le premier point, il s'agit d'ajouter le Fqdn d'Outlook Anywhere au compte de service Kerberos d'Exchange (le fameux "AlternateServiceAccount") - cela se fait en utilisant SETSPN (par exemple: setspn -A HTTP/outlookanywhere.domain.com DOMAIN\AlternateServiceAccount)
  • Pour le second point, il faut configurer Outlook Anywhere sur chaque CAS afin d'utiliser le mode "NegoEx" (par exemple:  Get-OutlookAnywhere -Server MonServeurCAS1 -ADPropertiesOnly | Set-OutlookAnywhere -ClientAuthenticationMethod NegoEx -IISAuthenticationMethods Ntlm)
    • Note: la valeur "Ntlm" positionnée pour les méthodes d'authentification IIS configurera en fait le répertoire virtuel "/Rpc" en activant l'authentification intégrée Windows avec les fournisseurs suivants: "Negotiate" et "NTLM" (dans cet ordre).
  • Vous devrez ensuite créer un nouveau pool d'application dans IIS (Application Pool). Nous pouvons le nommer par exemple "MSExchangeRpcProxyAppPool" (même nom qu'Exchange 2013 :)) et utiliser les paramètres suivants:
    • IdentityType: LocalSystem
    • QueueLength: 1000 pour une infrastructure de taille moyenne, 10000 pour une infrastructure devant supporter une majorité de clients en Rpc/Http
    • ProcessModel / LoadUserProfile: False
    • ProcessModel / IdleTimeout: 0
    • Recycling / PeriodicRestart / Time: 0 (jamais)
    • Failure / RapidFailProtection: False
  • Vous devrez ensuite assigner l'Application Pool au répertoire virtuel "/Rpc" (et idéalement, au répertoire virtuel "/RcpWithCert", que nous n'utiliserons pas ici).
Une fois ces modifications effectuées, il est recommandé d'attendre quelques minutes afin que les changement soient effectivement pris en compte.
Il reste un point essentiel, voire deux:
  • Créer un "Split DNS" afin de résoudre le Fqdn d'Outlook Anywhere via un DNS interne. Cela peut se faire facilement si vous avez déjà un split DNS. Sinon, il suffit de créer une zone DNS nommé "outlookanywhere.domain.com" et de créer un enregistrement de type "A" (Host) vide en spécifiant l'adresse IP du load-balancer. La relativité du DNS fait le reste...
  • Sur la partie load-balancer ou sur les CAS si vous ne faites pas de SSL Offloading ou de SSL Briding, et si ce n'était pas déjà le cas, remplacez le certificat de manière à avoir le Fqdn d'Outlook Anywhere en "Subject Name" et les autres noms (internes) en "Subject Alternate Names". Si vous ne voulez/pouvez pas faire ces modifications, vous pouvez configurer l'Outlook Provider "EXPR" afin que le nom pour l'authentification mutuelle SSL se fasse avec le Fqdn porté par le "Subject Name" du certificat. Attention toutefois, cela impacte vos clients "externes" et le nom doit être en adéquation avec le certificat porté par le Reverse Proxy. Par conséquent, la manipulation peut s'avérer plus ou moins complexe en fonction de la configuration en place.
Il est pris l'hypothèse que vous êtes déjà capable de load-balancer le Rpc/HTTP avec une bonne affinité (par exemple, cookie applicatif "OutlookSession") ou sinon n'utilisiez pas d'affinité du tout (le composant RPCHTTP-LB le faisant pour vous côté des serveurs Exchange au prix d'une consommation CPU accrue).
Dès lors, lors du prochain démarrage d'un client Outlook 2010 SP1 et pleinement mis à jour (testé avec les mises à jour de Novembre 2012) et après avoir forcé l'Autodiscover à reconfigurer la partie Rpc/HTTP proxy (un "repair" du profil s'impose, sinon attendre au max 2 heures), le client est maintenant configuré en mode "Negotiate" et non plus "Basic" ou "Ntlm".


Une petite vérification d'impose aussi sur les tickets Kerberos (avec KLIST):



Malheureusement, je n'ai pas encore réussi à faire fonctionner l'authentification par négociation avec un client Outlook 2007 SP3, même pleinement mis à jour. Cependant le mode d'authentification est disponible dans les propriétés Rpc/HTTP d'Outlook 2007 (depuis longtemps en fait).
En effet, lorsque mon client Outlook 2007 tente de se connecter, il échoue et se connecte en Mapi/Rpc classique et la méthode d'authentification se repositionne systématiquement sur "Basic". Il semble donc qu'il ne sache pas interpréter le mode d'authentification NegoEx (ci-dessous "Nego2" dans Outlook 2010 SP1).
Démonstration:


Aucun commentaire:

Enregistrer un commentaire