LDAP सिंक और प्रोविजनिंग समस्या निवारण

अवलोकन

LDAP (लाइटवेट डायरेक्टरी एक्सेस प्रोटोकॉल) सिंक्रनाइज़ेशन और उपयोगकर्ता प्रोविजनिंग सुरक्षित और कुशल संसाधनों की पहुँच के लिए महत्वपूर्ण घटक हैं। हालांकि, इस प्रक्रिया को बाधित करने वाले मुद्दे उत्पन्न हो सकते हैं, जिससे पहुँच समस्याएँ और संभावित सुरक्षा कमजोरियाँ पैदा हो सकती हैं। यह प्लेबुक Cato में आम LDAP सिंक और प्रोविजनिंग मुद्दों को हल करने के लिए उपाय प्रदान करने का उद्देश्य रखती है।

लक्षण

LDAP सिंक और प्रोविजनिंग असफलताएँ कई रूपों में प्रकट हो सकती हैं। एक प्रशासक निम्नलिखित लक्षणों को नोट कर सकता है:

  • LDAP सिंक विफलता
  • उपयोगकर्ता Cato में प्रोविजन होने में असफल होते हैं
  • अप्रत्याशित उपयोगकर्ता Cato में प्रोविजन होते हैं

संभावित कारण

  • Cato को वापस रूटिंग समस्याएँ
  • अवैध या अनुपलब्ध उपयोगकर्ता विशेषताएँ 
  • LDAP त्रुटि या अनुपलब्ध LDAP सर्वर
  • TLS कनेक्टिविटी त्रुटि
  • LDAP सर्वर के लिए विषम रूटिंग।
  • समूह और उनके भीतर के उपयोगकर्ता
  • उपलब्ध SDP लाइसेंस की कमी

समस्या निवारण

प्रशासक जिन लक्षणों का सामना कर सकता है, उन्हें समस्या निवारण के लिए चरण नीचे सूचीबद्ध हैं। इन चरणों का उद्देश्य सामने आने वाली समस्याओं के संभावित कारणों की पहचान करना है। समाधान के चरणों को आगे प्लेबुक में हाइलाइट किया जाएगा।

LDAP सिंक विफलता की समस्या का निवारण

मैन्युअल LDAP सिंक एक्सेस > डायरेक्टरी सेवाएं > LDAP के तहत अभी समन्वयित करें पर क्लिक करके ट्रिगर किया जा सकता है। अन्यथा, स्वचालित सिंक का प्रयास प्रति दिन 00:00UTC पर पूरे खाते के लिए किया जाएगा, जब तक कि खाता दैनिक सिंक को निष्क्रिय नहीं करता है। यह अनुभाग उस स्थिति को संबोधित करता है जिसमें LDAP सिंक पूरा करने में विफल होता है।

कनेक्शन टेस्ट चलाना

Cato प्रबंधन अनुप्रयोग से सीधे कनेक्टिविटी परीक्षण परिणाम को सत्यापित करें। यह परीक्षण TCP कनेक्टिविटी और डोमेन कंट्रोलर के साथ LDAP बाइंडिंग को सत्यापित करेगा। सामान्य समस्याएँ, जैसे अवैध प्रमाण-पत्र और सर्वर डाउन, इस उपकरण का उपयोग करके निदान की जा सकती हैं। 

डायरेक्टरी सेवाएं इवेंट विश्लेषण

सिंक विफलता Cato में एक इवेंट उत्पन्न करेगी। नीचे स्क्रीनशॉट के अनुसार डीसी कनेक्टिविटी विफलता और डायरेक्टरी सेवाएं में उप-प्रकार को चुनकर इन इवेंट्स को फ़िल्टर करें। इवेंट संदेश फ़ील्ड सिंक विफलता का कारण दिखाएगा।

LDAP त्रुटियों का विश्लेषण

सिंक का प्रयास करते समय डीसी इवेंट में देखी गई LDAP त्रुटि आपके अनुभव के प्रकार का संकेत दे सकती है। एक त्रुटि यह दिखाती है कि DC तक नहीं पहुंचा जा सकता (त्रुटि कोड 81, सर्वर डाउन) कनेक्टिविटी त्रुटि का संकेत देती है। कनेक्टिविटी समस्याओं का निवारण देखें।

