Rendre le savoir accessible au plus grand nombre: ADFS

Bonjour à tous, aujourd'hui nouvel article concernant le changement du mode d’authentification des clients vers les services Azure.

La plupart du temps, pour intégrer certaines applications comme "Office 365" et unifier les authentifications en y ajoutant du SSO, les entreprises mettaient en place une infrastructure ADFS dans leur infrastructure "On-Premise".

La grosse contrainte de l'ADFS, c'est que cela demande une infrastructure importante et complexe surtout si l'on souhaite y ajouter de la haute disponibilité à savoir:

- 2 serveurs ADFS
- 2 Serveurs Azure AD Connect
- 2 Serveurs WAP
- Un load balancer entre les serveurs WAP

Comme vous pouvez le constater cela demande beaucoup de maintenance.

Pour pallier à ça, Microsoft à décider de créer "Azure AD Pass Through Authentication et Seamless SSO"

L'idée est également de ne pas stocker les mots passes dans "Azure AD" comme on le faisait avec ADFS.

Je ne vais pas vous faire une présentation du produit qui est déjà sortie il y a deux ans, Microsoft le fera bien mieux que moi.

https://docs.microsoft.com/fr-fr/azure/active-directory/hybrid/how-to-connect-sso

Le tableau ci-dessous résume les différences entre Azure AD Pass Through Authentication et Seamless SSO" et "ADFS".

La solution qui va nous intéresser le plus sera celle avec le "Pass-Through" car elle ne synchronise pas les mots de passe dans "AzureAD".

Pour pouvoir modifier la façon dont va s'authentifier les utilisateurs, il suffit de se connecter sur le serveur "Azure AD Connect" et de relancer l’exécutable ci-dessous.

L'assistant se lance.

Choisir "Change user sign-in"

Authentifiez-vous avec le compte principal pour Azure AD.

Si "ADFS" est coché, il vous suffit de cocher "Pass-through authentication" et "Enable single sign-on"

Authentifiez-vous avec un "compte administrateur du domaine On-premise"

L'assistant d' "Azure AD Connect"vérifie les composants.

Tout est prêt pour la reconfiguration d' "Azure AD Connect"

Vous pouvez également lancer la synchronisation à la fin du processus.

La reconfiguration se lance.

L'agent pour la fonctionnalité "Pass-through autentication" s'installe sur notre serveur.

Il configure ensuite l'agent "Pass-through autentication"

Activation du sso.

L'opération s'est correctement déroulée.

Nous pouvons également voir que notre domaine "FFO365.FR" n'est plus fédéré et est passé en mode "Managed".

Sur la console "Azure AD" nous pouvons voir la bonne configuration

Lors de la mise en place Azure AD Pass Through Authentication et Seamless SSO" un compte "AZUREADSSOACC" a été créé dans l'OU "Computer"

Le compte ordinateur "AZUREADSSOACC" est utilisé pour lors de la connexion à "Azure AD/O365" pour générer le ticket Kerberos utilisateur.

La clé Kerberos de l’ordinateur "AZUREADSSOACC" est partagée avec "Azure AD/O365".

La clé Kerberos de l’ordinateur "AZUREADSSOACC" peut et doit être changée régulièrement, ce que je conseille fortement.

Pour que le SSO soit complètement fonctionnel pour les utilisateurs, il faudra ajouter les exceptions ci-dessous dans internet Explorer:

https://autologon.microsoftazuread-sso.com

https://aadg.windows.net.nsatc.net

Pour connaitre les compatibilités des navigateurs je vous laisse le soin de consulter le lien ci-dessous.

https://docs.microsoft.com/fr-fr/azure/active-directory/hybrid/how-to-connect-sso

Nous allons créer notre GPO pour les utilisateurs.

Les deux liens ci-dessus seront a configurer sur le paramètre suivant:

User Configuration > Administrative Templates > Windows Components > Internet Explorer > Internet

Control Panel > Security Page.

