Planifier les méthodes d’authentification utilisateur dans SharePoint ServerPlan for user authentication methods in SharePoint Server

S'applique à: oui2013 oui2016 oui2019 nonSharePoint OnlineAPPLIES TO: yes2013 yes2016 yes2019 noSharePoint Online

Découvrez les types et les méthodes d’authentifications utilisateur pris en charge par SharePoint Server et comment déterminer ceux à utiliser pour les applications et les zones web.Learn the user authentication types and methods that are supported by SharePoint Server and how to determine which ones to use for web applications and zones.

IntroductionIntroduction

L'authentification d'utilisateur est la validation de l'identité de l'utilisateur auprès d'un fournisseur d'authentification, c'est-à-dire un répertoire ou une base de données qui contient les informations d'identification de l'utilisateur et permet de confirmer qu'elles ont été entrées correctement. Services de domaine Active Directory (AD DS), par exemple, est un fournisseur d'authentification. D'autres termes sont employés pour désigner un fournisseur d'authentification, comme annuaire d'utilisateurs et magasin d'attributs.User authentication is the validation of a user's identity against an authentication provider, which is a directory or database that contains the user's credentials and can confirm the user submitted them correctly. An example of an authentication provider is Active Directory Domain Services (AD DS). Other terms for authentication provider are user directory and attribute store.

Une méthode d'authentification est un échange spécifique d'informations d'identification des comptes et d'autres informations qui prouvent l'identité d'un utilisateur. Le résultat de la méthode d'authentification permet de prouver, généralement sous la forme d'un jeton contenant des revendications, qu'un fournisseur d'authentification a authentifié un utilisateur.An authentication method is a specific exchange of account credentials and other information that assert a user's identity. The result of the authentication method is proof, typically in the form of a token that contains claims, that an authentication provider has authenticated a user.

Un type d'authentification est une méthode spécifique de validation des informations d'identification auprès d'un ou de plusieurs fournisseurs d'authentification, parfois selon un protocole standard de l'industrie. Un type d'authentification peut utiliser plusieurs méthodes d'authentification.An authentication type is a specific way of validating credentials against one or more authentication providers, sometimes using an industry standard protocol. An authentication type can use multiple authentication methods.

Une fois l'identité d'un utilisateur validée, le processus d'autorisation détermine à quels sites, contenus et autres fonctionnalités l'utilisateur peut accéder.After a user's identity is validated, the authorization process determines which sites, content, and other features the user can access.

Votre planification des types et des méthodes d'authentification des utilisateurs doit déterminer les points suivants :Your planning for user authentication types and methods should determine the following:

  • Types et méthodes d'authentification des utilisateurs pour chaque zone et application WebThe user authentication types and methods for each web application and zone

  • Infrastructure d'authentification nécessaire pour prendre en charge les types et méthodes d'authentifications déterminésThe authentication infrastructure needed to support the determined authentication types and methods

    Notes

    L'authentification Windows en mode classique n'est plus prise en charge dans SharePoint Server 2016.Windows classic mode authentication is no longer supported in SharePoint Server 2016.

Authentification basée sur les revendicationsClaims-based authentication

L'identité des utilisateurs dans AD DS est basée sur un compte d'utilisateur. Pour que l'authentification aboutisse, l'utilisateur fournit le nom de compte et la preuve de connaissance du mot de passe. Pour déterminer l'accès aux ressources, les applications doivent éventuellement demander les attributs de compte et d'autres informations au service AD DS, par exemple l'appartenance au groupe ou le rôle sur le réseau. Cette méthode fonctionne dans les environnements Windows, mais n'est pas adaptée aux fournisseurs d'authentification tiers ni aux environnements multifournisseurs qui prennent en charge les modèles d'informatique basés sur Internet, les partenaires ou le nuage.User identity in AD DS is based on a user account. For successful authentication, the user provides the account name and proof of knowledge of the password. To determine access to resources, applications might have to query AD DS for account attributes and other information, such as group membership or role on the network. While this works well for Windows environments, it does not scale out to third-party authentication providers and multi-vendor environments that support Internet, partner, or cloud-based computing models.

Avec les identités basées sur les revendications, les utilisateurs obtiennent un jeton de sécurité signé numériquement par un fournisseur d'identité approuvé. Le jeton contient un ensemble de revendications, chacune représentant un élément spécifique des données concernant un utilisateur, par exemple son nom, ses appartenances à des groupes et son rôle sur le réseau. L'authentification basée sur les revendications est l'authentification d'utilisateur qui repose sur les technologies et l'infrastructure d'identité basée sur les revendications. Les applications qui prennent en charge l'authentification basée sur les revendications obtiennent un jeton de sécurité d'un utilisateur, au lieu d'informations d'identification, et utilisent les informations des revendications pour déterminer l'accès aux ressources. Aucune demande séparée à un service d'annuaire tel qu'AD DS n'est nécessaire.With claims-based identities, a user obtains a digitally signed security token from a commonly trusted identity provider. The token contains a set of claims. Each claim represents a specific item of data about a user such as his or her name, group memberships, and role on the network. Claims-based authentication is user authentication that uses claims-based identity technologies and infrastructure. Applications that support claims-based authentication obtain a security token from a user, rather than credentials, and use the information within the claims to determine access to resources. No separate query to a directory service such as AD DS is needed.

L'authentification basée sur les revendications dans Windows repose sur Windows Identity Foundation (WIF), qui est un ensemble de classes .NET Framework servant à implémenter l'identité basée sur les revendications. L'authentification basée sur les revendications repose sur des normes telles que WS-Federation et WS-Trust, et sur des protocoles tels que SAML (Security Assertion Markup Language).Claims-based authentication in Windows is built on Windows Identity Foundation (WIF), which is a set of .NET Framework classes that is used to implement claims-based identity. Claims-based authentication relies on standards such as WS-Federation, WS-Trust, and protocols such as the Security Assertion Markup Language (SAML).

Pour plus d'informations sur l'authentification basée sur les revendications, voir les ressources suivantes :For more information about claims-based authentication, see the following resources:

En raison de l'utilisation répandue de l'authentification basée sur les revendications pour l'authentification utilisateur, l'authentification de serveur à serveur et l'authentification d'application, nous vous recommandons d'utiliser l'authentification basée sur les revendications pour l'ensemble des applications et des zones web d'une batterie de serveurs SharePoint Server. Pour plus d'informations, consultez la rubrique Planifier l'authentification de serveur à serveur dans SharePoint Server. Quand vous utilisez l'authentification basée sur les revendications, toutes les méthodes d'authentification sont disponibles pour vos applications web et vous pouvez bénéficier de nouvelles fonctionnalités et de nouveaux scénarios dans SharePoint Server qui utilisent l'authentification de serveur à serveur et l'authentification d'application.Due to the widespread use of claim-based authentication for user authentication, server-to-server authentication, and app authentication, we recommend claims-based authentication for all web applications and zones of a SharePoint Server farm. For more information, see Plan for server-to-server authentication in SharePoint Server. When you use claims-based authentication, all supported authentication methods are available for your web applications and you can take advantage of new features and scenarios in SharePoint Server that use server-to-server authentication and app authentication.

