Entra Connect Sync mise à jour obligatoire septembre 2026 : pourquoi la version 2.5.79.0 est la mauvaise cible

Ce que dit vraiment l'échéance de la mise à jour obligatoire Entra Connect Sync septembre 2026

L'échéance de la mise à jour obligatoire Entra Connect Sync septembre 2026 est un arrêt de service pur et simple, pas une simple incitation de politique de support. Microsoft l'indique noir sur blanc sur la page Microsoft Entra Connect : historique des versions (date de page : 7 juillet 2026), et répète la même formulation sur la page recommandations de mise à niveau :

Mise à jour obligatoire requise : tous les services de synchronisation de Microsoft Entra Connect Sync cesseront de fonctionner le 30 septembre 2026 si vous n'êtes pas au minimum en version 2.5.79.0. En mai 2025, nous avons publié cette version avec une modification du service back-end qui renforce nos services.

La phrase suivante lève toute ambiguïté sur le mode de défaillance : « Si vous ne parvenez pas à effectuer la mise à niveau avant l'échéance, tous les services de synchronisation échoueront jusqu'à ce que vous effectuiez la mise à niveau vers la dernière version. »

Deux détails opérationnels figurant dans le même encadré sont faciles à survoler. Le fichier .msi de Connect Sync n'est désormais disponible que depuis le centre d'administration Microsoft Entra, et non plus depuis le Centre de téléchargement. Et le programme d'installation continue d'imposer les prérequis de base : .NET Framework 4.7.2 et TLS 1.2.

Une incohérence mérite d'être signalée, car elle piégera quiconque recoupe son inventaire. La bannière indique que la version 2.5.79.0 est sortie « En mai 2025 », mais l'entrée de statut de publication de la même page pour 2.5.79.0 indique « 09/01/2025 : publié en téléchargement via le centre d'administration Microsoft Entra », et le tableau de fin de support date la fin de support de 2.5.76.0 au « 01 septembre 2026 (12 mois après la sortie de 2.5.79.0) ». Le plancher de version est le fait déterminant ; le mois de sortie indiqué dans la bannière ne correspond pas au reste de la page.

Pourquoi la version 2.5.79.0 est la mauvaise cible de mise à niveau

À lire le titre au pied de la lettre, la démarche évidente consiste à installer exactement la version 2.5.79.0, cocher la case, et passer à autre chose. La même page Learn montre pourquoi cela n'achète que 23 jours de répit, et non une année.

La politique de fin de support de Connect Sync chez Microsoft est relative à la version, pas au calendrier : « Les versions de Microsoft Entra Connect Sync 2.x prennent fin 12 mois après la date de sortie d'une version plus récente. Cette politique est entrée en vigueur le 15 mars 2023. » Plusieurs versions plus récentes sont sorties depuis la 2.5.79.0, de sorte que son compte à rebours a déjà commencé et touche presque à sa fin :

Un administrateur qui effectue la mise à niveau vers le plancher imposé échappe à l'arrêt brutal du 30 septembre, mais sort du support le 23 octobre 2026, vingt-trois jours plus tard. La ligne voisine est encore plus révélatrice : la version 2.5.76.0 arrive en fin de support le 01 septembre 2026, un mois avant l'arrêt brutal - un serveur se trouvant une version en dessous du plancher est donc déjà hors support au moment où le service le coupe.

Trois autres raisons pour lesquelles le minimum est la mauvaise destination :

• La version 2.5.79.0 comporte un défaut d'interface connu. Microsoft répète la même remarque pour les versions 2.5.3.0, 2.5.76.0, 2.5.79.0 et 2.5.190.0 : « N'utilisez pas l'interface Synchronization Service Manager dans cette version. Cela peut provoquer l'échec de l'assistant Microsoft Entra Connect et du renouvellement automatique des certificats. Ce problème est corrigé dans la version 2.6.1.0. » Le défaut touche toutes les versions antérieures à la 2.6.1.0 : effectuer la mise à niveau vers le plancher ne permet donc pas d'y échapper.
• La version actuelle apporte des correctifs de sécurité. La version 2.6.84.0, publiée le 07/07/2026, est signalée par la mention « Cette version inclut des correctifs de sécurité. Nous recommandons de procéder à la mise à niveau vers cette version dès que possible », et son journal des modifications indique « Correction de plusieurs vulnérabilités de sécurité dans les dépendances tierces embarquées ».
• N'installez pas la version 2.6.79.0. Microsoft l'a rappelée : « La version 2.6.79.0 n'est plus disponible au téléchargement. Un problème a été identifié après sa publication et le programme d'installation a été rappelé. Les clients ayant installé cette version doivent la désinstaller et installer la dernière version disponible (2.6.84.0) de Microsoft Entra Connect Sync. »