एक त्रुटि जो एक विशिष्ट LDAP त्रुटि लौटाती है सुझाव देती है कि LDAP सेवा के लिए कनेक्टिविटी स्थापित की जा सकती है लेकिन सिंक प्रक्रिया LDAP प्रोटोकॉल के भीतर विफल होती है। उत्पन्न त्रुटि कोड के आधार पर विशिष्ट LDAP त्रुटियों की जांच की जा सकती है। आपको इस LDAP त्रुटियों की सूची सहायक मिल सकती है।

नीचे दिया गया उदाहरण अवैध लॉगिन प्रमाण-पत्रों के कारण विफल सिंक प्रयास दिखाता है। इस समस्या को हल करने के लिए LDAP क्रेडेंशियल त्रुटियों को हल करना के साथ जारी रखें

कनेक्टिविटी समस्याओं का समाधान

Cato CMA और LDAP सर्वर के बीच द्वि-दिशात्मक कनेक्टिविटी की आवश्यकता है ताकि सिंक सफलतापूर्वक पूरा हो सके। निम्नलिखित की पुष्टि करें:

  1. DC सर्वर को Cato LDAP IP पते से ट्रैफ़िक प्राप्त करने में सक्षम होना चाहिए और उस पते को ट्रैफ़िक वापस करने के लिए Cato के लिए एक मार्ग होना चाहिए। Cato LDAP आईपी पता पहचानने के लिए, देखें Cato प्रबंधन अनुप्रयोग के लिए स्रोत IP पता (यह लेख देखने के लिए आपको साइन इन होना चाहिए)।
  2. यदि आपका डोमेन नियंत्रक IPsec कनेक्शन के पीछे है या यदि आप केवल कुछ सबनेट को सॉकेट तक रूट कर रहे हैं, तो अपने VPN टनल रूटिंग कॉन्फ़िगरेशन में Cato LDAP आईपी पता शामिल करना सुनिश्चित करें। Cato LDAP IP पता पहचानने के लिए, देखें Cato प्रबंधन अनुप्रयोग के लिए स्रोत IP पता (यह लेख देखने के लिए आपको साइन इन होना चाहिए)।
  3. DC सर्वर पर फ़ायरवॉल या सुरक्षा नीतियाँ इस ट्रैफ़िक के द्वि-दिशात्मक प्रवाह की अनुमति देनी चाहिए।

सॉकेट साइट के पीछे स्थित स्थानीय LDAP सर्वरों के लिए, ट्रैफ़िक न केवल द्वि-दिशात्मक होना चाहिए, बल्कि सममित्र भी होना चाहिए। Cato द्वारा प्रारंभ की गई LDAP क्वेरी सॉकेट टनल के माध्यम से सर्वर तक पहुंचेगी। वापसी ट्रैफ़िक को भी सॉकेट टनल के माध्यम से वापस रूट किया जाना चाहिए। ऐसा करने में विफलता एक असममित कनेक्शन का कारण बनेगी जो एक असफल सिंक का कारण बनेगी।  

साइट पर ज्ञात होस्ट्स पृष्ठ से अंतिम होस्ट गतिविधि मान की जाँच करके आंतरिक डोमेन नियंत्रक की जीवंतता की पुष्टि करें। एक साइट के लिए ज्ञात होस्ट्स दिखाना देखें

DC सर्वर से जुड़े सॉकेट LAN पर PCAP कैप्चर चलाकर कनेक्टिविटी समस्याओं का और निवारण किया जा सकता है, जबकि CMA से मैन्युअल सिंक चलाया जा रहा है। फ़िल्टर सेट करें ip.addr==Cato LDAP IP पता। असुरक्षित LDAP ट्रैफ़िक पोर्ट TCP/389 का उपयोग करता है और एन्क्रिप्टेड LDAP (LDAPS) पोर्ट TCP/636 का उपयोग करता है।

असुरक्षित LDAP ट्रैफ़िक को कैप्चर करना सिंक समस्या का निवारण करने में सहायक हो सकता है, क्योंकि LDAP प्रतिक्रियाएँ स्पष्ट टेक्स्ट में देखी जा सकती हैं।

