Les services de certificats Active Directory offrent une série d'interfaces supplémentaires basées sur le web (Service d'enregistrement des périphériques réseau (NDES), Service de politique d'enregistrement des certificats (CEP), Service web d'enregistrement des certificats (CES), Enregistrement web des autorités de certification (CAWE).
Les Microsoft Internet Information Services (IIS) sont donc pratiquement indispensables pour une ICP Microsoft. Chacune des interfaces basées sur le web (ainsi que les développements propres) présente ses propres défis en termes de procédures d'authentification et d'implémentation.
L'article suivant a pour but d'apporter un peu de clarté sur le sujet.
Authentification vs. impersonnalisation vs. délégation vs. transition de protocole
Connaissez-vous TameMyCerts? TameMyCerts est un add-on pour l'autorité de certification Microsoft (Active Directory Certificate Services). Il étend la fonction de l'autorité de certification et permet de Application de la réglementationIl s'agit d'un logiciel de gestion des certificats qui permet d'automatiser l'émission de certificats en toute sécurité. TameMyCerts est unique dans l'écosystème Microsoft, a déjà fait ses preuves dans d'innombrables entreprises du monde entier et est disponible sous une licence libre. Il peut téléchargé via GitHub et être utilisé gratuitement. Une maintenance professionnelle est également proposée.
En tant que Authentification (angl. Authentication) est désigné (en ce qui concerne IIS) lorsque l'utilisateur peut s'identifier en tant que tel auprès du serveur web, c'est-à-dire prouver qu'il est bien celui qu'il prétend être.
En tant que Impersonation (angl. Impersonation) désigne le cas où l'utilisateur s'est connecté à l'aide d'une procédure d'authentification quelconque et où le processus serveur (p. ex. l'application web) exécute ensuite une action dans le contexte de sécurité de l'utilisateur sur le même système (p. ex. l'accès à un répertoire local sur lequel les autorisations correspondantes sont configurées).
En tant que Délégation (angl. Delegation) désigne le cas où l'utilisateur s'est authentifié avec un ticket Kerberos (autorisé comme pouvant être délégué) et où le processus serveur (p. ex. l'application web) transmet ce ticket au nom de l'utilisateur à une ressource en aval (p. ex. une base de données ou une autorité de certification). En termes de Kerberos, ce processus est également appelé S4U2Proxy.
En tant que Transfert de protocole (en anglais : Protocol Transition) désigne le cas où l'utilisateur s'est authentifié à l'aide d'une procédure autre que Kerberos et où le processus serveur demande un ticket Kerberos au nom de l'utilisateur afin de le transmettre à une ressource en aval (par exemple une base de données). Dans le jargon Kerberos, ce processus est également appelé S4U. Il s'agit d'un droit extrêmement puissant, car il permet au service serveur de demander un tel ticket pour n'importe quel utilisateur, c'est-à-dire que le processus serveur peut prendre n'importe quelle identité.
On est souvent concerné par ce que l'on appelle le problème du double saut, c'est-à-dire que l'on souhaite que le processus serveur accède à une ressource en aval dans le contexte de sécurité de l'utilisateur connecté.
Qu'est-ce qu'on va faire ?
Pour choisir la méthode d'authentification correcte, nous devons réfléchir à ce que nous voulons obtenir :
- L'authentification nous suffit-elle ? (n'avons-nous pas un scénario à double saut)
- Quel type de client doit pouvoir s'authentifier ? (Uniquement à partir d'ordinateurs du domaine, uniquement Windows, quelles procédures d'authentification sont prises en charge par les applications ? Souhaitons-nous ou avons-nous besoin d'un nom d'utilisateur/mot de passe, d'un ticket Kerberos ou d'un certificat client ?)
- Souhaitons-nous même obtenir une connexion purement Kerberos, c'est-à-dire désactiver NTLM ?
Identité du pool d'applications IIS
Veuillez noter que l'Application Pool Identity permet l'impersonnalisation mais pas la délégation. Pour cela, il faudrait un "service réseau" (probablement non recommandé, mais pourquoi ?) ou un compte de domaine/gMSA.
Procédure d'authentification
Dans tous les cas, la connexion doit absolument être protégée par SSL, c'est-à-dire que l'option "Require SSL" doit être activée.
Authentification HTTP de base
Dans le cas de l'authentification de base, l'utilisateur qui se connecte transmet son mot de passe en texte clair via un en-tête HTTP. Le serveur dispose ainsi du mot de passe en clair de l'utilisateur connecté, ce qui lui permet de demander un ticket Kerberos en son nom. Cette méthode ne nécessite pas de délégation pour un accès dans le contexte de sécurité de l'utilisateur à d'autres hôtes.
Après tout, le processus serveur ne peut le faire que pour les comptes qui se connectent à lui.
Pour que l'authentification de base fonctionne, il faut ajouter ce qui suit dans le Web.config de l'application.
{system.web}
{authentication mode="Windows"/}
{/system.web}
ASP.NET Impersonation
Lorsque l'impersonnalisation ASP.NET est activée, tout le code côté serveur est exécuté dans le contexte de sécurité de l'utilisateur connecté.
L'activation de l'impersonnalisation ASP.NET place ce qui suit dans le Web.config de l'application.
{identity impersonate="true" /}
De plus, cela nécessite le mode „ Classic “ Managed Pipeline pour le pool d'applications IIS. En règle générale, cette option n'est pas nécessaire, car l'usurpation d'identité peut être effectuée en fonction de l'application. Voir à ce sujet l'authentification Windows.
Authentification Windows (intégrée, ou Kerberos)
Avec l'authentification Windows, l'utilisateur s'authentifie par Kerberos ou, en cas d'échec, par la procédure NTLM (qui transmet une somme de contrôle du mot de passe de l'utilisateur).
Si le saut vers un autre serveur est nécessaire, il faut au moins une délégation "Kerberos only" pour le compte de service du serveur web.
Cette procédure ne fonctionne avec Kerberos que si tous les composants (ordinateur client, compte utilisateur, service serveur et éventuelles ressources en aval) sont membres du même domaine Active Directory ou de la même structure globale, ou si une relation de confiance a été établie entre les domaines concernés.
L'essentiel de la configuration dans IIS :
- Au niveau de l'application, l'"Anonymous Authentication" doit être désactivée.
- Au niveau de l'application, "Windows Authentication" doit être activé.
- Si l'on configure le fournisseur "Negotiate:Kerberos" (donc uniquement Kerberos sans NTLM), l'authentification en mode noyau doit être désactivée.
Le site web doit être inclus dans la zone "Intranet local" du navigateur de l'utilisateur qui se connecte pour que la connexion automatique ait lieu.
Mappage des certificats clients (IIS)
Dans IIS, il existe deux formes d'authentification avec des certificats clients. "IIS Client Certificate Mapping" mappe contre des comptes définis dans IIS. Elle ne convient donc effectivement que pour l'authentification, mais pas pour l'impersonnalisation, la délégation ou la transition de protocole. Elle n'est donc pas traitée ici.
Mappage des certificats clients (Active Directory)
La fonctionnalité IIS "Client Certificate Mapping" mappe les certificats par rapport aux comptes dans l'Active Directory. Pour que cela fonctionne, le processus du serveur web doit, après avoir reçu l'authentification, demander un ticket Kerberos au nom de l'utilisateur qui se connecte (d'où la nécessité d'une transition de protocole). Enfin, il n'y a pas de transmission d'un mot de passe, d'une valeur de hachage ou d'un ticket Kerberos transmissible avec cette méthode. Cet avantage supposé est aussi un très gros inconvénient, car des droits étendus sont ainsi accordés aux comptes du serveur web.
L'essentiel de la configuration dans IIS :
- Le compte de service nécessite une délégation Kerberos avec "Use any Authentication protocol" (utiliser n'importe quel protocole d'authentification).
- L'organisme de certification qui délivre les certificats aux utilisateurs enregistrés doit être membre de NTAuthCertificates être. Cela peut également représenter un très grand risque pour la sécurité.
- Sur qui SSL Binding doit être le "DS Mapper" doit être activé sur le SSL Binding (sinon la connexion s'interrompt avec le code d'erreur HTTP 403.2.5).
- Le site Envoi de la liste de confiance devrait être activé sur le SSL Binding.
- La procédure d'authentification pour "Active Directory Client Certificate Authentication" doit être activée au niveau du serveur. C'est seulement à ce niveau que l'option est disponible dans IIS Manager.
- Au niveau du site web, le "Client Certificate Mapping" (l'option clientCertificateMappingAuthentication) doit également être activé.
- Au niveau du site web, les certificats clients doivent être sur "Accept" s'il y a des sous-dossiers qui utilisent sélectivement cette méthode d'authentification (sinon, "require").
- Au niveau de l'application ou du sous-dossier, les certificats clients doivent être définis sur "Required", s'ils existent.
- Au niveau de la page web (s'il n'y a pas de sous-dossier) ou de l'application, tous les protocoles d'authentification doivent être désactivés.
Un exemple d'activation de l'authentification par certificat client au niveau de la page web.
%WINDIR%\System32\inetsrv\appcmd.exe set config "Default Web Site" -section:system.webServer/security/authentication/clientCertificateMappingAuthentication /enabled:"True" /commit:apphost %WINDIR%\System32\inetsrv\appcmd.exe set config "Default Web Site" -section:system.webServer/security/access /sslFlags:"Ssl, SslNegotiateCert" /commit:apphost
Un exemple de configuration de la liaison SSL avec DS-Mapper et l'utilisation du magasin de certificats ClientAuthIssuer pour identifier les autorités de certification autorisées à se connecter.
netsh http delete sslcert ipport=0.0.0.0:443
netsh http add sslcert ipport=0.0.0.0:443 certstorename=MY certhash=71cc1fed1c7ef6cec45de66c288447a4ad464c20 appid={4dc3e181-e14b-4a21-b022-59fc669b0914} sslctlstorename=ClientAuthIssuer dsmapperusage=enable
L'ensemble du mécanisme est en général plutôt déconseillé, car il faut utiliser deux paramètres potentiellement très dangereux (adhésion à NTAuthCertificates ainsi que délégation Kerberos avec transition de protocole).
Liens complémentaires :
Sources externes
- NDES : inclure le nom d'utilisateur et le mot de passe pour http://myNDES/certsrv/mscep_admin/ (Forums Microsoft TechNet)
- Configurer l'authentification Windows (IIS 7) (Microsoft Corporation)
- Niveaux d'impersonnalisation (Microsoft Corporation)
- Comment faire : Utiliser l'impersonnalisation et la délégation dans ASP.NET 2.0 (Microsoft Corporation, lien vers l'archive)
- Comment configurer la délégation contrainte Kerberos pour les pages proxy d'inscription au Web ? (Microsoft Corporation)
- Choses à vérifier lorsque l'authentification Kerberos échoue en utilisant IIS/IE (Microsoft Corporation)
- Le problème du double saut Kerberos (Michael Lowery)
- Mappage de certificat client Authentification (Microsoft Corporation)
Français 
Deutsch 
English