Si vous avez configuré ADFS (services de fédération Active Directory) pour authentifier les utilisateurs de votre domaine dans Office365, vous saurez que pour maintenir la communication entre votre service adfs et office365, vous avez besoin d'un certificat approuvé par les deux serveurs / services. Évidemment, vous pouvez utiliser des certificats générés par une autorité de certification publique, qui reviennent encore plus à l'aise puisqu'ils font déjà confiance aux deux parties, mais il est également possible d'utiliser des certificats auto-signés; il problema è che i certificati hanno una scadenza dopo la quale non sono più validi e quindi si rischia di interrompere la comunicazione tra i due siti.
Prémisse: qualsiasi operazione di cui parlerò in questo articolo va eseguita sul server ADFS principale.
Cosa bisogna fare quando il certificato utilizzato sta per scadere? Rinnovarlo prima che scada ovviamente 🙂 e dato che ci si potrebbe dimenticare (office 365 comunque vi avvisa) la cosa più comoda è abilitare l’auto rinnovo.
Prima di tutto verificate se l’auto certificate rollover è abilitato, da powershell date questi due comandi:
PS C:\Windows\system32> Add-PSSnapin microsoft.adfs.powershell
PS C:\Windows\system32> Get-ADFSProperties
La commande doit renvoyer des données similaires à ceci:
AutoCertificateRolloverAutoCertificateRollover : Vrai
CertificateCriticalThresholdCertificateCriticalThreshold : 2
Durée du certificat : 365
CertificateGenerationThreshold : 20
CertificatPromotionSeuil : 5
CertificateRolloverInterval : 720
Le premier élément vous indique si le basculement automatique est activé ou non, si ce n'est pas le cas, vous pouvez l'activer:
Set-ADFSProperties -AutoCertificateRollover $ true
Les autres éléments indiquent d'autres paramètres intéressants:
CertificateGenerationThreshold: indique combien de jours avant l'expiration du certificat, votre serveur adfs générera automatiquement un nouveau certificat
CertificatPromotionSeuil: combien de jours avant l'expiration du certificat la promotion du certificat secondaire au certificat principal est effectuée (oui, car lorsque le rollover automatique génère un nouveau certificat, il ne remplace pas réellement le principal mais en crée un secondaire qui coïncide avec le principal de telle manière que, avant l'expiration du mandant, le nouveau certificat est reconnu à temps par office365 puis promu au rang principal)
CertificateRolloverInterval: indique combien de minutes le service adfs vérifie s'il doit générer de nouveaux certificats
CertificateCriticalThresholdCertificateCriticalThreshold: indique combien de jours avant l'expiration adfs force la génération d'un nouveau certificat même s'il n'y a pas de temps pour le répliquer sur les services office365 (cas extrême)
Ici vous trouverez la page officielle avec tous les paramètres et propriétés des adfs: http://social.technet.microsoft.com/wiki/contents/articles/16156.ad-fs-2-0-understanding-autocertificaterollover-threshold-properties.aspx
Une autre commande très utile est de mettre à jour si vous souhaitez forcer la création d'un nouveau certificat:
Update-ADFSCertificate
auquel vous pouvez éventuellement ajouter le paramètre -Urgent mais très soigneusement car il met directement le nouveau certificat comme principal et si les informations / métadonnées / certificats ne sont pas instantanément communiqués à office365, nous perdons l'authentification, continuer à lire…
Eh bien pour l'instant, nous avons vu comment modifier les paramètres et comment générer de nouveaux certificats côté adfs…. mais si nous changeons le certificat principal et ne le communiquons pas à office365, évidemment, le certificat ne sera pas considéré comme valide et donc tout sera bloqué (ou les utilisateurs ne seront plus authentifiés). Alors, comment transférer les métadonnées vers office365 peut-être automatiquement? Heureusement, Microsoft nous aide avec ce script:
https://gallery.technet.microsoft.com/scriptcenter/Office-365-Federation-27410bdc
est un script PowerShell, vous devez le télécharger et l'exécuter, vous devez avoir un utilisateur administrateur du domaine local et un utilisateur administrateur d'Office365, Je t'apporte tous les prérequis, rien de particulièrement complexe mais assurez-vous de les avoir tous:
Pour exécuter cet outil avec succès:
- Vous devez vous assurer que vous avez installé la dernière version du Module Microsoft Online Services pour Windows PowerShell
- Vous devez disposer d'un AD FS 2 fonctionnel.0 Service de la Fédération
- Vous devez avoir accès aux informations d'identification de l'administrateur général pour votre client Office 365
- Vous devez avoir au moins un domaine vérifié dans le client Office 365 doit être de type «Federated’
- Cet outil doit être exécuté sur un serveur de fédération accessible en écriture
- L'utilisateur actuellement connecté doit être membre du groupe Administrateurs local
- Le module Microsoft Online Services pour Windows PowerShell doit être installé. Vous pouvez télécharger le module depuis http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff652560.aspx
Ok si nous sommes d'accord avec les prérequis, nous pouvons exécuter le script qui vous demandera les deux informations d'identification (sur place e office365) et à la fin de l'exécution il générera un script en C: Office365-Scripts et il créera automatiquement une tâche planifiée qui exécutera le script tous les jours. Ce script se chargera de transférer vers office365 toutes les modifications des métadonnées, y compris les modifications des certificats; de cette façon, nous sommes sûrs qu'il y aura chaque jour une synchronisation entre ce que nous avons sur le serveur adfs et ce que nous avons sur office365. De cette façon, nous avons fermé le cercle en ce qui concerne la gestion de l'AutoCertificateRollover.
Pour plus de clarté, je résumerai brièvement comment tout le tour devrait fonctionner avec le rollover automatique configuré:
1) Lorsque vous arrivez au terme défini par le paramètre CertificateGenerationThreshold un nouveau certificat est généré qui sera défini comme secondaire
2) Ce nouveau certificat sera automatiquement communiqué / transféré à office365 grâce à la tâche planifiée qui exécute le script contenu dans C: Office365-Scripts tous les jours et à partir de là, il sera accepté comme valide par office365
3) À la fin définie par le paramètre CertificatPromotionSeuil le certificat secondaire deviendra principal et sera effectivement utilisé pour la communication et l'authentification entre adfs et office365 et sera considéré comme valide par office 365 car “le connaît déjà”