Błędy synchronizacji problemów

Ukończone

Błędy mogą wystąpić, gdy dane tożsamości są synchronizowane z Windows Server Active Directory (AD DS) do Azure Active Directory (Azure AD). Ta sekcja zawiera omówienie różnych typów błędów synchronizacji, niektórych możliwych scenariuszy, które powodują te błędy, oraz potencjalne sposoby ich naprawiania. Ta sekcja zawiera typowe typy błędów i może nie obejmować wszystkich możliwych błędów.

W najnowszej wersji programu Azure AD Connect (sierpień 2016 r. lub nowsza) raport o błędach synchronizacji jest dostępny w Azure Portal w ramach Azure AD Connect Health synchronizacji.

Od 1 września 2016 r. funkcja Azure Active Directory odporności na zduplikowane atrybuty będzie domyślnie włączona dla wszystkich nowych dzierżawców Azure Active Directory dzierżaw. Ta funkcja zostanie automatycznie włączona dla istniejących dzierżaw w najbliższych miesiącach.

Azure AD Connect wykonuje trzy typy operacji z katalogów, które są synchronizowane: import, synchronizacja i eksport. Błędy mogą wystąpić we wszystkich operacjach. Ta sekcja koncentruje się głównie na błędach podczas eksportowania do usługi Azure AD.

Błędy podczas eksportowania do usługi Azure AD

W poniższej sekcji opisano różne typy błędów synchronizacji, które mogą wystąpić podczas operacji eksportowania do usługi Azure AD przy użyciu łącznika usługi Azure AD. Ten łącznik można zidentyfikować za pomocą formatu nazwy "contoso. onmicrosoft.com". Błędy podczas eksportowania do usługi Azure AD wskazują, że operacja (dodawanie, aktualizowanie, usuwanie itp.) podejmowana przez Azure AD Connect (aparat synchronizacji) na Azure Active Directory nie powiodła się.

Błędy eksportu — omówienie.

Błędy niezgodności danych

InvalidSoftMatch

Opis

  • Gdy Azure AD Connect (aparat synchronizacji) nakazuje usłudze Azure Active Directory dodawanie lub aktualizowanie obiektów, usługa Azure AD dopasowuje obiekt przychodzący przy użyciu atrybutu sourceAnchor do atrybutu immutableId obiektów w usłudze Azure AD. To dopasowanie jest nazywane twardym dopasowaniem.

  • Jeśli usługa Azure AD nie znajdzie żadnego obiektu zgodnego z atrybutem immutableId z atrybutem sourceAnchor obiektu przychodzącego, przed aprowizowanie nowego obiektu powraca do użycia atrybutów ProxyAddresses i UserPrincipalName w celu znalezienia dopasowania. To dopasowanie jest nazywane dopasowaniem miękkim. Dopasowanie nie soft jest przeznaczone do dopasowania obiektów, które już istnieją w usłudze Azure AD (które pochodzą z usługi Azure AD) z nowymi obiektami dodawanymi/aktualizowanym podczas synchronizacji, które reprezentują tę samą jednostkę (użytkowników, grupy) lokalnie.

  • Błąd InvalidSoftMatch występuje, gdy twarde dopasowanie nie znajduje żadnego pasującego obiektu I dopasowanie niepasujące znajduje pasujący obiekt, ale ten obiekt ma inną wartość immutableId niż wartość SourceAnchor obiektu przychodzącego, sugerując, że pasujący obiekt został zsynchronizowany z innym obiektem z lokalnej usługi Active Directory.

Innymi słowy, aby dopasowanie programowe działało, obiekt, który ma zostać dopasowany soft-matched z , nie powinien mieć żadnej wartości dla immutableId. Jeśli dowolny obiekt z identyfikatorem immutableId ustawionym z wartością nie spełnia twardego dopasowania, ale spełnia kryteria dopasowania nie soft, operacja spowoduje błąd synchronizacji InvalidSoftMatch.

