Microsoft wprowadza zmianę dotyczącą firm korzystających jednocześnie z lokalnego Active Directory i chmurowego Entra ID. Od 1 czerwca 2026 r. Entra ID blokuje hard match w sytuacji, gdy lokalne konto z AD miałoby zostać połączone z istniejącym, mającym role administracyjne kontem w chmurze. To nie jest drobna korekta techniczna, tylko wyraźny sygnał, że przy kontach uprzywilejowanych Microsoft chce ograniczyć ryzykowne skróty w synchronizacji tożsamości.

Autor: 7 min czytania

W środowisku hybrydowym, gdzie firma korzysta z lokalnego Active Directory, Entra ID i Entra Connect albo Cloud Sync, jednym z ważniejszych mechanizmów jest dopasowywanie kont. Chodzi o to, by system potrafił rozpoznać, że użytkownik z lokalnego AD i użytkownik w chmurze to ta sama osoba. Microsoft opisuje dwa podstawowe sposoby takiego dopasowania: soft match i hard match.

Czym są soft match i hard match?

Soft match działa wtedy, gdy Entra próbuje połączyć obiekty na podstawie takich danych jak userPrincipalName albo adresy zapisane w proxyAddresses. Mówiąc prościej, system sprawdza login oraz adres e-mail i jeśli wartości się zgadzają, uznaje, że chodzi o tego samego użytkownika. Hard match działa inaczej. W tym przypadku dopasowanie opiera się na sourceAnchor albo immutableId, czyli trwałym identyfikatorze, który ma jednoznacznie wskazać konkretny obiekt. Microsoft traktuje to jako bardziej trwały sposób połączenia kont.

Rozróżnienie to ma znaczenie, bo hard match nie jest tylko technicznym „sklejeniem” dwóch wpisów. Gdy do niego dochodzi, zmienia się źródło zarządzania użytkownikiem. Konto, które wcześniej było zarządzane bezpośrednio w Entra ID, zaczyna być traktowane jako zarządzane z lokalnego Active Directory. W praktyce oznacza to, że dane z AD mogą nadpisać wartości, które wcześniej istniały w chmurze. Microsoft ostrzega też, że jeśli włączona jest synchronizacja hashy haseł, to hash hasła w Entra może zostać nadpisany wartością z AD.

Dlaczego Microsoft zdecydował się to ograniczyć?

Przez długi czas dla wielu firm był to po prostu wygodny sposób na porządkowanie użytkowników. Jeśli konto istniało już w chmurze, a potem pojawiało się odpowiadające mu konto w lokalnym AD, hard match pozwalał połączyć oba światy. Problem w tym, że ten sam mechanizm mógł być ryzykowny, jeśli dotyczył konta z wysokimi uprawnieniami. Microsoft ogłosił więc, że od 1 czerwca 2026 r. Entra ID blokuje próby hard match, gdy nowy obiekt z Active Directory ma zostać dopasowany do istniejącego cloud-managed użytkownika w Entra ID, który ma przypisane role Entra. Microsoft podkreśla jednocześnie, że soft match nie zmienia się, a zwykłe hard match dla użytkowników bez ról administracyjnych też pozostają bez zmian.

Jaki błąd może się pojawić?

Z punktu widzenia administratora najważniejszy skutek tej zmiany to błąd InvalidHardMatch. Microsoft opisuje go jako sytuację, w której synchronizacja próbuje wykonać hard match między nowym obiektem przychodzącym z AD a istniejącym obiektem w Entra ID, ale operacja zostaje zablokowana. W dokumentacji Microsoft wskazuje dwa główne powody: w tenantcie może być włączona funkcja BlockCloudObjectTakeoverThroughHardMatchEnabled albo istniejący obiekt Entra ma przypisane role uprzywilejowane i zawiera OnPremisesImmutableId.

