Microsoft continue de travailler sur un point sensible de sa stratégie d'identité hybride : Le défi que représente le déploiement de son pont d'identité entre les services de domaine Active Directory (AD DS) dans les locaux et Azure Active Directory dans le nuage. Ce pont se compose d'AD FS pour la fédération et d'une succession d'utilitaires, dont le point culminant est Azure AD Connect, pour la synchronisation des identités. Azure AD Connect a récemment été mis à la disposition de tous, et il permet de relier votre AD DS sur site (et d'autres types de bases de données d'identité telles que SQL Server ou LDAP) à Azure AD plus facilement que ses prédécesseurs DirSync et Azure AD Sync.
Les nouvelles fonctionnalités d'AD Connect
AD Connect (pour en savoir plus ici) est un utilitaire de configuration qui simplifie la mise en place de la synchronisation des identités entre une courte liste de sources d'identité populaires (y compris les services de domaine Active Directory, bien sûr) et, en option, l'authentification unique avec AD FS. Il simplifie grandement le processus de configuration et offre également de nouvelles fonctionnalités telles que l'écriture d'attributs liés à un appareil d'Azure AD vers AD DS.
Une nouvelle fonctionnalité dont on a toutefois peu parlé est pourtant celle que pratiquement tous mes clients professionnels réclament : l'option de serveur de transit Azure AD Connect. Pour bien comprendre cette option, examinons d'abord la situation qu'elle est censée résoudre.
Comment fonctionne la synchronisation des identités Microsoft
Cette évolution des outils de synchronisation – DirSync, son successeur AADSync, puis enfin AD Connect – repose sur une version allégée du service de métadirectory de Microsoft, connu sous différents noms : MIIS, ILM, FIM et, depuis quelques mois, Microsoft Identity Manager (MIM). Ces services de métadirectory disposent de connecteurs vers AD DS et Azure AD afin d’extraire des attributs vers des espaces de connexion. Un ensemble de règles de synchronisation détermine si ces attributs sont ajoutés à un métaverse qui regroupe à la fois les attributs d’identité sur site et les attributs Azure AD. Enfin, les règles de synchronisation sortantes déterminent quels attributs sont écrits dans Azure AD.
Figure 1 : Architecture du service AD Connect (avec l'aimable autorisation de Microsoft)
Cela nécessite un serveur sur lequel les connecteurs sont configurés, les règles définies, et un moteur de base de données (SQL Server Express ou SQL Server complet) pour héberger les espaces de connecteurs et le métaverse. Cette base de données sur serveur n'intègre ni tolérance aux pannes ni redondance, et la mise en cluster n'est pas recommandée. Et si vous vous dites « je n'ai qu'à restaurer la base de données à partir des sauvegardes que j'effectue », sachez que cela n'est pas pris en charge non plus. En résumé, si le serveur tombe en panne, vous devez soit désinstaller puis réinstaller le service de synchronisation, soit restaurer l'intégralité du serveur à partir des sauvegardes.
Ce n'est pas aussi grave qu'il n'y paraît. Microsoft affirme à juste titre que, bien que la synchronisation soit sans aucun doute un service essentiel, elle n'est pas particulièrement sensible au facteur temps ; l'intervalle de synchronisation par défaut et recommandé est de trois heures. Cela signifie que, même s'il peut falloir quelques heures pour rétablir le service de synchronisation en cas de panne, vous ne manquerez probablement qu'un seul cycle de synchronisation au maximum. Les services informatiques d’entreprise, cependant, n’apprécient guère les zones d’ombre concernant les délais de reprise de leurs systèmes de production. Dans la plupart des grandes entreprises, si un système est considéré comme hautement critique, il doit intégrer une certaine tolérance aux pannes ou une disponibilité renforcée. « Vous êtes sérieux ? » : voilà un commentaire que j’ai entendu plus d’une fois lorsqu’une entreprise envisageait d’utiliser les fonctionnalités de haute disponibilité de DirSync ou d’AADSync.
Fonctionnement de l'option "serveur de transit" (staging server)
L'option du serveur de transit a été développée pour pallier cette lacune. Bien qu'il ne s'agisse pas d'une véritable haute disponibilité, la mise en place d'un serveur de transit vous permettra de reprendre la synchronisation des identités en quelques minutes (une fois que vous aurez décidé de basculer vers celui-ci).
Pour configurer un serveur de transit (Figure 2), vous devez suivre la même procédure de configuration d’Azure AD Connect que pour le serveur AD Connect principal, à une exception près : à la toute dernière étape, vous devez cocher l’option « serveur de transit ». Cela empêche que les résultats de la synchronisation générés par le service du serveur de transit ne soient enregistrés dans Azure AD ou renvoyés vers AD DS. Cela signifie également que la réécriture des mots de passe et la synchronisation des hachages de mots de passe sont désactivées, car la première nécessite que les modifications soient enregistrées dans AD DS, tandis que la seconde nécessite qu’elles soient enregistrées dans Azure AD.
Figure 2 : Architecture AD Connect avec Staging Server
Récupération d'une défaillance d'AD Connect
En cas de panne du serveur AD Connect principal, il vous suffit de relancer l'assistant de configuration d'AD Connect et de décocher l'option « serveur de transit » (ainsi que celles relatives à la réécriture des mots de passe ou à la synchronisation des hachages, si vous les utilisez). Cela permet d'activer les mises à jour vers Azure AD et AD DS. Bien entendu, veillez à ce qu'un seul serveur AD Connect soit pleinement activé à la fois !
L'option « serveur de transit » d'AD Connect est une nouvelle fonctionnalité qui sera très appréciée par les grandes entreprises. Elle permet un temps de reprise de service bien plus court que ses prédécesseurs et est simple à mettre en œuvre, sans nécessiter de matériel ni de logiciel spécifique. Je suis convaincu qu'elle deviendra une pratique de déploiement courante pour de nombreuses entreprises.