असुरक्षित LDAP पर स्विच करने के लिए, डायरेक्टरी सेवाएँ कॉन्फ़िगरेशन के अंतर्गत SSL एन्क्रिप्शन विकल्प को अनचेक करें

यदि LDAP सिंक्स SSL एन्क्रिप्टेड होनी चाहिए, तो TLS त्रुटियों का निवारण के साथ जारी रखें

TLS त्रुटियों का निवारण

LDAPS करते समय, TLS बातचीत Cato PoP या LDAP सर्वर द्वारा असफल हो सकती है। त्रुटि पैकेट कैप्चर में पहचानी जा सकती है, जैसे कि घातक अलर्ट। नीचे दिए गए उदाहरण में, PoP क्लाइंट हैलो ACK प्राप्त करने के बाद TCP कनेक्शन बंद कर देता है, जो PoP के साथ एक समस्या का संकेत देता है।

mceclip0 (2).png

LDAPS करते समय पैकेट कैप्चर से किसी भी TLS त्रुटियों की पहचान करें। इन्हें हल करने के लिए, LDAPS TLS त्रुटियों को हल करना के साथ जारी रखें।

 

उपयोगकर्ता प्रावधान विफलता का समस्या निवारण

विभिन्न कारणों से, LDAP उपयोगकर्ता Cato के लिए प्रावधान किए जाने में विफल हो सकते हैं। इस अनुभाग में उन सबसे सामान्य परिदृश्यों को समझाया गया है जिनसे इस व्यवहार की व्याख्या हो सकती है।

उपयोगकर्ता निर्देशिका पृष्ठ की जाँच

प्रवेश > उपयोगकर्ता के अंतर्गत उपयोगकर्ता निर्देशिका पृष्ठ पर प्रभावित उपयोगकर्ता की पहचान करने का प्रयास करें। यह पहचानें कि क्या:

अनुपलब्ध उपयोगकर्ता गुण की जाँच

उपयोगकर्ता गुण Cato द्वारा अमान्य या अनुपलब्ध के रूप में माना जा सकता है और इससे उपयोगकर्ता प्रावधान से छूट सकते हैं। सुनिश्चित करें कि निम्नलिखित गुण उपयोगकर्ता के लिए सही ढंग से विन्यस्त हैं:

  • AD उपयोगकर्ताओं के लिए पहला और अंतिम नाम कॉन्फ़िगर किया जाना चाहिए। अन्यथा, पहला या अंतिम नाम अनुपलब्ध उपयोगकर्ता आपके Cato खाते से सिंक नहीं होंगे।
  • ईमेल और UPN गुण को निम्न प्रारूप में परिभाषित किया जाना चाहिए: user@domain। अन्यथा, उपयोगकर्ता को प्रोविजन्ड किया जाएगा लेकिन उसे SDP लाइसेंस असाइनमेंट प्राप्त करने में विफलता होगी।

उपयोगकर्ता सिंक सेटिंग्स की जाँच

डोमेन नियंत्रक पर LDAP उपयोगकर्ताओं में परिवर्तन CMA में उपयोगकर्ता संशोधन की अधिक संख्या को ट्रिगर कर सकते हैं जो LDAP सेटिंग्स में नियंत्रित है। जैसा कि मौजूदा उपयोगकर्ताओं का विवरण अपडेट करना में समझाया गया है, विकल्प सिंक के दौरान अधिक से अधिक उपयोगकर्ताओं को हटाने या अक्षम करने से रोकें। और उपयोगकर्ताओं के ईमेल अपडेट करें, अधिकतम प्रत्येक सिंक के लिए हटाए, अक्षम, या अपडेट किए जा सकने वाले उपयोगकर्ताओं की संख्या को सीमित करेंगे।

यदि सीमा पार कर जाती है, तो अगली LDAP सिंक विफल हो जाएगी और नए LDAP उपयोगकर्ताओं को प्रोविजन्ड करने में विफलता होगी। इनमें से कोई भी मुद्दा होने पर एक डायरेक्टरी सेवाएं घटना उत्पन्न होगी।

 