Pour l’authentification basée sur les revendications, SharePoint Server modifie automatiquement tous les comptes d’utilisateur en identités de revendications, ce qui génère un jeton de sécurité (également appelé jeton de revendication) pour chaque utilisateur. Le jeton de revendication contient les revendications liées à l’utilisateur. Les comptes Windows sont convertis en revendications Windows. Les utilisateurs d’une appartenance basée sur les formulaires sont convertis en revendications d’authentification basée sur les formulaires. SharePoint Server peut utiliser les revendications incluses dans les jetons SAML. Par ailleurs, les développeurs et les administrateurs SharePoint peuvent ajouter des revendications supplémentaires aux jetons utilisateur. Par exemple, les comptes d’utilisateur Windows et les comptes d’utilisateur basés sur les formulaires peuvent obtenir des revendications supplémentaires utilisées par SharePoint Server.For claims-based authentication, SharePoint Server automatically changes all user accounts to claims identities. This results in a security token (also known as a claims token) for each user. The claims token contains the claims pertaining to the user. Windows accounts are converted into Windows claims. Forms-based membership users are transformed into forms-based authentication claims. SharePoint Server can use claims that are included in SAML-based tokens. Additionally, SharePoint developers and administrators can augment user tokens with additional claims. For example, Windows user accounts and forms-based accounts can be augmented with additional claims that are used by SharePoint Server.

Il n'est pas nécessaire d'être architecte de revendications pour utiliser l'authentification basée sur les revendications dans SharePoint Server. Toutefois, l'implémentation de l'authentification basée sur les jetons SAML nécessite une coordination avec les administrateurs de votre environnement basé sur les revendications, comme décrit dans la section Planifier l'authentification basée sur un jeton SAML.You do not have to be a claims architect to use claims-based authentication in SharePoint Server. However, implementing SAML token-based authentication requires coordination with administrators of your claims-based environment, as described in Plan for SAML token-based authentication.

Authentification classique dans SharePoint Server 2013Classic mode authentication in SharePoint Server 2013

Dans SharePoint 2013, quand vous créez une application web dans l'Administration centrale, vous pouvez uniquement spécifier les types et les méthodes d'authentification pour l'authentification basée sur les revendications. Dans des versions précédentes de SharePoint, vous pouviez également configurer l'authentification en mode classique pour les applications web dans l'Administration centrale. L'authentification en mode classique utilise l'authentification Windows et SharePoint 2013 traite les comptes d'utilisateur comme des comptes AD DS.In SharePoint 2013, when you create a web application in Central Administration, you can only specify authentication types and methods for claims-based authentication. In previous versions of SharePoint, you could also configure classic mode authentication for web applications in Central Administration. Classic mode authentication uses Windows authentication and SharePoint 2013 treats the user accounts as AD DS accounts.

Pour configurer une application web pour utiliser l'authentification en mode classique, vous devez utiliser la cmdlet New-SPWebApplication PowerShell pour la créer. Les applications web Produits SharePoint 2010 qui sont configurées pour l'authentification en mode classique conservent leurs paramètres d'authentification à la suite d'une mise à niveau vers SharePoint 2013. Nous vous recommandons toutefois de transférer vos applications web vers l'authentification basée sur les revendications avant d'effectuer la mise à niveau vers SharePoint 2013.To configure a web application to use classic mode authentication, you must use the New-SPWebApplication PowerShell cmdlet to create it. SharePoint 2010 Products web applications that are configured for classic mode authentication retain their authentication settings when you upgrade to SharePoint 2013. However, we recommend that you migrate your web applications to claims-based authentication before upgrading to SharePoint 2013.

Une batterie de serveurs SharePoint 2013 peut inclure une combinaison d'applications web qui utilisent les deux modes. Certains services ne font pas la différence entre les comptes d'utilisateur Windows traditionnels et les comptes basés sur les revendications Windows.A SharePoint 2013 farm can include a mix of web applications that use both modes. Some services do not differentiate between user accounts that are traditional Windows accounts and Windows claims accounts.

Pour plus d'informations sur la migration avant la mise à niveau, voir Migrer de l'authentification en mode classique vers l'authentification basée sur les revendications.For more information about migrating before upgrading, see Migrate from classic-mode to claims-based authentication.

Pour plus d'informations sur la migration après la mise à niveau, voir Migrate from classic-mode to claims-based authentication in SharePoint Server.For more information about migrating after upgrading, see Migrate from classic-mode to claims-based authentication in SharePoint Server.

Pour plus d'informations sur la création d'applications web qui utilisent l'authentification en mode classique dans SharePoint 2013, voir Créer des applications web qui utilisent l'authentification en mode classique dans SharePoint Server. Notez que vous ne pouvez pas transférer une application web qui utilise l'authentification basée sur les revendications vers l'authentification en mode classique.For information about how to create web applications that use classic mode authentication in SharePoint 2013, see Create web applications that use classic mode authentication in SharePoint Server. Note that you cannot migrate a web application that uses claims-based authentication to use classic mode authentication.

Important

Office Online ne peut être utilisé que par des applications web SharePoint 2013 qui utilisent une authentification basée sur les revendications. Le rendu et la modification dans Office Online ne fonctionneront pas sur des applications web SharePoint 2013 qui utilisent le mode d'authentification classique. Si vous migrez des applications web SharePoint 2010 qui utilisent le mode d'authentification classique vers SharePoint 2013, vous devez les migrer vers une authentification basée sur les revendications pour leur permettre de fonctionner dans Office Online.Office Online can be used only by SharePoint 2013 web applications that use claims-based authentication. Office Online rendering and editing will not work on SharePoint 2013 web applications that use classic mode authentication. If you migrate SharePoint 2010 web applications that use classic mode authentication to SharePoint 2013, you must migrate them to claims-based authentication to allow them to work with Office Online.

Types et méthodes d’authentification pris en chargeSupported authentication types and methods

SharePoint Server prend en charge différents fournisseurs et méthodes d’authentification pour les types d’authentification suivants :SharePoint Server supports a variety of authentication methods and authentication providers for the following authentication types:

  • Authentification WindowsWindows authentication

  • Authentification basée sur les formulairesForms-based authentication

  • Authentification basée sur les jetons SAMLSAML token-based authentication

Authentification WindowsWindows authentication

Le type d’authentification Windows bénéficie de votre fournisseur d’authentification Windows actuelle (AD DS) et des protocoles d’authentification utilisés par un environnement de domaine Windows pour valider les informations d’identification des clients qui se connectent. Les méthodes d’authentification Windows, qui sont utilisées par l’authentification basée sur les revendications, incluent les éléments suivants :The Windows authentication type takes advantage of your existing Windows authentication provider (AD DS) and the authentication protocols that a Windows domain environment uses to validate the credentials of connecting clients. Windows authentication method, which is used by both claims-based authentication include the following:

  • NTLMNTLM

  • KerberosKerberos

  • DigestDigest

  • De baseBasic

Pour plus d'informations, voir Planifier l'authentification Windows dans cet article.For more information, see Plan for Windows authentication in this article.

