Aujourd’hui, je vous propose de voir ensemble comment mettre en place ADFS pour permettre l’identification au sein d’Office 365 et Azure Active Directory via la fédération des identités.
Introduction
L’objectif étant de pouvoir permettre à vos utilisateurs de s’authentifier sans avoir à partager le hash des mots de passe avec Microsoft (Password Hashed Synchronization).
Je ne vais pas justifier l’utilisation de l’option Password Hashed Synchronization… Pour moi, c’est nécessairement la solution la plus rapide à mettre en place et surtout la plus simple à gérer en termes de maintien en conditions opérationnelles.
Vous allez voir que la solution fédérée avec ADFS est plus lourde.
Globalement, pour un cas de Production, l’infrastructure minimum à mettre en place est équivalente au diagramme qui suit…
Si on détaille un peu ce qu’il se passe :
- Nous aurons besoin de définir une URL d’accès qui permettra de s’identifier pour accéder aux services. Dans mon cas j’ai choisi : login.akril.co.
- Cette URL doit être résolue depuis l’extérieur de votre réseau. Vous devez donc créer une entrée A auprès de votre registrar. L’adresse IP correspond à une IP publique associée à une appliance et/ou Load Balancer qui permettra de rediriger vers nos 2 serveurs ADFS WAP ou proxy ADFS. C’est par là que vos utilisateurs « externes » accéderont au service lorsqu’ils ne sont pas dans votre LAN.
- Les 2 serveurs WAP sont au sein de votre infrastructure mais comme ils sont en DMZ ; ils ne sont pas joints au domaine (WORKGROUP) pour des raisons de sécurité.
- Vous avez besoin de 2 serveurs pour assurer la haute disponibilité. C’est eux qui sont en frontal des 2 serveurs ADFS afin d’éviter de mettre des serveurs membres – qui plus est ADFS – directement en DMZ.
- Cette URL d’accès doit également être connue au sein de votre LAN. Dans ce cas, elle pointera également vers un VIP interne qui assurera la haute disponibilité et redirigera vers vos 2 serveurs ADFS.
- Dans le cas d’un accès en interne, vous ne passez donc pas les serveurs WAP mais vous vous identifiez directement auprès des serveurs ADFS.
- L’ADFS vérifiera votre identité avec l’aide de l’Active Directory (DC).
Comme vous pouvez le voir, si vous optez pour ce type d’infrastructure c’est plus lourd : 2 serveurs ADFS, 2 serveurs WAP, Load Balancer (et donc appliance réseau pro) – en plus des DC et de l’AAD Connect dont vous disposez déjà.
En effet, dans ce scénario l’infrastructure ADFS + WAP devient critique car si vos 2 serveurs WAP et/ou vos 2 serveurs ADFS sont down – il devient alors impossible d’accéder à vos services Cloud.
Dans mon scénario, j’effectue ce design en environnement de Lab, j’ai donc réduit à 1 serveur ADFS et 1 serveur WAP. Dans ce cas, l’infrastructure cible sera donc la suivante :
D’où l’intérêt de bien comprendre techniquement comment ça se passe car si vous déployez ce type d’infrastructure au sein de votre Production, il est possible que vous soyez sur une infrastructure multi-sites et ayez même besoin de davantage de serveurs ADFS, Proxy. 😉
Certificat SSL pour votre ADFS
Qui dit authentification dit mot de passe… Et dans ce cas, vous vous doutez que notre URL d’accès sera évidemment sécurisée en https. Vous devez donc disposer d’un certificat SSL associé à l’URL de connexion que vous souhaitez créer. Non, pas de certificat auto-signé (au cas où vous auriez eu la question). 🙂
Commencez par générer un CSR depuis votre IIS Manager sur votre serveur ADFS (ou n’importe quel autre serveur).
Ne vous trompez pas sur le Common Name qui doit correspondre exactement à l’URL que vous souhaitez protéger.
Une fois que vous disposez de votre CSR, vous pouvez demander à votre fournisseur de créer un certificat SSL.
Cette partie dépend évidemment de votre fournisseur. Pour ma part, j’utilise DigitCert dont je vous avais déjà parlé dans un ancien article.
Une fois que c’est fait, vous devez disposer d’un ou plusieurs certificats. Ces derniers doivent être ajoutés à l’ensemble des magasins sur votre serveur ADFS, WAP et AAD Connect.
Selon votre fournisseur, vous aurez peut-être plusieurs certificats à ajouter au sein de votre magasin.
Notre certificat est prêt.
Installation et configuration du serveurs ADFS
Provisionnez une nouvelle machine virtuelle et intégrez là au sein de votre domaine Active Directory. Depuis le Server Manager, installez le rôle ADFS puis démarrez l’assistant de configuration.
Si vous avez bien importé votre certificat SSL, vous devriez avoir le nom de l’URL que l’on se prépare à configurer directement dans le menu déroulant. Il ne reste plus qu’à la sélectionner.
Vous pouvez également choisir un nom pour la page ADFS de votre organisation (purement décoratif).
Vous devez maintenant définir un compte de service pour votre serveur ADFS. Si vous en avez la possibilité, je vous encourage à utiliser un compte de type gMSA qui est bien meilleur en termes de sécurité. Si ce n’est pas possible dans votre environnement, vous devrez créer un compte de service standard avec login + password (à l’ancienne).
Je vous encourage également à choisir une base de données de type WID – Windows Internal Database. Cela convient même pour les environnements de Production. La base de données dédiée SQL Server ne se justifie que pour certains cas rares d’environnements. Plus d’infos sur le lien suivant (nombre de serveurs ADFS, nombre d’applications, etc.).
Voilà, globalement c’est terminé pour votre serveur ADFS. Il n’y a rien de particulier à faire en plus sur ce composant. Si vous disposiez d’un 2nd serveur ADFS, vous devrez reprendre l’ensemble de l’assistant et choisir tout au début l’option Add a federation server to a federation server farm.
Création de votre serveur ADFS Proxy ou WAP (Web Application Proxy)
Comme expliqué précédemment, c’est ce serveur WAP qui va faire le lien avec « le monde extérieur » et votre serveur ADFS car on ne souhaite pas publier ce dernier sur Internet.
Le serveur WAP est donc configuré en WORKGROUP. Il n’est pas serveur membre de votre domaine Active Directory.
Installez le rôle Web Application Proxy depuis le Server Manager. Si vous utilisez Windows Server 2019, le rôle est désormais un peu caché… 😉
Démarrez le Server Manager, installez le Server Role appelé : Remote Access. Puis dans les Role Services, vous aurez alors accès à Web Application Proxy.
Une fois que l’installation est terminée, nous allons passer à la configuration. Veillez à bien être connecté avec un compte Local Administrateur.
Si ce n’est pas déjà fait, n’oubliez pas que vous devez disposer du certificat SSL également sur ce serveur ! 🙂
Depuis le Menu Démarrer, ouvrez l’outil Remote Access Management Console puis lancez l’assistant de configuration.
Définissez le nom de votre URL de connexion ainsi qu’un compte Local Administrator.
Si votre certificat est correctement installé, vous devriez pouvoir retrouver dans le menu déroulant le nom de votre URL. Il ne reste qu’à cliquer sur Next.
La configuration est terminée.
Vous pouvez également vérifier que votre serveur WAP et ADFS parviennent bien à communiquer en vérifiant le statut depuis la console Remote Access Management Console. Tout devrait être vert.
Création des entrées DNS (pour l’interne et l’externe)
Comme je l’ai déjà expliqué précédemment, notre URL d’accès doit être accessible depuis l’interne et l’externe de votre infrastructure.
- Pour l’interne, il nous suffit de créer une entrée DNS directement depuis le DNS Manager d’un Domain Controller. Le champs A devra pointer sur votre serveur ADFS (ou bien sur la VIP associée si vous disposez de 2+ serveurs ADFS).
Dans mon cas, je dispose d’un seul serveur ADFS, je fais donc pointer mon login.akril.co vers l’adresse IP interne de mon serveur ADFS.
- Pour l’externe, je dois créer une nouvelle entrée de type A dans mes DNS publiques. Dans mon cas, c’est Google Domains. Elle pointera sur l’adresse IP publique associée à mon réseau et je vais ensuite rediriger le flux 443/TCP depuis l’extérieur vers mon serveur WAP (10.0.0.10) en interne. Ce dernier redirigera ensuite le tout vers le serveurs ADFS… ça va vous suivez ? 🙂
Configuration de votre serveur AAD Connect
Dans mon cas mon serveur AAD Connect était actuellement configuré en mode Password Hashed Synchronization. Nous allons donc maintenant configurer notre AAD Connect afin qu’il ait conscience de notre infrastructure fédérée.
Attendez que votre dernière synchronisation soit terminée puis démarrez l’assistant AAD Connect.
Choisissez l’option Manage federation.
Vous ne devriez avoir que l’option Update SSL certificate. Suivez les étapes décrites ci-dessous.
Vous pouvez saisir manuellement le nom court ou long de votre serveur ADFS ou bien utiliser le bouton Browse pour qu’il soit détecté par votre AAD Connect.
Normalement, vous pouvez passer sans rien changer sur l’option Proxy servers car le serveur WAP n’est pas géré par le serveur AAD Connect.
Dans mon cas, je n’ai pas pu utiliser le format de certificat délivré par Digitcert via l’assistant d’AAD Connect. J’ai donc réalisé un export classique depuis le serveur ADFS. Le nouveau fichier généré porté l’extension pfx et j’ai pu le charger dans l’assistant AAD Connect.
Le certificat est confirmé comme étant valide.
La configuration est terminée.
Si besoin, vous pouvez relancer l’assistant d’AAD Connect pour voir un résumé de la configuration en mode Fédération (URL, certificat, etc.).
Activer la fédération via votre ADFS
Tous les éléments sont en place pour nous permettre de nous identifier en mode fédérée auprès de O365 et des services Cloud Microsoft. Il nous reste maintenant à activer notre domaine en mode fédéré pour que cela fonctionne.
Depuis le serveur AAD Connect, exécutez maintenant les quelques commandes PowerShell ci-dessous (à adapter à votre cas bien entendu) :
Connect-MsolService
Set-MsolADFSContext -Computer akl-adfs.akril.cloud
Convert-MsolDomainFederated -domain akril.co
Lorsque vous devrez vous identifier, utilisez un compte « pure-cloud » et non pas un compte synchronisé. Identifiez-vous avec un compte user@tenant.onmicrosoft.com.
Vous devriez avoir le retour suivant :
C’est terminé ! 🙂
Vérifier et tester la configuration
Avant de tester, sachez que vous pouvez vérifier que votre domaine est désormais fédéré depuis le portail Azure Active Directory, AAD Connect.
Si vous aviez bien ouvert les flux (depuis l’extérieur vers votre serveur WAP, 443/TCP), alors vous pouvez tenter de vous identifier en accédant à portal.office.com ou au portail Azure. Une fois votre adresse email saisie, vous devriez être redirigé vers votre page ADFS pour finaliser l’authentification. Si elle est validée, vous serez ensuite redirigé vers le service désiré. 🙂
C’est terminé ! 😉
Vous pouvez désormais vous identifier sans partager avec Microsoft la version hashé de vos mots de passe. Et ajoutons à cela que cette ferme ADFS peut être utilisée pour de nombreux autres besoins… 🙂
Si vous n’avez pas obtenu le résultat souhaité, n’hésitez pas à me solliciter via les commentaires.