Azure Active Directory nie zezwala na co najmniej dwa obiekty mają taką samą wartość następujących atrybutów. (Nie jest to wyczerpująca lista).

  • ProxyAddresses
  • UserPrincipalName
  • onPremisesSecurityIdentifier
  • ObjectId

Funkcja odporności na zduplikowane atrybuty usługi Azure AD jest również wdawana jako domyślne zachowanie Azure Active Directory. Spowoduje to zmniejszenie liczby błędów synchronizacji widocznych dla usługi Azure AD Connect (a także innych klientów synchronizacji) przez większą odporność usługi Azure AD w sposób obsługi zduplikowanych atrybutów ProxyAddresses i UserPrincipalName obecnych w lokalnych środowiskach usługi AD. Ta funkcja nie naprawia błędów duplikowania. W ten sposób dane nadal muszą zostać naprawione. Umożliwia jednak aprowizowanie nowych obiektów, które w przeciwnym razie są blokowane z powodu zduplikowanych wartości w usłudze Azure AD. Spowoduje to również zmniejszenie liczby błędów synchronizacji zwracanych do klienta synchronizacji. Jeśli ta funkcja jest włączona dla dzierżawy, podczas aprowizowania nowych obiektów nie będą widoczne błędy synchronizacji InvalidSoftMatch.

Przykładowe scenariusze dla invalidSoftMatch

  1. Istnieją co najmniej dwa obiekty o tej samej wartości dla atrybutu ProxyAddresses w lokalna usługa Active Directory. Tylko jedna z nich jest aprowizowana w usłudze Azure AD.

  2. Co najmniej dwa obiekty o tej samej wartości dla atrybutu userPrincipalName istnieją w lokalna usługa Active Directory. Tylko jedna z nich jest aprowizowana w usłudze Azure AD.

  3. Obiekt został dodany w lokalnej usłudze Active Directory z taką samą wartością atrybutu ProxyAddresses jak istniejący obiekt w Azure Active Directory. Obiekt dodany lokalnie nie jest aprowowany w Azure Active Directory.

  4. Obiekt został dodany w lokalnej usłudze Active Directory z taką samą wartością atrybutu userPrincipalName jak dla konta w Azure Active Directory. Obiekt nie jest aprowizowany w Azure Active Directory.

  5. Zsynchronizowane konto zostało przeniesione z lasu A do lasu B. Azure AD Connect (aparat synchronizacji) używa atrybutu ObjectGUID do obliczenia elementu SourceAnchor. Po przenoszeniu lasu wartość SourceAnchor jest inna. Nie można zsynchronizować nowego obiektu (z lasu B) z istniejącym obiektem w usłudze Azure AD.

  6. Zsynchronizowany obiekt został przypadkowo usunięty z lokalnej usługi Active Directory, a nowy obiekt został utworzony w usłudze Active Directory dla tej samej jednostki (takiej jak użytkownik) bez usuwania konta w usłudze Azure Active Directory. Nie można zsynchronizować nowego konta z istniejącym obiektem usługi Azure AD.

  7. Azure AD Connect została odinstalowana i ponownie zainstalowana. Podczas ponownej instalacji inny atrybut został wybrany jako SourceAnchor. Wszystkie obiekty, które wcześniej były synchronizowane, zatrzymały synchronizację z błędem InvalidSoftMatch.