इस समस्या का समाधान करने के लिए इन विकल्पों को अनचेक करें यदि उच्च संख्या में उपयोगकर्ता परिवर्तन सिंक को पूर्ण होने से रोक रहे हैं।

अक्षम LDAP उपयोगकर्ताओं की जाँच

जब एक सिंक चल रही होती है, अगर प्रोविजन्ड करने के लिए उपयोगकर्ता Active Directory में निष्क्रिय या समाप्त हो गया है, तो उपयोगकर्ता को CMA में प्रोविजन्ड नहीं किया जाएगा। CMA में कोई विफल घटना नहीं होगी।

डोमेन नियंत्रक पर पुष्टि करें कि उपयोगकर्ता सक्रिय है।

उपयोगकर्ता प्रश्न सीमितता की जाँच

Microsoft Active Directory LDAP में एक अंतर्निहित सीमा होती है जो किसी भी एकल प्रश्न में 1500 गुण से कम के वस्तुओं को ही लौटने की अनुमति देती है। इस प्रकार, जब CMA LDAP क्वेरी चलाता है, तो 1500 से अधिक सदस्यों वाले कोई भी समूह CMA को एक खाली सदस्य सूची लौटाएगा, जिसके परिणामस्वरूप CMA में निष्क्रिय/हटाए गए उपयोगकर्ता होते हैं।

PCAP कैप्चर को सॉकेट LAN से चलाकर आप यह सत्यापित कर सकते हैं कि क्या आप इस सीमा का सामना कर रहे हैं। सदस्य विशेषता खाली होगी और रेंज=0-X दिखाते हुए एक अतिरिक्त सदस्य विशेषता होगी। यह दर्शाता है कि AD सर्वर पृष्ठांकन को मजबूर करने का प्रयास कर रहा था।

इस समस्या को हल करने के लिए, उपयोगकर्ता क्वेरी सीमा का समाधान करें देखें

डुप्लिकेट उपयोगकर्ताओं की जांच

सिंक चलाते समय, यदि प्रोविजन्ड किए जाने वाले उपयोगकर्ता का ईमेल पता पहले से CMA में मौजूद है, तो नया उपयोगकर्ता प्रावधान का व्यवहार इस पर निर्भर करेगा कि डुप्लिकेट उपयोगकर्ता को CMA में कैसे आयात किया गया था;

  • यदि डुप्लिकेट उपयोगकर्ता LDAP है, तो नया LDAP उपयोगकर्ता सफलतापूर्वक प्रावधानित किया जाएगा, लेकिन उपयोगकर्ता निर्देशिका पृष्ठ पर कोई SDP लाइसेंस असाइन नहीं होगा।
    ऊपर बताई गई शर्तों के तहत एक SDP लाइसेंस घटना उत्पन्न होगी।


    इस समस्या को हल करने के लिए, नए प्रावधानित उपयोगकर्ता के ईमेल पते या उपयोगकर्ता नाम को संशोधित करें या डुप्लिकेट LDAP उपयोगकर्ता को हटा दें। ये फ़ील्ड डायरेक्टरी सेवा के सभी उपयोगकर्ताओं में अद्वितीय होने चाहिए।

  • यदि डुप्लिकेट उपयोगकर्ता SCIM है, तो नया LDAP उपयोगकर्ता प्रावधानित नहीं होगा क्योंकि यह SCIM प्रावधानित उपयोगकर्ता को ओवरराइड नहीं करेगा जैसा कि SCIM से LDAP प्रावधानिंग में परिवर्तन में समझाया गया है। इस समस्या को हल करने के लिए, सुनिश्चित करें कि प्रत्येक उपयोगकर्ता के ईमेल पते अद्वितीय हैं और LDAP और SCIM के साथ प्रावधानित उपयोगकर्ता और समूह एक-दूसरे से ओवरलैप नहीं होते।
  • यदि डुप्लिकेट उपयोगकर्ता मैनुअल है, तो नया LDAP उपयोगकर्ता प्रावधानित नहीं होगा क्योंकि यह मैनुअल प्रावधानित उपयोगकर्ता को ओवरराइड नहीं करेगा। इस समस्या को हल करने के लिए, सुनिश्चित करें कि प्रत्येक उपयोगकर्ता का ईमेल पता अद्वितीय है या LDAP सिंकिंग से पहले CMA से मैनुअली प्रावधानित उपयोगकर्ता को हटा दें।

