Configurer l'authentification intégrée Windows dans IIS n'est pas en soi très compliqué. Les scénarios se compliquent cependant lorsqu'il s'agit de mettre en place Kerberos sur des serveurs mutualisés ou sur des fermes de serveurs Web.
Configuration IIS pour Délégation Kerberos
Délégation Kerberos
Configuration IIS
Ce billet décrit pas à pas la configuration à mettre en place.
1. Configuration de l'identité de l'application Pool.
L’authentification Kerberos ne fonctionnera pas dans le cas d’une ferme de serveurs IIS dont les application pool s’exécuteraient sous Network Service ou Local Sytem/Service car le SPN nécessaire à l'authentification Kerberos ne pourrait pas être enregistré sur les différents compte d'ordinateur de la ferme.
Configuration IIS pour Délégation Kerberos
Pour permettre l'authentification Kerberos sur une ferme Web ( Ferme NLB, boitier F5 etc.), l'application Pool d'IIS doit s'exécuter sous l'identité du même compte utilisateur du domaine sur chaque serveur. Le SPN correspondant à l'URL de connexion sera enregistré sur ce compte. Dans cette configuration, le navigateur peut demander un ticket Kerberos pour la chaine SPN spécifiée et présenter le ticket Kerberos à chaque noeud de la ferme web puisque chauqe noeud tourne sous le même compte d'utilisateur du domaine.
Délégation Kerberos
Dans l'Active Directory, créez simplement un compte utilisateur, dit compte de service, et positionnez les flags « User cannot Change Password » et « Password never expires ».
2. Configuration d'IIS
Créez ensuite dans IIS un nouveau pool d'application et définissez comme identité le compte que vous venez de créer.
Créez ensuite le
site web, puis configurez le pour s’exécuter dans le pool d’application
précédemment configuré.
Cas particulier: Environnement mutualisé
Dans le cas où le serveur héberge plusieurs sites IIS, il faut pouvoir séparer les instances de IIS.
Celà peut être réalisé de 2 manières:
- soit en les différençiant grâce à un numéro de port différent.
- soit en les différençiant par le host header.
La première solution presente le désavantage d’avoir à manipuler des numéros de port nécessaires pendant la construction du SPN. Les navigateurs se comportant différemment, certains risquent de ne pas passer le numéro de port pendant la construction du SPN, au final le SPN demandé ne sera pas trouvé ou un ticket Kerberos pour le mauvais compte sera retourné par l'AD. De plus, il risque sur la route d'y avoir des réécritures de port: (ex à travers un boitier F5) et le port passé dans la construction du SPN par le client ne sera pas nécessairement celui enregistré dans le SPN dans l'AD.
Afin d’avoir une meilleure maitrise de la solution et s’assurer d’une configuration qui fonctionne dans tous les cas, la seconde solution est à privilégier lorsque c’est posible. Elle nécessite la configuration du Host Header dans le site IIS.
Dans le scénario le plus simple, ce host header doit correspondre à une entrée de type A (host) dans le DNS (et pas une entrée de type CNAME (Alias) dans le DNS) et être enregistré au niveau des SPN sur le compte de service de l’application pool.
Ainsi, lorsque le navigateur Internet Explorer, demande l’URL http://portaldns, il demande un ticket kerberos pour le SPN http/portaldns enregistré sur le compte de service domAD\svcdnsadmin. Il le presente alors au serveur IIS qui grâce au host header portaldns redirige la requête vers la bonne instance.
Si un alias est enregistré au niveau host header, le spn associé à l’entrée de type host correspondant à l’alias DNS doit également être enregistré en tant que SPN.
Vous pouvez placer plusieurs host headers sur un même instance IIS (ie plusieurs URL d’accès).
Importance du Host vs ALIAS DNS
Les navigateurs se comportent tous différemment.
Ainsi, lors de la construction du SPN, Internet Explorer fait une résolution DNS du nom de serveur spécifié dans l'URL et construit par défaut un SPN de type host/fqdn ou fqdn est le nom de host (type A) présent dans le DNS, même si dans l'URL un alias DNS (type CNAME) a été spécifié. en d'autre terme, si vous demandez http://alias, le spn construit sera http/host. Le mécanisme peut être inversé par le biais d'un htofix. Je ne recommande personnellement pas la modification de ce comportement. Il est en effet élégant d'avoir à n'enregistrer qu'un seul SPN dans l'AD (celui du host) et de pouvoir avoir une multitude d'aliases. Firefox par contre utilise le nom passé dans l'URL sans transformer l'alias en host.
Dans le scénario de host header, si IIS est accédé par une url contenant un alias, il faudra enregistrer en SPN le host et l'alias pour que ça fonctionne depuis n'importe quel navigateur.
3. Configuration supplémentaire
A ce stade,ça ne fonctionne pas encore. Il faut donner les bonnes permissions au compte de service sur le serveur. Le compte de service nouvellement crée a besoin de permissions sur la metabase IIS et de permissions sur le répertoire temporaire %Windir%\Microsoft.NET\Framework\version\Temporary ASP.NET
La commande aspnet_regiis –ga réalise ces 2 opérations. Lancez: aspnet_regiis -ga Domain\AccountName
Ensuite,
rajoutez le
compte d’identité du pool d’application IIS dans le groupe local IIS_WPG.
Rajoutez maintenant les SPN requis sur le compte de service du pool d'application à l'aide de la commande setspn. Ex:
setspn -a http/portaldns domAD\svcportaladmin et setspn -a http/alias domAD\svcportaladmin enregistrent les SPN pour le host et l'alias sur le compte de service. Celà permet de faire fonctionner kerberos dans la majorité des cas. Plusieurs aliases peuvent être ajoutés.
4. Délégation Kerberos
Pour terminer, la délégation Kerberos doit être mise en place. Le compte de service doit être approuvé pour la délégation (Trusted for Delegation) dans l'Active Directory et pour des raisons de sécurité, les contraintes de délégation doivent être mises en place, c'est à dire lister uniquement les TGS Kerberos (représentés par les SPN) que le compte de service est autorisé à demander.
Le compte de service nouvellement crée a besoin de permissions sur la metabase IIS et de permissions sur le répertoire temporaire %Windir%\Microsoft.NET\Framework\version\Temporary ASP.NET
La commande aspnet_regiis –ga réalise ces 2 opérations. Lancez:
aspnet_regiis -ga Domain\AccountName
Dans le cas d’une application ASP.NET, le fichier web.config doit être configuré de la façon suivante : http://support.microsoft.com/kb/810572
Bien évidemment, pour que la délégation Keberos fonctionne, cela nécessite au préalable une authentification du poste client et donc désactivation de l’authentification anonyme et l’activation de l’authentification intégrée.
Au niveau Internet
Explorer, l’authentification intégrée doit être activée, et l’URL résolue en
tant que site Intranet (c’est souvent le proxy.pac qui détermine si l’url est locale ou
non).