W praktyce ten komunikat nie oznacza, że cała synchronizacja przestała działać. Oznacza raczej, że Microsoft nie pozwala już wykonać tego konkretnego połączenia w dotychczasowy sposób. To ważna zmiana, bo wcześniej hard match bywał traktowany jak wygodne narzędzie „naprawcze” przy porządkowaniu tożsamości. Teraz przy kontach uprzywilejowanych Microsoft wymaga większej ostrożności.

Co zrobić, jeśli pojawi się InvalidHardMatch?

Microsoft opisuje konkretną ścieżkę postępowania. Jeżeli problem dotyczy konta z rolami administracyjnymi, trzeba najpierw przywrócić użytkownika, jeśli znajduje się w stanie soft-deleted, następnie tymczasowo usunąć jego role administracyjne, upewnić się, że OnPremisesImmutableId jest ustawione poprawnie, pozwolić dokończyć synchronizację, a dopiero potem ponownie nadać role. Może to wydawać się mniej wygodne, ale właśnie taki jest sens tej zmiany: połączenie konta lokalnego z uprzywilejowanym kontem w chmurze ma być działaniem świadomym i kontrolowanym, a nie automatycznym efektem synchronizacji.

Co ta zmiana oznacza dla firm działających hybrydowo?

Warto też zwrócić uwagę na szerszy kontekst. W dokumentacji dotyczącej istniejącego tenanta Microsoft od dawna zaznacza, że Entra ID nie dopasowuje użytkowników on-premises do użytkowników chmurowych, którzy mają rolę administracyjną, i że takie zachowanie jest domyślne. Ta sama dokumentacja pokazuje też możliwość zablokowania przejęcia przez hard match szerzej, na poziomie tenanta, przy użyciu ustawienia BlockCloudObjectTakeoverThroughHardMatchEnabled.

Dlaczego hard match budził tyle obaw?

Najważniejsze pytanie brzmi jednak nie „co Microsoft zmienił”, ale dlaczego to zmienił. I tu odpowiedź jest prosta. Hard match był ryzykowny, bo pozwalał lokalnemu obiektowi z AD przejąć rolę źródła zarządzania dla istniejącego użytkownika w chmurze. W zwykłym koncie użytkownika mogło to skończyć się bałaganem w danych. W koncie uprzywilejowanym stawka była dużo wyższa. Jeśli ktoś miał możliwość manipulowania obiektem po stronie Active Directory, mógł próbować doprowadzić do sytuacji, w której lokalny obiekt przejmie kontrolę nad istniejącym kontem z wysokimi uprawnieniami. Microsoft wprost opisuje tę zmianę jako działanie wzmacniające bezpieczeństwo środowiska Entra ID.

Ryzyko to nie dotyczyło wyłącznie ataku. Problem mógł pojawić się także przy zwykłych działaniach administracyjnych: po usunięciu użytkownika z zakresu synchronizacji, przy przywracaniu konta, przy zmianach w katalogu albo przy próbie uporządkowania istniejących kont po migracji. W takich momentach hard match bywał wygodnym skrótem, ale skrótem mogącym mieć nieprzyjemne skutki uboczne. Dlatego zmiana ta jest ważna także dla firm, w których nigdy nie wystąpił incydent bezpieczeństwa. Ona po prostu zmusza do lepszego uporządkowania procesu zarządzania tożsamością w modelu hybrydowym.

Na co warto zwrócić uwagę?

Dla organizacji korzystających z AD i Entra ID oznacza to przede wszystkim potrzebę przeglądu własnych procedur. Warto sprawdzić, jak zakładane są konta administracyjne, czy istnieją konta uprzywilejowane utworzone najpierw w chmurze, a dopiero później łączone z AD, a także czy zespoły odpowiedzialne za synchronizację wiedzą, kiedy i dlaczego może pojawić się InvalidHardMatch. Zmiana ta nie unicestwia modelu hybrydowego. Synchronizacja nadal działa, a soft match i zwykłe scenariusze dla nieuprzywilejowanych kont pozostają bez zmian. Microsoft po prostu wyraźnie stawia granicę tam, gdzie chodzi o konta z największą siłą rażenia.