अनुपलब्ध SDP लाइसेंस की जांच

सिंक चलाते समय, यदि खाते में या संबंधित उपयोगकर्ता और उपयोगकर्ता समूह के लिए कोई उपलब्ध SDP लाइसेंस नहीं है, तो उपयोगकर्ता सफलतापूर्वक प्रावधानित होगा लेकिन उपयोगकर्ता निर्देशिका पृष्ठ पर SDP लाइसेंस असाइन नहीं होगा।

जैसा कि SDP लाइसेंस असाइनमेंट में समझाया गया है, सत्यापित करें कि SDP लाइसेंस उपयोगकर्ता या उसके उपयोगकर्ता समूह को असाइन किया गया है। यदि समस्या खाते में SDP लाइसेंस से संबंधित है, तो नीचे दिखाया गया SDP लाइसेंस घटना उत्पन्न होगी।

इस समस्या को हल करने के लिए, SDP लाइसेंस त्रुटियों का समाधान देखें

 

अप्रत्याशित प्रावधानित उपयोगकर्ताओं की समस्या निवारण

विभिन्न कारणों से आयातित LDAP उपयोगकर्ता CMA में कॉन्फ़िगर की गई अपेक्षाओं से भिन्न हो सकते हैं। इस खंड में उन सबसे सामान्य परिदृश्यों की व्याख्या की गई है जो इस व्यवहार का कारण हो सकते हैं।

खाली उपयोगकर्ता समूह फ़ील्ड

जैसा कि Active Directory समूहों का आयात में समझाया गया है, यदि LDAP सेटिंग्स के तहत कोई उपयोगकर्ता समूह चयनित नहीं है, तो संपूर्ण Active Directory आयात किया जाता है। इससे सम्पूर्ण उपयोगकर्ता आधार के CMA में आयात और Cato उपयोगकर्ता लाइसेंस की समाप्ति होगी।

इस समस्या को हल करने के लिए, केवल उन्ही विशेष LDAP समूहों को परिभाषित करें जिन्हें आप Cato में आयात करना चाहते हैं और SDP लाइसेंस त्रुटियों का समाधान का पालन करें

नेस्टेड समूहों की जाँच

यदि LDAP सिंक करने के बाद, आप यह देखते हैं कि कुछ प्रोविजन्ड उपयोगकर्ताओं को पहुँच > डायरेक्टरी सेवाएँ > LDAP > उपयोगकर्ता समूह सूचना में आयात के लिए परिभाषित नहीं किया गया था, तो निम्नलिखित की जाँच करें:

  • Cato LDAP सिंक हर परिभाषित उपयोगकर्ता समूह के सदस्यों को स्कैन करता है। इन समूहों में उपयोगकर्ता और अन्य नेस्टेड समूह शामिल हो सकते हैं। इस उदाहरण में, केवल VPN समूह CMA में परिभाषित है।
  • आप CMA में समूहों का सदस्य पृष्ठ से जाँच सकते हैं कि एक विशेष उपयोगकर्ता किन सभी समूहों का सदस्य है।
  • उपरोक्त उदाहरण में, उपसमूह VPN समूह का एक नेस्टेड समूह है, इसलिए उपसमूह का कोई भी सदस्य CMA में आयात किया जाएगा क्योंकि Cato नेस्टेड समूहों और उनके उपयोगकर्ताओं को आयात करता है अगर वे एक परिभाषित उपयोगकर्ता समूह में रहते हैं। 

 

खोजी गई समस्याओं का समाधान

LDAP क्रेडेंशियल त्रुटियों का समाधान

LDAP सेटिंग्स में लॉगिन DN और बेस DN फ़ील्ड्स की पुष्टि करें कि वे Active Directory में कॉन्फ़िगर किए गए प्रशासक उपयोगकर्ता के गुणों के आधार पर सही हैं। 

