Често срещани грешки в инструмента User Sync Tool

Последна актуализация на 14.08.2026 г.

Открийте често срещани грешки в инструмента User Sync Tool и как да ги разрешите.

Тази страница изброява най-често срещаните грешки, с които може да се сблъскате при стартиране на инструмента User Sync Tool, заедно със стъпки за разрешаване на всяка от тях.За общ преглед на инструмента и къде да намерите настройката, конфигурацията и справочника с команди, вижте Настройване на инструмента User Sync Tool.

Инсталация и среда

Това може да се появи в Windows, когато пътищата надхвърлят 256 символа. Създайте променлива на средата с име PEX_ROOT със стойност C:\pex. Ако стартирате скрипта от диск, различен от C:, променете буквата на диска, за да съответства. Понякога е необходимо рестартиране на системата, за да влезе промяната в сила.

Стартирайте командния ред python от папката, където се намира user-sync.pex.

  • Проверете дали версията на Python, инсталирана във вашата система, е 32-битова. Деинсталирайте 32-битовата версия и инсталирайте 64-битовата версия.
  • Проверете дали версията на user-sync.pex, която сте изтеглили от GitHub, съответства на версията на Python и операционната ви система. Например изтеглете user-sync-v2.3-win64-py365.zip за Windows 64-битов и Python 3. Съответствайте версията на Python, с която е създаден .pex файлът, вместо да използвате най-новата версия на Python. Наставката на .zip файла идентифицира версията: за user-sync-v2.3-win64-py365.zip това е Python 3.6.5.

Тази грешка е записана в macOS High Sierra при използване на инструмента User Sync Tool версия 2.3 и Python 3.7.0. Стартирането на brew install openssl в терминала разреши проблема за този сценарий.

Връзка, времеизлизания и ограничаване

Ако времето за изчакване е по-малко от 30 минути, тези предупреждения се появяват, когато е достигната квотата за разрешени API повиквания в рамките на една минута.Инструментът използва механизъм за експоненциално забавяне при повторен опит, увеличавайки времето между опитите, и спира след три неуспешни опита.Оставете скрипта да се изпълни до края.

Ако времето за изчакване е над 1000 секунди, ограничаването е свързано с честотата на стартиране на всеки екземпляр от инструмента User Sync Tool.Екземпляр, който се стартира твърде често, се ограничава за 30 до 75 минути.Времеизлизането само поставя инструмента на пауза за определен период; инструментът се възстановява и продължава синхронизацията след това.

Тъй като инструментът разпознава кога два екземпляра се стартират едновременно, нов екземпляр не се стартира, докато първият не приключи.В този случай логът може да показва съобщение, че даден процес вече е в ход.

За оптимална производителност следвайте тези препоръки за честота на стартиране:

  • Настройте планираната задача да се повтаря с интервал от поне 2 часа.
  • Настройте заданието за планираната задача така, че да не започва на :00 или :30 минути, за да избегнете пиковия трафик.
  • Ако трябва да стартирате инструмента по-често, помислете за използване на стратегията за изтласкване (делта на промените) вместо пълна синхронизация.
  • Съобразете графика за стартиране на инструмента с работния ден на вашата организация.Например, не стартирайте задачи за синхронизация през нощта, ако организацията ви няма нужда да модифицира провизионирането тогава.

Инструментът не може да се свърже към обществените API крайни точки.Локални настройки като правила на защитна стена, прокси, блокиращ трафика, или настройки за интернет достъп до акаунта могат да предотвратят достъпа.Добавянето на променливата за среда https_proxy със стойност като http://<proxyAddress>:<port> или https://<proxyAddress>:<port> може да помогне.В други случаи разрешете достъп до тези крайни точки: ims-na1.adobelogin.com:443 и usermanagement.adobe.io:443.Това може да бъде разрешено само локално чрез изчистване на достъпа до тези крайни точки за текущия акаунт.

SSL инспекцията на локалния прокси сървър причинява това.

