ADFS 3.0 sur Windows Server 2012 R2 avec Office 365
Windows Server 2012 R2 intègre une nouvelle version d’Active Directory Federation Services (ADFS), estampillée 3.0.
Si plusieurs changements notables ont été apportés, la nouveauté la plus marquante est sûrement la suppression du rôle ADFS Proxy, remplacé désormais par Web Application Proxy (WAP), un composant du rôle Remote Access. Notez au passage qu’ADFS 3.0 n’utilise plus la plateforme IIS.
Web Application Proxy permet de publier sur Internet des applications présentes en interne. Deux modes sont disponibles : une authentification via ADFS avant d’accéder aux ressources, et une publication en “pass-through”, sans authentification. Avec WAP, il est donc possible de publier des applications comme Outlook Web Access, un site SharePoint ou même un simple site Web IIS. Les scénarios de BYOD (Bring Your Own Device) et d’authentification multi-facteurs sont également facilités, notamment grâce au Device Registration Service et Workplace Join.
Cet article détaille l’installation d’une infrastructure ADFS 3.0 simple (mono-serveur) et la configuration d’une fédération avec un compte Office 365 pour assurer une authentification unique (SSO).
- Prérequis
- Installation et configuration du rôle ADFS 3.0
- Installation et configuration du rôle Web Application Proxy
- Configuration de la synchronisation Active Directory / Office 365
- Configuration de la fédération avec Office 365
- Tests de connexion
- Ajout d’une nouvelle adresse SMTP
Prérequis
Active Directory Federation Services 3.0
- Windows Server 2012 R2 (Standard ou Datacenter)
- Serveur joint au domaine
Web Application Proxy
- Windows Server 2012 R2 (Standard ou Datacenter)
- Serveur joint au domaine ou en WORKGROUP (plus sécurisé)
- Au moins une adresse IP publique configurée sur la machine
- Un nom de domaine externe ==> dans notre cas, adfs.home.maximerastello.com
Windows Azure Active Directory Sync
- Windows Server 2003 SP2 ou supérieur (x64 uniquement)
- Serveur joint au domaine (obligatoire)
- PowerShell 1.0 ou supérieur
- .NET Framework 3.5
- Accès à Internet
Note : l’installation du DirSync n’est pas possible sur un contrôleur de domaine
Edit : La version 1.0.6567.18 de l’outil autorise désormais l’installation du DirSync sur un contrôleur de domaine. Ce n’est conseillé qu’à des fins de tests.
PKI
- Autorité de certification interne
- Certificat externe pour la publication du serveur ADFS ==> solution recommandée en production.
OU - Certificat interne et publication de la CRL + déploiement du certificat racine sur toutes les machines (clients et serveurs) ==> solution choisie dans notre cas pour plus de facilité, non recommandée en production.
Office 365
Un compte actif avec au moins une licence utilisateur parmi les offres suivantes :
- Office 365 Moyenne Entreprise
- Office 365 Grande Entreprise (E1, E3 et Exchange Online)
Note : Office 365 Petite Entreprise ne permet pas la synchronisation AD
Commentaires
Je ne détaillerai pas dans cet article l’installation des prérequis pour la mise en place d’une infrastructure ADFS. Prévoyez bien évidemment un domaine Active Directory et trois machines sous Windows Server 2012 R2, la première pour le rôle ADFS, la seconde pour WAP et la troisième pour le DirSync.
Le serveur hébergeant ADFS doit être joint au domaine dans votre réseau interne, alors que les bonnes pratiques veulent que le serveur hébergeant WAP soit laissé en WORKGROUP et placé en DMZ.
Enfin, vous aurez également besoin d’une PKI interne ainsi qu’un compte Office 365 permettant la synchronisation AD.
Infrastructure
Voici un schéma classique d’infrastructure ADFS/WAP. Pour des raisons techniques, WAP sera installé sur un serveur joint au domaine. Attention cependant, le serveur doit être joignable depuis Internet, vous devez donc posséder au moins une adresse IP publique.
Installation et configuration du rôle ADFS 3.0
L’installation du rôle ADFS se fait via le Server Manager. Dans cet exemple, ADFS est installé sur le serveur nommé HOME-ADFS.
Lorsque l’installation du rôle est terminée, il faut configurer ADFS.
Dans notre cas, nous installons le tout premier serveur ADFS interne. Il est également possible de rajouter des serveurs ADFS à une ferme existante avec ce même assistant de configuration.
Vous devez ensuite spécifier les identifiants d’un compte administrateur du domaine pour la configuration du rôle.
Il faut ensuite entrer le nom du service ADFS, choisir un certificat et un nom d’affichage “user-friendly”. Dans notre cas, nous avons choisi adfs.home.maximerastello.com, home.maximerastello.com étant le domaine AD.
N’oubliez pas de créer un enregistrement DNS de type A pour que le nom d’hôte (ici adfs) pointe vers l’adresse IP de votre serveur ADFS. Un certificat doit également être généré par votre autorité de certification interne. Dans notre exemple, j’ai opté pour un certificat de type wildcard (*) couvrant *.maximerastello.com, et contenant un Subject Alternative Name (SAN) couvrant *.home.maximerastello.com.
Vous avez ensuite le choix entre utiliser un Group Managed Service Account (gMSA) ou un simple compte de domaine. L’avantage d’utiliser un gMSA est de ne pas avoir à se soucier du mot de passe du compte puisqu’il sera généré automatiquement. Pour plus d’informations, n’hésitez pas à consulter cette page.
Attention, si vous utilisez un gMSA, vous devrez créer une clé racine Key Distribution Services (KDS Root Key) avec la commande suivante. Cela permet de fixer une date d’utilisation antérieure (-10h) pour une utilisation immédiate :
Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))
Lorsque vous aurez renseigné un compte de service ou un compte du domaine, l’assistant se charge de créer l’enregistrement SPN automatiquement. Dans notre exemple, j’opte pour un GMSA en utilisant le compte adfs_sa.
L’assistant crée un enregistrement SPN de type HOST, qui peut également être créé manuellement avec la commande suivante :
setspn -s host/adfs.home.maximerastello.com home\adfs_sa
ADFS stocke toutes ses informations dans une base données. Vous pouvez soit utiliser Windows Internal Database (WID), soit spécifier un serveur SQL Server dédié. WID ne nécessite aucune installation supplémentaire, et est souvent suffisant pour la plupart des utilisations : elle supporte jusqu’à 8 serveurs ADFS dans une même ferme.
Je vous recommande de lire cet article afin de déterminer si votre infrastructure nécessite plutôt WID ou SQL Server.
Vérifiez ensuite que les informations sont correctes dans la première fenêtre. Lorsque vous passez à l’étape suivante, les prérequis sont automatiquement vérifiés et la moindre erreur est rapportée dans cette fenêtre.
Notez au passage que si vous possédez plusieurs contrôleurs de domaine dans votre infrastructure, vous devrez patienter un peu le temps que la clé racine KDS soit répliquée.
Pour vérifier que l’installation du serveur ADFS s’est déroulée correctement, vous pouvez tenter d’ouvrir l’URL suivante depuis une machine interne au domaine : https://fqdnduserviceadfs/adfs/ls/IdpInitiatedSignon.aspx. l’affichage d’une page de connexion prouve que la plateforme est fonctionnelle.
Installation et configuration du rôle Web Application Proxy
Pour publier le serveur ADFS sur Internet, il faut utiliser un proxy ADFS. Le rôle Proxy ADFS n’existe plus à proprement parlé dans Windows Server 2012 R2. Il a été intégré à une nouvelle fonctionnalité : Web Application Proxy.
L’installation de WAP se fait via le Server Manager, en choisissant le rôle Remote Access.
Il faut ensuite sélectionner le service de rôle Web Application Proxy.
Lorsque le rôle est installé, cliquez sur le lien afin de lancer l’assistant de configuration.
Web Application Proxy a besoin du nom du service ADFS pour interagir avec. Renseignez simplement le nom choisi durant l’installation (ici adfs.home.maximerastello.com) et saisissez les accès d’un compte ayant des permissions suffisantes pour s’y connecter.
En production, il est fortement recommandé de créer un compte de domaine dédié, et de le rajouter dans le groupe des administrateurs locaux de chaque serveur ADFS.
Sélectionnez ensuite le certificat externe qui sera utilisé par les clients en provenance d’Internet. Il est fortement recommandé d’utiliser un certificat signé par une autorité de certification en ligne comme Verisign. Si vous ne souhaitez pas en acheter un, vous pouvez toujours utiliser un certificat de votre PKI interne, en prenant soin de déployer le certificat racine sur chaque machine et de publier sur Internet la CRL de votre autorité.
Terminez la configuration du rôle en validant les informations. Votre serveur ADFS est désormais accessible à l’adresse spécifiée. Depuis l’extérieur, tentez d’accéder à la même URL : https://fqdnduserviceadfs/adfs/ls/IdpInitiatedSignon.aspx.
Configuration de la synchronisation Active Directory / Office 365
Tout d’abord, Vous devez vérifier que le domaine pour lequel vous souhaitez établir une synchronisation soit bien dans la liste des domaines acceptés sur la page https://portal.microsoftonline.com/Domains/DomainManager.aspx. Pour plus d’informations concernant la synchronisation d’annuaires, consultez cette page.
Avant d’établir une synchronisation d’annuaire entre votre infrastructure et Office 365, vous devez activer le service dans les paramètres de votre compte Office 365 puis télécharger l’outil Windows Azure Active Directory Sync, à l’adresse https://portal.microsoftonline.com/DirSync/DirectorySynchronization.aspx.
L’installation de l’outil DirSync doit se faire sur un serveur joint au domaine et doté du .NET Framework 3.5. Vous pouvez l’installer manuellement en insérant le CD d’installation de Windows Server 2012 R2 et en tapant la commande suivante :
Install-WindowsFeature NET-Framework-Core –Source D:\Sources\SxS
Lancez ensuite l’installation de l’outil de synchronisation. La première fenêtre demande de renseigner des accès administrateur à la plateforme Office 365.
Note : Ces informations sont enregistrées de manière sécurisée sur le serveur DirSync.
Entrez ensuite les identifiants d’un compte administrateur du domaine. Pour des raisons de sécurité, ces accès ne sont pas sauvegardés sur le serveur.
Vous pouvez décider d’activer le mode Hybride. Sans ce mode, les objets Active Directory sont synchronisés uniquement dans le sens ‘Infrastructure interne’ > ‘Office 365’. Si le mode hybride est activé, certains attributs des objets AD peuvent être modifiés depuis l’interface de gestion Office 365, notamment la liste des adresses SMTP d’un utilisateur (proxyAddresses).
Vous avez également la possibilité d’activer la synchronisation des mots de passe. Grâce à cette option, vos utilisateurs internes peuvent accéder à leur compte Office 365 avec le même mot de passe que leur compte Active Directory. Pour plus d’informations, consultez cette page.
Terminez l’assistant pour finaliser la configuration. Je vous conseille d’effectuer une première synchronisation dès que possible.
Il est également possible de lancer manuellement la synchronisation des annuaires en utilisant la console PowerShell installée avec l’outil DirSync. Elle se nomme DirSyncConfigShell et se trouve dans le dossier C:\Program Files\Windows Azure Active Directory Sync.
Tapez ensuite la commande suivante pour lancer une synchronisation manuelle :
Start-OnlineCoexistenceSync
Pour vérifier que la synchronisation s’est correctement effectuée, vous utilisez la console Synchronization Service Manager de Forefront Identity Manager 2012 R2.
La console, nommée miisclient.exe, se situe dans le dossier C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell.
Nous reviendrons plus en détail sur cette console dans un prochain article.
Configuration de la fédération avec Office 365
Pour configurer une fédération entre votre domaine Active Directory et Office 365, vous devez tout d’abord installer les outils nécessaires pour administrer la plateforme à distance. Les étapes détaillées se situent sur la page de gestion de l’authentification unique du portail : https://portal.microsoftonline.com/IdentityFederation/IdentityFederation.aspx.
Je vous recommande d’installer les outils suivants dans l’ordre indiqué, soit sur une machine dédiée à l’administration, soit directement sur le serveur DirSync :
- Microsoft Online Services Sign-in Assistant
- Module Windows Azure Active Directory pour Windows PowerShell : x64 / x86
Lancez ensuite la console PowerShell Windows Azure Active Directory et tapez la commande suivante :
Connect-MsolService
Renseignez vos accès Office 365 puis tapez la commande suivante pour vérifier la liste des domaines acceptés :
Get-MsolDomain
Identifiez le domaine à fédérer avec votre ADFS, ici home.maximerastello.com, et tapez la commande suivante :
Convert-MsolDomainToFederated -DomainName home.maximerastello.com
Tests de connexion
Votre fédération ADFS avec Office 365 est désormais prête. Pour tester son bon fonctionnement, connectez-vous simplement à Outlook.com en utilisant l’adresse https://outlook.com/votrenomdedomainefédéré, par exemple https://outlook.com/home.maximerastello.com.
Si vous êtes sur un réseau externe, vous serez automatiquement redirigé vers l’adresse du proxy ADFS que vous avez publié.
Si vous êtes sur un réseau interne, l’interface Exchange Online se lance directement, sans avoir besoin de rentrer des identifiants de domaine.
Ajout d’une nouvelle adresse SMTP
Lorsque vous rajoutez plusieurs domaines dans votre compte Office 365, il peut être intéressant de les rajouter à un compte utilisateur pour qu’il dispose de plusieurs alias sur sa messagerie Exchange.
Si vous n’utilisez pas le mode hybride, vous devez modifier manuellement chaque objet Active Directory puis effectuer une synchronisation manuelle.
Ouvrez la console Active Directory Users and Computers et activez l’affichage avancé afin d’accéder à l’onglet Attribute Editor.
Repérer l’attribut proxyAddresses puis rajouter l’entrée :
- smtp:adresseSMTP@domaine.com pour rajouter cette adresse en tant qu’alias simple.
- SMTP:adresseSMTP@domaine.com pour rajouter cette adresse en tant qu’alias et adresse de réponse.
Note : la casse du mot clé “SMTP” est donc importante
Une double synchronisation manuelle est nécessaire pour exporter les changements dans Office 365 :
Vérifiez ensuite que les changements ont été répercutés dans la console Exchange Control Panel (https://outlook.com/ECP) :
Bonjour,
Petite question concernant ce type d’infrastructure, est ce qu’il faut avoir un domaine active directory en .local (ex : toto.local) ou directement en .fr (toto.fr) ?
Actuellement je suis en toto.local et j’ai un domaine externe toto.fr mais j’ai ajouté l’UPN (toto.fr) sur tous les utilisateurs.
Merci d’avance.
StarLord
Bonjour,
Pour que l’authentification unique via ADFS puisse se faire, l’UPN Active Directory doit correspondre à l’UPN Office365. Il faut donc en effet que tous vos utilisateurs aient un suffixe UPN identique au domaine utilisé dans Office365.
A partir du moment où le suffixe UPN est rajouté sur le domaine en question (console Active Directory Domain and Trusts) et que les utilisateurs devant s’authentifier via ADFS ont le bon suffixe UPN, il n’y a pas de problème.