Configuration de SharePoint 2010 et d’ADFS v2 de bout en bout

Configuration de SharePoint 2010 et d’ADFS v2 de bout en bout

Dans ce billet, je vais effectuer une présentation de bout en bout de la façon de configurer SharePoint 2010 et ADFS v2 ensemble pour utiliser l’authentification par revendications SAML. J’inclurai des étapes et des scripts PowerShell à des fins d’illustration et tâcherai de rassembler toutes les pièces dans une publication globale.

Tout d’abord, une vue d’ensemble brève des composants impliqués et de ce que nous devrons faire. Dans ce scénario, ADFS v2 est notre fournisseur d’identités, également appelé service d’émission de jeton de sécurité de fournisseur d’identités. Nous devons configurer ADFS avec des informations sur notre partie de confiance. Dans ce cas, SharePoint est notre partie de confiance – il revient à ADFS d’effectuer l’authentification et de fournir les revendications. Concernant SharePoint, nous devons le configurer afin qu’il approuve le service d’émission de jeton de sécurité de fournisseur d’identités qui nous envoie les revendications, puis nous devons configurer une application et un site Web destinés à consommer ces revendications.

Nous allons commencer par créer la partie de confiance dans ADFS. Notez que l’ordre dans lequel vous effectuez ces opérations n’est pas réellement important ; pour ma part, je configure généralement ADFS en premier. Accédez au serveur sur lequel ADFS est installé et ouvrez l’application de gestion AD FS 2.0. Développez le nœud Relations d’approbation (Trust Relationships) et cliquez sur le nœud Approbations de la partie de confiance (Relying Party Trusts).

Cliquez sur le lien Ajouter une approbation de la partie de confiance (Add Relying Party Trust) dans le volet de droite pour démarrer l’Assistant Ajouter une approbation de la partie de confiance.

Cliquez sur le bouton Démarrer (Start) pour continuer.

Sélectionnez l’option Entrer les données sur la partie de confiance manuellement (Enter data about the relying party manually), puis cliquez sur le bouton Suivant (Next).

Entrez un nom d’affichage et éventuellement une description pour la partie de confiance, puis cliquez sur le bouton Suivant (Next).

Sélectionnez l’option permettant d’utiliser le profil AD FS 2.0, puis cliquez sur le bouton Suivant (Next).

Vous pouvez sélectionner un certificat pour chiffrer le jeton SAML proprement dit. Cette opération est peu fréquente ; étant donné qu’ADFS nous oblige à effectuer la connexion à SharePoint via SSL, le canal d’envoi du jeton est déjà chiffré. Cliquez sur le bouton Suivant (Next).

Activez la case à cocher Activer la prise en charge du protocole passif WS-Federation (Enable support for the WS-Federation Passive protocol). Pour l’URL du protocole, vous devez entrer l’URL du site racine de l’application Web SharePoint et inclure le sous-répertoire « _trust ». Dans cet exemple, l’URL de mon application Web SharePoint étant https://seo14, le l’URL du protocole passif WS-Federation est https://seo14/_trust/. Après avoir entré votre URL, cliquez sur le bouton Suivant (Next).

Pour l’identificateur de l’approbation de la partie de confiance, vous devez entrer un domaine que votre application Web transmettra à ADFS lorsque les utilisateurs se connecteront à l’application Web. Le domaine est généralement créé au format urn:foo:bar. Le domaine est associé à une application Web et détermine la façon dont ADFS peut mapper la demande de connexion entrante sur les approbations de partie de confiance qu’il détient. Lorsqu’il est utilisé avec SharePoint, ADFS détermine le domaine associé à la demande de connexion, y recherche l’approbation de la partie de confiance et, après avoir authentifié l’utilisateur, recherche l’URL du protocole passif WS-Federation pour déterminer vers où rediriger l’utilisateur. Par conséquent, dans ce cas, j’ai entré un domaine au format urn:seo:sharepoint. Lorsque j’essaierai d’accéder à mon site SharePoint à l’adresse https://seo14, je serai redirigé vers ADFS et je vais configurer SharePoint pour utiliser le domaine urn:seo:sharepoint pour cette demande. Une fois qu’ADFS m’authentifiera, il me redirigera vers https://seo14/_trust/, car il s’agit de l’URL du protocole passif pour cette partie de confiance. Ajoutez le domaine de votre choix ici et notez-le, car vous devrez l’entrer de nouveau lorsque vous configurerez SharePoint. Ensuite, cliquez sur le bouton Suivant (Next).