Regardez la vidéo sur l'authentification basée sur les revendications Windows dans SharePoint 2013 et SharePoint Server 2016Watch the Windows claims authentication in SharePoint 2013 and SharePoint Server 2016 video

Même s’il n’est pas un type d’authentification Windows, SharePoint Server prend également en charge l’authentification anonyme. Les utilisateurs peuvent accéder au contenu SharePoint sans valider leurs informations d’identification. L’authentification anonyme est désactivée par défaut. Elle sert généralement quand vous utilisez SharePoint Server pour publier du contenu qui ne nécessite pas de sécurité et est disponible pour tous les utilisateurs, par exemple un site web public.Although not a Windows authentication type, SharePoint Server also supports anonymous authentication. Users can access SharePoint content without validating their credentials. Anonymous authentication is disabled by default. You typically use anonymous authentication when you use SharePoint Server to publish content that does not require security and is available for all users, such as a public Internet website.

Notez qu'en plus de l'activation de l'authentification anonyme, vous devez configurer l'accès anonyme (autorisations) aux sites et aux ressources des sites.Note that in addition to enabling anonymous authentication, you must also configure anonymous access (permissions) on sites and site resources.

Notes

Pour les sites web Internet Information Services (IIS) créés par SharePoint pour les applications web, les méthodes d'authentification anonyme et d'authentification par formulaires sont toujours activées, même lorsque les paramètres SharePoint pour l'authentification anonyme et l'authentification par formulaires sont désactivés. Cette configuration est intentionnelle et la désactivation de l'authentification anonyme ou par formulaires directement dans les paramètres IIS génèrera des erreurs dans le site SharePoint.Internet Information Services (IIS) websites that are created by SharePoint for serving web applications always have the Anonymous Authentication and Forms Authentication methods enabled, even when the SharePoint setting for Anonymous and Forms Authentication are disabled. This is intentional and disabling Anonymous or Forms Authentication directly in the IIS settings will result in errors in the SharePoint site.

Authentification basée sur les formulairesForms-based authentication

L’authentification basée sur les formulaires est un système de gestion d’identité basée sur les formulaires qui repose sur l’authentification par fournisseur de rôles et d’appartenance ASP.NET. L’authentification basée sur les formulaires peut être utilisée sur des informations d’identification stockées chez un fournisseur d’authentification, par exemple :Forms-based authentication is a claims-based identity management system that is based on ASP.NET membership and role provider authentication. Forms-based authentication can be used against credentials that are stored in an authentication provider, such as the following:

  • AD DS ;AD DS

  • une base de données telle que SQL Server ;A database such as a SQL Server database

  • un magasin de données LDAP (Lightweight Directory Access Protocol) tel que Novell eDirectory, NDS (Novell Directory Services) ou Sun ONE.An Lightweight Directory Access Protocol (LDAP) data store such as Novell eDirectory, Novell Directory Services (NDS), or Sun ONE

L'authentification basée sur les formulaires valide les utilisateurs en fonction des informations d'identification qu'ils ont entrées dans un formulaire d'ouverture de session (généralement, une page web). Les demandes non authentifiées sont redirigées vers une page de connexion dans laquelle l'utilisateur doit fournir des informations d'identification valides et envoyer le formulaire. Le système émet un cookie pour les demandes authentifiées qui contiennent une clé permettant de rétablir l'identité pour les demandes suivantes.Forms-based authentication validates users based on credentials that users type in a logon form (typically a web page). Unauthenticated requests are redirected to a logon page, where a user must provide valid credentials and submit the form. The system issues a cookie for authenticated requests that contains a key for reestablishing the identity for subsequent requests.

Regardez la vidéo sur l’authentification basée sur les formulaires (revendications) dans SharePoint 2013 et SharePoint Server 2016Watch the forms-based claims authentication in SharePoint 2013 and SharePoint Server 2016 video

Notes

Avec l’authentification basée sur les formulaires, les informations d’identification des utilisateurs sont envoyées sous forme de texte brut. Vous ne devez donc pas utiliser ce type d’authentification, sauf si vous utilisez le chiffrement SSL (Secure Sockets Layer) pour chiffrer le trafic du site web.With forms-based authentication, the user account credentials are sent as plaintext. Therefore, you should not use forms-based authentication unless you are also using Secure Sockets Layer (SSL) to encrypt the website traffic.

Pour plus d'informations, voir Planifier l'authentification basée sur les formulaires.For more information, see Plan for forms-based authentication.

Authentification basée sur un jeton SAMLSAML token-based authentication

L’authentification basée sur les jetons SAML dans SharePoint Server utilise le protocole SAML 1.1 et la norme WS-F PRP (WS-Federation Passive Requestor Profile). Elle nécessite une coordination avec les administrateurs d’un environnement basé sur les revendications, qu’il s’agisse de votre propre environnement interne ou d’un environnement partenaire. Si vous utilisez les services AD FS (Active Directory Federation Services) 2.0, votre environnement est basé sur les revendications.SAML token-based authentication in SharePoint Server uses the SAML 1.1 protocol and the WS-Federation Passive Requestor Profile (WS-F PRP). It requires coordination with administrators of a claims-based environment, whether it is your own internal environment or a partner environment. If you use Active Directory Federation Services (AD FS) 2.0, you have a SAML token-based authentication environment.

Un environnement d'authentification basée sur les jetons SAML inclut un fournisseur d'identité IP-STS (identity provider security token service). L'IP-STS émet des jetons SAML pour le compte des utilisateurs ayant leurs comptes chez le fournisseur d'authentification associé. Les jetons peuvent inclure un nombre indéfini de revendications sur un utilisateur, par exemple un nom d'utilisateur et les groupes auxquels il appartient. Un serveur AD FS 2.0 est un exemple d'IP-STS.A SAML token-based authentication environment includes an identity provider security token service (IP-STS). The IP-STS issues SAML tokens on behalf of users whose accounts are included in the associated authentication provider. Tokens can include any number of claims about a user, such as a user name and the groups to which the user belongs. An AD FS 2.0 server is an example of an IP-STS.

SharePoint Server exploite les revendications incluses dans les jetons émis par un IP-STS pour les utilisateurs autorisés. Dans les environnements de revendications, une application qui accepte les jetons SAML porte le nom de STS de partie de confiance (RP-STS). Une application de partie de confiance reçoit le jeton SAML et utilise les revendications qu’il contient pour décider si le client peut accéder à la ressource demandée. Dans SharePoint Server, chaque application web configurée pour utiliser un fournisseur SAML est ajoutée au serveur IP-STS en tant qu’entrée RP-STS distincte. Une batterie SharePoint peut comprendre plusieurs entrées RP-STS dans l’IP-STS.SharePoint Server takes advantage of claims that are included in tokens that an IP-STS issues to authorized users. In claims environments, an application that accepts SAML tokens is known as a relying party STS (RP-STS). A relying party application receives the SAML token and uses the claims inside to decide whether to grant the client access to the requested resource. In SharePoint Server, each web application that is configured to use a SAML provider is added to the IP-STS server as a separate RP-STS entry. A SharePoint farm can represent multiple RP-STS entries in the IP-STS.