Przykładowy przypadek:

  1. Bob Smith jest zsynchronizowanym użytkownikiem w Azure Active Directory z lokalnej usługi Active Directory contoso.com

  2. Wartość UserPrincipalName boba Smitha jest ustawiona na bobs@contoso.com .

  3. "abcdefghijklmnopqrstuv==" to wartość SourceAnchor obliczana przez usługę Azure AD Connect przy użyciu identyfikatorów objectGUID Boba Smitha z lokalnej usługi Active Directory, która jest niezmiennym identyfikatorem Boba Smitha w Azure Active Directory.

  4. Bob ma również następujące wartości atrybutu proxyAddresses:

    • Smtp: bobs@contoso.com

    • Smtp: bob.smith@contoso.com

    • Smtp: bob@contoso.com

  5. Do lokalnej usługi Active Directory jest dodawany nowy użytkownik, Bob Zaimek.

  6. Parametr UserPrincipalName Boba Boba Jest ustawiony na bobt@contoso.com wartość .

  7. "abcdefghijkl0123456789=="" to wartość sourceAnchor obliczona przez usługę Azure AD Connect przy użyciu obiektu ObjectGUID Boba Boba z lokalnej usługi Active Directory. Obiekt Boba Boba Nie został jeszcze zsynchronizowany Azure Active Directory.

  8. Bob Przemysł ma następujące wartości dla atrybutu proxyAddresses

    • Smtp: bobt@contoso.com

    • Smtp: bob.taylor@contoso.com

    • Smtp: bob@contoso.com

  9. Podczas synchronizacji program Azure AD Connect dodanie BobaSynchronizowaća w lokalnej usłudze Active Directory i poprosi usługę Azure AD o tę samą zmianę.

  10. Usługa Azure AD najpierw wykona twarde dopasowanie. Oznacza to, że zostanie wyszukany, jeśli istnieje obiekt o identyfikatorze immutableId równym "abcdefghijkl0123456789==". Twarde dopasowanie nie powiedzie się, ponieważ żaden inny obiekt w usłudze Azure AD nie będzie miał tego niezmiennego obiektu.

  11. Następnie usługa Azure AD podejmie próbę dopasowania programowego Boba Boba Boba. Oznacza to, że będzie wyszukiwać, czy istnieje dowolny obiekt o wartości proxyAddresses równej trzem wartościom, w tym smtp: bob@contoso.com

  12. Usługa Azure AD znajdzie obiekt Boba Smitha, aby dopasować kryteria dopasowania programowego. Jednak ten obiekt ma wartość immutableId = "abcdefghijklmnopqrstuv==". , co oznacza, że ten obiekt został zsynchronizowany z innym obiektem z lokalnej usługi Active Directory. W związku z tym usługa Azure AD nie może dopasować soft-match tych obiektów i powoduje błąd synchronizacji InvalidSoftMatch.

Jak naprawić błąd InvalidSoftMatch

Najczęstszą przyczyną błędu InvalidSoftMatch są dwa obiekty o różnych atrybutach SourceAnchor (immutableId) o takiej samej wartości dla atrybutów ProxyAddresses i/lub UserPrincipalName, które są używane podczas procesu dopasowania programowego w usłudze Azure AD. Aby rozwiązać problem z nieprawidłowym dopasowaniem nietrwowym

  1. Zidentyfikuj zduplikowaną wartość proxyAddresses, userPrincipalName lub inną wartość atrybutu, która powoduje błąd. Zidentyfikuj również, które dwa obiekty (lub więcej) są zaangażowane w konflikt. Raport wygenerowany przez Azure AD Connect Health synchronizacji może pomóc w zidentyfikowaniu tych dwóch obiektów.

  2. Zidentyfikuj obiekt, który powinien nadal mieć zduplikowaną wartość, a który nie.

  3. Usuń zduplikowaną wartość z obiektu , który NIE powinien mieć tej wartości. Należy wprowadzić zmianę w katalogu, z którego pochodzi obiekt. W niektórych przypadkach może być konieczne usunięcie jednego z obiektów w konflikcie.

  4. Jeśli w lokalnej u usługach AD wszedliśmy do tej zmiany, Azure AD Connect zsynchronizować zmianę.

Raporty o błędach synchronizacji Azure AD Connect Health synchronizacji są aktualizowane co 30 minut i zawierają błędy z ostatniej próby synchronizacji.

Uwaga

Identyfikator ImmutableId z definicji nie powinien zmieniać się w okresie istnienia obiektu. Jeśli Azure AD Connect z powyższymi scenariuszami nie skonfigurowano niektórych scenariuszy, może to być sytuacją, w której usługa Azure AD Connect oblicza inną wartość elementu SourceAnchor dla obiektu usługi AD, która reprezentuje tę samą jednostkę (ten sam użytkownik/grupa/kontakt itp.), która ma istniejący obiekt usługi Azure AD, którego chcesz nadal używać.