Dans la plupart des cas, vous souhaiterez que tous les utilisateurs puissent recourir à cette partie de confiance. Nous supposons que c’est le cas dans ce scénario ; par conséquent, acceptez simplement l’option par défaut et cliquez sur le bouton Suivant (Next).

Si, à ce stade, vous deviez apporter d’autres modifications à la configuration de l’approbation de la partie de confiance, vous pourriez les réaliser ici. Comme ce n’est pas le cas dans ce scénario, cliquez simplement sur le bouton Suivant (Next) pour continuer.

Nous avons terminé de configurer l’approbation de la partie de confiance, mais nous devons créer une règle de revendication indiquant à ADFS les revendications à envoyer à SharePoint. Par conséquent, laissez activée la case à cocher Ouvrir la boîte de dialogue Modifier les règles de revendication (Open the Edit Claim Rules dialog) et cliquez sur le bouton Fermer (Close).

À présent, comme nous allons créer une règle, cliquez sur le bouton Ajouter une règle (Add Rule).

Nous allons envoyer des attributs LDAP en tant que revendications, car dans ce cas nous obtenons des informations auprès d’Active Directory, ce qui signifie que nous nous authentifierons auprès d’ADFS, qui utilisera l’annuaire Active Directory d’entreprise pour nous authentifier et déterminer nos attributs. Par conséquent, laissez la valeur par défaut sélectionnée et cliquez sur le bouton Suivant (Next) pour continuer.

Commencez par taper le nom de règle de revendication de votre choix. Ensuite, dans la liste déroulante Magasin des attributs (Attribute store), sélectionnez Active Directory. Ensuite, pour notre scénario, nous souhaitons envoyer l’adresse de messagerie et les groupes auxquels l’utilisateur appartient à SharePoint. Nous allons utiliser l’adresse de messagerie en tant qu’identificateur de la personne et nous souhaitons que tous les groupes auxquels un utilisateur appartient soient communiqués dans la revendication Rôle (Role). Pour établir cette correspondance, sélectionnez l’attribut de votre choix dans la liste déroulante sur le côté gauche, puis sélectionnez la revendication sous la forme de laquelle il sera envoyé dans la liste déroulante du volet de droite. Dans le cas présent, nous souhaitons que l’attribut Adresses de messagerie (E-Mail-Addresses) d’Active Directory soit envoyé dans la revendication Adresse de messagerie (E-Mail Address) standard. Nous souhaitons que les groups auxquels un utilisateur appartient soient envoyés dans la revendication Rôle (Role) standard. Dans le cas présent, j’ai sélectionné Jeton-Groupes – noms non qualifiés (Token-Groups – Unqualified Names), car il envoie le nom du groupe sous la forme d’une chaîne simple, en l’occurrence le nom du groupe. Vous pourriez envoyer le SID des groupes, mais il s’avère plus difficile à utiliser lors de l’affectation d’une revendication Rôle (Role) à un groupe SharePoint. Une fois que vous avez configuré cette règle comme décrit ici, cliquez sur le bouton Terminer (Finish).

Cliquez sur le bouton OK pour terminer le processus de création de votre approbation de partie de confiance dans ADFS. Dans ADFS, en ce qui concerne la configuration, aucune autre opération ne doit être réalisée. Toutefois, nous devons y récupérer autre chose. ADFS utilise un certificat pour signer les jetons qu’il envoie. Cela garantit au consommateur du jeton que celui-ci n’a pas été modifié depuis sa création. Pour configurer SharePoint, nous avons besoin d’une copie de ce certificat, car elle nous permettra de configurer celui-ci afin qu’il utilise ADFS en guise de service d’émission de jeton de sécurité de fournisseur d’identités. Pour obtenir ce certificat de signature de jetons auprès d’ADFS, développez le nœud Service et cliquez sur le nœud Certificats (Certificates).