Regardez la vidéo sur l’authentification basée sur les revendications SAML dans SharePoint 2013 et SharePoint Server 2016Watch the SAML-based claims authentication in SharePoint 2013 and SharePoint Server 2016 video

L'ensemble des fournisseurs d'authentification pour l'authentification basée sur un jeton SAML dépend de l'IP-STS de votre environnement de revendications. Si vous utilisez AD FS 2.0, les fournisseurs d'authentification (connus comme magasins d'attributs pour AD FS 2.0) peuvent inclure les éléments suivants :The set of authentication providers for SAML token-based authentication depends on the IP-STS in your claims environment. If you use AD FS 2.0, authentication providers (known as attribute stores for AD FS 2.0) can include the following:

  • Windows Server 2003 Active Directory et AD DS dans Windows Server 2008 ;Windows Server 2003 Active Directory and AD DS in Windows Server 2008

  • toutes les éditions de SQL Server 2005 et de SQL Server 2008 ;All editions of SQL Server 2005 and SQL Server 2008

  • des magasins d'attributs personnalisés.Custom attribute stores

Pour plus d'informations, voir Planifier l'authentification basée sur un jeton SAML.For more information, see Plan for SAML token-based authentication.

Choix des types d’authentification pour les environnements LDAPChoosing authentication types for LDAP environments

L’authentification basée sur les formulaires ou sur un jeton SAML peut utiliser les environnements LDAP. Vous devez utiliser le type d’authentification qui correspond à votre environnement LDAP actuel. Si vous n’en possédez pas encore, nous vous recommandons d’utiliser l’authentification basée sur les formulaires, car elle est moins complexe. Cependant, si votre environnement d’authentification prend déjà en charge WS-Federation 1.1 et SAML 1.1, nous vous conseillons d’utiliser SAML. SharePoint Server intègre un fournisseur LDAP.Forms-based authentication or SAML token-based authentication can use LDAP environments. You should use the authentication type that matches your current LDAP environment. If you do not already have an LDAP environment, we recommend that you use forms-based authentication because it is less complex. However, if your authentication environment already supports WS-Federation 1.1 and SAML 1.1, then we recommend SAML. SharePoint Server has a built-in LDAP provider.

Planifier l’authentification WindowsPlan for Windows authentication

Le processus de planification et d'implémentation des méthodes d'authentification Windows est semblable pour l'authentification basée sur les revendications. L'authentification basée sur les revendications pour une application web ne complique pas l'implémentation des méthodes d'authentification Windows. Cette section présente une synthèse de la planification des méthodes d'authentification Windows.The process of planning and implementing Windows authentication methods is similar for claims-based authentication. Claims-based authentication for a web application does not increase the complexity of implementing Windows authentication methods. This section summarizes the planning for the Windows authentication methods.

NTLM et protocole KerberosNTLM and the Kerberos protocol

NTLM et le protocole Kerberos sont des méthodes d’authentification Windows intégrées, qui permettent aux utilisateurs de procéder à l’authentification de façon transparente sans demande d’informations d’identification. Par exemple :Both NTLM and the Kerberos protocol are Integrated Windows authentication methods, which let users seamlessly authenticate without prompts for credentials. For example:

  • Les utilisateurs qui accèdent aux sites SharePoint à partir d'Internet Explorer utilisent les informations d'identification sous lesquelles s'exécute le processus Internet Explorer. Par défaut, il s'agit des informations d'identification employées par l'utilisateur pour ouvrir une session sur l'ordinateur.Users who access SharePoint sites from Internet Explorer use the credentials under which the Internet Explorer process is running to authenticate. By default, these credentials are the credentials that the user used to log on to the computer.

  • Les services ou applications qui utilisent les méthodes d'authentification Windows intégrées pour accéder aux ressources SharePoint tentent de s'authentifier à l'aide des informations d'identification du thread en cours d'exécution qui, par défaut, correspondent à l'identité du processus.Services or applications that use Integrated Windows authentication methods to access SharePoint resources attempt to use the credentials of the running thread, which by default is the identity of the process, to authenticate.

NTLM est la forme d'authentification Windows la plus simple à implémenter et ne demande généralement aucune configuration supplémentaire de l'infrastructure d'authentification. Il suffit de sélectionner cette option quand vous créez ou configurez l'application web.NTLM is the simplest form of Windows authentication to implement and typically requires no additional configuration of authentication infrastructure. Simply select this option when you create or configure the web application.

Le protocole Kerberos prend en charge l’authentification par ticket. Son utilisation nécessite une configuration supplémentaire de l’environnement. 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. Pour configurer le protocole Kerberos, vous devez configurer des noms de principaux du service (SPN) dans les services AD DS avant d’installer SharePoint Server.The Kerberos protocol supports ticketing authentication. Use of the Kerberos protocol requires additional configuration of the environment. To enable Kerberos authentication, the client and server computers must have a trusted connection to the domain Key Distribution Center (KDC). Configuring the Kerberos protocol involves setting up service principal names (SPNs) in AD DS before you install SharePoint Server.

Voici les avantages de l'authentification Kerberos :The reasons why you should consider Kerberos authentication are as follows:

  • Le protocole Kerberos est le protocole d'authentification Windows intégrée le plus fort et prend en charge des fonctionnalités avancées de sécurité, notamment le chiffrement AES (Advanced Encryption Standard) et l'authentification mutuelle de clients et de serveurs.The Kerberos protocol is the strongest Integrated Windows authentication protocol, and supports advanced security features including Advanced Encryption Standard (AES) encryption and mutual authentication of clients and servers.

  • Le protocole Kerberos autorise la délégation des informations d'identification du client.The Kerberos protocol allows for delegation of client credentials.

  • Parmi les méthodes d'authentification sécurisée disponibles, Kerberos est celle qui nécessite le moins de trafic réseau vers les contrôleurs de domaine AD DS. Suivant les scénarios, Kerberos peut réduire la latence des pages ou augmenter le nombre de pages qu'un serveur web frontal peut servir. Kerberos peut également réduire la charge sur les contrôleurs de domaine.Of the available secure authentication methods, Kerberos requires the least amount of network traffic to AD DS domain controllers. Kerberos can reduce page latency in certain scenarios, or increase the number of pages that a front-end web server can serve in certain scenarios. Kerberos can also reduce the load on domain controllers.

  • Le protocole Kerberos est ouvert et pris en charge par un grand nombre de plateformes et de fournisseurs.The Kerberos protocol is an open protocol that many platforms and vendors support.

