Principes de base : procédures d'authentification pour les services d'information Internet (IIS)

Auteur Uwe GradeneggerPublié le Catégories Active Directory, Services d'information sur Internet (IIS), Utilisation du certificatÉtiquettes , ,

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 (engl. Protocol Transition) wird bezeichnet, wenn der Benutzer sich mit einem Verfahren abseits Kerberos authentisiert hat, und der Server-Prozess im Namen des Benutzers ein Kerberos-Ticket in dessen Namen anfordert, um es an eine nachgeschaltete Ressource (z.B. eine Datenbank) weiterzuleiten. In Kerberos-Termini wird dieser Prozess auch als S4U bezeichnet. Hierbei handelt es sich um ein extrem mächtiges Recht, denn es ist damit verbunden, dass der Server-Dienst das Recht erhält, für jeden beliebigen Benutzer ein solches Ticket zu beantragen, sprich der Server-Prozess kann jede beliebige Identität annehmen.

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é.

Le problème du double saut

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)
  • Welche Art Client soll sich authentisieren können? (Nur von Domänen-Computern aus, nur Windows, welche Authentisierungsverfahren werden von den Anwendungen unterstützt? Möchten oder brauchen wir Benutzername/Kennwort, Kerberos-Ticket, oder Clientzertifikat?)
  • 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" /}

Außerdem erfordert die den „Classic“ Managed Pipeline Modus für den IIS-Anwendungspool. In der Regel ist diese Option nicht notwendig, da Anwendungsbezogen impersoniert werden kann. Siehe hierzu die Windows Authentication.

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.

Dieses Verfahren funktioniert mit Kerberos nur dann, wenn alle Komponenten (Client-Computer, Benutzerkonto, Serverdienst und eventuelle nachgeschaltete Ressourcen) Mitglieder der gleichen Active Directory Domäne oder Gesamtstruktur sind, oder wen eine Vertrauensstellung zwischen den beteiligten Domänen eingerichtet ist.

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.
Au niveau de l'application, l'"Anonymous Authentication" 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).
  • Die Zertifizierungsstelle, welche die Zertifikate der angemeldenen Benutzer ausstellet, muss Mitglied von 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.
L'option "Active Directory Client Certificate Authentication" n'est disponible qu'au niveau du serveur.
Au niveau de l'application, toutes les méthodes d'authentification doivent être désactivées.

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

fr_FRFrançais
de_DEDeutsch en_USEnglish fr_FRFrançais