Erori comune ale instrumentului User Sync Tool

Ultima actualizare la 14 aug. 2026

Găsiți erorile comune ale instrumentului User Sync Tool și cum să le rezolvați.

Această pagină enumeră erorile comune pe care le puteți întâlni la rularea instrumentului User Sync Tool, împreună cu pașii pentru rezolvarea fiecăreia.Pentru o prezentare generală a instrumentului și unde să găsiți configurarea, configurația și referința comenzilor, consultați Configurați instrumentul User Sync Tool.

Instalarea și mediul

Acest lucru poate apărea pe Windows când căile depășesc 256 de caractere. Creați o variabilă de mediu numită PEX_ROOT cu valoarea C:\pex. Dacă rulați scriptul de pe o altă unitate decât C:, schimbați litera unității pentru a se potrivi. Uneori este necesară o repornire a sistemului pentru ca modificarea să aibă efect.

Rulați comanda python din interiorul dosarului unde se află user-sync.pex.

  • Verificați dacă versiunea Python instalată pe sistemul dumneavoastră este pe 32 de biți. Dezinstalați versiunea de 32-bit și instalați versiunea de 64-bit.
  • Verificați dacă versiunea user-sync.pex pe care ați descărcat-o de pe GitHub corespunde versiunii Python și sistemului de operare. De exemplu, descărcați user-sync-v2.3-win64-py365.zip pentru Windows 64-bit și Python 3. Potriviți versiunea Python cu care a fost construit .pex în loc să folosiți cea mai nouă versiune Python. Sufixul .zip identifică versiunea: pentru user-sync-v2.3-win64-py365.zip, aceasta este Python 3.6.5.

Această eroare a fost înregistrată pe macOS High Sierra folosind User Sync Tool v2.3 și Python 3.7.0. Executarea brew install openssl în Terminal a rezolvat problema pentru acel scenariu.

Conexiune, timeout-uri și limitarea traficului

Dacă timeout-ul este mai mic de 30 de minute, aceste avertismente apar când cota apelurilor API permise într-un minut este atinsă.Instrumentul folosește un mecanism de back-off exponențial pentru a reîncerca, crescând timpul dintre reîncercări și se oprește după trei încercări eșuate.Lăsați scriptul să ruleze până la sfârșit.

Dacă timeout-ul este mai mare de 1000 de secunde, limitarea este legată de frecvența cu care rulează fiecare instanță a instrumentului User Sync Tool.O instanță care rulează prea frecvent este limitată pentru 30 până la 75 de minute.Timeout-ul doar pune în pauză instrumentul pentru o perioadă; instrumentul se recuperează și continuă sincronizarea după aceea.

Deoarece instrumentul detectează când două instanțe pornesc în același timp, nicio instanță nouă nu rulează până când prima se termină.În acest caz, jurnalul poate afișa un mesaj că un proces este deja în curs.

Pentru cea mai bună performanță, urmați aceste recomandări de frecvență de rulare:

  • Setați sarcina programată să se repete la cel puțin 2 ore distanță.
  • Setați declanșatorul sarcinii programate astfel încât să nu înceapă la minutul :00 sau :30, pentru a evita traficul de vârf.
  • Dacă trebuie să rulați instrumentul mai des, luați în considerare utilizarea strategiei push (delta modificărilor) în loc de o sincronizare completă.
  • Potriviți programul de rulare al instrumentului cu ziua lucrătoare a organizației dvs.De exemplu, nu rulați operațiuni de sincronizare noaptea dacă organizația dvs. nu are nevoie să modifice aprovizionarea în acel moment.

Instrumentul nu se poate conecta la punctele finale ale API-ului public.Setările locale precum regulile firewall-ului, un proxy care blochează traficul sau setările de acces la internet ale contului pot împiedica accesul.Adăugarea variabilei de mediu https_proxy cu o valoare precum http://<proxyAddress>:<port> sau https://<proxyAddress>:<port> poate ajuta.În alte cazuri, permiteți accesul la aceste puncte finale: ims-na1.adobelogin.com:443 și usermanagement.adobe.io:443.Aceasta poate fi rezolvată doar local prin eliberarea accesului la aceste puncte finale pentru contul care rulează.

Inspecția SSL pe serverul proxy local cauzează aceasta.

Soluția 1: Obțineți certificatul CA rădăcină al proxy-ului în format PEM (de exemplu, thecert.crt).Dacă este în format DER, convertiți-l la PEM cu această comandă openssl: openssl x509 -inform DER -in thecert.crt -out thecert.pem -outform PEM.Un fișier PEM arată un șir codificat base64 între liniile -----BEGIN CERTIFICATE----- și -----END CERTIFICATE-----.Creați o variabilă de mediu numită REQUESTS_CA_BUNDLE și setați valoarea sa la calea către thecert.pem.

Soluția 2: Pe Windows, această eroare poate apărea dacă instrumentul rulează de pe o unitate diferită de cea unde sunt instalate sistemul de operare și Python.Mutați întregul script pe unitatea unde se află sistemul de operare.Dacă aceasta nu este o opțiune, copiați fișierul cacert.pem care conține CA-urile rădăcină de încredere pe cealaltă unitate și setați calea sa ca REQUESTS_CA_BUNDLE.Dacă un proxy inspectează de asemenea traficul SSL, copiați conținutul certificatului CA rădăcină al proxy-ului în cacert.pem astfel încât certificatul proxy să fie de încredere.O instalare Python implicită păstrează pachetul de certificate la C:\Python36\Lib\site-packages\certifi\cacert.pem.

Soluția 3: Dezactivați inspecția SSL pe proxy pentru punctele finale ale API-ului ims-na1.adobelogin.com și usermanagement.adobe.io.

Autentificare și acreditări

Intrarea din Magazinul de Acreditări pentru umapi_api_key poate lipsi.Creați intrarea în Magazinul de Acreditări.Consultați documentația instrumentului User Sync privind stocarea acreditărilor în stocarea la nivel de sistem de operare.

Este posibil ca valoarea să fi fost adăugată în Magazinul de acreditări sub un cont de utilizator diferit în timp ce intrarea lipsește pentru utilizatorul conectat în prezent.Adăugați-o sau comutați conturile de utilizator.

  • Dacă nu puteți identifica rapid problema, reemiteți perechea de chei.
  • Nu utilizați atributul umapi_private_key_data când rulați scriptul pe Windows.În schimb, criptați cheia și stocați parola în Managerul de credențiale.
  • Dacă ați folosit un format diferit pentru a emite perechea de chei, încercați o cheie privată RSA de 2048 de biți.
  • Este posibil să fi configurat secure_priv_key_pass_key: umapi_private_key_passphrase în fișierul connector-umapi.yml.Asigurați-vă că intrarea corespunzătoare din Magazinul de acreditări și valorile asociate se potrivesc.

În Adobe Admin Console, accesați Setări, apoi Setări de autentificare.Este posibil să fie selectată o opțiune diferită de Cel mai ușor pentru utilizatori (parola nu expiră niciodată).Opțiunea Mai sigur sau Cel mai sigur poate expira parola contului tehnic legat de integrare.Pentru a remedia această problemă, creați o integrare nouă și reînnoiți metadatele în fișierul connector-umapi.yml.A fost implementată o remediere pentru aceasta, dar poate afecta integrările create înainte de octombrie 2018.

Deschideți integrarea pe care ați creat-o în Adobe Developer Console și verificați lista de API-uri din meniul din stânga.Asigurați-vă că API-ul User Management este adăugat ca serviciu și apare în listă.

  • Valoarea tech_acct din fișierul connector-umapi.yml poate diferi de ID-ul contului tehnic din integrarea din Adobe Developer Console.Verificați ID-ul contului tehnic din integrarea curentă și copiați-l în fișier.
  • Certificate-ul public din integrare poate fi expirat. Reînnoiți cheia privată și publică, încărcați cheia publică și înlocuiți vechea cheie privată cu cea nouă. Verificați că calea din fișierul connector-umapi.yml indică către fișierul corect.
  • Confirmați că integrarea este pentru organizația corectă. Selectați organizația din meniul derulant din colțul din stânga-sus al Adobe Developer Console, apoi verificați ID-ul contului tehnic pentru integrarea principală împreună cu celelalte metadate (ID organizație, secret și ID client).

Această eroare apare la integrările mai vechi. Creați o integrare nouă (sau Proiect) în Adobe Developer Console alături de cea existentă utilizată în același scop. Noua integrare oferă credențiale noi, așa că actualizați-le în fișierul connector-umapi.yml. Perechea de chei (cheie privată și publică) este probabil reemisă, așa că noua cheie privată trebuie să înlocuiască cea existentă.

LDAP și grupuri

  • Grupul nu există în LDAP cu acel nume exact. Adăugați numele LDAP corect al grupului.
  • Grupul nu poate fi descoperit sub base_dn declarat (consultați fișierul connector-ldap.yml). Schimbați valoarea base_dn pentru a include grupul.Acest lucru se întâmplă în principal când base_dn indică către un OU specific în loc să fie cât mai larg posibil.

Grupul de utilizatori group_name din ieșire nu există pe partea Adobe. Creați-l. Dacă ați intenționat să setați numele unei configurații de licență de produs (PLC) în loc de un grup de utilizatori, consultați documentația instrumentului User Sync Tool despre crearea grupurilor corespunzătoare în directorul dvs. de întreprindere.

Grupurile de interes pot fi într-un subdomeniu în timp ce valoarea host este unul dintre domeniile rădăcină.Modificați valoarea host la un subdomeniu unde se găsesc grupurile de utilizatori. Dacă utilizatorii sau grupurile se află atât în domeniul rădăcină, cât și în subdomeniile sale, utilizați portul catalogului global pe domeniul rădăcină și modificați grupurile de subdomenii în Universal în loc de Global. Exemplu de valoare host utilizând catalogul global: ldap://domain.local:3268 sau ldaps://domain.local:3269.Când utilizați portul catalogului global, setați base_dn la o valoare goală: base_dn: &quot;&quot;.

Utilizatori și crearea conturilor

Domeniul utilizat pentru crearea contului poate să nu fie revendicat sau de încredere în organizația dvs. Un steag verde sau un punct apare pentru domeniile active în Adobe Admin Console sub Setări.Dacă nu apare, finalizarea procesului de revendicare a domeniului poate rezolva acest lucru.

S-a încercat crearea unui cont Federated ID, dar directorul este creat pentru Enterprise ID, sau invers. Găsiți atributul user_identity_type în fișierul user-sync-config.yml. Setați valoarea pentru a corespunde tipului de director afișat în Adobe Admin Console (Setări, apoi Identitate, apoi Domenii, apoi valoarea pentru Tipul directorului pentru domeniu).

Uneori domeniul @claimed-domain.com este deținut de o organizație diferită care a configurat un conector Azure sau Google pentru sincronizarea conturilor cu Admin Console, iar domeniul este apoi de încredere pentru o organizație diferită care utilizează instrumentul User Sync pentru sincronizarea conturilor în formatul @claimed-domain.com. Mesajul apare când instrumentul extrage contul user@claimed-domain.com dintr-un server LDAP pentru a-l crea în organizația secundară, dar contul nu este încă creat sau sincronizat în organizația principală prin conectorul Azure sau Google. Creați sau sincronizați contul user@claimed-domain.com în organizația care utilizează conectorul Azure sau Google, apoi reîncercați sincronizarea cu instrumentul User Sync în organizația beneficiară.

Această eroare generică are cauze multiple, dar problema obișnuită este că domeniul utilizat în acțiunea de creare se află sub o configurare de sincronizare Azure sau Google. Pentru verificare, conectați-vă la Adobe Admin Console cu contul de Administrator de sistem, accesați Setări, selectați directorul care conține domeniul și selectați fila Sincronizare. Dacă este prezentă o cartelă Sync Source, remediul depinde de cum ar trebui să continue sincronizarea:

  • Dacă conectorul Azure sau Google ar trebui să facă sincronizarea, continuați cu configurarea Sync Source și eliminați complet instrumentul User Sync.
  • Dacă instrumentul User Sync ar trebui să efectueze sincronizarea, selectați Accesați setările, apoi Eliminați sincronizarea în partea de jos a paginii.Instrumentul rulează apoi în mod obișnuit.

Dacă nu este prezentă nicio cartelă Sync Source, instrumentul curent poate rula împotriva unei Console unde domeniul este încredințat dintr-o Console diferită (organizația proprietară). Acea organizație poate avea sincronizarea Azure sau Google activată, ceea ce provoacă această eroare. Sincronizați mai întâi contul în Console-ul proprietar, apoi utilizați instrumentul pentru a crea contul în Console-ul curent.

Dacă niciunul dintre acestea nu se potrivește, contactați Asistența pentru întreprinderi.