Qui est réellement à risque : le piège de l'éligibilité à la mise à niveau automatique

La lecture intuitive est que seuls les administrateurs ayant délibérément désactivé la mise à niveau automatique sont exposés. Les règles d'éligibilité documentées disent le contraire. Selon Microsoft Entra Connect : mise à niveau automatique, la mise à niveau automatique n'est activée par défaut que lorsque toutes les conditions suivantes sont réunies :

• Une installation en paramètres Express ou une mise à niveau DirSync
• SQL Express LocalDB, ce qu'utilisent systématiquement les paramètres Express
• Le compte AD est le compte MSOL_ par défaut créé par les paramètres Express ou DirSync
• Moins de 100 000 objets dans le metaverse

C'est le profil des petits tenants. Un déploiement d'entreprise typique - installation personnalisée, SQL Server complet, compte de connecteur dédié, nombre d'objets à six chiffres - n'a jamais bénéficié de la mise à niveau automatique. Ce sont ces serveurs qui dérivent vers le 30 septembre, sans que personne n'ait rien désactivé pour en arriver là.

Microsoft publie les conditions précises qui rendent un serveur inéligible, chacune se traduisant par une chaîne de résultat nommée :

Il existe un piège plus subtil pour les tenants qui bénéficient effectivement de la mise à niveau automatique. Celle-ci ne délivre que les versions que Microsoft publie sur ce canal, et les notes de version précisent lesquelles : les versions 2.6.1.0 et 2.6.3.0 indiquent chacune que la mise à niveau automatique fera passer les installations existantes vers cette version, alors que la version actuelle 2.6.84.0 indique seulement « Publié en téléchargement via le centre d'administration Microsoft Entra ». Un serveur en bonne santé bénéficiant de la mise à niveau automatique se trouve donc très probablement en version 2.6.3.0 - confortablement au-delà de l'arrêt brutal, mais pas sur la version portant les correctifs de sécurité de juillet 2026. Microsoft formule lui-même ce compromis ainsi : « La version issue de la mise à niveau automatique peut ne pas inclure les dernières fonctionnalités. »

Deux autres éléments suspendent silencieusement la mise à niveau automatique. Laisser l'interface Synchronization Service Manager ouverte sur le serveur la met en pause (« la mise à niveau est suspendue jusqu'à la fermeture de l'interface »), et bloquer les URL de Microsoft Entra Connect Health au niveau du proxy la casse purement et simplement, car la mise à niveau automatique s'appuie sur l'infrastructure Health.

Détection : confirmer votre version et l'état de votre mise à niveau automatique

Ne faites pas confiance à la CMDB. Vérifiez chaque serveur Connect Sync directement, y compris les serveurs de secours (staging), qui sont tout autant soumis à l'échéance que le serveur actif.

Get-ADSyncAutoUpgrade
Get-ADSyncAutoUpgrade -Detail
(Get-ADSyncGlobalSettings).Parameters | Select-Object Name,Value
Get-ADSyncScheduler

C'est la paire de versions qui compte, plus que l'un ou l'autre chiffre pris isolément. Les conseils de dépannage de Microsoft pour un serveur qui se comporte mal après une mise à niveau automatique - KB 4038479, dont la liste de symptômes est circonscrite aux anciennes versions 1.x mais dont la description du mécanisme de mise à niveau reste générique - sont explicites : « Lors de la mise à niveau automatique, l'installation actuelle de Microsoft Entra Connect est mise à niveau, puis la version dans la configuration du serveur est mise à jour. Si les deux versions ne correspondent pas, Microsoft Entra Connect n'est que partiellement mis à niveau. » Un serveur affichant une version installée conforme mais dont le Microsoft.Synchronize.ServerConfigurationVersion est resté périmé n'a pas terminé le processus, et ne doit pas être compté comme corrigé. C'est de cette même page que proviennent la vérification SchedulerSuspended et le chemin du journal SyncEngine-AutoUpgrader.

Le filtrage du journal d'événements est le moyen le plus rapide de repérer les serveurs qui échouent depuis des mois : filtrez le journal Application sur la source Microsoft Entra Connect Upgrade et la plage d'ID d'événements 300-399. Les codes de résultat préfixés par UpgradeAborted sont transitoires et font l'objet de nouvelles tentatives. Les codes préfixés par UpgradeNotSupported signifient, selon les mots de Microsoft, que « l'attente est que le système soit mis à niveau manuellement ».