Voici les inconvénients de l'authentification Kerberos :The reasons why Kerberos authentication might not be appropriate are as follows:

  • Comparée à d'autres méthodes, l'authentification Kerberos nécessite une configuration supplémentaire de l'infrastructure et de l'environnement pour fonctionner correctement. Dans de nombreux cas, il est nécessaire de détenir l'autorisation d'administrateur de domaine pour configurer le protocole Kerberos. L'authentification Kerberos peut être difficile à configurer et à gérer. Une mauvaise configuration de Kerberos peut entraîner l'échec de l'authentification auprès de vos sites.Kerberos authentication requires more configuration of infrastructure and environment than other authentication methods to function correctly. In many cases, domain administrator permission is required to configure the Kerberos protocol. Kerberos authentication can be difficult to set up and manage. Misconfiguring Kerberos can prevent successful authentication to your sites.

  • L'authentification Kerberos nécessite que l'ordinateur client dispose d'une connexion à un centre de distribution de clés (KDC) et à un contrôleur de domaine des services de domaine Active Directory (AD DS, Active Directory Domain Services). Dans un déploiement Windows, le KDC est un contrôleur de domaine AD DS. Bien qu'il s'agisse d'une configuration réseau courante dans l'intranet d'une organisation, les déploiements exposés à Internet ne sont généralement pas configurés de la sorte.Kerberos authentication requires client computer connectivity to a KDC and to an AD DS domain controller. In a Windows deployment, the KDC is an AD DS domain controller. While this is a common network configuration on an organization intranet, Internet-facing deployments are typically not configured in this manner.

Les étapes suivantes résument la configuration de l'authentification Kerberos :The following steps summarize configuring Kerberos authentication:

  1. Configurez l'authentification Kerberos pour les communications SQL Server en créant des SPN dans AD DS pour le compte de service SQL Server.Configure Kerberos authentication for SQL Server communications by creating SPNs in AD DS for the SQL Server service account.

  2. Créez des SPN pour les applications Web qui utiliseront l'authentification Kerberos.Create SPNs for web applications that will use Kerberos authentication.

  3. Installez la batterie de serveurs SharePoint Server.Install the SharePoint Server farm.

  4. Configurez des services particuliers dans la batterie de façon à utiliser des comptes spécifiques.Configure specific services within the farm to use specific accounts.

  5. Créez les applications Web qui utiliseront l’authentification Kerberos.Create the web applications that will use Kerberos authentication.

Digest et de baseDigest and Basic

Avec la méthode d'authentification Digest, les informations d'identification de compte d'utilisateur sont envoyées sous forme de résumé de message MD5 au service Internet Information Services (IIS) sur le serveur web qui héberge l'application ou la zone web. Avec la méthode d'authentification de base, les informations de compte d'utilisateur sont envoyées sous forme de texte brut. Vous ne devez donc pas utiliser la méthode d'authentification de base, sauf si vous utilisez le chiffrement SSL (Secure Sockets Layer) pour chiffrer le trafic du site web.With the Digest authentication method, the user account credentials are sent as an MD5 message digest to the Internet Information Services (IIS) service on the web server that hosts the web application or zone. With the Basic authentication method, the user account credentials are sent as plaintext. Therefore, you should not use the Basic authentication method unless you are also using SSL to encrypt the website traffic.

Vous devrez peut-être utiliser ces anciennes méthodes d'authentification si votre environnement utilise des navigateurs ou des services web qui prennent en charge uniquement l'authentification Digest ou de base des sites web.You might have to use these older authentication methods if your environment uses web browsers or services that only support Digest or Basic authentication to websites.

Contrairement aux méthodes d'authentification NTLM, Kerberos et anonyme, vous devez configurer les méthodes Digest et de base à partir des propriétés du site web qui correspond à l'application ou la zone web du logiciel enfichable Internet Information Services (IIS).Unlike the NTLM, Kerberos, and Anonymous authentication methods, you configure Digest and Basic authentication methods from the properties of the web site that corresponds to the web application or zone in the Internet Information Services (IIS) snap-in.

Si vous utilisez l'authentification basée sur les revendications, reportez-vous aux articles suivants :If you are using claims-based authentication, see the following:

Planifier l’authentification basée sur les formulairesPlan for forms-based authentication

Pour utiliser l'authentification basée sur les formulaires pour authentifier les utilisateurs dans un système de gestion d'identité qui n'est pas basé sur Windows ou qui est externe, vous devez enregistrer le fournisseur d'appartenances et le gestionnaire de rôles dans le fichier Web.config. SharePoint Server utilise l'interface du gestionnaire de rôles ASP.NET standard pour collecter des informations de groupe sur l'utilisateur actuel. Chaque rôle ASP.NET est traité comme un groupe de domaines par le processus d'autorisation dans SharePoint Server. Pour enregistrer les gestionnaires de rôles dans le fichier Web.config, procédez exactement comme pour enregistrer les fournisseurs d'appartenances pour l'authentification.To use forms-based authentication to authenticate users against an identity management system that is not based on Windows or that is external, you must register the membership provider and role manager in the Web.config file. SharePoint Server uses the standard ASP.NET role manager interface to collect group information about the current user. Each ASP.NET role is treated as a domain group by the authorization process in SharePoint Server. You register role managers in the Web.config file exactly as you register membership providers for authentication.

Si vous souhaitez gérer les utilisateurs d'appartenances (membership users) ou les rôles à partir du site web Administration centrale, vous devez inscrire le fournisseur d'appartenances et le gestionnaire de rôles dans le fichier Web.config du site web Administration centrale. Vous devez également inscrire le fournisseur d'appartenances et le gestionnaire de rôles dans le fichier Web.config de l'application web qui héberge le contenu.If you want to manage membership users or roles from the Central Administration website, you must register the membership provider and the role manager in the Web.config file for the Central Administration website. You must also register the membership provider and the role manager in the Web.config file for the web application that hosts the content.

Pour obtenir les étapes détaillées de configuration de l’authentification basée sur les formulaires, reportez-vous à l’article Configurer l’authentification par formulaires pour une application web basée sur les revendications dans SharePoint ServerFor detailed steps to configure forms-based authentication, see Configure forms-based authentication for a claims-based web application in SharePoint Server

Planifier l’authentification basée sur un jeton SAMLPlan for SAML token-based authentication