Решение 1: Вземете основния CA сертификат на проксито в PEM формат (например thecert.crt).Ако е в DER формат, конвертирайте го в PEM с тази openssl команда: openssl x509 -inform DER -in thecert.crt -out thecert.pem -outform PEM.PEM файлът показва base64-кодиран низ между редовете -----BEGIN CERTIFICATE----- и -----END CERTIFICATE-----.Създайте променлива за среда с име REQUESTS_CA_BUNDLE и задайте стойността ѝ на пътя към thecert.pem.

Решение 2: В Windows тази грешка може да възникне, ако инструментът се стартира от различен диск от този, където са инсталирани операционната система и Python.Преместете целия скрипт на диска, където е операционната система.Ако това не е възможно, копирайте файла cacert.pem, който съдържа доверените основни CA в другия диск и задайте пътя му като REQUESTS_CA_BUNDLE.Ако прокси също инспектира SSL трафика, копирайте съдържанието на основния CA сертификат на проксито в cacert.pem, за да бъде доверен сертификатът на проксито.Инсталацията по подразбиране на Python пази пакета със сертификати в C:\Python36\Lib\site-packages\certifi\cacert.pem.

Решение 3: Деактивирайте SSL инспекцията на проксито за крайните точки на API ims-na1.adobelogin.com и usermanagement.adobe.io.

Удостоверяване и идентификационни данни

Записът в хранилището за идентификационни данни за umapi_api_key може да липсва.Създайте записа в хранилището за идентификационни данни.Вижте документацията на инструмента User Sync Tool за съхраняване на идентификационни данни в хранилище на ниво операционна система.

Стойността може да е била добавена и в хранилището за идентификационни данни под различен потребителски акаунт, докато записът липсва за текущо свързания потребител. Добавете я или сменете потребителския акаунт.

  • Ако не можете бързо да идентифицирате проблема, издайте отново двойката ключове.
  • Не използвайте атрибута umapi_private_key_data, когато стартирате скрипта в Windows. Вместо това шифровайте ключа и съхранете паролата в Credential Manager.
  • Ако сте използвали различен формат за издаване на двойката ключове, опитайте с частен ключ RSA 256, 2048-битов.
  • Може да сте задали secure_priv_key_pass_key: umapi_private_key_passphrase във файла connector-umapi.yml. Уверете се, че съответстващият запис в хранилището за идентификационни данни и свързаните с него стойности съвпадат.

В Adobe Admin Console отидете в „Настройки", след това в „Настройки за удостоверяване". Може да е избрана опция, различна от „Най-лесно за потребители" (паролата никога не изтича). Опцията „По-защитено" или „Най-защитено" може да изтече паролата на техническия акаунт, свързан с интеграцията. За да коригирате това, създайте нова интеграция и подновете метаданните във файла connector-umapi.yml. За това беше внедрена корекция, но може да засегне интеграции, създадени преди октомври 2018 г.

Отворете интеграцията, която създадохте в Adobe Developer Console, и проверете списъка с API в лявото меню. Уверете се, че User Management API е добавен като услуга и се появява в списъка.

  • Стойността tech_acct във файла connector-umapi.yml може да се различава от ID на техническия акаунт в интеграцията в Adobe Developer Console. Проверете идентификатора на техническия акаунт в текущата интеграция и го копирайте във файла.
  • Публичният сертификат от интеграцията може да е изтекъл.Подновете частния и публичния ключ, качете публичния ключ и заменете стария частен ключ с новия.Проверете дали пътят във файла connector-umapi.yml сочи към правилния файл.
  • Потвърдете, че интеграцията е за правилната организация.Изберете организацията от падащото меню в горния ляв ъгъл на Adobe Developer Console, след което проверете идентификатора на техническия акаунт за основната интеграция заедно с другите метаданни (идентификатор на организацията, тайна и идентификатор на клиента).

