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 n'a pas beaucoup parlé est pourtant demandée par la quasi-totalité de mes clients professionnels : L'option de serveur de transit Azure AD Connect. Pour comprendre cette option, examinons d'abord la situation qu'elle est censée atténuer.
Comment fonctionne la synchronisation des identités Microsoft
Cette évolution des utilitaires de synchronisation - DirSync, son successeur AADSync, et enfin AD Connect - utilise une version réduite du service de méta-annuaire de Microsoft, diversement nommé MIIS, ILM, FIM, et depuis quelques mois, Microsoft Identity Manager (MIM). Ces services de méta-annuaire ont des connecteurs avec AD DS et Azure AD pour attirer les attributs dans les espaces de connecteurs. Un ensemble de règles de synchronisation détermine si ces attributs sont ajoutés dans un métavers qui contient la jonction des attributs d'identité sur site et des attributs Azure AD. Enfin, les règles de synchronisation sortante 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 avec des connecteurs configurés, des règles définies et un moteur de base de données (SQL Server Express ou SQL Server complet) pour contenir les espaces de connecteurs et le métavers. Il n'y a pas de tolérance de panne ou de redondance intégrée dans cette base de données sur serveur, et la mise en grappe n'est pas recommandée. Et si vous vous dites, je vais juste restaurer la base de données à partir des sauvegardes que j'ai faites, ce n'est pas supporté non plus. En fait, si le serveur meurt, vous devez soit désinstaller et réinstaller le service de synchronisation, soit restaurer l'ensemble du serveur à partir des sauvegardes.
Ce n'est pas aussi grave qu'il n'y paraît. Microsoft indique à juste titre que, bien que la synchronisation soit un service essentiel, il ne s'agit pas d'un service particulièrement sensible au temps ; l'intervalle de synchronisation par défaut et recommandé est de trois heures. Cela signifie que même s'il faut quelques heures pour reconstruire le service de synchronisation en cas de panne, vous ne manquerez probablement qu'un cycle de synchronisation au maximum. Les services informatiques des grandes entreprises n'aiment pas les zones d'ombre dans le temps de reprise de leurs systèmes de production. Dans la plupart des grandes entreprises, si un système est considéré comme très important, il doit être doté d'une certaine tolérance aux pannes ou d'une disponibilité accrue. Êtes-vous sérieux ? est un commentaire que j'ai reçu plus d'une fois lorsqu'une entreprise envisageait les capacités de haute disponibilité de DirSync ou d'AADSync.
Fonctionnement de l'option "serveur de transit" (staging server)
L'option "staging server" a été développée pour remédier à cette lacune. Bien qu'il ne s'agisse pas d'une véritable haute disponibilité, la mise en œuvre d'un serveur d'essai vous permettra de reprendre la synchronisation des identités en quelques minutes (une fois que vous aurez décidé de basculer sur ce serveur).
Pour configurer un serveur de transit (figure 2), vous devez procéder à une configuration d'Azure AD Connect identique à celle du serveur AD Connect principal, à une exception près : À la toute dernière étape, vous cochez l'option "staging server". Cette option permet d'éviter que les résultats de la synchronisation développés dans le service du serveur d'essai ne soient écrits dans Azure AD ou renvoyés dans AD DS. Cela signifie également que la synchronisation de l'écriture et du hachage des mots de passe est désactivée, car la première nécessite des modifications écrites dans AD DS, tandis que la seconde nécessite des modifications écrites dans Azure AD.
Figure 2 : Architecture AD Connect avec Staging Server
Récupération d'une défaillance d'AD Connect
En cas de défaillance du serveur AD Connect primaire, il vous suffit d'exécuter à nouveau l'assistant de configuration AD Connect et de décocher l'option "staging server" (ainsi que l'option "password writeback" ou "hash synchronization" si vous l'utilisez). Cela permet de mettre à jour Azure AD et AD DS. Il est évident qu'il faut veiller à ce qu'un seul serveur AD Connect soit activé à la fois !
L'option "staging server" d'AD Connect est une nouvelle fonctionnalité qui sera bien accueillie par les grandes entreprises. Elle offre un temps de reprise des services beaucoup plus court que ses prédécesseurs et elle est simple à mettre en œuvre, sans exigences particulières en matière de matériel ou de logiciel. Je suis certain qu'elle deviendra une pratique de déploiement standard pour de nombreuses entreprises.