L'architecture d'implémentation des fournisseurs basés sur un jeton SAML inclut les composants suivants :The architecture for implementing SAML token-based providers includes the following components:

  • Service d'émission de jeton de sécurité SharePoint Ce service crée les jetons SAML utilisés par la batterie. Il est créé et démarré automatiquement sur tous les serveurs d'une batterie de serveurs. On l'utilise pour les communications entre les batteries, car toutes les communications entre les batteries utilisent l'authentification basée sur les revendications. Ce service est également utilisé pour les méthodes d'authentification qui sont mises en œuvre pour les applications web qui utilisent l'authentification basée sur les revendications, notamment l'authentification Windows, l'authentification basée sur les formulaires et l'authentification basée sur le jeton SAML.SharePoint Security Token Service This service creates the SAML tokens that the farm uses. The service is automatically created and started on all servers in a server farm. The service is used for inter-farm communication because all inter-farm communication uses claims-based authentication. This service is also used for authentication methods that are implemented for web applications that use claims-based authentication. This includes Windows authentication, forms-based authentication, and SAML token-based authentication.

  • Certificat de signature de jetons (ImportTrustCertificate) Il s'agit du certificat exporté à partir d'un service IP-STS, puis copié sur un serveur de la batterie et ajouté à la liste Autorités racines approuvées de la batterie de serveurs. Quand vous avez utilisé ce certificat pour créer un SPTrustedIdentityTokenIssuer, vous ne pouvez pas l'utiliser pour en créer un autre. Pour utiliser le certificat pour créer un autre SPTrustedIdentityTokenIssuer, vous devez d'abord supprimer celui qui existe. Avant cela, vous devez le dissocier de toutes les applications web susceptibles de l'utiliser.Token-signing certificate (ImportTrustCertificate) This is the certificate that you export from an IP-STS and then copy to one server in the farm and add it to the farm's Trusted Root Authority list. Once you use this certificate to create an SPTrustedIdentityTokenIssuer, you cannot use it to create another one. To use the certificate to create a different SPTrustedIdentityTokenIssuer, you must delete the existing one first. Before you delete an existing one, you must disassociate it from all web applications that may be using it.

  • Revendication d'identité La revendication d'identité est la revendication tirée d'un jeton SAML qui constitue l'identificateur unique de l'utilisateur. Seul le propriétaire du service IP-STS connaît la valeur dans le jeton qui est unique pour chaque utilisateur. La revendication d'identité est créée en tant que mappage de revendications ordinaire lors du mappage de toutes les revendications souhaitées. La revendication qui sert de revendication d'identité est déclarée lors de la création du SPTrustedIdentityTokenIssuer.Identity claim The identity claim is the claim from a SAML token that is the unique identifier of the user. Only the owner of the IP-STS knows which value in the token will always be unique for each user. The identity claim is created as a regular claims mapping during the mapping of all desired claims. The claim that serves as the identity claim is declared when the SPTrustedIdentityTokenIssuer is created.

  • Autres revendications Il s'agit des revendications supplémentaires d'un ticket SAML, qui décrivent les utilisateurs. Il peut s'agir de rôles utilisateurs, de groupes d'utilisateurs ou d'autres types de revendications telles que l'âge. Tous les mappages de revendications sont créés en tant qu'objets répliqués sur les serveurs d'une batterie SharePoint Server.Other claims These claims consist of additional claims from a SAML ticket that describe users. These can include user roles, user groups, or other kinds of claims such as age. All claims mappings are created as objects that are replicated across the servers in a SharePoint Server farm.

  • Domaine Dans l'architecture de revendications de SharePoint, l'URI ou URL associée à une application web SharePoint configurée de façon à utiliser un fournisseur basé sur les jetons SAML représente un domaine. Quand vous créez un fournisseur d'authentification basé sur les jetons SAML dans la batterie, vous spécifiez un à la fois les domaines, ou URL d'applications web, que vous souhaitez que le service IP-STS reconnaisse. Vous spécifiez le premier domaine lors de la création du SPTrustedIdentityTokenIssuer. Vous pouvez ajouter des domaines après avoir créé le SPTrustedIdentityTokenIssuer. Vous devez spécifier les domaines à l'aide d'une syntaxe semblable à la suivante : $realm = "urn:sharepoint:mysites". Après avoir ajouté le domaine au SPTrustedIdentityTokenIssuer, vous devez créer une approbation RP-STS avec l'identificateur de domaine sur le serveur IP-STS. Ce processus nécessite de spécifier l'URL de l'application web.Realm In the SharePoint claims architecture, the URI or URL that is associated with a SharePoint web application that is configured to use a SAML token-based provider represents a realm. When you create a SAML-based authentication provider on the farm, you specify the realms, or web application URLs, that you want the IP-STS to recognize, one at a time. The first realm is specified when you create the SPTrustedIdentityTokenIssuer. You can add more realms after you create the SPTrustedIdentityTokenIssuer. Realms are specified by using syntax similar to the following: $realm = "urn:sharepoint:mysites". After you add the realm to the SPTrustedIdentityTokenIssuer, you must create an RP-STS trust with the realm identifier on the IP-STS server. This process involves specifying the URL for the web application.

  • SPTrustedIdentityTokenIssuer Il s'agit de l'objet créé dans la batterie SharePoint qui inclut les valeurs nécessaires pour communiquer avec le service IP-STS et recevoir des jetons à partir de ce service. Lors de la création du SPTrustedIdentityTokenIssuer, vous spécifiez le certificat de signature de jetons à utiliser, le premier domaine, la revendication qui représente la revendication d'identité et les éventuelles revendications supplémentaires. Vous ne pouvez associer un certificat de signature de jetons d'un service STS qu'à un seul SPTrustedIdentityTokenIssuer. Toutefois, une fois le SPTrustedIdentityTokenIssuer créé, vous pouvez ajouter des domaines supplémentaires pour d'autres applications web. Une fois le domaine ajouté au SPTrustedIdentityTokenIssuer, vous devez également l'ajouter au service IP-STS en tant que partie de confiance. L'objet SPTrustedIdentityTokenIssuer est répliqué sur les serveurs de la batterie SharePoint Server.SPTrustedIdentityTokenIssuer This is the object that is created on the SharePoint farm that includes the values necessary to communicate with and receive tokens from the IP-STS. When you create the SPTrustedIdentityTokenIssuer, you specify which token-signing certificate to use, the first realm, the claim that represents the identity claim, and any additional claims. You can only associate a token-signing certificate from an STS with one SPTrustedIdentityTokenIssuer. However, after you create the SPTrustedIdentityTokenIssuer, you can add more realms for additional web applications. After you add a realm to the SPTrustedIdentityTokenIssuer, you must also add it to the IP-STS as a relying party. The SPTrustedIdentityTokenIssuer object is replicated across servers in the SharePoint Server farm.

  • RP-STS (Relying Party Security Token Service) Dans SharePoint Server, chaque application web configurée de façon à utiliser un fournisseur SAML est ajoutée au serveur IP-STS comme entrée RP-STS. Une batterie SharePoint Server peut comprendre plusieurs entrées RP-STS.Relying party security token service (RP-STS) In SharePoint Server, each web application that is configured to use a SAML provider is added to the IP-STS server as an RP-STS entry. A SharePoint Server farm can include multiple RP-STS entries.

  • Service IP-STS (Identity Provider Security Token Service) Il s'agit du service d'émission de jetons de sécurité dans l'environnement de revendications qui émet les jetons SAML pour le compte des utilisateurs figurant dans l'annuaire d'utilisateurs associé.Identity provider security token service (IP-STS) This is the secure token service in the claims environment that issues SAML tokens on behalf of users who are included in the associated user directory.

Le diagramme suivant représente l’architecture des revendications de jeton SAML SharePoint Server.The following diagram shows the SharePoint Server SAML token claims architecture.

Architecture des revendications de jeton SAMLSAML token claims architecture

Composants de l'authentification basée sur les revendications de SharePoint

