Nous avions déjà commencé un premier article concernant la synchronisation des comptes utilisateurs Active Directory avec Office 365 ici : http://www.alexgiraud.net/blog/Lists/Billets/Post.aspx?ID=203 puis un autre article pour configurer les composants clients et activer automatiquement les utilisateurs synchronisés : http://www.alexgiraud.net/blog/Lists/Billets/Post.aspx?ID=211 Dans ce 3ème volet, ce sera l'authentification SSO avec ADFS qui sera traité.
Comment permettre une authentification unique (SSO) entre votre les identités Active Directory et Microsoft Online avec les services ADFS
Nous avons donc provisioné des comptes directement sur Office 365, mais vous avez bien compris cette problèmatique de gestion de mot de passe. Il n'est pas possible d'utiliser des composants comme PCNS, alors pour valider une authentification unique pour les collaborateurs, seul la fédération ADFS sera possible. Attention, pour prendre en compte les utilisateurs nomades il faudra que vos services ADFS soient également accessible depuis Internet.
L'objectif est donc de prendre en compte que les utilisateurs ne connaissent seulement que leur mot de passe Active Directory local à l'entreprise. Le mot de passe associé à leurs comptes synhcronisés sur Office 365 ne sera pas connu par ces collaborateurs. L'accès ne pourra être effectué qu'avec un jeton SAML donc.
Petite précision à prendre en compte pour ma présentation ici, c'est que j'utilise des machines virtuelles. Je vais donc utiliser le même nom de domaine et n'utiliser que des certificats issus de ma PKI privée tant que possible. Le cas échéant, je prendrai des certificats d'évaluation si nécéssaire.
Donc la première partie consiste à établir une architecture bien précise afin de pouvoir prendre en compte l'ensemble des contraintes et répondre aux besoins d'une entreprise. Pour cela nous utiliserons donc un serveur ADFS sur le réseau principal. Ce serveur ADFS sera utilisé pour les accès fédérés des utilisateurs locaux, lors de leurs présence en entreprise. Nous utiliserons un serveur Proxy ADFS en périmétrie, ce dernier servira aux utilisateurs nomades. De manière simplifié, cela donnerai ceci :
Vous trouverez des détails complémentaires relatifs à ADFS et Office 365 sur le site de Microsoft : http://onlinehelp.microsoft.com/fr-fr/office365-enterprises/ff652539.aspx
Prérequis pour la mise en œuvre d'ADFS pour l'authentification unique avec Office 365 :
Dans le cadre de ma maquette, je n'ai pas assez de mémoire pour configurer un serveur Proxy ADFS. J'utiliserai donc un seul serveur ADFS. Par contre, j'ai une connexion Internet avec une adresse IP dynamique, … je vais avoir quelques soucis pour stabiliser le tout donc inutile de vous expliquer tout ce que j'ai dû faire pour parvenir à le mettre en œuvre dans mon scénario très particulier qui n'est absolument pas représentatif d'un environnement de production d'entreprise.
Alors pour commencer, il nous faut définir une url ADFS. Celle-ci sera utilisée par l'ensemble des collaborateurs, donc l'url doit être au moins routable sur Internet. Le nom de domaine devra donc être alexgiraud.eu. Prenons donc https://adfs.alexgiraud.eu . Cet enregistrement devra donc être renseigné auprès de mon provider DNS pour résoudre d'adresse IP publique de mon Reverse Proxy, ou de mon serveur Proxy ADFS si ce dernier est en DMZ publique.
Si comme moi vous utilisez un domaine DNS différent en interne, alors il faudra créer une zone DNS dans votre forêt Active Directory identique à votre zone DNS publique, mais pour résoudre cette fois-ci l'adresse IP interne de votre serveur DNS. Attention, cette derniète étape implique donc qu'il vous faudra copier la zone DNS une première fois depuis votre provider vers votre serveur interne, puis de la maintenir à jour lors de chaque modification.
Il faut donc procéder au téléchargement et à l'installation des composants Microsoft ADFS 2.0. Ensuite se reporter à la documentation et en fonction de votre architecture (Bases de données, ferme, haute disponibilité, …). Il est inutile ici que je vous décrive l'installation des services ADFS. Nous verrons surtout la configuration avancée . Au niveau certificat, il faut surtout en avoir un utilisant le nom CN : adfs.alexgiraud.eu (le nom public ADFS, utilisé aussi bien en interne qu'en externe comme expliqué ci-dessus).
Obsolète (à ignorer, voir plus bas) : Vérifiez que vous avez bien installé les patchs suivants, le cas échéant les appliquer sur le(s) serveur(s) ADFS :
Update : En fait le nouvel Update 1 d'ADFS 2.0 qui vient tout juste de sortir : http://support.microsoft.com/kb/2607496 prend en charge les deux précédents patchs. Alors, vous pouvez uniquement installer cet Update 1 ; d'autant qu'il comporte des améliorations prévues pour Office 365 J
Quand tout est OK, vous devriez pouvoir accéder en interne à l'url https://adfs.alexgiraud.eu sans aucunes erreurs, ni avertissements.
Ensuite, il faudra aussi installer le module PowerShell en fonction de votre version, pour la version x64 : https://bposast.vo.msecnd.net/MSOPMW/3300.101/amd64/Administrationconfig-fr.msi et éventuellement la X86 si ça vous intéresse : https://bposast.vo.msecnd.net/MSOPMW/3300.101/i386/Administrationconfig-fr.msi
N'oubliez pas que ce composant PowerShell nécéssite l'agent de connexion Microsoft Online, comme expliqué dans les précédents articles (x64 : https://bposast.vo.msecnd.net/msoidcli/amd64/en/msoidcli.msi )
Il faut penser à ajouter dans votre Active Directory, l'ajout de l'UPN du domaine Office 365.
Maintenant que tout est installé et préparé, au niveau de la page d'administration Office 365, vous trouverez un menu pour configurer l'authentification unique
Tout un guide vous permet de suivre pas à pas ce qu'il faut configurer afin de mettre en place l'authentification unique. En d'autres termes, cela se passe en PowerShell
Alors se connecter à Office 365 à l'aide de vos identifiants :
import-module MSOnline
$cred=Get-Credential
Connect-MsolService -Credential $cred |
Ensuite il suffit de connecter au contexte ADFS avec la commande Set-MsolAdfscontext –Computer adfs.alexgiraud.local (à remplacer le FQDN de votre serveur ADFS) ; un identifiant AD vous sera demandé, celui de votre Active Directory.
Puis il faut ajouter le domaine avec la commande New-MsolFederatedDomain –DomainName alexgiraud.eu (à remplacer avec votre domaine Office 365) ; Vous pouvez avoir un message indiquant que le domaine existe déjà et doit êter converti « New-MsolFederatedDomain : The domain already exists as a standard authentication domain. To convert the domain to identity federation, use convert-MSOLDomainToFederated. ». Donc, dans ce cas placez la commande Convert-MsolDomainToFederated –DomainName alexgiraud.eu .
Comment vérifier les bonnes étapes ?
Vous pouvez voir le nouveau relai, qui est apparu dans l'outil de gestion ADFS
Via PowerShell avec la commande : Get-MsolFederationProperty –DomainName alexgiraud.eu
Source : ADFS Server
ActiveClientSignInUrl : https://adfs.alexgiraud.eu/adfs/services/trust/2
005/usernamemixed
FederationServiceDisplayName : adfs.alexgiraud.eu
FederationServiceIdentifier : http://adfs.alexgiraud.eu/adfs/services/trust
FederationMetadataUrl : https://adfs.alexgiraud.eu/adfs/services/trust/m
ex
PassiveClientSignInUrl : https://adfs.alexgiraud.eu/adfs/ls/
PassiveClientSignOutUrl : https://adfs.alexgiraud.eu/adfs/ls/
TokenSigningCertificate : [Subject]
CN=ADFS Signing - adfs.alexgiraud.eu
[Issuer]
CN=ADFS Signing - adfs.alexgiraud.eu
[Serial Number]
5CEA1BFA92E58BB24BF1B07F7C4E6C9D
[Not Before]
30/09/2011 17:27:41
[Not After]
29/09/2012 17:27:41
[Thumbprint]
B367977A23062FBC4DD570395C822AF09677B52A
NextTokenSigningCertificate :
Source : Microsoft Office 365
ActiveClientSignInUrl : https://adfs.alexgiraud.eu/adfs/services/trust/2
005/usernamemixed
FederationServiceDisplayName : adfs.alexgiraud.eu
FederationServiceIdentifier : http://adfs.alexgiraud.eu/adfs/services/trust
FederationMetadataUrl : https://adfs.alexgiraud.eu/adfs/services/trust/m
ex
PassiveClientSignInUrl : https://adfs.alexgiraud.eu/adfs/ls/
PassiveClientSignOutUrl : https://adfs.alexgiraud.eu/adfs/ls/
TokenSigningCertificate : [Subject]
CN=ADFS Signing - adfs.alexgiraud.eu
[Issuer]
CN=ADFS Signing - adfs.alexgiraud.eu
[Serial Number]
5CEA1BFA92E58BB24BF1B07F7C4E6C9D
[Not Before]
30/09/2011 17:27:41
[Not After]
29/09/2012 17:27:41
[Thumbprint]
B367977A23062FBC4DD570395C822AF09677B52A
NextTokenSigningCertificate : |
Ou encore depuis le portail d'administration Office 365 : https://portal.microsoftonline.com/Domains/DomainManager.aspx en affichant les propriétés de votre domaine
Et en pratique, cela donne quoi ?
Par exemple, lorsque vous tentez de vous connecter au portail Microsoft Online, dès lors que vous avez indiqué un compte qui a comme suffixe DNS le domaine SSO configuré (utilisateur@alexgiraud.eu dans mon cas) alors la partie mot de passe devient grisée, et une connexion à votre ADFS devra être effectué.
Il n'est plus possible de réinitialiser les mots de passe utilisateurs (il y en a plus vraiment, donc adieu la gestion des mots de passe)
Au niveau d'une trace réseau http, on voit clairement lors de la requête d'accès au portail Microsoft Online un accès à votre serveur ADFS
Et autre outil intéressant pour valider le SSO ADFS, c'est à partir de l'outil en ligne ExCRA (Exchange Connectivity Remote Analizer). Une version bêta est actuellement disponible pour tester les paramètres ADFS. Un lien direct ici : https://www.testexchangeconnectivity.com/#&&/wEXBAUFdGFiaWQFATEFBnRlc3RJZAUkMDAwMDAwMDAtMDAwMC0wMDAwLTAwMDAtMDAwMDAwMDAwMDAwBQ5pbnB1dENvbnRyb2xJZAUMU2luZ2xlU2lnbk9uBQFzBQExK1y7TLdP9I9NK/l+2gefC30nFcA=
Et pour les collaborateurs nomades ?
En effet, maintenant que vos collaborateurs internes peuvent correctement se connecter aux services Microsoft Online d'Office 365. Qu'en est-il de ces utilisateurs nomades ? Alors il faudra tout simplement publier les ressources de votre serveur ADFS. L'url publique devra être la même que celle utilisée en interne, à savoir https://adfs.alexgiraud.eu dans notre cas précis. Cette url devra donc permettre depuis l'éxtérieur d'accèder jusqu'à votre serveur ADFS via un Reverse Proxy, bien entendu. Et Reverse, disons … un serveur Microsoft Forefront TMG ou Forefront UAG bien entendu ;)
Concernant les Reverse Proxy ISA ou TMG, attention car le filtre http va bloquer (à juste titre) la longue requête qui tentera de le traverser. Le filtre http d'iSA/TMG ne va pas trop aimer et pretextera un été d'erreur : « 12217 The request was rejected by the HTTP filter », et inquera : « URL normalization was not complete after one pass ». Il faudra juste penser donc à configurer le filtre http pour votre règle de publication ADFS
Puis de désactiver la normalization d'URL
En effet voilà l'URL qui tente de traverser : http://adfs.alexgiraud.eu/adfs/ls/?cbcxt=&vv=&username=alexandreg%40alexgiraud.eu&mkt=&lc=1036&wa=wsignin1.0&wtrealm=urn:federation:MicrosoftOnline&wctx=MEST%3D0%26LoginOptions%3D2%26wa%3Dwsignin1.0%26rpsnv%3D2%26ct%3D1320574089%26rver%3D6.1.6206.0%26wp%3DMCMBI%26wreply%3Dhttps:%252F%252Fportal.microsoftonline.com%252Flanding.aspx%253Ftarget%253D%25252fDefault.aspx%26lc%3D1036%26id%3D271346%26bk%3D1320574088 un tant soit peu trop longue et trop de caracthères J
Alors depuis l'externe, les collaborateurs seront donc inviter à saisir leurs identifiants Active Directory via une authentification basique (par défaut)
A la validation, le serveur ADFS fournira donc un jeton SAML au client qu'il consomera directement aurpès des services de fédérations Microsoft Online pour asssurer le SSO. Le process est le même qu'en local. Alors, pour que cela soit plus « joli », on peut aussi très bien utiliser un formulaire par défaut en modifiant le fichier « C:\inetpub\adfs\ls\web.config » sur vos serveur ADFS afin de positionner le mode formulaire avant l'authentification IWA.
Le formulaire par défaut se présentera ainsi, mais bien entendu il est entièrement personalisable
Quelques petites astuces à ne pas oublier :