Тази грешка се появява в по-стари интеграции.Създайте нова интеграция (или проект) в Adobe Developer Console заедно със съществуващата, използвана за същата цел.Новата интеграция предоставя нови идентификационни данни, така че ги актуализирайте във файла connector-umapi.yml.Двойката ключове (частен и публичен ключ) вероятно е издадена отново, така че новият частен ключ трябва да замени съществуващия.

LDAP и групи

  • Групата не съществува в LDAP с това точно име.Добавете правилното LDAP име на групата.
  • Групата не може да бъде открита под декларирания base_dn (вижте файла connector-ldap.yml).Променете стойността на base_dn, за да включите групата.Това се случва главно когато base_dn сочи към конкретна OU вместо да бъде възможно най-широк.

Потребителската група group_name в резултата не съществува от страна на Adobe.Създайте я.Ако сте планирали да зададете името на конфигурация на продуктов лиценз (PLC) вместо потребителска група, вижте документацията на инструмента User Sync Tool за създаване на съответни групи в корпоративната директория.

Групите от интерес може да са в поддомейн, докато стойността на host е един от главните домейни.Променете стойността на host към поддомейн, където са намерени потребителските групи. Ако потребителите или групите са както в основния домейн, така и в неговите поддомейни, използвайте порта на глобалния каталог в основния домейн и променете групите на поддомейна на Universal вместо Global. Примерна стойност на host с помощта на глобалния каталог: ldap://domain.local:3268 или ldaps://domain.local:3269. Когато използвате порта на глобалния каталог, задайте base_dn с празна стойност: base_dn: "".

Потребители и създаване на акаунти

Домейнът, използван за създаване на акаунта, може да не е заявен или доверен във вашата организация. Зелено флагче или точка се появява за активните домейни в Adobe Admin Console под Настройки. Ако това не се случва, завършването на процеса за заявяване на домейна може да реши проблема.

Направен е опит за създаване на акаунт с Federated ID, но директорията е създадена за Enterprise ID или обратното. Намерете атрибута user_identity_type във файла user-sync-config.yml. Задайте стойността да съвпада с типа директория, показан в Adobe Admin Console (Настройки, след това Identity, след това Domains, след това стойността на Directory type за домейна).

Понякога домейнът @claimed-domain.com е притежание на различна организация, която е настроила Azure или Google конектор за синхронизиране на акаунти с Admin Console, и домейнът след това е доверен на различна организация, която използва User Sync Tool за синхронизиране на акаунти с формата @claimed-domain.com. Съобщението се появява, когато инструментът извлече акаунта user@claimed-domain.com от LDAP сървър, за да го създаде във вторичната организация, но акаунтът все още не е създаден или синхронизиран в основната организация чрез Azure или Google конектора. Създайте или синхронизирайте акаунта user@claimed-domain.com в организацията, която използва Azure или Google конектора, след което повторете синхронизацията с User Sync Tool в доверената организация.

Тази обща грешка има множество причини, но обичайният проблем е, че домейнът, използван в действието за създаване, е под настройка за Azure или Google синхронизация. За да проверите, влезте в Adobe Admin Console с акаунта на системния администратор, отидете на Настройки, изберете директорията, която съдържа домейна, и изберете раздела Sync. Ако е налична карта Sync Source, поправката зависи от това как синхронизацията трябва да продължи:

  • Ако Azure или Google конекторът трябва да извърши синхронизацията, продължете с настройката на Sync Source и премахнете изцяло User Sync Tool.
  • Ако User Sync Tool трябва да извърши синхронизацията, изберете Go to Settings, след това Remove Sync в долната част на страницата. Инструментът след това работи както обикновено.

Ако няма налична карта Sync Source, текущият инструмент може да работи срещу Console, където домейнът е доверен от различен Console (притежаващата организация). Тази организация може да има включена Azure или Google синхронизация, което причинява тази грешка. Първо синхронизирайте акаунта в собствената конзола, след което използвайте инструмента, за да създадете акаунта в текущата конзола.

Ако нито едно от тези не отговаря, свържете се с корпоративната поддръжка.