Microsoft 365 i Active Directory

Łączenie kont Active Directory z Azure AD w Office 365 – Kompleksowy Przewodnik

Zaktualizowano: 9 sierpnia 2026 r. · Autor: Jan Chmielewski

Gdy pracownik ma konto w lokalnym Active Directory i niezależne istniejące konto Microsoft 365, celem jest dopasowanie ich do tej samej tożsamości — bez utraty skrzynki, licencji, danych Teams lub OneDrive.

Azure AD nosi obecnie nazwę Microsoft Entra ID. Po uruchomieniu synchronizacji Microsoft Entra Connect może utworzyć drugi obiekt, jeżeli nie dopasuje właściwie konta lokalnego do konta istniejącego w chmurze. Nie usuwaj konta ani nie zmieniaj atrybutu sourceAnchor na ślepo: tożsamość, licencje i dane użytkownika muszą najpierw zostać zweryfikowane.

Scenariusz problemu

Przykładowy Jan Kowalski loguje się do komputera kontem jkowalski@firma.local, a do Microsoft 365 kontem jan.kowalski@firma.pl. Po synchronizacji może pojawić się dodatkowy obiekt z domeną firma.onmicrosoft.com. To nie jest dowód, że nadmiarowe konto można od razu skasować — trzeba najpierw ustalić, który obiekt ma skrzynkę, licencje, urządzenia, role i dane.

Najpierw: inwentaryzacja i kopia planu wycofania

1. Potwierdź z użytkownikiem właściwy UPN, główny adres SMTP i właściciela danych.
2. Sprawdź licencje, skrzynkę Exchange, OneDrive, Teams, grupy oraz role Microsoft Entra.
3. Ustal, czy konto lokalne jest już w zakresie synchronizacji i jaki atrybut sourceAnchor wybrał Microsoft Entra Connect.
4. Wykonaj zmianę najpierw na koncie testowym oraz przygotuj plan cofnięcia.

Nie wykonuj hard match dla kont uprzywilejowanych. Aktualne mechanizmy ochronne Microsoft mogą blokować takie dopasowanie, aby lokalny obiekt nie przejął niewłaściwej tożsamości chmurowej.

Dopasowanie kont: soft match i hard match

Microsoft Entra Connect próbuje dopasować nowy obiekt lokalny do istniejącego konta chmurowego. Soft match może używać zgodnego UPN lub podstawowego adresu SMTP. Hard match wykorzystuje sourceAnchor, który w Microsoft Entra ID odpowiada atrybutowi onPremisesImmutableId.

W nowoczesnych wdrożeniach sourceAnchor często bazuje na mS-DS-ConsistencyGuid, a nie zawsze bezpośrednio na objectGUID. Dlatego oryginalny przepis polegający na bezwarunkowej konwersji ObjectGUID do ImmutableId jest poprawny tylko w konfiguracji, która rzeczywiście używa ObjectGUID jako sourceAnchor.

# Odczyt do weryfikacji obiektu lokalnego
Get-ADUser -Identity "jkowalski" -Properties ObjectGUID,msDS-ConsistencyGuid |
  Select-Object SamAccountName,ObjectGUID,msDS-ConsistencyGuid

Bezpieczna procedura wdrożenia

1. Wyrównaj w AD właściwy UPN i podstawowy SMTP z docelowym kontem Microsoft 365, jeśli polityka domeny na to pozwala.
2. Przeanalizuj wynik synchronizacji i spróbuj soft match, gdy dopasowanie jest jednoznaczne.
3. Jeżeli konieczny jest hard match, porównaj sourceAnchor skonfigurowany w Entra Connect z wartością istniejącego konta. Zmianę wykonuje administrator odpowiedzialny za synchronizację, po zatwierdzeniu zakresu.
4. Uruchom synchronizację różnicową na serwerze Entra Connect i przeanalizuj wynik eksportu, zanim przekażesz użytkownikowi zmianę.

Start-ADSyncSyncCycle -PolicyType Delta

Dlaczego nie używać już MSOnline?

Starsze polecenia Connect-MsolService, Get-MsolUser, Set-MsolUser i Remove-MsolUser pochodzą z modułu MSOnline. Moduł został wycofany; aktualne wdrożenia powinny używać Microsoft Graph PowerShell albo Microsoft Entra PowerShell. W szczególności nie usuwaj konta @onmicrosoft.com tylko dlatego, że wygląda na duplikat — może ono zawierać licencję lub dane, które trzeba zachować albo prawidłowo przenieść.

Test po synchronizacji

1. Sprawdź w Microsoft Entra admin center, czy konto ma oczekiwany status synchronizacji i identyfikator lokalny.
2. Potwierdź licencje, skrzynkę, OneDrive i członkostwa w grupach.
3. Poproś użytkownika o test logowania do Microsoft 365 przez właściwy UPN.
4. Jeżeli używana jest synchronizacja skrótów haseł, zapowiedz, że hasło chmurowe zostanie zastąpione hasłem z lokalnego AD.

Podsumowanie

Połączenie kont AD i Azure AD/Microsoft Entra ID jest projektem zarządzania tożsamością, a nie prostym usunięciem „drugiego użytkownika”. Najpierw potwierdź dane i sourceAnchor, potem zastosuj właściwe dopasowanie oraz przetestuj je na ograniczonym zakresie.