Remédiation : choisir la voie de mise à niveau, puis en éviter le piège

Microsoft documente trois stratégies de mise à niveau. Choisissez en fonction du nombre de serveurs et de la dérive de configuration, pas par commodité.

1. Mise à niveau automatique. Viable uniquement pour les installations Express encore éligibles. Aucune intervention manuelle n'est nécessaire, mais la version sur laquelle vous atterrissez peut être en retard sur la version actuelle.

2. Mise à niveau sur place. Microsoft la qualifie de « préférable lorsque vous disposez d'un seul serveur et de moins d'environ 100 000 objets », et énonce clairement le compromis : « En cas de problème lors d'une mise à niveau sur place, vous ne pouvez pas revenir en arrière sur la nouvelle version ou configuration ... » Deux points à anticiper :

• Si les règles de synchronisation prêtes à l'emploi ont changé entre les versions, une importation complète et une synchronisation complète s'exécutent ensuite. « Cette exécution peut prendre plusieurs heures, selon le nombre d'objets dans le périmètre du moteur de synchronisation. » La synchronisation delta est suspendue pendant ce temps ; la synchronisation des mots de passe se poursuit.
• Si vous avez modifié les règles de synchronisation prêtes à l'emploi, « ces règles sont réinitialisées à la configuration par défaut lors de la mise à niveau ».

Pour reporter la synchronisation complète en dehors des heures d'activité, décochez Démarrer le processus de synchronisation une fois la configuration terminée pendant la mise à niveau, puis inspectez et effacez les substitutions enregistrées :

Get-ADSyncSchedulerConnectorOverride | Format-List

foreach ($connectorOverride in Get-ADSyncSchedulerConnectorOverride)
{
    Set-ADSyncSchedulerConnectorOverride -ConnectorIdentifier $connectorOverride.ConnectorIdentifier.Guid -FullSyncRequired $false -FullImportRequired $false
}

Set-ADSyncScheduler -SyncCycleEnabled $true

Exécutez l'importation complète et la synchronisation complète différées dès que possible. Les abandonner définitivement laisse la nouvelle configuration non appliquée aux objets existants.

3. Migration swing. Construisez le nouveau serveur en parallèle, vérifiez-le, puis promouvez-le. Microsoft la présente comme l'« approche la plus sûre et la transition la plus fluide vers une version plus récente », précise que « la synchronisation n'est pas interrompue et ne fait courir aucun risque à la production », et donne un critère clair pour la choisir : les clients qui n'ont pas effectué de mise à niveau depuis 12 à 18 mois « devraient plutôt envisager une mise à niveau swing, car il s'agit de l'option la plus prudente et la moins risquée ». C'est également la voie prise en charge lorsque le système d'exploitation Windows Server doit être remplacé, puisque les mises à niveau de l'OS sur place ne sont prises en charge que de Server 2016, 2019 ou 2022 vers Server 2025.

Si vous optez pour un swing, décommissionnez entièrement l'ancien serveur. Le mode de défaillance est silencieux et lent : un serveur de synchronisation laissé en place « peut ne plus être en mesure d'accéder à l'Active Directory local ... mais peut encore se connecter à Microsoft Entra ID et faire revenir en permanence les valeurs d'attributs à chaque cycle de synchronisation ».

Deux défauts liés à la mise à niveau à surveiller

Fichier miiserver.exe.config modifié. Sur les versions 2.5.190.0 et 2.6.1.0, si ce fichier a été modifié précédemment - généralement en suivant d'anciennes recommandations pour prendre en charge la synchronisation des empreintes de mot de passe (password hash) dans des environnements FIPS -, la mise à niveau le laisse inchangé et la synchronisation échoue alors avec System.IO.FileLoadException: Could not load file or assembly 'System.Diagnostics.DiagnosticSource, Version=6.0.0.1'. Le contournement documenté consiste à sauvegarder le fichier dans %programfiles%\Microsoft Azure AD Sync\Bin, à ajouter la redirection de liaison (binding redirect) dans la section assemblyBinding, puis à redémarrer le service ADSync :

<dependentAssembly>
  <assemblyIdentity name="System.Diagnostics.DiagnosticSource" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-8.0.0.0" newVersion="8.0.0.0" />
</dependentAssembly>

La version 2.6.84.0 s'attaque à la cause racine : son journal des modifications indique que la mise à niveau automatique « fusionne désormais les modifications du client avec la nouvelle configuration et valide le résultat avant application », plutôt que d'écraser le fichier.

