Share via

Configurer l’authentification (Office SharePoint Server)

  • Article

Mise à jour : 2009-03-26

Dans ce chapitre :

L’authentification est le processus consistant à valider l’identité du client, généralement par le biais d’une autorité désignée. L’authentification d’un site Web permet d’établir qu’un utilisateur qui essaie d’accéder aux ressources du site Web peut être considéré comme une entité authentifiée. Une application d’authentification obtient les informations d’identification d’un utilisateur qui demande l’accès au site Web. Les informations d’identification peuvent revêtir diverses formes d’identification, telles que le nom d’utilisateur et le mot de passe. L’application d’authentification essaie de valider les informations d’identification auprès d’une autorité d’authentification. Si les informations d’identification sont valides, l’utilisateur qui a envoyé les informations d’identification est considéré comme une identité authentifiée.

Authentification Office SharePoint Server

Pour déterminer le mécanisme d’authentification Office SharePoint Server à utiliser le plus approprié, tenez compte des points suivants :

  • Pour utiliser un mécanisme d’authentification Windows, vous avez besoin d’un environnement qui prend en charge les comptes d’utilisateur pouvant être authentifiés par une autorité de confiance.

  • Si vous utilisez un mécanisme d’authentification Windows, le système d’exploitation effectue les tâches liées à la gestion des informations d’identification utilisateur. Si vous utilisez un fournisseur d’authentification autre que Windows, tel que l’authentification par formulaire, vous devez planifier et implémenter un système de gestion des informations d’identification et déterminer où stocker les informations d’identification utilisateur.

  • Vous devrez peut-être mettre en œuvre un modèle d’emprunt d’identité/de délégation pouvant transmettre le contexte de sécurité de niveau système d’exploitation d’un utilisateur sur différents niveaux. Cela permet au système d’exploitation d’emprunter l’identité de l’utilisateur et de déléguer le contexte de sécurité de l’utilisateur au sous-système en aval suivant.

Microsoft Office SharePoint Server est une application distribuée qui est divisée logiquement en trois niveaux : le niveau du serveur Web frontal, le niveau du serveur d’application et le niveau de la base de données principale. Chaque niveau est un sous-système approuvé et l’authentification peut être requise pour l’accès à chaque niveau. La validation des informations d’identification nécessite un fournisseur d’authentification. Les fournisseurs d’authentification sont des composants logiciels qui prennent en charge des mécanismes d’authentification spécifiques. L’authentification Office SharePoint Server 2007 repose sur le modèle d’authentification ASP.NET et comprend trois fournisseurs d’authentification :

  • fournisseur d’authentification Windows ;

  • Fournisseur d’authentification par formulaire ;

  • Fournisseur d’authentification unique Web.

Vous pouvez utiliser le service d’annuaire Active Directory pour l’authentification ou vous pouvez concevoir votre environnement de manière à ce que les informations d’identification de l’utilisateur soient validées auprès d’autres magasins de données, tels qu’une base de données Microsoft SQL Server, un annuaire LDAP (Lightweight Directory Access Protocol) ou tout autre annuaire disposant d’un fournisseur d’appartenances ASP.NET 2.0. Le fournisseur d’appartenances spécifie le type de magasin de données que vous allez utiliser. Le fournisseur d’appartenances ASP.NET 2.0 par défaut utilise une base de données SQL Server. Office SharePoint Server 2007 inclut un fournisseur d’appartenances v3 LDAP et ASP.NET 2.0 comprend un fournisseur d’appartenances SQL Server.

Vous pouvez également déployer plusieurs fournisseurs d’authentification pour activer, par exemple, l’accès intranet en utilisant l’authentification Windows et l’accès externe en utilisant l’authentification par formulaire. L’utilisation de plusieurs fournisseurs d’authentification implique le recours à plusieurs applications Web. Chaque application Web doit disposer d’une zone désignée et d’un fournisseur d’authentification unique.

