Délégation d’authentification

de gestion COM+ et entre celui-ci et le serveur de base de données, comme l’illustre la figure 4. Si l’on veut utiliser l’identité de l’utilisateur pour mettre en place le contrôle d’accès aux données sur le serveur de base de données, les protocoles d’authentification que l’on utilise doivent permettre la délégation. Autrement dit, les protocoles d’authentification doivent être capables de retransmettre les références de l’utilisateur d’une machine à  une autre. Chaque machine utilise l’identité du client pour authentifier la machine suivante.

Protocoles d’authentification et leur effet sur la délégation :

Le tableau ci-dessus illustre le mode de relation entre le support de délégation et le protocole d’authentification en vigueur. Supposons, par exemple, que vous utilisiez l’authentification de base pour authentifier un utilisateur travaillant depuis son navigateur vers un serveur Web sur un quelconque serveur distant. Pour authentifier vis-à -vis d’un serveur (un serveur Exchange, par exemple) qui se trouve à  un tronçon du serveur Web, ce dernier peut réutiliser l’identité de l’utilisateur. Si AD est installé (et si le protocole d’authentification Kerberos est disponible), les machines qui se trouvent sur plusieurs tronçons du serveur Web peuvent utiliser l’identité de l’utilisateur pour l’authentification. Le processus du serveur Web peut utiliser Kerberos et les références du client pour s’authentifier auprès d’un processus serveur COM+. A son tour, le serveur COM+ peut utiliser Kerberos et l’identité du client pour s’authentifier auprès d’un processus Microsoft SQL Server (sur encore une autre machine). A noter que quand on utilise l’accès anonyme et que la synchronisation par mot de passe Microsoft IIS est activée, on ne peut pas déléguer le compte IUSR_servername. Il en est de même quand on utilise l’authentification par certificat de type SSL/TLS et que les mappings de certificat sont définis dans AD. Rappelons également que NTLM ne permet pas la délégation.

La figure 4 montre comment établir la délégation Kerberos dans un environnement intranet Win2K classique. Tous les composants peuvent utiliser des RPC pour communiquer. L’interface client est de type navigateur et, de ce fait, communique avec le serveur Web par HTTP. Par ailleurs, l’utilisateur est déjà  enregistré dans un domaine par l’intermédiaire de Kerberos ou de NTLM. Dans un contexte Internet, le client communiquerait également par HTTP mais ne serait généralement pas enregistré dans un domaine. Quoi qu’il en soit, il n’est pas conseillé d’utiliser Kerberos ou NTLM sur Internet : ces protocoles d’authentification ne s’adaptent pas bien à  de vastes environnements et ont besoin d’un tiers de confiance en ligne.

Pour utiliser Kerberos du navigateur vers le serveur de base de données, il faut remplir les conditions suivantes :
· Tout le logiciel impliqué doit avoir accès au Negotiate SSP (Security Support Provider) et au SSP Kerberos et savoir comment les utiliser. Les SSP sont des modules logiciels qui dispensent les applications et les développeurs d’applications de connaître le fonctionnement interne d’un mécanisme d’authentification. Le Negociate SSP est un fournisseur spécial qui négocie le protocole d’authentification (c’est-à -dire, Kerberos ou NTLM) entre un client et un serveur. Au moment de l’écriture de ces lignes, le Kerberos SSP n’est disponible que sur les plates-formes Win2K. Microsoft Internet Explorer (IE) 5.5 et IE 5.0, Internet Information Services (IIS) 5.0, SQL Server 2000, Exchange 2000, et COM+ savent comment utiliser les Negotiate et Kerberos SSP.
· L’utilisateur doit avoir un compte dans AD qui n’ait pas la propriété Account is sensitive and cannot be delegated activée. Pour vérifier ce paramètre, aller dans le snap-in Microsoft Management Console (MM) Active Directory Users and Computers, accéder à  la feuille Properties d’un objet utilisateur AD et sélectionner l’onglet Account, que l’on voit dans la figure 5. Les comptes de services exécutant IIS et SQL Server, ainsi que l’identité utilisée pour l’application COM+ devraient être définis dans AD. Le compte de service IIS (par défaut, compte machine), et l’identité d’application COM+ doivent être « trusted for delegation » (de confiance pour la délégation). On règle la propriété Account is trusted for delegation sur l’onglet Account. Pour définir un compte machine, aller à  l’onglet General de l’objet dans le snap-in Active Users and Computers.
· Le service Web doit avoir un SPN (Service Principal Name) valide enregistré dans AD. Si le nom du service Web est différent du nom de l’ordinateur IIS, il faut absolument utiliser l’utilitaire setspn.exe du Microsoft Windows 2000 Resource Kit pour enregistrer un SPN personnalisé.
· L’application COM+ doit supporter le niveau d’imitation Delegate (Delegate impersonation).

Bien qu’il soit facile d’établir une délégation d’authentification dans un environnement Win2K, je conseille fortement de la tester et de se familiariser avec elle avant de commencer à  mettre en oeuvre la sécurité pour votre infrastructure .NET. La technologie qui sous-tend la délégation d’authentification est bien plus complexe que les options de configuration de la GUI Active Directory Users and Computers.