Connecteurs non standard. Si vous utilisez le connecteur Generic LDAP ou Generic SQL, actualisez la configuration du connecteur dans Synchronization Service Manager après une mise à niveau sur place. Si vous omettez cette étape, les phases d'exécution d'importation et d'exportation échouent avec une erreur « Assembly version in AAD Connector configuration ... is earlier than the actual version » dans le journal d'événements de l'application.

La question de Cloud Sync

Microsoft ouvre désormais sa propre page de mise à niveau par une invitation : « Plutôt que de mettre à niveau vers la dernière version de Microsoft Entra Connect, vérifiez si Cloud Sync vous convient. » C'est une option légitime, et les deux peuvent cohabiter dans la même forêt. Vérifiez toutefois le tableau des scénarios pris en charge avant de vous engager : Cloud Sync ne prend pas en charge la jonction hybride Microsoft Entra, Windows Hello for Business, les domaines de plus de 250 000 objets, le filtrage des objets d'annuaire sur des valeurs d'attributs, ni la topologie où les comptes utilisateurs se trouvent dans une forêt et les boîtes aux lettres dans une forêt de ressources.

Ce qui casse réellement le 1er octobre

« Tous les services de synchronisation échoueront » a un rayon d'impact bien plus large qu'un simple cycle de synchronisation en pause, car Connect Sync sert de transport à plusieurs éléments qui ne relèvent pas évidemment de la « synchronisation ».

• La synchronisation des empreintes de mot de passe (PHS) cesse de se mettre à jour. PHS est, selon les mots de Microsoft, « une extension de la fonctionnalité de synchronisation d'annuaire implémentée par Microsoft Entra Connect Sync ». Les changements de mot de passe effectués localement cessent d'atteindre le tenant, si bien que les utilisateurs continuent de s'authentifier avec des empreintes de plus en plus obsolètes.
• La détection des identifiants divulgués devient obsolète pour les comptes hybrides. La même page indique que « Password Hash Sync active également la détection des identifiants divulgués pour vos comptes hybrides ». Sans flux d'empreintes à jour, les correspondances sont évaluées par rapport à des mots de passe qui ont peut-être déjà été changés en local - et les utilisateurs à risque que personne ne corrige constituent déjà le maillon faible de cette chaîne.
• Le processus arrivée-mutation-départ (joiner-mover-leaver) s'arrête à la frontière du tenant. C'est le point le plus sensible en matière de sécurité. Désactiver ou supprimer un compte dans l'AD local ne se propage plus, si bien que l'identité cloud continue de fonctionner pendant toute la durée de la panne, et chaque départ survenu durant cette fenêtre devient un compte orphelin mais toujours activé. C'est précisément l'angle mort de la synchronisation d'identité hybride qui remonte comme constat d'audit des mois plus tard.
• L'appartenance aux groupes se fige. Les changements de groupes locaux cessent de piloter l'accès cloud, y compris l'appartenance aux groupes utilisés pour l'attribution de rôles ou le ciblage de l'accès conditionnel.

Traitez le 30 septembre comme un événement de gouvernance des identités, pas seulement de disponibilité. Ce n'est d'ailleurs pas le seul changement Entra daté en cours - le changement SSPR limité aux méthodes enregistrées du 9 novembre 2026 arrive environ six semaines plus tard.

Comment EtcSec détecte cela

Un Connect Sync bloqué ou partiellement mis à niveau ne se signale pas de lui-même dans le tenant. Il se manifeste sous forme de dérive identitaire, et c'est précisément ce qu'un audit peut détecter. Les contrôles Azure d'EtcSec font justement remonter ce type de dérive : HYBRID_ORPHANED_CLOUD_USER signale les utilisateurs hybrides toujours marqués comme synchronisés localement mais désactivés dans Entra ID, HYBRID_CLOUD_ONLY_PRIVILEGED repère les utilisateurs cloud-only détenant des rôles privilégiés en dehors de la gouvernance Tier 0 locale, UNRESOLVED_PRIVILEGED_MEMBERS signale les attributions de rôles privilégiés pointant vers des principals qui ne peuvent plus être résolus, et PA_ADMIN_STALE_ACCOUNT repère les attributions de rôles d'administration détenues par des utilisateurs qui ne se sont pas connectés depuis une période prolongée.

Côté local, le même audit couvre les comptes privilégiés et de service qu'une synchronisation cassée abandonne silencieusement, et il s'inscrit dans le type de flux d'audit reproductible qui détecte la dérive entre les échéances plutôt qu'après. Côté tenant, il s'intègre à la même revue de sécurité Entra ID que vous devriez déjà mener sur l'accès conditionnel, la MFA et les attributions de rôles.