Les fournisseurs d’authentification permettent d’effectuer l’authentification par rapport aux informations d’identification des utilisateurs et des groupes stockées dans Active Directory, dans une base de données SQL Server ou dans un service d’annuaire LDAP non-Active Directory (tel que NDS). Pour plus d’informations sur les fournisseurs d’appartenance ASP.NET, voir Configuration d’une application ASP.NET pour utiliser l’appartenance (https://go.microsoft.com/fwlink/?linkid=87014&clcid=0x40C).

Fournisseur d’authentification Windows

Le fournisseur d’authentification Windows prend en charge les méthodes d’authentification suivantes :

  • Authentification anonyme

    L’authentification anonyme permet aux utilisateurs de rechercher des ressources dans les zones publiques de sites Web sans avoir à fournir d’informations d’authentification. IIS (Internet Information Services) crée le compte IUSR_nom_ordinateur pour authentifier les utilisateurs anonymes en réponse à une demande de contenu Web. Le compte IUSR_nom_ordinateur, où nom_ordinateur représente le nom du serveur qui exécute IIS, permet à l’utilisateur d’accéder aux ressources de manière anonyme dans le contexte du compte IUSR. Vous pouvez réinitialiser l’accès utilisateur anonyme pour utiliser n’importe quel compte Windows valide. Dans un environnement autonome, le compte IUSR_nom_ordinateur se trouve sur le serveur local. Si le serveur est un contrôleur de domaine, le compte IUSR_nom_ordinateur est défini pour le domaine. Par défaut, l’accès anonyme est désactivé lorsque vous créez une nouvelle application Web. Cela renforce la sécurité, car IIS rejette les demandes d’accès anonyme avant même qu’elles puissent être traitées si l’accès anonyme est désactivé.

  • Authentification de base

    L’authentification de base nécessite les informations d’identification du compte Windows précédemment attribuées pour l’accès des utilisateurs. L’authentification de base permet à un navigateur Web de fournir des informations d’identification lorsqu’il effectue une demande au cours d’une transaction HTTP. Étant donné que les informations d’identification de l’utilisateur ne sont pas chiffrées pour la transmission réseau, mais envoyées sur le réseau en texte brut, il n’est pas recommandé d’utiliser l’authentification de base sur une connexion HTTP non sécurisée. Pour utiliser l’authentification de base, vous devez activer le chiffrement SSL (Secure Sockets Layer).

  • Authentification Digest

    L’authentification Digest fournit les mêmes fonctionnalités que l’authentification de base, mais avec une sécurité accrue. Les informations d’identification de l’utilisateur sont chiffrées au lieu d’être envoyées sur le réseau en texte brut. Elles sont envoyées en tant que synthèse de message MD5 qui ne permet pas de déchiffrer le nom d’utilisateur et le mot de passe d’origine. L’authentification Digest utilise un protocole de stimulation/réponse qui exige que le demandeur de l’authentification présente des informations d’identification valides en réponse à une stimulation du serveur. Pour s’authentifier sur le serveur, le client doit fournir une synthèse de message MD5 dans une réponse contenant un mot de passe de secret partagé sous forme de chaîne. L’algorithme Message Digest MD5 est décrit en détail dans la RFC 1321 IETF (Internet Engineering Task Force) (http://www.ietf.org//) .

    Pour utiliser l’authentification Digest, notez les conditions requises suivantes :

    • L’utilisateur et le serveur IIS doivent être membres du même domaine ou approuvés par le même domaine.

    • Les utilisateurs doivent posséder un compte d’utilisateur Windows valide stocké dans Active Directory sur le contrôleur de domaine.

    • Le domaine doit utiliser un contrôleur de domaine Microsoft Windows Server 2003.

    • Vous devez installer le fichier IISSuba.dll sur le contrôleur de domaine. Ce fichier est copié automatiquement au cours de l’installation de Windows Server 2003.

  • Authentification Windows intégrée

    L’authentification Windows intégrée peut être implémentée à l’aide de NTLM ou de la délégation Kerberos contrainte. La délégation Kerberos contrainte est la méthode d’authentification la plus sécurisée. L’authentification Windows intégrée fonctionne bien dans un environnement intranet dans lequel les utilisateurs possèdent des comptes de domaine Windows. Dans l’authentification Windows intégrée, le navigateur tente d’utiliser les informations d’identification de l’utilisateur actuel à partir d’une ouverture de session de domaine et, si la tentative échoue, l’utilisateur est invité à entrer un nom d’utilisateur et un mot de passe. Si vous utilisez l’authentification Windows intégrée, le mot de passe de l’utilisateur n’est pas transmis au serveur. Si l’utilisateur a ouvert une session sur l’ordinateur local en tant qu’utilisateur de domaine, il n’a pas besoin de s’authentifier à nouveau lorsqu’il accède à un ordinateur réseau dans ce domaine.

  • Authentification Kerberos

    Cette méthode est destinée aux serveurs qui exécutent Active Directory sous Microsoft Windows 2000 Server et sous les versions plus récentes de Windows. Kerberos est un protocole sécurisé qui prend en charge l’authentification par ticket. Un serveur d’authentification Kerberos accorde un ticket en réponse à une demande d’authentification d’un ordinateur client dans laquelle figurent des informations d’identification utilisateur valides. L’ordinateur client utilise ensuite le ticket pour accéder aux ressources du réseau. Pour activer l’authentification Kerberos, les ordinateurs client et serveur doivent disposer d’une connexion approuvée au centre de distribution de clés du domaine. Les ordinateurs client et serveur doivent également être en mesure d’accéder à Active Directory. Pour plus d’informations sur la configuration d’un serveur virtuel pour utiliser l’authentification Kerberos, voir dans la Base de connaissances Microsoft l’article 832769 : Comment faire pour configurer un serveur virtuel Windows SharePoint Services pour utiliser l’authentification Kerberos et comment faire pour revenir ensuite à l’authentification NTLM (https://support.microsoft.com/kb/832769/fr-fr?amp;clcid=0x40C).

  • Délégation Kerberos contrainte

    L’authentification par délégation contrainte est la configuration la plus sécurisée pour la communication entre plusieurs niveaux d’application. Vous pouvez utiliser la délégation contrainte pour transmettre l’identité de l’appelant d’origine à travers plusieurs niveaux d’application : par exemple, depuis un serveur Web vers un serveur d’applications, puis vers un serveur de bases de données. En outre, elle représente la configuration la plus sécurisée pour accéder aux sources de données principales à partir des serveurs d’applications. L’emprunt d’identité permet à un thread de s’exécuter dans un contexte de sécurité autre que celui du processus à qui il appartient. Dans la plupart des déploiements de batteries de serveurs dans lesquels des serveurs Web frontaux et des serveurs d’applications s’exécutent sur des ordinateurs différents, l’emprunt d’identité nécessite une délégation Kerberos contrainte.

  • Emprunt d’identité et délégation Kerberos

    La délégation Kerberos permet à une entité authentifiée d’emprunter les informations d’identification d’un utilisateur ou d’un ordinateur au sein de la même forêt. Lorsque l’emprunt d’identité est activé, l’entité qui emprunte l’identité est autorisée à utiliser les informations d’identification pour exécuter des tâches pour le compte de l’utilisateur ou de l’ordinateur représenté.

    Pendant l’emprunt d’identité, les applications ASP.NET peuvent s’exécuter à l’aide des informations d’identification d’une autre entité authentifiée. Par défaut, l’emprunt d’identité ASP.NET est désactivé. Si l’emprunt d’identité est activé pour une application ASP.NET, cette application s’exécute à l’aide des informations d’identification du jeton d’accès transmis par IIS à ASP.NET. Ce jeton peut être un jeton d’utilisateur authentifié, tel qu’un jeton pour un utilisateur Windows connecté, ou le jeton fourni par IIS pour les utilisateurs anonymes (en général, l’identité IUSR_nom_ordinateur).

    Lorsque l’emprunt d’identité est activé, seul le code de votre application s’exécute dans le contexte de l’utilisateur représenté. Les applications sont compilées et les informations de configuration sont chargées à l’aide de l’identité du processus ASP.NET.

    Pour plus d’informations sur l’emprunt d’identité, voir Emprunt d’identité ASP.NET (https://go.microsoft.com/fwlink/?linkid=115573&clcid=0x40C) .

  • Authentification NTLM

    Cette méthode est destinée aux serveurs Windows qui n’exécutent pas Active Directory sur un contrôleur de domaine. L’authentification NTLM est requise pour les réseaux qui reçoivent des demandes d’authentification de la part d’ordinateurs clients ne prenant pas en charge l’authentification Kerberos. NTLM est un protocole sécurisé qui prend en charge le chiffrement des informations d’identification utilisateur et la transmission sur un réseau. Dans le cadre de l’authentification NTLM, les noms d’utilisateurs et les mots de passe sont chiffrés avant d’être envoyés sur le réseau. Choisissez l’authentification NTLM si le serveur du réseau reçoit des requêtes d’ordinateurs clients qui ne prennent pas en charge l’authentification Kerberos. NTLM est le protocole d’authentification qui est utilisé dans Windows NT Server et dans les environnements de groupe de travail Windows 2000 Server, ainsi que dans de nombreux déploiements Active Directory. NTLM est utilisé dans les environnements de domaines Windows 2000 Active Directory mixtes qui doivent authentifier les systèmes Windows NT. Lorsque Windows 2000 Server passe en mode natif, dans lequel il n’existe aucun contrôleur de domaine Windows NT de niveau inférieur, NTLM est désactivé. Kerberos devient alors le protocole d’authentification par défaut pour l’entreprise.

Fournisseur d’authentification par formulaire

Le fournisseur d’authentification par formulaire prend en charge l’authentification par rapport à des informations d’identification stockées dans Active Directory, dans une base de données telle qu’une base de données SQL Server ou dans un magasin de données LDAP tel que Novell eDirectory, NDS (Novell Directory Services) ou Sun ONE. L’authentification par formulaire permet l’authentification de l’utilisateur basée sur la validation de l’entrée des informations d’identification à partir d’un formulaire d’ouverture de session. Les demandes non authentifiées sont redirigées vers une page d’ouverture de session, dans laquelle l’utilisateur doit fournir des informations d’identification valides et envoyer le formulaire. Si la demande peut être authentifiée, le système émet un cookie qui contient une clé pour rétablir l’identité pour les demandes suivantes.

Fournisseur d’authentification unique Web

L’authentification unique Web est également appelée authentification déléguée ou authentification fédérée, dans la mesure où elle prend en charge une communication sécurisée au-delà des limites du réseau.

L’authentification unique est une méthode d’authentification qui permet d’accéder à plusieurs ressources sécurisées après une authentification unique réussie des informations d’identification utilisateur. Il existe plusieurs formes d’implémentation de l’authentification unique. L’authentification unique Web prend en charge une communication sécurisée au-delà des limites du réseau en permettant aux utilisateurs qui ont été authentifiés dans une organisation d’accéder aux applications Web dans une autre organisation. Les services ADFS (Active Directory Federation Services) prennent en charge l’authentification unique Web. Dans un scénario ADFS, deux organisations peuvent créer une relation d’approbation de fédération permettant aux utilisateurs dans une organisation d’accéder aux applications Web contrôlées par une autre organisation. Pour des informations sur la configuration de l’authentification unique Web à l’aide des services ADFS, voir Configurer l’authentification unique Web à l’aide des services ADFS (Office SharePoint Server). Pour des informations sur la façon d’effectuer cette procédure au moyen de l’outil en ligne de commande Stsadm, voir Authentification : opération Stsadm (Office SharePoint Server).

Télécharger ce livre

Cette rubrique est incluse dans le livre à télécharger suivant pour une lecture et une impression plus faciles :

Consultez la liste des livres disponibles dans la Bibliothèque TechNet pour Office SharePoint Server.