Dans Assignment List. Entrer les valeurs suivantes :

Modifier ensuite le paramètre ci-dessous:

User Configuration > Administrative Templates > Windows Components > Internet Explorer > Internet

Control Panel > Security Page > Intranet Zone.

Activer Allow updates to status bar via script.

Je vérifie la bonne application sur mes postes.

Je vérifie ensuite la bon fonctionnement en allant sur le portail Office 365.

Haute disponibilité:

Si vous souhaitez mettre en place de la haute disponibilité, il vous faudra déployer d'autres agents sur d'autres serveurs qui doivent pouvoir communiquer sur les ports 443 et 80.

Pour cela lancer le lien ci-dessous:

http://aka.ms/getauthagent

Exécuter le programme:

Authentifiez-vous sur Azure.

Vérifiez ensuite sur le portail Azure AD la présence du deuxième agent.

Dans cet article nous avons pu voir comment changer l'authentification ADFS vers l’authentification Pass-Through et seamless SSO.

A bientôt. 😏

Bonjour à tous, aujourd'hui nous allons démarrer une série d'articles pour migrer les services utilisés pour Office 365.

L’objectif est de changer de système d'exploitation pour plus de sécurité et de pouvoir profiter des nouvelles fonctionnalités qu'apportent les dernières versions.

Les migrations ci-dessous seront donc effectuées et décrites sur plusieurs articles.

- Migration ADFS de la version Windows 2012 R2 vers Windows Server 2019.

- Migration Azure AD Connect de la version Windows 2012 R2 vers Windows Server 2019.

- Migration reverse proxy WAP de la version Windows 2012 R2 vers Windows Server 2019.

- Migration du serveur Exchange 2013 en mode Hybride vers un serveur Windows Server 2019 avec Exchange 2019.

Le premier article ci-dessous concerne donc la mise à jour de notre serveur ADFS en Windows 2012 R2 Server vers un nouveau serveur ADFS en Windows 2019 Server.

Ci-dessous le rappel de notre architecture avec nos serveurs .

Le plan de migration sera le suivant:

- Sauvegarde ADFS

- Import nouveau certificat sur le futur serveur ADFS.

- Ajout du nouveau serveur ADFS à la ferme (mode mixte).

- Modifier le serveur ADFS par défaut.

- Reconfigurer le WAP.

- Mise à jour du Schéma en version 88 (Windows 2019).

- Suppression de l'ancien serveur ADFS 2012.

- Augmenter le niveau de comportement de la batterie (FBL).

- Test du bon fonctionnement.

Dans un premier temps comme toujours, avant toutes migrations nous devons avoir une sauvegarde.

Il faudra sauvegarder la machine virtuelle et en plus nous allons sauvegarder la structure "ADFS" avec l'utilitaire "ADFS Rapid Restore Tool"

L'utilitaire est téléchargeable sur le lien suivant: https://www.microsoft.com/en-us/download/details.aspx?id=56569

L'installation est toute simple, il vous suffit de lancer le MSI précédemment téléchargé et de suivre les écrans ci-dessous.

Une fois l'installation terminée nous allons lancer une console Powershell sur le serveur ADFS.

Nous allons ensuite importer le module de sauvegarde avec la commande suivante:

Import-Module 'C:\Program Files (x86)\ADFS Rapid Recreation Tool\ADFSRapidRecreationTool.dll'

Nous vérifions ensuite le bon import avec la commande "Get-Module"

Nous allons maintenant lancer la sauvegarde de notre serveur ADFS avec la commande suivante:

Backup-ADFS -StorageType "FileSystem" -StoragePath C:\temp\backup_ADFS -EncryptionPassword "Password@123" -BackupComment "Backup_ADFS" -BackupDKM

La sauvegarde s'est terminée correctement (j'ai juste une erreur sur le certificat mais lié à un bug sur ma machine virtuelle, mais cela ne pose pas de problème car mon certificats est déjà sauvegardé).

On peut vérifier le bon export de la sauvegarde.

