Vous souhaitez rendre certaines de vos applications disponibles par le biais de la fédération, mais vous avez plusieurs forêts. Que pouvez-vous faire ? Si vous avez une confiance bidirectionnelle entre vos forêts, vous avez de la chance, car AD FS fonctionne très bien si vous avez une confiance bidirectionnelle entre les forêts. Mais que se passe-t-il si vous n'avez qu'une confiance à sens unique entre les forêts ? Que se passe-t-il alors ?
Pour ce scénario, nous supposerons que vous souhaitez fournir un SSO à plusieurs applications pour les utilisateurs de deux forêts différentes. Les applications peuvent résider dans l'une ou l'autre des forêts ou être basées sur le cloud (et donc dans aucune des deux forêts).
Avec une confiance réciproque entre vos forêts AD et votre serveur AD FS dans la forêt "A", AD FS est en mesure de fournir une authentification pour tous les utilisateurs des deux forêts et d'interroger AD pour leurs attributs en utilisant la confiance réciproque. Voir la figure 1. Tous les utilisateurs pourront utiliser la fédération pour se connecter aux applications fédérées.
Mais attendez, que se passe-t-il si les utilisateurs de l'une des forêts sont en fait des comptes de partenaires ou de clients et que la forêt n'est pas entièrement fiable, de sorte que nous n'avons qu'une confiance à sens unique ? Si le serveur AD FS est relié à la forêt partenaire, les utilisateurs partenaires peuvent s'authentifier auprès d'AD FS et AD FS peut interroger l'AD des partenaires pour obtenir leurs attributs. En outre, les utilisateurs internes de la forêt des employés peuvent s'authentifier auprès d'AD FS par le biais de la confiance à sens unique. Oh, mais attendez, nous avons un problème. Dans ce scénario, AD FS ne peut pas interroger la forêt de l'employé pour obtenir les attributs de l'utilisateur car le compte de service sous lequel AD FS s'exécute dans la forêt du partenaire n'a pas les autorisations nécessaires pour interroger AD dans la forêt de l'employé. L'authentification fonctionne, mais AD FS ne peut pas fournir d'informations supplémentaires pour remplir les demandes, de sorte que la connexion fédérée échouera pour la plupart des applications. Voir la figure 2.
Vous pensez peut-être que la solution à ce dilemme consiste à placer le serveur AD FS dans la forêt de l'employé, mais cela pose un certain nombre de problèmes. Placer le serveur AD FS dans la forêt de l'employé permettrait aux utilisateurs internes de la forêt de l'employé de s'authentifier auprès d'AD FS et permettrait à AD FS d'interroger la forêt de l'employé pour obtenir les attributs de l'utilisateur, mais les utilisateurs de la forêt du partenaire seraient laissés pour compte. Ils ne pourraient pas s'authentifier auprès d'AD FS parce que le sens de la confiance signifie que les applications de la forêt d'employés ne font pas confiance aux utilisateurs de la forêt partenaire. Les tentatives de connexion aux applications fédérées pour les utilisateurs partenaires échoueraient avant même d'avoir commencé.
Il existe au moins trois options pour résoudre ce dilemme :
- Limitez-vous à l'utilisation de certains attributs.
- Configurer un serveur AD FS pour chaque forêt.
- Placez le serveur AD FS dans la forêt partenaire, mais exécutez-le sous un compte de la forêt de l'employé.
Option 1 Se limiter à l'utilisation de certains attributs
Il s'avère qu'avec une confiance à sens unique, il est possible d'obtenir certains attributs pour l'utilisateur. Tant que vous n'essayez d'utiliser que les attributs fournis dans un scénario de confiance à sens unique, vous pouvez utiliser une confiance à sens unique pour authentifier l'utilisateur et créer les réclamations de la fédération.
Les attributs disponibles sont les suivants
- Nom - sous la forme DOMAIN\sAMAccountName
- Windowsaccountname - sous la forme DOMAIN\sAMAccountName
- Primarygroupsid - sous la forme d'un identifiant de sécurité (SID) tel que S-1-5-19
- Groupsid - une liste de SID de groupes dont l'utilisateur est membre, par exemple S-1-1-0, S-1-5-11
Option 2 Configurer un serveur AD FS pour chaque forêt
Du point de vue des fonctionnalités de base, l'option 2 fonctionne bien. Avec cette conception, les utilisateurs partenaires peuvent s'authentifier auprès de l'AD partenaire et l'AD FS partenaire peut interroger l'AD pour obtenir leurs attributs ; il en va de même pour les employés et la forêt d'employés. Toutefois, dans ce cas, outre la nécessité de disposer de deux fois plus de serveurs AD FS, le problème de la découverte du domaine d'origine refait surface. Voir la figure 3.
La principale pierre d'achoppement de cette option est que si un utilisateur tente d'accéder à l'application web interne 1 (voir figure 3), cette application ne sait pas si elle doit envoyer l'utilisateur s'authentifier sur le serveur AD FS de la forêt du partenaire ou de l'employé. Il existe plusieurs approches pour résoudre ce problème, mais il peut s'avérer très difficile à résoudre. Dans sa version standard, AD FS demande à l'utilisateur de choisir l'organisation ou le domaine vers lequel il doit être envoyé (par exemple, employé ou partenaire). Voir la figure 4.
Option 3 Placer le serveur AD FS dans la forêt partenaire, mais l'exécuter sous un compte de la forêt des employés
Examinons maintenant l'option 3 - le serveur AD FS réside dans la forêt partenaire et fonctionne sous un compte de service de la forêt de l'employé. Cette conception couvre l'essentiel. Les utilisateurs de la forêt partenaire peuvent s'authentifier auprès de l'AD partenaire et AD FS peut interroger l'AD partenaire pour obtenir les attributs de l'utilisateur, car la confiance AD unidirectionnelle permet aux utilisateurs de la forêt de l'employé d'effectuer des recherches AD dans la forêt partenaire. Les utilisateurs de la forêt de l'employé peuvent s'authentifier auprès de l'AD de l'employé et AD FS peut interroger l'AD de l'employé pour obtenir les attributs de l'utilisateur car le compte de service pour AD FS est membre de la forêt de l'employé.
Comme il n'y a qu'un seul serveur AD FS dans ce scénario, il n'y a pas de problème de découverte du domaine d'origine. Les applications internes n'auront pas besoin de demander aux utilisateurs d'identifier le serveur AD FS à utiliser pour leur authentification, ce qui simplifie l'expérience de l'utilisateur. En outre, vous n'avez besoin que de la moitié des serveurs requis pour l'option 2. Voir la figure 5.
Si vous pensez que cette option est la solution idéale pour tous les scénarios AD FS à confiance unidirectionnelle multi-forêts, sachez qu'elle ne fonctionne pas s'il y a plus de deux forêts qui ne se font pas confiance l'une à l'autre. AD FS ne peut s'exécuter que sous un seul compte de service, il ne peut donc y avoir qu'une seule connexion non fiable pour que cette solution fonctionne.
Résumé :
Comme le montre le tableau suivant, chaque option présente des avantages et des inconvénients et vous devez donc choisir celle qui correspond le mieux à votre situation.
| Option | Fonds forestiers | Attributs | Problème de découverte du royaume d'origine |
| 1 | Prise en charge de plusieurs fiducies à sens unique | Limitée | Non |
| 2 | Aucune confiance n'est requise | Tous | Oui |
| 3 | Une seule confiance à sens unique | Tous | Non |
Références :
- Permettez aux utilisateurs de votre Active Directory d'accéder à vos applications et services de gestion des sinistres
https://technet.microsoft.com/en-us/library/dd807071%28WS.10%29.aspx
"Employés ayant des comptes d'utilisateur dans n'importe quelle forêt à laquelle cette forêt fait confiance (par le biais d'une confiance réciproque avec Windows)". - Services de fédération d'Active Directory (AD FS) 2.0
https://technet.microsoft.com/en-us/library/adfs2%28WS.10%29.aspx - HomeRealmDiscoveryPage Aperçu de la classe
https://msdn.microsoft.com/en-us/library/ee895364.aspx