लॉगिन DN की पुष्टि करने के लिए, DC के कमांड प्रॉम्प्ट से निम्नलिखित कमांड चलाएँ:

 dsquery user -name <username>

आउटपुट प्रदर्शित करेगा कि प्रशासक उपयोगकर्ता के लिए कॉन्फ़िगर किया गया पूरा distinguishedName क्या है जो CMA में लॉगिन DN फ़ील्ड के साथ मेल खाना चाहिए

यदि आवश्यक हो, तो डोमेन नियंत्रक पर प्रशासक उपयोगकर्ता के लिए पासवर्ड रीसेट करें और सुनिश्चित करें कि यह CMA में दर्ज पासवर्ड से मेल खाता है।

LDAPS TLS त्रुटियों का समाधान

यदि LDAP सर्वर द्वारा TLS त्रुटि भेजी गई है, तो आप अधिक जानकारी के लिए विंडोज घटना दर्शक की जांच कर सकते हैं अगर यह PoP द्वारा भेजा गया है तो आप निर्देशिका सेवाओं के तहत संबंधित डोमेन नियंत्रक को निकालने और इसे फिर से जोड़ने का प्रयास कर सकते हैं यह LDAP सर्वर के साथ TLS कनेक्शन का पुनःस्थापन करेगा। 

उपयोगकर्ता क्वेरी सीमा का समाधान

जैसा कि LDAP के साथ उपयोगकर्ताओं का समन्वयन में उल्लेख किया गया है, इस सीमा के कारण उपयोगकर्ताओं का अवांछित निष्क्रियता/हटाने को रोकने के लिए, आप CMA में "समूह सदस्यता को अपडेट करने से रोकें" विकल्प को कॉन्फ़िगर करके एकल सिंक में उपयोगकर्ता समूह सदस्यता को बदल सकने वाले उपयोगकर्ताओं की अधिकतम संख्या को अनुकूलित कर सकते हैं।

डोमेन नियंत्रक से खाली क्वेरी प्रतिक्रिया को हल करने के लिए, आप इन चरणों का पालन कर सकते हैं:

  • Microsoft LDAP नीति के MaxValRange गुण को समायोजित करें जो यह नियंत्रित करता है कि कितने मान लौटाए जाएंगे। इस प्रक्रिया का वर्णन इस MS लेख में किया गया है।
  • वैकल्पिक रूप से, इस MS लेख में समझाए अनुसार क्वेरी प्रतिबंध को पूरी तरह से हटाया जा सकता है।
  • यदि एक्टिव डायरेक्टरी में परिवर्तन की अनुमति नहीं है, तो एकमात्र विकल्प उपयोगकर्ताओं को Cato में प्रोविजन करने के लिए 1500 गुणों से कम के साथ एक LDAP समूह का उपयोग करना है।

SDP लाइसेंस त्रुटियों को हल करना

खातों की लाइसेंसिंग स्थिति प्रशासन > लाइसेंस > उपयोगकर्ता के अंतर्गत पाई जा सकती है 

ऐसे मामलों में जहां पर्याप्त लाइसेंस उपलब्ध नहीं हैं, पहुँच > लाइसेंस असाइनमेंट के अंतर्गत उपयोगकर्ताओं और उपयोगकर्ता समूह की स्कोप को कम करें। अन्यथा, अतिरिक्त SDP लाइसेंस खरीदने के लिए अपने CSM या खाता मालिक से संपर्क करें।

 

Cato समर्थन के लिए मामले उठाना

उपरोक्त समस्या निवारण चरणों के परिणामों के साथ सहायता टिकट जमा करें। कृपया टिकट में निम्नलिखित जानकारी शामिल करें:

  • अनुभव की गई समस्या का विवरण और उपयोगकर्ताओं पर समग्र प्रभाव।
  • संबंधित डायरेक्टरी सेवाएं घटनाएँ और मैन्युअल LDAP सिंक का परिणाम।
  • LDAP सर्वर के साथ पूर्ण बातचीत दिखाने वाली PCAP कैप्चर फ़ाइल।

क्या यह लेख उपयोगी था?

0 में से 0 के लिए उपयोगी रहा

0 टिप्पणियां