Office 365 – Mise en place de la Federation Identite – Partie 3
Configuration de la relation de confiance et mise en place du SSO (Single Sign On).
Nous avons vu dans le précédent article comment déployer ADFS pour préparer la coexistence avec Office 365 (https://blogs.technet.com/b/dcaro/archive/2011/05/17/office-365-mise-en-place-de-la-federation-identite-partie-2.aspx). dans cart article nous allons mettre en place la relation de confiance.
Office 365 est suffisamment souple pour permettre, au sein d'un même environnement (tenant) d'avoir des comptes qui utilisent la fédération d'identité et d'autres qui utilisent le provider d'identité de Office 365. La différentiation se faisant avec le domaine d'authentification de l'utilisateur.
L'authentification dans Office 365 repose sur l'utilisation des UPN (User Principal Name). Cette notion est apparue avec Windows 2000 mais relativement peu utilisée jusqu'à présent dans les entreprises. Le principe est que tout utilisateur peut se connecter sur son domaine en entrant son compte sous le format "user@contoso.com" au lieu de CONTOSO\user. L'intérêt de l'UPN est qu'il est relativement souple à modifier par rapport à un compte traditionnel.
Dans le cas d'une maquette vous ne souhaiterez peut-être pas utiliser le domaine de production pour les comptes de test, il est recommandé dans ce cas d'ajouter un domaine UPN supplémentaire uniquement pour valider la mécanique de SSO. Pour cela, il faut suivre les étapes décrites ici : https://support.microsoft.com/kb/243629
Dans notre exemple, le domaine principal s'appelle caro.eu.com mais le domaine de fédération s'appelle zecloud.net comme le montre la capture d'écran ci-dessous:
Vous pouvez alors changer l'UPN de vos utilisateurs simplement en allant dans les propriétés du compte dans Active Directory Users and Computers puis dans l'onglet Account il suffit de choisir le domaine associé à l'utilisateur dans la liste déroulante.
Il reste à lancer l'outil de gestion de la fédération d'identité installé sur le serveur ADFS et indiquer à Office 365 que le domaine "zecloud.net" est un domaine fédéré avec une infrastructure d'entreprise. Suivez les étapes suivantes :
$cred=Get-Credential
Saisissez les credentials de votre compte d'administration de votre tenant Office 365.
Set-MSOLContextCredential –MSOLAdminCredentials $cred -Computer <Nom Interne de votre serveur ADFS>
Cette commande crée le contexte de sécurité pour configure Office 365, elle est nécessaire avant de pouvoir exécuter toute commande supplémentaire.Add-MSOLFederatedDomain –DomainName <domain>
Domain est le nom du domaine qui sera utilisé pour la fédération d'identité. Dans notre cas, il s'agit du domaine zecloud.net.
Lors de l'exécution de cette commande, le système peut vous demander de vérifier votre domaine en ajoutant un CNAME du type ms12345678.contoso.com. Si vous avez enregistré et vérifié votre domaine au préalable dans la console d'administration de Office 365, ce message ne s'affichera pas.
Si vous voulez vérifier la configuration de la fédération d'identité que vous venez de mettre en place, lancez la cmdlet : Get-MSOLFederationProperty –DomainName <domain>
Remarquez les valeurs des champs ActiveClientSignInUrl et PassiveClientSignInUrl. Les deux pointent vers le nom FQDN du serveur ADFS que nous avons utilisé dans la configuration du serveur ADFS v2.
Il faut que ces URLs soit accessibles par les clients qui souhaitent se connecter à Office 365 dont l'UPN est dans le domaine "zecloud.net".
Il faut donc procéder à la publication sur Internet (via TMG – Threat Management Gateway) du serveur ADFS et plus spécifiquement des URLs qui seront utilisées dans le mécanisme de SSO.
Publication sur Internet du serveur ADFS
Pour la publication du serveur ADFS sur Internet, dans le cadre de notre maquette nous allons utiliser la configuration la plus simple possible:
- Le contrôleur de domaine et le serveur ADFS sont sur le réseau de l'entreprise.
- TMG est en rupture avec Internet.
- La publication se fait sur le port 443 (HTTPS).
Création du Listener
Au niveau du serveur TMG, il faut donc créer un listener (du nom que vous souhaitez) qui écoute sur le port 443 de l'interface externe de notre TMG.
C'est sur ce listener qui est le point d'entrée externe de notre TMG que l'on va positionner le certificat qui sera présenté pour chiffrer les communications. Dans notre cas, nous allons utiliser le certificat que nous avons obtenu précédemment.
Comme nous allons utiliser ce point d'entrée sur notre maquette pour plusieurs usages, nous allons désactiver l'authentification sur le listener pour la laisser se faire au niveau des différents serveurs et rôles publiés. Cette approche permet d'utiliser une seule combinaison adresse / port pour plusieurs usages. Remarquez au passage que l'onglet Forms est désactivé.
De même le SSO est inactif au niveau du listener puisque ce n'est pas TMG qui va se charger de cette opération mais bien ADFS.
Après avoir créé le listener, il faut créer une règle de publication du serveur ADFS (ou plus exactement du serveur web sts) sur Internet
Création de la règle de publication du serveur ADFS sur TMG
Nous allons donc créer une règle qui redirige les demandes de connexion à sts.zecloud.net vers notre serveur ADFS.
Il faut lancer l'assistant de publication d'un site Web. La règle peut prendre le nom que l'on souhaite mais doit être une règle d'autorisation pour un seul site web.
Nous devons ensuite définir le type de connectivité qui existera entre le serveur TMG et le serveur ADFS. Dans notre cas, et c'est une bonne pratique, nous aurons un canal de communication chiffré entre le client the le serveur TMG et un canal chiffré entre le serveur TMG et le serveur ADFS. Ce dernier étant chiffré avec le certificat émis par l'autorité de certification interne que nous avons utilisé lors de la configuration du serveur ADFS. Il s'agit du certificat qui utilise comme SAN les noms adfs.caro.eu.com et sts.zecloud.net.
Dans notre cas, nous ne faisons pas de filtrage sur les URLs publiés, nous laisserons les détails de publication vide.
Le nom public indiqué ci-dessus sert justement à faire le routage des connexions entrantes. Il est important que ce nom corresponde au nom qui a été utilisé dans la mise en œuvre de la fédération avec Office 365. Il est aussi important que ce nom corresponde à l'un des SAN du certificat qui est utilisé sur le listener spécifié à l'étape suivante.
C'est en quelque sorte ici que se connectent toutes les pièces du puzzle que nous sommes en train de monter depuis le début de ce document.
Il reste à définir le mode d'authentification utilisé. Le principe est le même que pour le listener, nous laissons le serveur publié s'occuper de l'authentification des clients.
Dans l'assistant de création de la règle, il faut bien choisir l'option "No Delegation, but client may authenticate directly". Et pour les utilisateurs qui ont le "droit" d'utiliser cette règle, bien préciser "All Users". Du point de vue de TMG, le flux qui circule étant non authentifié, il rentre dans la catégorie anonyme.
La règle est maintenant crée.
Si vous essayez d'utiliser votre plateforme ainsi montée, vous rencontrerez une erreur d'authentification sur le serveur ADFS de type 401:
Ceci est un comportement connu lié à l'utilisation de TMG comme proxy standalone pour ADFS dans le cadre de la mise en œuvre d'un SSO.
Une première solution consiste à désactiver le mode de protection étendue.
Il faut aller dans le gestionnaire de IIS : Default Web Site / adfs / ls puis double cliquer sur l'icône "Authentication". Faire un clic droit sur la ligne "Windows Authentication" puis "Advanced Settings" et mettre le champ "Extended Protection" à Off.
Cette configuration rend la connexion à Office 365 complètement transparente pour les machines qui sont membres du domaine fédéré avec Office 365.
Une seconde solution consiste à forcer ADFS à faire l'authentification par formulaire avant de faire une authentification Kerberos.
Pour cela, il faut aller dans la console d'administration de IIS puis dans le répertoire Default Website\adfs\ls et explorer le répertoire en question.
Ensuite il faut éditer le fichier web.config (pensez à faire une sauvegarde avant). Recherchez la section suivante :
Il faut simplement mettre en premier la ligne suivante :
<add name="Forms" page="FormsSignIn.aspx" />
Pour obtenir le résultat suivant :
Cette configuration est moins transparente pour les utilisateurs mais est adaptée pour les accès depuis des machines partagées par exemple.
Il reste à tester ce qui a été mis en place. C'est l'objet de l'article suivant : https://blogs.technet.com/b/dcaro/archive/2011/05/09/office-365-mise-en-place-de-la-federation-identite-partie-4.aspx