Ce nœud comporte une section dédiée aux certificats de signature de jetons. Vous pouvez détenir entre un et plusieurs certificats de signature de jetons, mais il y a toujours un seul certificat de signature de jetons principal. Cliquez sur ce certificat, puis cliquez sur le lien Afficher le certificat (View Certificate) dans le volet de droite.

Dans le cas présent, j’ai choisi d’utiliser le certificat que j’ai créé pour SSL sur le site Web ADFS. Je ne suggère pas que cela est nécessaire ou même recommandé ; c’est simplement ce que j’ai choisi de faire. Le certificat étant affiché, cliquez sur l’onglet Détails (Details) en haut de la boîte de dialogue.

Cliquez sur le bouton Copier dans un fichier (Copy to File). Cette opération démarre un Assistant qui permet d’enregistrer une copie du certificat sur le disque.

Cliquez sur le bouton Suivant (Next) pour continuer.

Étant donné que vous n’avez pas besoin de la clé privée, acceptez les paramètres par défaut et cliquez sur le bouton Suivant (Next).

Le format par défaut convient ; vous pouvez donc cliquer sur le bouton Suivant (Next) pour continuer.

Sélectionnez l’emplacement auquel vous souhaitez enregistrer le certificat, puis cliquez sur le bouton Suivant (Next). Veillez à vous souvenir de l’emplacement auquel vous enregistrez le certificat, car vous devrez copier celui-ci sur le serveur SharePoint à partir de cet endroit.

Toutes les informations requises pour copier le certificat localement étant désormais capturées, cliquez sur le bouton Terminer (Finish) pour terminer l’Assistant et enregistrer le certificat dans un fichier local. Copiez ce fichier sur le serveur SharePoint ; nous en aurons alors fini avec le serveur ADFS.

Passez au serveur SharePoint afin que nous commencions à le configurer. Avant que nous ne commencions à configurer SharePoint, je vous recommande de créer une application Web maintenant. Créez-la de manière à utiliser l’authentification par revendications, mais sélectionnez Authentification intégrée Windows – NTLM (Integrated Windows authentication – NTLM) dans les paramètres d’authentification. Veillez à configurer l’application Web de manière à ce qu’elle utilise le port 443 et à sélectionner la case d’option Utiliser le protocole SSL (Secure Sockets Layer) (Use Secure Sockets Layer (SSL)). Une fois que vous avez créé votre application Web, pensez à accéder au Gestionnaire IIS et à modifier les liaisons pour le nouveau serveur virtuel afin de pouvoir affecter le certificat SSL approprié. Ces étapes n’entrent pas dans le cadre de cette publication, mais de nombreuses sources sur Internet les expliquent correctement. En résumé, pour notre scénario, il existe à ce stade une application Web créée par mes soins qui utilise le port 443 et SSL, tandis que l’URL de cette application Web est https://seo14.

La première chose que je vais effectuer côté SharePoint consiste à ajouter le certificat de signature de jetons que j’ai copié à partir du serveur ADFS. Toutefois, au préalable, je dois observer le certificat. La chaîne du certificat de signature de jetons peut comporter un ou plusieurs certificats parents. Si tel est le cas, je dois ajouter chaque certificat présent dans cette chaîne à la liste de SharePoint des autorités racines approuvées. Pour déterminer cela, je vais rechercher le certificat de signature de jetons que j’ai copié à partir d’ADFS et double-cliquer dessus, afin d’afficher la fenêtre des propriétés du certificat. Si vous cliquez sur l’onglet Chemin d’accès de certification (Certification Path), vous pouvez voir si la chaîne comporte d’autres certificats. Dans mon scénario, mon certificat de signature de jetons contient effectivement un parent ; il s’agit du certificat d’autorité de certification racine.

