SharePoint 2013 : Authentification ADFS 2.0

Dans cet article, je vais décrire les étapes pour déployer ADFS 2.0 et configurer une authentification basée sur des jetons SAML pour SharePoint 2013.

Le processus d’authentification s’effectuera ainsi :

  1. Le client navigue vers https://sharepoint.testlab.fr
  2. SharePoint reçoit la requête et redirige le client vers https://adfs.testlab.fr/adfs/ls
  3. ADFS reçoit la requête et présente une fenêtre d’authentification au client
  4. ADFS vérifie les informations d’authentification fournies aupres d’un annuaire LDAP : testlab.dom
  5. AD authentifie l’utilisateur
  6. ADFS envoi un jeton SAML au client
  7. Le client est redirigé à nouveau vers SharePoint qui utilise le jeton SAML pour authentifier l’utilisateur (le fournisseur du jeton étant “de confiance”)

Le déploiement sera effectué suivant 4 phases :

– Installation & Configuration des services ADFS 2.0
– Création d’une “Relying Party Trust” sur le serveur ADFS pour le serveur SharePoint
– Configurer SharePoint pour approuver les services ADFS comme fournisseur d’authentification
– Configurer les “Web Applications” SharePoint pour utiliser l’authentification par jeton

Etape 1 : Installation & Configuration des services ADFS 2.0

On considère qu’un domaine existe déjà, le besoin est d’y installer un serveur ADFS 2.0. Ceci peut être fait soit sur un serveur dédié, soit sur un contrôleur de domaine. Dans notre cas, le serveur ADFS sera installé sur un contrôleur du domaine “testlab.dom”.