ObjectTypeMismatch

Opis

Gdy usługa Azure AD próbuje dopasować nie soft dwa obiekty, możliwe, że dwa obiekty o różnych typach obiektów (takich jak Użytkownik, Grupa, Kontakt itp.) mają te same wartości dla atrybutów używanych do wykonania dopasowania programowego. Ponieważ duplikowanie tych atrybutów nie jest dozwolone w usłudze Azure AD, operacja może spowodować błąd synchronizacji "ObjectTypeMismatch".

Przykładowe scenariusze błędu ObjectTypeMismatch

  • Grupa zabezpieczeń z włączoną obsługą poczty e-mail jest tworzona Microsoft 365. Administrator dodaje nowego użytkownika lub kontakt w lokalnej usłudze AD (która nie jest jeszcze zsynchronizowana z usługą Azure AD) z taką samą wartością atrybutu ProxyAddresses jak atrybut Microsoft 365 usługi.

Przykładowy przypadek

  1. Administrator tworzy nową grupę zabezpieczeń z włączoną obsługą poczty e-mail w Microsoft 365 dla działu podatkowego i udostępnia adres e-mail jako tax@contoso.com . Do tej grupy jest przypisywana wartość atrybutu ProxyAddresses smtp: tax@contoso.com

  2. Nowy użytkownik dołącza do Contoso.com a dla użytkownika lokalnego jest tworzone konto z adresem proxyAddress jako smtp: tax@contoso.com

  3. Gdy Azure AD Connect zostanie zsynchronizowane nowe konto użytkownika, zostanie wyświetlany błąd "ObjectTypeMismatch".

Jak naprawić błąd ObjectTypeMismatch

Najczęstszą przyczyną błędu ObjectTypeMismatch są dwa obiekty różnego typu (Użytkownik, Grupa, Kontakt itp.) mają taką samą wartość dla atrybutu ProxyAddresses. Aby naprawić obiekt ObjectTypeMismatch:

  1. Zidentyfikuj zduplikowaną wartość proxyAddresses (lub inny atrybut), która powoduje błąd. Zidentyfikuj również, które obiekty (lub więcej) są zaangażowane w konflikt. Raport wygenerowany przez Azure AD Connect Health do synchronizacji może pomóc zidentyfikować dwa obiekty.

  2. Zidentyfikuj obiekt, który powinien nadal mieć zduplikowaną wartość, a który nie.

  3. Usuń zduplikowaną wartość z obiektu , który NIE powinien mieć tej wartości. Należy wprowadzić zmianę w katalogu, z którego pochodzi obiekt. W niektórych przypadkach może być konieczne usunięcie jednego z obiektów w konflikcie.

  4. Jeśli w lokalnej u usługach AD wszedliśmy do tej zmiany, Azure AD Connect zsynchronizować zmianę. Raport o błędach synchronizacji Azure AD Connect Health synchronizacji jest aktualizowany co 30 minut i zawiera błędy z ostatniej próby synchronizacji.

Zduplikowane atrybuty

AttributeValueMustBeUnique

Opis

Azure Active Directory nie zezwala na co najmniej dwa obiekty mają taką samą wartość następujących atrybutów. Każdy obiekt w usłudze Azure AD musi mieć unikatową wartość tych atrybutów w danym wystąpieniu.

  • ProxyAddresses

  • UserPrincipalName

Jeśli Azure AD Connect próbuje dodać nowy obiekt lub zaktualizować istniejący obiekt przy użyciu wartości dla powyższych atrybutów, które są już przypisane do innego obiektu w programie Azure Active Directory, operacja powoduje błąd synchronizacji "AttributeValueMustBeUnique".

Możliwe scenariusze:

Zduplikowana wartość jest przypisywana do już zsynchronizowanego obiektu, co powoduje konflikt z innym zsynchronizowanym obiektem.