À présent, pour chaque certificat présent dans la chaîne au-dessus de mon certificat de signature de jetons, je dois enregistrer une copie de chacun d’eux localement. Pour ce faire, je peux cliquer sur le certificat ; cette opération se traduit par l’activation du bouton Afficher le certificat (View Certificate) dans la boîte de dialogue. Si je clique sur ce bouton, une boîte de dialogue de propriétés distinctes propre au certificat apparaît. Je peux alors suivre le même processus que celui que j’ai décrit antérieurement pour enregistrer une copie du certificat sur le disque : cliquer sur l’onglet Détails (Details), cliquer sur le bouton Copier dans un fichier (Copy to File), puis enregistrer le certificat localement dans un fichier .CER. Dans mon cas, j’ai suivi cette procédure et enregistré le certificat dans C:\adfsParent.cer. Par conséquent, à présent, je possède deux certificats sur mon serveur SharePoint :

· C:\adfs.cer, le certificat de signature de jetons que j’ai copié à partir de mon serveur ADFS ;

· C:\adfsParent.cer, le certificat parent de mon certificat de signature de jetons.

Ces deux certificats étant en ma possession, je dois les ajouter à ma liste des autorités racines approuvées. Je vais effectuer cette opération dans PowerShell à l’aide du script suivant :

$root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\adfsParent.cer")

New-SPTrustedRootAuthority -Name "Token Signing Cert Parent" -Certificate $root

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\adfs.cer ")

New-SPTrustedRootAuthority -Name "Token Signing Cert" -Certificate $cert

Une fois que j’exécute ces commandes dans PowerShell, la sortie ressemble à ceci :

Ensuite, je vais créer les mappages de revendications que SharePoint utilisera. Comme vous vous en souvenez peut-être, j’ai précédemment indiqué dans cet article que j’utiliserais l’adresse de messagerie et des revendications de rôle dans SharePoint. Voici la commande PowerShell que je vais utiliser pour créer ces mappages :

$map = New-SPClaimTypeMapping -IncomingClaimType "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming

$map2 = New-SPClaimTypeMapping -IncomingClaimType "https://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" -SameAsIncoming

Ensuite, je vais créer une variable pour le domaine que SharePoint doit utiliser. Dans le cadre de ce scénario, j’ai indiqué que j’allais utiliser le domaine urn:seo:sharepoint. Voici la commande PowerShell qui permet de créer la variable de domaine :

$realm = "urn:seo:sharepoint"

À présent, je suis en mesure de créer mon émetteur de jeton SPTrustedIdentityTokenIssuer. C’est à cet endroit que je rassemble toutes les informations de configuration afin que SharePoint sache comment se connecter au service d’émission de jeton de sécurité de fournisseur d’identités et utiliser ce service. Je vais montrer ci-après la commande PowerShell, puis expliquerai les parties importantes :

$ap = New-SPTrustedIdentityTokenIssuer -Name "SAML Provider" -Description "SharePoint secured by SAML" -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$map2 -SignInUrl "https://congen1.contoso.local/adfs/ls" -IdentifierClaim "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"

L’attribut « Name » correspond au texte qui apparaît dans votre application Web lorsque vous configurez le fournisseur d’authentification qu’elle doit utiliser. L’attribut « realm » définit l’endroit auquel nous enfichons le domaine que SharePoint doit utiliser avec cet émetteur de jeton d’identité approuvé. L’attribut « ImportTrustCertificate » désigne à quel endroit nous lui transmettons le certificat de signature de jetons que nous avons copié à partir du serveur ADFS. L’attribut « ClaimsMappings » représente l’endroit auquel nous lui indiquons les revendications que cet émetteur de jeton d’identité approuvé doit utiliser. L’attribut « SignInUrl » désigne l’URL vers laquelle les utilisateurs doivent être redirigés pour s’authentifier auprès du service d’émission de jeton de sécurité de fournisseur d’identités. Dans le cas présent, nous souhaitons que les utilisateurs s’authentifient auprès du serveur ADFS à l’aide de la sécurité intégrée Windows ; par conséquent, nous les redirigeons vers le sous-répertoire /adfs/ls. Enfin, l’attribut « IdentifierClaim » indique à SharePoint laquelle des revendications sera la revendication à utiliser pour identifier les utilisateurs. Dans le cas présent, nous supposons que vous identifiez une personne par son adresse de messagerie.

Une fois exécutée la dernière commande PowerShell, nous disposons d’un émetteur de jeton SPTrustedIdentityTokenIssuer utilisable avec notre application Web SharePoint. À présent, nous allons ouvrir le navigateur et accéder à l’Administration centrale. Cliquez sur le lien Gérer les applications Web, puis, dans la liste, cliquez sur l’application Web qui va utiliser ADFS pour s’authentifier et cliquez sur le bouton Fournisseurs d’authentification dans le Ruban. Dans la boîte de dialogue, cliquez sur le lien qui correspond à la zone dans laquelle vous allez utiliser ADFS pour l’authentification. Faites défiler l’écran vers le bas jusqu’à la section Types d’authentification basée sur les revendications (Claims Authentication Types). Vous pouvez maintenant désactiver NTLM et vous devez voir un nouveau fournisseur appelé « SAML Provider » dans la liste des fournisseurs approuvés.

Activez la case à cocher en regard de ce fournisseur et cliquez sur le bouton Enregistrer pour enregistrer vos modifications. À présent, vous pouvez créer une collection de sites pour l’application Web. Rappelons que la description de ce processus n’entre pas dans le cadre de cette publication ; toutefois, au cours de processus, vous devez garder à l’esprit une chose importante. Lorsque vous ajoutez l’administrateur de collection de sites, pensez à entrer le nom dans le format de votre revendication d’identité. Par exemple, dans ce scénario, la revendication d’identité est l’adresse de messagerie. Par conséquent, lorsque j’ai ajouté l’administrateur de collection de sites, le nom que j’ai utilisé était administrator@contoso.local, car il s’agit de l’adresse de messagerie de la personne qui doit faire office d’administrateur de collection de sites.

À présent, je suis en mesure d’accéder à ma nouvelle collection de sites. J’ouvre le navigateur, tape https://seo14 et appuie sur Entrée. La première chose qui se produit est que je suis redirigé vers l’URL SignInUrl de l’émetteur de jeton SPTrustedIdentityTokenIssuer associé à mon application Web. Comme indiqué dans la commande PowerShell utilisée pour la création de l’émetteur de jeton SPTrustedIdentityTokenIssuer, cette URL est https://congen1.contoso.local/adfs/ls. Par conséquent, voici ce que je vois après avoir tapé l’URL de mon site SharePoint dans le navigateur :

Vous pouvez constater que l’URL dans la fenêtre du navigateur pointe maintenant vers mon serveur ADFS, tandis que les informations en arrière-plan de la boîte de dialogue de connexion concernent le serveur ADFS. Vous pouvez également noter que je me connecte en utilisant mes informations d’identification Windows, c’est-à-dire domaine\utilisateur. Souvenez-vous que je peux procéder ainsi, car je m’authentifie sur le serveur ADFS, pas sur SharePoint. Bien que SharePoint soit configuré pour utiliser l’adresse de messagerie en guise de mon identité, je vais m’authentifier auprès d’ADFS, qui utilisera la règle de revendication que nous avons créée pour récupérer mes adresse de messagerie et groupes et les insérer dans des revendications qui seront envoyées à SharePoint. Par conséquent, après mon authentification, je suis redirigé vers SharePoint à l’adresse https://seo14/_trust/, telle que je l’ai configurée dans la partie de confiance que j’ai configurée dans ADFS. À ce stade, SharePoint termine le processus d’authentification de son côté lorsqu’il récupère les revendications qu’il a obtenues dans le jeton SAML et qu’il les convertit en une classe SPUser. Ensuite, j’arrive enfin à la page d’accueil du site :

Vous noterez que le contrôle de connexion dans la partie supérieure droite de la page affiche mon identité en tant qu’adresse de messagerie, dans la mesure où il s’agit de ma revendication d’identité.

Voilà le processus de bout en bout complet agrémenté de quelques explications. En suivant ces instructions, vous devriez être en mesure d’utiliser ce processus pour configurer vos sites et les rendre opérationnels.

Ce billet de blog a été traduit de l’anglais. L’article d’origine est disponible à la page Configuring SharePoint 2010 and ADFS v2 End to End.