L'objet SPTrustedIdentityTokenIssuer est créé avec plusieurs paramètres, notamment les suivants :The SPTrustedIdentityTokenIssuer object is created with several parameters, which include the following:

  • Une revendication d'identité uniqueA single identity claim.

  • Un paramètre SignInURL uniqueA single SignInURL parameter.

    Le paramètre SignInURL spécifie l'URL vers laquelle rediriger une demande d'utilisateur pour s'authentifier auprès du service IP-STS.The SignInURL parameter specifies the URL to redirect a user request to in order to authenticate to the IP-STS.

  • Un paramètre Wreply uniqueA single Wreply parameter.

    Certains serveurs IP-STS nécessitent le paramètre Wreply, qui prend la valeur true ou false. Cette dernière est la valeur par défaut. Utilisez le paramètre Wreply uniquement si le service IP-STS le demande.Some IP-STS servers require the Wreply parameter, which is set to either true or false. False is the default. Use the Wreply parameter only if it is required by the IP-STS.

  • Plusieurs domainesMultiple realms.

  • Plusieurs mappages de revendicationsMultiple claims mappings.

Pour implémenter l’authentification basée sur un jeton SAML avec SharePoint Server, appliquez les étapes suivantes, qui doivent être planifiées :To implement SAML token-based authentication with SharePoint Server, use the following steps which require planning in advance:

  1. Exportez le certificat de signature de jetons à partir du service IP-STS. Copiez le certificat dans un serveur de la batterie SharePoint Server.Export the token-signing certificate from the IP-STS. Copy the certificate to a server in the SharePoint Server farm.

  2. Définissez la revendication qui sera utilisée comme identificateur unique de l'utilisateur. Elle porte le nom de revendication d'identité. Le nom d'utilisateur principal (UPN) ou nom de messagerie de l'utilisateur est souvent utilisé comme identificateur d'utilisateur. Collaborez avec l'administrateur du service IP-STS pour déterminer l'identificateur correct, car seul le propriétaire du service IP-STS sait quelle valeur dans le jeton sera toujours unique pour chaque utilisateur. L'identification de l'identificateur unique de l'utilisateur fait partie du processus de mappage de revendications. Microsoft PowerShell permet de créer les mappages de revendications.Define the claim that will be used as the unique identifier of the user. This is known as the identity claim. The user principal name (UPN) or user e-mail name is frequently used as the user identifier. Coordinate with the administrator of the IP-STS to determine the correct identifier because only the owner of the IP-STS knows the value in the token that will always be unique per user. Identifying the unique identifier for the user is part of the claims-mapping process. You use Microsoft PowerShell to create claims mappings.

  3. Définissez les mappages de revendications supplémentaires. Définissez les revendications supplémentaires du jeton entrant qui seront utilisées par la batterie SharePoint Server. Les rôles utilisateurs sont un exemple de revendication pouvant être utilisée pour accorder des autorisations aux ressources dans la batterie SharePoint Server. Toutes les revendications d’un jeton entrant qui ne possèdent pas de mappage sont rejetées.Define additional claims mappings. Define the additional claims from the incoming token that the SharePoint Server farm will use. User roles are an example of a claim that can be used to assign permissions to resources in the SharePoint Server farm. All claims from an incoming token that do not have a mapping will be discarded.

  4. PowerShell permet de créer un fournisseur d'authentification pour importer le certificat de signature de jetons. Ce processus crée le SPTrustedIdentityTokenIssuer. Durant ce processus, vous spécifiez la revendication d'identité et les revendications supplémentaires que vous avez mappées. Vous devez également créer et spécifier un domaine associé aux premières applications web SharePoint que vous configurez pour l'authentification basée sur les jetons SAML. Une fois le SPTrustedIdentityTokenIssuer créé, vous pouvez créer et ajouter davantage de domaines pour d'autres applications web SharePoint. C'est ainsi que vous configurez plusieurs applications web de façon à utiliser le même SPTrustedIdentityTokenIssuer.Use PowerShell to create a new authentication provider to import the token-signing certificate. This process creates the SPTrustedIdentityTokenIssuer. During this process, you specify the identity claim and additional claims that you have mapped. You must also create and specify a realm that is associated with the first SharePoint web applications that you are configuring for SAML token-based authentication. After you create the SPTrustedIdentityTokenIssuer, you can create and add more realms for additional SharePoint web applications. This is how you configure multiple web applications to use the same SPTrustedIdentityTokenIssuer.

  5. Pour chaque domaine ajouté au SPTrustedIdentityTokenIssuer, vous devez créer une entrée RP-STS sur le service IP-STS. Cette opération peut s'effectuer avant la création de l'application web SharePoint. Quoi qu'il en soit, vous devez planifier l'URL avant de créer les applications web.For each realm that you add to the SPTrustedIdentityTokenIssuer, you must create an RP-STS entry on the IP-STS. You can do this before the SharePoint web application exists. Regardless, you must plan the URL before you create the web applications.

  6. Configurez une application web SharePoint, nouvelle ou existante, pour utiliser le nouveau fournisseur d'authentification. Ce dernier figure en tant que fournisseur d'identité approuvé dans l'Administration centrale quand vous créez une application web.For an existing or new SharePoint web application, configure it to use the newly created authentication provider. The authentication provider is displayed as a trusted identity provider in Central Administration when you create a web application.

Vous pouvez configurer plusieurs fournisseurs d'authentification basée sur les jetons SAML. Cependant, vous ne pouvez utiliser un certificat de signature de jetons qu'une seule fois dans une batterie. Tous les fournisseurs configurés apparaissent comme des options dans l'Administration centrale. Les revendications issues de différents environnements STS approuvés n'entrent pas en conflit.You can configure multiple SAML token-based authentication providers. However, you can only use a token-signing certificate once in a farm. All configured providers are displayed as options in Central Administration. Claims from different trusted STS environments will not conflict.

Si vous implémentez l’authentification basée sur les jetons SAML avec une société partenaire et que votre propre environnement comprend un service IP-STS, nous vous recommandons d’établir, avec l’administrateur de votre environnement de revendications interne, une relation d’approbation entre votre service IP-STS interne et le service STS partenaire. En adoptant cette approche, vous n’avez pas besoin d’ajouter un fournisseur d’authentification à votre batterie SharePoint Server. De plus, votre administrateur de revendications peut gérer l’ensemble de l’environnement de revendications.If you implement SAML token-based authentication with a partner company and your own environment includes an IP-STS, we recommend that you and the administrator of your internal claims environment establish a one-way trust relationship from your internal IP-STS to the partner STS. This approach does not require you to add an authentication provider to your SharePoint Server farm. It also enables your claims administrators to manage the whole claims environment.

Important

Désormais, vous n’avez plus besoin de définir l’équilibrage de la charge réseau en affinité simple lorsque vous utilisez l’authentification basée sur les revendications dans SharePoint Server.You no longer have to set network load balancing to single affinity when you are using claims-based authentication in SharePoint Server.

Notes

Lorsqu'une application web est configurée pour utiliser l'authentification basée sur un jeton SAML, la classe SPTrustedClaimProvider ne fournit pas de fonctionnalité de recherche au contrôle Sélecteur de personnes. Tout texte entré dans ce contrôle est automatiquement affiché comme s'il avait été résolu, que l'utilisateur, le groupe ou la revendication soient valides ou non. Si votre solution SharePoint Server est appelée à utiliser l'authentification basée sur un jeton SAML, vous devez envisager de créer un fournisseur de revendications personnalisé qui implémente une recherche et une résolution de nom personnalisées.When a web application is configured to use SAML token-based authentication, the SPTrustedClaimProvider class does not provide search functionality to the People Picker control. Any text entered in the People Picker control will automatically be displayed as if it resolves, regardless of whether it is a valid user, group, or claim. If your SharePoint Server solution uses SAML token-based authentication, plan to create a custom claims provider that implements custom search and name resolution.