Przykładowy przypadek:

  1. Bob Smith jest zsynchronizowanym użytkownikiem w Azure Active Directory z lokalnej usługi Active Directory contoso.com

  2. Lokalna nazwa UserPrincipalName Boba Smitha jest ustawiona jako bobs@contoso.com .

  3. Bob ma również następujące wartości dla atrybutu proxyAddresses:

    • Smtp: bobs@contoso.com

    • Smtp: bob.smith@contoso.com

    • Smtp: bob@contoso.com

  4. Do lokalnej usługi Active Directory jest dodawany nowy użytkownik, BobOwi Bobowi Bobowi.

  5. Parametr UserPrincipalName Boba Boba Jest ustawiony na bobt@contoso.com wartość .

  6. Bob Przemysł ma następujące wartości dla atrybutu ProxyAddresses i. smtp: bobt@contoso.com ii. Smtp: bob.taylor@contoso.com

  7. Obiekt Boba Boba został pomyślnie zsynchronizowany z usługą Azure AD.

  8. Administrator zdecydował się zaktualizować atrybut ProxyAddresses BobAddresses o następującą wartość: i. Smtp: bob@contoso.com

  9. Usługa Azure AD podejmie próbę zaktualizowania obiektu Boba Kowalskiego w usłudze Azure AD przy użyciu powyższej wartości, ale ta operacja nie powiedzie się, ponieważ ta wartość ProxyAddresses jest już przypisana do Boba Smitha, co spowoduje błąd "AttributeValueMustBeUnique".

Jak naprawić błąd AttributeValueMustBeUnique

Najbardziej typową przyczyną błędu AttributeValueMustBeUnique są dwa obiekty o różnych atrybutach SourceAnchor (immutableId) o tej samej wartości dla atrybutów ProxyAddresses i/lub UserPrincipalName. Aby naprawić błąd AttributeValueMustBeUnique

  1. Zidentyfikuj zduplikowaną wartość proxyAddresses, userPrincipalName lub inną wartość atrybutu, która powoduje błąd. Zidentyfikuj również, które obiekty (lub więcej) są zaangażowane w konflikt. Raport wygenerowany przez Azure AD Connect Health do synchronizacji może pomóc zidentyfikować dwa obiekty.

  2. Zidentyfikuj obiekt, który powinien nadal mieć zduplikowaną wartość, a który nie.

  3. Usuń zduplikowaną wartość z obiektu , który NIE powinien mieć tej wartości. Należy wprowadzić zmianę w katalogu, z którego pochodzi obiekt. W niektórych przypadkach może być konieczne usunięcie jednego z obiektów w konflikcie.

  4. W przypadku zmiany wprowadzonej w lokalnej u usługi AD zsynchronizujmy Azure AD Connect, aby błąd został naprawiony.

Błędy walidacji danych

IdentityDataValidationFailed

Opis

Azure Active Directory wymusza różne ograniczenia dotyczące danych przed zezwoleniem na ich zapisywanie w katalogu. Te ograniczenia mają na celu zapewnienie, że użytkownicy końcowi uzyskają najlepsze możliwe środowisko podczas korzystania z aplikacji zależnych od tych danych.

Scenariusze

Wartość atrybutu UserPrincipalName zawiera nieprawidłowe/nieobsługiwane znaki. b. Atrybut UserPrincipalName nie ma wymaganego formatu.

Jak naprawić błąd IdentityDataValidationFailed

Upewnij się, że atrybut userPrincipalName ma obsługiwane znaki i wymagany format.

FederatedDomainChangeError

Opis

W takim przypadku występuje błąd synchronizacji "FederatedDomainChangeError", gdy sufiks UserPrincipalName użytkownika zostanie zmieniony z jednej domeny federowej na inną domenę federacyjną.

Scenariusze

W przypadku zsynchronizowanego użytkownika sufiks UserPrincipalName został zmieniony z jednej domeny federowej na inną domenę federacyjną lokalnie. Na przykład wartość UserPrincipalName = została bob@contoso.com zmieniona na UserPrincipalName = bob@fabrikam.com.

