Configuration pas à pas de IIS8 pour l’utilisation du protocole KERBEROS – SSO Windows
Nous allons voir dans cet article comment configurer IIS 8 pour qu’un site hébergé utilise l’authentification intégrée Windows. L’authentification anonyme sera donc désactivée au profil de Negociate (Kerberos) et NTLM en secours si Kerberos échoue pour une raison quelconque.
Dans ce scénario nous allons fournir une identité au pool d’application IIS grâce à un compte de service Active Directory. Ce point est très important. Il va complexifier un peu le scénario mais nous permettre d’assurer un contrôle plus poussé en terme de sécurité et une segmentation réelle de nos sites hébergés.
Dans les fermes composées de plusieurs serveurs IIS load balancés, l’utilisation d’un compte de service Active Directory est obligatoire. Ce scénario n’intègre qu’un seul serveur IIS mais la configuration de l’authentification reste applicable.
Présentation de la maquette
Nom du domaine: test.local (TESTLOCAL)
Nom du site: monsite.test.local
Nom du compte de service: svc.monsite@test.local (UPN)
Petit rappel sur Kerberos
Kerberos met en œuvre une authentification à minima entre 3 acteurs (que nous retrouvons dans notre maquette):
– Un utilisateur identifié par un UPN (User Principal Name): svc.monsite@test.local
– Un service identifié par un SPN (Service Principal Name): HTTP/monsite.test.local
– Un tiers de confiance, le KDC (Key Distribution Center): DC2016, notre contrôleur de domaine
Chaque acteur dispose d’un secret (on parle de clé Kerberos) connu de lui et du KDC : Kc et Ks. Le KDC dispose de sa propre clé : Kkdc
La clés Kc est calculé depuis le mot de passe du compte utilisateur. La clé Ks est calculé depuis le mot de passe du compte de service (notre cas) ou du compte machine. La clé Kkdc est généré à la création du domaine et conservé dans les attributs de l’utilisateur krbtgt.
Configuration coté contrôleur de domaine: DC2016
Création d’une entrée DNS
Les services DNS sont intimement liés à l’authentification Kerberos. Sans un service DNS 100% fonctionnel aucune authentification Kerberos ne fonctionnera.
Nous allons créer une entrée de type A dans notre DNS qui va « pointer » vers l’adresse IP de notre serveur IIS:
Création du compte de service
Le compte de service est un compte standard pour lequel nous désactivons l’expiration du mot de passe. Ce paramètre n’est pas recommandé et l’utilisation d’un compte sMSA est plus approprié (nous reviendrons sur ce point plus tard).
Tous les services Kerberos doivent être associés à un compte (machine ou utilisateur) de l’Active Directory
Par défaut, dans l’Active Directory, les SPN sont associés aux comptes machines. Par exemple, pour srv-01$, les SPN sont : host/srv-01, cifs/srv-01, …
Il est cependant possible de définir un SPN pour un compte utilisateur en modifiant son attribut servicePrincipalName.
Rappel : pour un SPN donné, la partie chiffrée d’un ticket de service l’est avec la clé Kerberos du compte associé.
Ce n’est pas gênant pour les comptes machine car leur mot de passe, à partir duquel les clés Kerberos sont calculées, est garanti être totalement aléatoire, en revanche, les mots de passe des comptes utilisateur n’étant pas aléatoire, la robustesse des clés Kerberos n’est pas assurée. L’utilisation d’un mot de passe complexe ou d’un compte gMSA est donc recommandée.
Nous avons ici fait le choix d’utiliser un compte utilisateur pour l’exécution du pool d’application. Il va donc falloir positionner les SPN sur ce dernier:
Ce point est important et nécessite une configuration particulière dans IIS que nous allons voir par la suite.
Configuration coté serveur IIS: SRV2012
Paramétrage du pool d’application
Le pool d’application doit donc s’exécuter avec le compte de service précédemment créé. Sans besoin particulier, c’est le seul élément à configurer à ce niveau.
Paramétrage de la méthode d’authentification du site
Dans les paramètres d’authentification du site, l’authentification anonyme doit être désactivée et l’authentification Windows activée. L’ensemble des paramètres sont à laisser par défaut.
L’activation de l’authentification Windows ne signifie pas que le protocole Kerberos sera obligatoirement utilisé. Dans certains cas NTLM peut également être appelé.
Par exemple si le SPN n’arrive pas a être résolu dans le cas ou un utilisateur saisi l’adresse IP du site au lieu du nom long.
Il faut s’assurer que « Négocier » se trouve en haut de la liste dans la section fournisseurs que vous pouvez voir lorsque vous sélectionnez l’authentification Windows. Negotiate est un provider qui prend en charge le protocole Kerberos et qui contient également NTLM comme failback lorsque Kerberos échoue.
Paramétrage du ApplicationHost.config
« useAppPoolCredentials » doit être défini sur true: Lorsque « useAppPoolCredentials » est défini sur true, vous indiquez à IIS qu’il doit utiliser son identité de pool d’applications pour déchiffrer le jeton / ticket Kerberos obtenu à partir d’AD et transmis par le client au serveur pour authentifier l’utilisateur.
Remarque: Si nous avons à la fois les méthodes useAppPoolCredentials et useKernelMode définies sur true, useAppPoolCredentials est prioritaire et le compte du pool d’applications est utilisé pour le déchiffrement du ticket. Le paramètre Usekernelmode a été introduit à partir d’IIS 7 et des versions ultérieures. Dans IIS 6 et versions antérieures, l’identité du pool d’applications était toujours utilisée pour le déchiffrement du jeton / ticket
Via l’interface graphique:
ou directement dans le C:\Windows\System32\inetsrv\config\applicationHost.config:
Stratégies de sécurité locale
Par défaut et après avoir configuré le pool d’application, IIS affecte les droits sur le serveur au compte qu’il utilise pour son exécution. Il est possible de voir ces droits via la console secpol.msc puis Local Policies / User Right Assignment.
Droits affectés par défaut:
- Adjust memory quotas for a process: Ajout de IIS APPPOOL\monsite
- Generate security audits: Ajout de IIS APPPOOL\monsite
- Log on as a service: Ajout de IIS APPPOOL\monsite
- Replace a process level token: Ajout de IIS APPPOOL\monsite
Droits à ajouter:
- Log on as a batch job: Ajout de IIS APPPOOL\monsite
- Log on locally: Ajout de TESTLOCAL\svc.monsite
- Impersonate a client after authentication: Ajout de IIS APPPOOL\monsite
Une fois ces 3 droits positionnés, il faudra lancer dans un cmd gpupdate /force ainsi qu’un iisreset.
Droits d’accès au site
L’affectation des droits au site se fait de manière classique en utilisant les ACL Windows. Ainsi pour donner les droits de se connecter au site au compte localadminuser@test.local il faudra le positionner en lecture sur le répertoire C:\inetpub\wwwroot\monsite
Configuration coté client: WIN8
Ce test de connexion a été effectué avec Internet explorer mais d’autres navigateurs supportent l’authentification Windows intégrée (WIA) moyennant une configuration particulière sur ces derniers.
En l’état l’authentification Kerberos doit fonctionner à partir du client. Celui ci doit malgré tout avoir à s’authentifier en saisissant son UPN et son mot de passe de domaine à la connexion au site. Ce comportement est normal car le site ou la zone ne sont pas détectées en intranet local. La connexion automatique (SSO) ne s’effectue que dans ce cas.
Pour y remédier et donc permettre au navigateur de « jouer » la connexion automatique, il suffira d’insérer le site https://monsite.test.local ou plus communément https://*.test.local dans la zone intranet local.
La connexion doit être alors automatique, et l’utilisateur doit se connecter au site de manière transparente.
Kerberos, vraiment?
Pour être certain que l’authentification fonctionne en Kerberos, plusieurs méthodes s’offrent à nous:
Analyse de trame via Wireshark par exemple. La séquense classique d’authentification doit s’afficher en filtrant sur « kerberos ».
Chaque étape est composée d’une requête REQ et d’une réponse REP, ce qui fait 6 échanges pour réaliser une authentification complète (les 2 premiers échanges indiqué en erreur et liés à la pré-aauthentification ne sont pas à prendre en compte)
- KRB_AS_REQ et KRB_AS_REP
- KRB_TGS_REQ et KRB_TGS_REP
- KRB_AP_REQ et KRB_AP_REP (nous ne voyons pas ces 2 dernières dans la capture car elles sont encapsulées dans le protocole TLSv1.2)
Vérification des tickets présents sur le client en utilisant dans un cmd la commande klist
Le premier ticket #0 est le TGT et le #1 correspond au TGS obtenu pour notre SPN: HTTP/monsite.test.local
Bonus (sécurité)!
En regardant bien, la clé qui a permis de chiffrer les informations dans notre TGS est issue d’une méthode très ancienne: RSADSI RC4-HMAC. D’autres types d’empreintes, liées à Kerberos sont également calculées et ne demandent qu’à être utilisées. Par exemple depuis Windows 7/2008R2, il est possible d’utiliser AES Session-Key (Calcul des clés avec HMAC-SHA256 – Chiffrement avec AES-128 – Signature avec HMAC-SHA256): AES256-CTS-HMAC-SHA1-96 (RFC3962).
Les empreintes AES, calculées via PBKDF2, apportent : – des itérations (4096 par défaut) – une graine (basée sur le nom de l’utilisateur et du domaine).
Il suffira d’indiquer au compte de service que nous supportons le chiffrement basé sur AES-256 via la console ADUC:
Exécuter ensuite un « klist purge » dans un cmd pour vider les tickets précédemment émis.
Il suffit de relancer une nouvelle connexion au site dans internet explorer et vérifier à nouveau la liste des tickets via « klist » pour constater l’évolution:
