डायरेक्ट्री सिंक से जुड़ी समस्या हल करना

• पक्का करें कि प्रोजेक्ट में, Data Connectors API चालू हो. ज़्यादा जानकारी के लिए, Data Connectors API चालू करना लेख पढ़ें.
• अगर वर्चुअल प्राइवेट क्लाउड (वीपीसी) सर्विस कंट्रोल के पेरीमीटर का कोई नियम कॉन्फ़िगर किया गया है और Google Cloud console में, storage.googleapis.com से जुड़ी PERMISSION_DENIED गड़बड़ियां दिख रही हैं, तो आपको अपने प्रोजेक्ट के लिए Cloud Storage API का ऐक्सेस देना होगा. अगर आपको artifactregistry.googleapis.com से जुड़ी गड़बड़ियां भी दिखती हैं, तो डायरेक्ट्री सिंक के संसाधनों को अपनी बाहरी डायरेक्ट्री तक पहुंचने की अनुमति देने के लिए, यह आउटबाउंड नियम जोड़ें:

  egress To:
  _ serviceName : artifactregistry.googleapis.com
   methodSelectors :
    - method: artifactregistry.googleapis.com/DockerRead
  Resources
  - projects/397958601689
  egressFrom:
   identityType: ANY_IDENTITY

सर्विस पेरीमीटर के नियमों में बदलाव करने के बारे में ज़्यादा जानने के लिए, सर्विस पेरीमीटर की जानकारी और पुष्टि करना लेख पढ़ें.

डायरेक्ट्री सिंक के एक से ज़्यादा कनेक्शन, एक ही डोमेन को पॉइंट नहीं कर सकते. डायरेक्ट्री सिंक, बेस डिस्टिंग्विश्ड नेम (डीएन) की तुलना करता है. अगर डोमेन मेल खाते हैं, तो डायरेक्ट्री नहीं बनाई जा सकती.

इस समस्या को हल करने के लिए, एक ही डोमेन के साथ नई डायरेक्ट्री बनाने से पहले, मेल खाने वाले डीएन वाले कनेक्शन को मिटाएं.

अगर आपको एडमिन के लॉग इवेंट के डेटा में यह गड़बड़ी दिखती है, तो इन चीज़ों की जांच करें:

• Microsoft Active Directory (AD) सर्वर चालू है.
• आपके नेटवर्क और फ़ायरवॉल, एलडीएपी पोर्ट पर आने वाले ट्रैफ़िक की अनुमति देने के लिए सेट अप किए गए हैं.
• आपने अनुमति वाले खाते की क्रेडेंशियल सही तरीके से डाली हैं. इसके लिए, username@example.com या EXAMPLE\username फ़ॉर्मैट का इस्तेमाल किया है.

अगर आपको अब भी गड़बड़ी दिखती है, तो एडी होस्टनेम को हल करने के लिए, डोमेन नेम सिस्टम (डीएनएस) सर्वर की जानकारी जोड़ें. ज़्यादा जानकारी के लिए, बाहरी डायरेक्ट्री जोड़ना लेख पढ़ें.

वर्चुअल प्राइवेट क्लाउड (वीपीसी) ऐक्सेस कनेक्टर वाले सबनेट में, Linux वर्चुअल मशीन (वीएम) भी बनाई जा सकती है. पोर्ट 636 पर, एडी सर्वर के आईपी पते से टेलनेट करने की कोशिश करें. अगर टेलनेट नहीं हो पाता है, तो एडी सर्वर की नेटवर्क सेटिंग की पुष्टि करें. उदाहरण के लिए, देखें कि पोर्ट 636 खुला है या नहीं.

अगर टेलनेट हो जाता है, तो यह पुष्टि करने के लिए कि एडी सर्वर सही सर्टिफ़िकेट का इस्तेमाल कर रहा है या नहीं, Linux वीएम पर यह कमांड डालें:

openssl s_client -showcerts -connect external server IP address:636

आपको एडमिन के लॉग इवेंट के डेटा में, इस गड़बड़ी के दो वर्शन मिल सकते हैं.

गड़बड़ी 1–कॉन्फ़िगर किए गए 10,000 मिलीसेकंड के टाइम आउट में, सर्वर (Server IP) से कनेक्ट करने में कोई गड़बड़ी हुई

इस गड़बड़ी का मतलब है कि डायरेक्ट्री सिंक, Active Directory (AD) सर्वर से कनेक्ट नहीं हो पाया. इस समस्या को हल करने के लिए, पक्का करें कि आपने एडी को सही तरीके से सेट अप किया हो. ज़्यादा जानकारी के लिए, एडी डायरेक्ट्री जोड़ना लेख पढ़ें.

गड़बड़ी 2–सर्वर (Server IP) से कनेक्शन बनाने में कोई गड़बड़ी हुई: (SSLHandshakeException(sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target)

इस गड़बड़ी का मतलब है कि एडी टीएलएस सर्टिफ़िकेट, उस सर्टिफ़िकेट से मेल नहीं खाता जिसे आपने बाहरी डायरेक्ट्री कनेक्शन को कॉन्फ़िगर करते समय जोड़ा था. इस समस्या को हल करने के लिए, पक्का करें कि सर्टिफ़िकेट मेल खाते हों. ज़्यादा जानकारी के लिए, एडी डायरेक्ट्री जोड़ना लेख पढ़ें.

एडी टीएलएस सर्टिफ़िकेट को स्थानीय तौर पर सेव करने के लिए, Microsoft PowerShell में यह स्क्रिप्ट डालें. इसमें localhost की जगह, अपने एडी सर्वर का डीएनएस रिकॉर्ड या आईपी पता डालें:

$webRequest = [Net.WebRequest]::Create("https://localhost:636")
try { $webRequest.GetResponse() } catch {}
$cert = $webRequest.ServicePoint.Certificate
$bytes = $cert.Export([Security.Cryptography.X509Certificates.X509ContentType]::Cert)
set-content -value $bytes -encoding byte -path "$pwd\Workspace.cer"

अगर Google और Microsoft Azure Active Directory के बीच कनेक्शन की जांच नहीं की जा सकती, तो समस्या हल करने से जुड़ी जानकारी के लिए, एडमिन के लॉग इवेंट देखें. ज़्यादा जानकारी के लिए, एडमिन के लॉग इवेंट लेख पढ़ें.

आपको डायरेक्ट्री सिंक के लॉग इवेंट में यह गड़बड़ी दिख सकती है: "उपयोगकर्ता नहीं बनाया जा सका. मैसेज: DOMAIN_OVER_USER_LIMIT_FIX_BY_CONTACT_SUPPORT."

इस गड़बड़ी का मतलब है कि उपयोगकर्ता के लाइसेंस से जुड़ी कोई समस्या है. अगर Google Workspace में उपलब्ध लाइसेंस की संख्या से ज़्यादा उपयोगकर्ता जोड़े जाते हैं या लाइसेंस असाइन करने के लिए उपलब्ध नहीं हैं, तो उपयोगकर्ता नहीं बनाया जा सकता. साथ ही, आपको यह गड़बड़ी दिखती है.

इस समस्या को हल करने के लिए, अपने उपयोगकर्ताओं के लिए उपलब्ध लाइसेंस की संख्या बढ़ाएं. ज़्यादा जानकारी के लिए, उपयोगकर्ता के ज़्यादा लाइसेंस खरीदना लेख पढ़ें.

मिलते-जुलते विषय

• डायरेक्ट्री सिंक के लॉग इवेंट देखना
• लाइसेंस असाइन करना, हटाना, और फिर से असाइन करना

अगर आपको नतीजा - रेफ़रल से शुरू होने वाली कोई गड़बड़ी दिखती है, तो पक्का करें कि सिंक सेट अप करते समय डाला गया बेस डीएन सही हो.

अगर ग्लोबल कैटलॉग पोर्ट 3269 का इस्तेमाल किया जा रहा है, तो इसे 636 पर बदलें.

डायरेक्ट्री सिंक के लॉग इवेंट में, आपको इस ब्यौरे के साथ सिंक करने से जुड़ी गड़बड़ियां दिख सकती हैं. आम तौर पर, यह गड़बड़ी तब दिखती है, जब उपयोगकर्ता खाता इनऐक्टिव होता है या ईमेल आईडी में एडी में गलत डोमेन होता है. अपने लॉग में इस समस्या को हल करने के लिए, टेबल देखें.

इनऐक्टिव उपयोगकर्ता के लॉग एंट्री से जुड़ी समस्या हल करना

अमान्य ईमेल पते और गलत डोमेन के लॉग एंट्री से जुड़ी समस्या हल करना

मिलता-जुलता विषय

डायरेक्ट्री सिंक के लॉग इवेंट देखना

यह तरीका पूरा करने के लिए, आपके पास सुपर एडमिन या डायरेक्ट्री सिंक एडमिन की भूमिका होनी चाहिए. इसके अलावा, आपके पास डायरेक्ट्री सिंक की सेटिंग मैनेज करें की अनुमति होनी चाहिए.

अगर उपयोगकर्ता और ग्रुप सिंक नहीं किए गए हैं, तो:

1. अपने Google Admin console (admin.google.com पर) में, डायरेक्ट्री सिंक बाहरी डायरेक्ट्री पर क्लिक करें.
2. अपनी डायरेक्ट्री का सिंक स्टेटस देखें.
3. अगर सिंक की सुविधा बंद है या सिंक नहीं किया जा सका है, तो सिंक की सुविधा चालू करें.

   ज़्यादा जानकारी के लिए, सिंक करना लेख पढ़ें.

अगर आपका Microsoft Domain Users ग्रुप सिंक नहीं हो रहा है, तो:

डायरेक्ट्री सिंक, Microsoft Domain Users ग्रुप के साथ काम नहीं करता. _ज़्यादा जानें_

1. Active Directory में, एक नया ग्रुप बनाएं. इसमें Microsoft Domain Users ग्रुप के सभी सदस्य और अनुमतियां शामिल करें.
2. उस ग्रुप को Microsoft Domain Users ग्रुप के सदस्य के तौर पर जोड़ें.
3. सदस्यों को मैनेज करने और सिंक करने के लिए, नए ग्रुप का इस्तेमाल करें.

ध्यान दें: Microsoft Domain User ग्रुप के एट्रिब्यूट न बदलें, क्योंकि इससे अन्य समस्याएं हो सकती हैं.

आपको इस गड़बड़ी को हल करने के बारे में ज़्यादा जानकारी, डायरेक्ट्री सिंक के लॉग इवेंट में मिल सकती है:

1. डायरेक्ट्री सिंक के लॉग इवेंट खोलें.

   ज़्यादा जानकारी के लिए, डायरेक्ट्री सिंक के लॉग इवेंट का डेटा ऐक्सेस करना लेख पढ़ें.

2. फ़िल्टर जोड़ें टारगेट ऑब्जेक्ट आईडी पर क्लिक करें.
3. उपयोगकर्ता का ईमेल पता डालें और लागू करें पर क्लिक करें.
4. अगर आपको:
   • ऑब्जेक्ट अपडेट किया गया इवेंट दिखता है और उसका ब्यौरा नए एट्रिब्यूट {निलंबित: सही है} है, तो डायरेक्ट्री सिंक ने उपयोगकर्ता को निलंबित कर दिया है, क्योंकि एडी में उसका खाता ऐक्टिव नहीं है.
   • ऑब्जेक्ट डीप्रोविज़न किया गया इवेंट दिखता है, तो देखें कि एडी में उपयोगकर्ता को मिटाया गया है या उसे किसी ऐसे पाथ पर ले जाया गया है जो एलडीएपी के खोज के दायरे में नहीं आता.

पता लगाएं कि कौनसे उपयोगकर्ता सिंक नहीं किए गए हैं. साथ ही, पक्का करें कि उपयोगकर्ता:

• आपकी बाहरी डायरेक्ट्री में इनऐक्टिव न हो
• उस ग्रुप का डायरेक्ट सदस्य हो जिसे आपने उपयोगकर्ता को सिंक करने की सुविधा सेट अप करते समय चुना था
• आपकी बाहरी डायरेक्ट्री में उपयोगकर्ता ऑब्जेक्ट हो, न कि संपर्क
• के पास ऐसा ईमेल आईडी हो जो आपकी बाहरी डायरेक्ट्री में मौजूद हो. साथ ही, ईमेल आईडी में मौजूद डोमेन, आपके Google Workspace डोमेन के जैसा हो

आपको इस समस्या को हल करने के बारे में ज़्यादा जानकारी, डायरेक्ट्री सिंक के लॉग इवेंट में मिल सकती है:

1. डायरेक्ट्री सिंक के लॉग इवेंट खोलें.

   ज़्यादा जानकारी के लिए, डायरेक्ट्री सिंक के लॉग इवेंट का डेटा ऐक्सेस करना लेख पढ़ें.

2. फ़िल्टर जोड़ें सोर्स ऑब्जेक्ट आईडी पर क्लिक करें.
3. उपयोगकर्ता का डीएन जोड़ें और लागू करें पर क्लिक करें.
4. सिंक करने में गड़बड़ी वाले इवेंट ढूंढें और गड़बड़ियों की समीक्षा करें.
5. उपयोगकर्ता के डीएन के साथ ऑब्जेक्ट पढ़ें इवेंट खोजें.
6. अगर आपको ऑब्जेक्ट पढ़ें इवेंट नहीं मिलते हैं, तो डायरेक्ट्री सिंक ने उपयोगकर्ता को सिंक नहीं किया है. इसकी आम वजहें ये हैं:
   • उपयोगकर्ता की सदस्यता, एलडीएपी के खोज के दायरे में नहीं आती (उपयोगकर्ता, उस ग्रुप के बेस डीएन पर या उसके नीचे मौजूद नहीं है जिसे आपने उपयोगकर्ता को सिंक करने की सुविधा सेट अप करते समय चुना था).
   • डायरेक्ट्री सिंक, किसी दूसरे डोमेन कंट्रोलर से कम्यूनिकेट कर रहा है. साथ ही, इंक्रीमेंटल सिंक, सभी बदलावों को पिक अप नहीं कर रहा है. पक्का करें कि होस्टनेम और आईपी पता, एक ही डोमेन कंट्रोलर को पॉइंट करते हों.

देखें कि ग्रुप के सदस्य के पास:

• मेल एट्रिब्यूट की वैल्यू सेट है और मान्य फ़ॉर्मैट में ईमेल आईडी है
• ग्रुप के बेस डीएन पर या उसके नीचे मौजूद नहीं है

उपयोगकर्ता पहले से मौजूद है गड़बड़ी आम तौर पर तब दिखती है, जब अपनी बाहरी डायरेक्ट्री में किसी उपयोगकर्ता को मिटा दिया जाता है और फिर उसी ईमेल पते से कोई नया उपयोगकर्ता बनाया जाता है.

डायरेक्ट्री सिंक, Google Workspace और आपकी बाहरी डायरेक्ट्री के बीच उपयोगकर्ताओं को लिंक करने के लिए, यूनीक आइडेंटिफ़ायर का इस्तेमाल करता है. Microsoft Active Directory के उपयोगकर्ताओं के पास ObjectGUID आइडेंटिफ़ायर होता है. वहीं, Microsoft Azure Active Directory के उपयोगकर्ताओं के पास ऑब्जेक्ट आईडी होता है.

अगर अपनी बाहरी डायरेक्ट्री में किसी उपयोगकर्ता को फिर से बनाया जाता है, तो नए उपयोगकर्ता को ओरिजनल ObjectGUID या ऑब्जेक्ट आईडी आइडेंटिफ़ायर मिलता है. हालांकि, Workspace में नए उपयोगकर्ता का ईमेल पता अब भी मिटाए गए उपयोगकर्ता से लिंक होता है. इसलिए, सिंक नहीं किया जा सकता.

अगर आपको उसी ईमेल पते से किसी उपयोगकर्ता को फिर से बनाना है, तो अपनी बाहरी डायरेक्ट्री में उपयोगकर्ता का ObjectGUID या ऑब्जेक्ट आईडी सेव रखें. इसके अलावा, Workspace में उपयोगकर्ता का ईमेल पता बदलें या मिटाएं. इससे डायरेक्ट्री सिंक, उपयोगकर्ता खाते को आपकी बाहरी डायरेक्ट्री में मौजूद नए उपयोगकर्ता से लिंक कर पाएगा.