Nous allons maintenant nous positionner sur le nouveau serveur "ADFS2019" (voir schéma plus haut).

Nous allons importer notre certificat sur notre serveur.

Le certificat a correctement été importé.

Sur ce même serveur, nous allons maintenant ajouter le rôle "ADFS".

Le fait d'installer un serveur ADFS en Windows 2019 Server dans une ferme avec un serveur ADFS en Windows 2012 R2 est un mode appelé ferme ADFS en mode mixte.

Nous avons un serveur plus récent mais nous ne pourrons pas utiliser les dernières fonctionnalités tant que nous possédons des serveurs ADFS en "Windows 2012 R2" dans notre ferme.

Une fois l'installation terminée, nous allons pouvoir configurer notre serveur pour l'ajouter dans la ferme existante.

Cocher "Ajouter un serveur de fédération à une batterie de serveurs de fédération"

Ajouter un compte ayant des droits "admin du domaine" sur l'Active Directory.

Entrer le nom de "serveur de fédération principal", pour ma part "adfs.dude16.fr"

Sélectionner le certificat précédemment importé.

Entrer votre compte service ADFS.

Comme toujours, je vous recommande d'utiliser les comptes de services "gMSA" (https://ffo365.blogspot.com/2018/12/mise-en-place-de-comptes-gmsa.html)

Nous avons également la possibilité d'afficher le script de configuration de l'ADFS.

Pas d'erreurs sur les "conditions préalables".

Une fois la configuration terminée, il faudra redémarrer le serveur.

Nous allons nous connecter à nouveau sur le nouveau serveur ADFS et passer ce serveur en "Serveur ADFS principal"

Pour cela, lancer la commande suivante:

"Set-AdfsSyncProperties -Role PrimaryComputer "

Sur le serveur ADFS d'origine, nous allons lui indiquer qui est le nouveau serveur principal avec la commande suivante:

"Set-AdfsSyncProperties -Role SecondaryComputer -PrimaryComputerName ADFS2019"

Nous vérifions sur le nouveau serveur qu'il possède bien le rôle principal.

"Get-AdfsSyncProperties"

Nous vérifions également sur le serveur d'origine avec la commande suivante:

"Get-AdfsSyncProperties"

Nous allons devoir reconfigurer notre reverse proxy "WAP"

Lancer une console "PowerShell" sur le serveur "WAP" et lancer la commande suivante pour récupérer le "Certificate Thumbprint"

"dir Cert:\LocalMachine\My\"

lancer ensuite les lignes de commandes suivantes:

$trustcred = Get-Credential -Message "Enter Domain Administrator credentials"

Install-WebApplicationProxy -CertificateThumbprint "EE94546695BB75C11B4AB78E6FF49BB5285FF580" -FederationServiceName adfs.dude16.fr -FederationServiceTrustCredential $trustcred

Restart-Service adfssrv

Il faudra vous authentifier avec votre compte de service ADFS.

La reconfiguration c'est correctement terminée.

Lorsque nous mettons à niveau une ferme ADFS, il est impératif de mettre à jour notre Schéma Active Directory.

Pour cela, insérer l'iso de système "Windows Server 2019" et lancer la commande suivante:

"adprep /forestprep"

Même chose pour le domaine.

"adprep /domainprep"

Une fois la mise à jour du schéma terminée, nous allons nous connecter sur notre serveur "Azure AD Connect" et "Actualisé le schéma de l'annuaire"

Vérifier le bon fonctionnement de votre ADFS.

Nous allons maintenant supprimer notre ancien serveur ADFS pour le supprimer de la ferme.

Nous avons deux solutions:

- Le supprimer de la ferme avec la commande "Set-AdfsFarmInformation -RemoveNode "adfs2012.labdude.local""

- En désinstallant le rôle ADFS en mode graphique (ce que l'on va faire) ou en PowerShell avec la commande "Uninstall-WindowsFeature adfs-federation -IncludeManagementTools"