Przykład

  1. Bob Smith, konto usługi Contoso.com, jest dodawane jako nowy użytkownik w usłudze Active Directory z userPrincipalName bob@contoso.com

  2. Bob przechodzi do innego podziału Contoso.com o nazwie Fabrikam.com a ich userPrincipalName jest zmieniana na bob@fabrikam.com

  3. Domeny contoso.com i fabrikam.com są domenami federacyjną z Azure Active Directory.

  4. Parametr userPrincipalName Boba nie jest aktualizowany i powoduje błąd synchronizacji "FederatedDomainChangeError".

Jak rozwiązać problem

Jeśli sufiks UserPrincipalName użytkownika został zaktualizowany z bob@contoso.com do bob@fabrikam.com, gdzie zarówno contoso.com, jak i fabrikam.com są domenami federacyjną, wykonaj następujące kroki, aby naprawić błąd synchronizacji

  1. Zaktualizuj parametr UserPrincipalName użytkownika w usłudze Azure AD z bob@contoso.com na bob@contoso.onmicrosoft.com . Z modułem Azure AD PowerShell możesz użyć następującego polecenia programu PowerShell: Set-MsolUserPrincipalName -UserPrincipalName bob@contoso.com -NewUserPrincipalName bob@contoso.onmicrosoft.com

  2. Zezwalaj na kolejny cykl synchronizacji, aby spróbować synchronizacji. Tym razem synchronizacja zakończy się pomyślnie i zaktualizuje nazwę UserPrincipalName boba do bob@fabrikam.com wartości zgodnie z oczekiwaniami.

LargeObject

Opis

Gdy atrybut przekracza dozwolony limit rozmiaru, limit długości lub liczbę ustawiony przez schemat Azure Active Directory, operacja synchronizacji powoduje błąd synchronizacji LargeObject lub ExceededAllowedLength. Zazwyczaj ten błąd występuje dla następujących atrybutów

  • userCertificate

  • userSMIMECertificate

  • thumbnailPhoto

  • proxyAddresses

Możliwe scenariusze

  1. Atrybut userCertificate Boba przechowuje zbyt wiele certyfikatów przypisanych do Boba. Mogą to być starsze, wygasłe certyfikaty. Limit twardy wynosi 15 certyfikatów.

  2. Atrybut userSMIMECertificate Boba przechowuje zbyt wiele certyfikatów przypisanych do Boba. Mogą to być starsze, wygasłe certyfikaty. Limit twardy wynosi 15 certyfikatów.

  3. Zestaw thumbnailPhoto Boba w usłudze Active Directory jest zbyt duży, aby można go było zsynchronizować w usłudze Azure AD.

  4. Podczas automatycznego zaludniania atrybutu ProxyAddresses w usłudze Active Directory obiekt ma przypisanych zbyt wiele adresów ProxyAddresses.

Jak rozwiązać problem

Upewnij się, że atrybut powodujący błąd jest w zakresie dozwolonego ograniczenia.

Konflikt roli administratora

Opis

Istniejący konflikt roli administratora wystąpi w obiekcie użytkownika podczas synchronizacji, gdy ten obiekt użytkownika ma:

  • uprawnienia administracyjne i

  • ten sam element UserPrincipalName co istniejący obiekt usługi Azure AD

Azure AD Connect obiekt użytkownika z lokalnej usługi AD z obiektem użytkownika w usłudze Azure AD, który ma przypisaną rolę administracyjną.

Istniejący administrator.

Jak rozwiązać problem

Aby rozwiązać ten problem, wykonaj następujące czynności:

  1. Usuń konto usługi Azure AD (właściciela) ze wszystkich ról administratora.

  2. Trwale usuń obiekt poddane kwarantannie w chmurze.

  3. Następny cykl synchronizacji będzie uwzględniać dopasowywanie programowe użytkownika lokalnego do konta w chmurze (ponieważ użytkownik w chmurze nie jest już globalnym użytkownikiem globalnym).

  4. Przywróć członkostwo w rolach właściciela.

Uwaga

Rolę administracyjną można ponownie przypisać do istniejącego obiektu użytkownika po zakończeniu nie soft match między obiektem użytkownika lokalnego a obiektem użytkownika usługi Azure AD.