Télécharger l’utilitaire d’installation d’ADFS 2.0 depuis le centre de téléchargement Microsoft (http://www.microsoft.com/en-gb/download/details.aspx?id=10909) et l’installer sur le serveur. Durant l’installation, sélectionner “Federation Server” pour le rôle du serveur, toutes les autres options peuvent être laissées par défaut.

Une fois installé, nous devons le configurer. Dans la console de management ADFS, cliquer sur “AD FS 2.0 Server Configuration Wizard” et choisir “Create a new Federation Service”.

Il faut choisir entre un serveur autonome ou une batterie de serveurs. Même si dans notre cas nous n’avons besoin que d’un serveur, nous allons choisir l’option batterie de serveur qui nous permettra une meilleure flexibilité pour le futur. En faisant ce choix, les services ADFS s’exécuteront via un compte Active Directory et un SPN (Service Principal Name) est créé.

Création d’un nouveau “Federation Service” :

Création d’une nouvelle batterie de serveurs :

L’étape suivante (choix du certificat) est importante parce qu’elle décidera du nom de votre serveur ADFS. Il y a 2 possibilités :

– Votre site Web par défaut possède déjà un certificat https => Le serveur ADFS va automatiquement utiliser ce certificat et le nom du serveur ADFS sera défini en fonction du sujet du certificat.
– Votre site Web par défaut n’est pas mappé à un certificat https => Vous devez choisir le certificat utilisé par ADFS dans la liste fournie (les certificats présentés sont ceux qui respectent les prérequis MS comme la longueur de la clé ou l’EKU).

Dans notre cas, un certificat était déjà attribué au Site Web par défaut ayant pour sujet “adfs.testlab.fr”, l’assistant d’installation l’a donc sélectionné automatiquement.

Dernière étape, définir le compte Active Directory “adfs_svc” pour exécuter les services ADFS (le compte existe déjà dans AD).

Une fois la configuration terminée, nous pouvons vérifier que :

– Le compte ADFS a au moins le droit de lecture sur la clé privée des certificats utilisés
– Un SPN a été créé pour le compte ADFS
 Pour vérifier les SPN du compte adfs_svc, utiliser la commande : setspn –l testlabadfs_svc
 Pour créer le SPN (si besoin), utiliser la commande : setspn –a HOST/adfs.testlab.fr testlabadfs_svc
– Il n’y a pas d’avertissements ou d’erreurs au démarrage des services ADFS 2.0

Si tous ces points sont bons, alors le serveur ADFS est installé et il est possible d’accéder à l’URL Federation Metadata des services ADFS : https://adfs.testlab.fr/federationmetadata/2007-06/federationmetadata.xml

Etape 2 : Création d’une “Relying Party Trust” sur le serveur ADFS pour le serveur SharePoint

Une fois le serveur ADFS configuré, nous devons créer une “Relying Party Trust” pour notre serveur SharePoint. Dans la console d’administration ADFS, nous choisissons l’option “Add Relying Party Trust”.

Nous sélectionnons l’option de création manuelle “Enter data about the relying party manually” et spécifions un nom pour cette relation d’approbation.

Ensuite, nous sélectionnons de créer un profil de type ADFS 2.0 et ne sélectionnons aucun certificat d’encryption (c’est optionnel).

Nous choisissons l’option “Enable support for the WS-Federation Passive protocol” et nous devons entrer l’URL du site racine SharePoint en y incluant le chemin “_trust/”. Dans notre cas : “https://sharepoint.testlab.fr/_trust/”.

Comme identifiant pour cette relation d’approbation, nous devons entrer un “Realm” qui permettra d’identifier l’application Web du client, nous utiliserons “urn:sharepoint:testlab”.

Enfin, nous choisissons d’autoriser tous les utilisateurs via l’option “Permit all users to access this Relying Party” et pouvons revalider tous les paramètres sur la page résumé. La dernière étape est maintenant de créer les règles associées au jeton (nous pouvons donc laisser cocher la case “Open the Edit Claims Rules dialog ….” à la fin de l’assistant d’installation).

Nous devons créer une règle pour passer des attributs AD dans le jeton, nous avons choisi de passer l’adresse mail ainsi que les appartenances aux groupes.

Ajouter une règle et sélectionner “Send LDAP Attributes as Claims” :

Comme dernière action, nous allons exporter le certificat “Signing” du serveur ADFS (sans la clé privée) ainsi que tous les certificats parents (l’autorité de certification) et les copier sur le serveur SharePoint.

Dans notre cas, je vais copier sur le serveur SharePoint deux certificats :ADFS_Signing.cer (le certificat ADFS Signing) et TestLab_CA.cer (le certificat de l’autorité de certification).

Etape 3 : Configurer SharePoint pour approuver les services ADFS comme fournisseur d’authentification

Sur le serveur SharePoint, nous devons créer un nouveau fournisseur d’authentification basé sur nos services ADFS.

En utilisant la console PowerShell SharePoint, nous allons ajouter les certificats requis et créer le fournisseur d’authentification sur SharePoint :

$CAcert=New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(« C:TestLab_CA.cer ») New-SPTrustedRootAuthority -name « TestLab Certificate Authority » -Certificate $CAcert

$cert=New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(« C:ADFS_Signing.cer »)
 $map1=New-SPClaimTypeMapping « http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress » -IncomingClaimTypeDisplayName « EmailAddress » -SameAsIncoming
 $map2=New-SPClaimTypeMapping « http://schemas.microsoft.com/ws/2008/06/identity/claims/role » -IncomingClaimTypeDisplayName « Role » -SameAsIncoming
 $realm= »urn:sharepoint:testlab »
 $signurl= »https://adfs.testlab.fr/adfs/ls/ »
 $ap=New-SPTrustedIdentityTokenIssuer -Name « Testlab ADFS » -Description « Testlab ADFS 2.0 Server » -realm $realm -importtrustcertificate $cert -claimsmappings $map1,$map2 -signinurl $signurl -identifierclaim $map1.InputClaimType

Une fois la dernière commande PowerShell exécutée, nous avons un nouveau “SPTrustedIdentityTokenIssuer” qui peut être utilisé pour nos “Web Applications” SharePoint.

Etape 4 : Configurer les “Web Applications” SharePoint pour utiliser l’authentification par jeton

La dernière étape est de définir l’authentification par jeton pour notre site Web. Nous supposons ici que le site Web existe déjà et qu’il utilise l’authentification intégrée Windows en https.

Sur le serveur SharePoint, nous cliquons sur “Manage Web Applications” dans la centrale d’administration SharePoint, sélectionnons notre “Web Application” puis cliquons sur “authentication provider”.

Désélectionnons “Windows authentication”, et sélectionnons à la place “Trusted Identity Provider” ainsi que notre nouvellement créé “Testlab ADFS”, puis sauvegardons les modifications.

Avec ce nouveau paramétrage, l’identifiant pour notre site Web devient désormais l’adresse mail de l’utilisateur, nous devons donc modifier l’administrateur de la collection de site et utiliser les adresse mail pour positionner les droits.

Dans la centrale d’administration SharePoint, nous sélectionnons “Application Management” puis “Change Site Collection Administrators”.

Nous modifions le “Primary Site Collection Administrator” avec l’adresse mail de l’administrateur et sauvegardons les modifications.

Le site Web SharePoint doit désormais être joignable avec une authentification ADFS. Quand on essaye, nous obtenons une fenêtre d’authentification du serveur ADFS (notez le “Connecting to adfs.testlab.fr”) et après une authentification réussie, nous sommes redirigés vers le site SharePoint et bien authentifié via notre adresse mail (notez l’identification de l’utilisateur “admin@testlab.fr” dans le coin supérieur droit).

Etape 5 : Plus …

La solution peut être adaptée suivant votre environnement, on pourra par exemple :

– Utiliser une authentification de type formulaire sur le serveur ADFS plutôt que l’IWA

Sur le serveur ADFS, éditer le fichier “C:inetpubadfslsweb.config” avec Notepad (ou un autre éditeur) et modifier l’ordre des types d’authentification disponibles suivant vos besoins. Par exemple, utilisez la section suivante pour une authentification par formulaire :

<microsoft.identityServer.web>
<localAuthenticationTypes>
<add name= »Forms » page= »FormsSignIn.aspx » />
<add name= »Integrated » page= »auth/integrated/ » />
<add name= »TlsClient » page= »auth/sslclient/ » />
<add name= »Basic » page= »auth/basic/ » />
</localAuthenticationTypes>

– Publier la solution via TMG ou UAG pour une utilisation externe.

Nous explorerons probablement ces possibilités dans un futur post.