Pour obtenir les étapes détaillées de configuration de l’authentification basée sur un jeton SAML avec AD FS, consultez la rubrique relative à la configuration de l’authentification basée sur les revendications SAML avec AD FS dans SharePoint Server.For detailed steps to configure SAML token-based authentication using AD FS, see Configure SAML-based claims authentication with AD FS in SharePoint Server.

Planification des zones des applications WebPlanning zones for web applications

Les zones représentent différents itinéraires logiques permettant d'accéder aux mêmes sites dans une application web. Chaque application web peut inclure jusqu'à cinq zones. Lors de la création d'une application web, l'Administration centrale crée la zone par défaut. Pour créer des zones supplémentaires, étendez l'application web et sélectionnez l'un des noms de zones restants : intranet, extranet, Internet ou personnalisé.Zones represent different logical paths to gain access to the same sites in a web application. Each web application can include as many as five zones. When you create a web application, Central Administration creates the zone named default. To create additional zones, extend the web application and select one of the remaining zone names: intranet, extranet, Internet, or custom.

Votre plan pour les zones Web dépendra des éléments suivants :Your plan for zones will depend on the following:

  • Authentification basée sur les revendications (recommandé) : vous pouvez implémenter plusieurs fournisseurs d'authentification sur une même zone. Vous pouvez également utiliser plusieurs zones.Claims-based authentication (recommended) — You can implement multiple authentication providers on a single zone. You can also use multiple zones.

Implémentation de plusieurs types d'authentification sur une même zoneImplementing more than one type of authentication on a single zone

Si vous utilisez l'authentification basée sur les revendications et que vous implémentez plusieurs méthodes d'authentification, nous vous recommandons d'implémenter plusieurs méthodes d'authentification sur la zone par défaut. Le résultat est la même URL pour tous les utilisateurs.If you use claims-based authentication and implement more than one authentication method, we recommend that you implement multiple authentication methods on the default zone. The result is the same URL for all users.

Lorsque vous implémentez plusieurs méthodes d'authentification sur la même zone, les restrictions suivantes sont applicables :When you implement multiple authentication methods on the same zone, the following restrictions apply:

  • Vous pouvez implémenter uniquement une instance de l'authentification basée sur les formulaires sur une zone.You can implement only one instance of forms-based authentication on a zone.

  • L'Administration centrale permet d'utiliser conjointement l'authentification Windows intégrée et l'authentification de base. Autrement, il est impossible d'implémenter plusieurs types d'authentification Windows sur une zone.Central Administration allows you to use both an Integrated Windows method and Basic at the same time. Otherwise, you cannot implement more than one type of Windows authentication on a zone.

Si plusieurs fournisseurs d'authentification basée sur les jetons SAML sont configurés pour une batterie, ils apparaîtront tous comme options lors de la création d'une application web ou d'une zone. Vous pouvez configurer plusieurs fournisseurs SAML sur la même zone.If multiple SAML token-based authentication providers are configured for a farm, all appear as options when you create a web application or a new zone. You can configure multiple SAML providers on the same zone.

Le diagramme suivant illustre plusieurs types d'authentification implémentés sur la zone par défaut pour un site de collaboration partenaire.The following diagram shows multiple types of authentication implemented on the default zone for a partner collaboration site.

Plusieurs types d'authentification implémentés sur la zone par défautMultiple types of authentication implemented on the default zone

Types d’authentification multiples sur une zone

Sur le diagramme, les utilisateurs de différents magasins d’annuaires accèdent au site web partenaire à l’aide de la même URL. Le cadre en pointillés qui entoure les sociétés partenaires indique la relation entre l’annuaire d’utilisateurs et le type d’authentification configuré dans la zone par défaut.In the diagram, users from different directory stores use the same URL to access the partner web site. The dashed box that surrounds partner companies shows the relationship between the user directory and the authentication type that is configured in the default zone.

Planification de l'analyse du contenuPlanning to crawl content

Le composant d'analyse nécessite NTLM pour accéder au contenu. Au moins une zone doit être configurée de façon à utiliser l'authentification NTLM. Si l'authentification NTLM n'est pas configurée sur la zone par défaut, le composant d'analyse peut utiliser une zone différente configurée de façon à utiliser l'authentification NTLM.The crawl component requires NTLM to access content. At least one zone must be configured to use NTLM authentication. If NTLM authentication is not configured on the default zone, the crawl component can use a different zone that is configured to use NTLM authentication.

Implémenter plusieurs zonesImplement more than one zone

Si vous souhaitez implémenter plusieurs zones pour les applications Web, suivez les instructions suivantes :If you plan to implement more than one zone for web applications, use the following guidelines:

  • Utilisez la zone par défaut pour implémenter les paramètres d'authentification les plus sécurisés. Si une demande ne peut pas être associée à une zone spécifique, les paramètres d'authentification et autres stratégies de sécurité de la zone par défaut sont appliqués. La zone par défaut est créée quand vous créez une application web. En règle générale, les paramètres d'authentification les plus sécurisés sont conçus pour l'accès de l'utilisateur final. Ainsi, les utilisateurs finaux sont susceptibles d'accéder à la zone par défaut.Use the default zone to implement your most secure authentication settings. If a request cannot be associated with a specific zone, the authentication settings and other security policies of the default zone are applied. The default zone is the zone that is created when you create a web application. Typically, the most secure authentication settings are designed for end-user access. Consequently, end-users are likely to access the default zone.

  • Utilisez le nombre minimal de zones requises pour l'accès des utilisateurs. Chaque zone est associée à un nouveau site IIS et domaine IIS pour accéder à l'application web. Ajoutez de nouveaux points d'accès uniquement lorsqu'ils sont nécessaires.Use the minimum number of zones that are required to provide access to users. Each zone is associated with a new IIS site and domain for accessing the web application. Only add new access points when they are required.

  • Vérifiez qu'au moins une zone est configurée pour utiliser l'authentification NTLM pour le composant d'analyse. Ne créez pas de zone réservée au composant d'index, sauf en cas de nécessité.Ensure that at least one zone is configured to use NTLM authentication for the crawl component. Do not create a dedicated zone for the index component unless it is necessary.

Le diagramme suivant représente plusieurs zones implémentées de façon à gérer différents types d'authentification pour un site de collaboration partenaire.The following diagram shows multiple zones that are implemented to accommodate different authentication types for a partner collaboration site.

Une zone par type d'authentificationOne zone per authentication type

Une zone pour chaque type d'authentification

Sur le diagramme, la zone par défaut est utilisée pour les employés distants. Chaque zone est associée à une URL différente. Les employés utilisent une zone différente selon qu'ils travaillent au bureau ou à distance.In the diagram, the default zone is used for remote employees. Each zone has a different URL associated with it. Employees use a different zone depending on whether they are working in the office or are working remotely.