इस सुविधा के साथ काम करने वाले वर्शन: Frontline Standard और Frontline Plus, Business Plus, Enterprise Standard और Enterprise Plus, Education Fundamentals, Education Standard, Education Plus, और Enterprise Essentials Plus. अपने वर्शन की तुलना करें
अपने LDAP क्लाइंट को सुरक्षित LDAP सेवा से कनेक्ट करने से पहले, ज़रूरी नहीं है कि आप ldapsearch, ADSI या ldp.exe जैसे सामान्य टूल का इस्तेमाल करके, कनेक्टिविटी की जांच करें. अगर अपने LDAP क्लाइंट को सेवा से कनेक्ट करने में गड़बड़ियां आती हैं, तो इन टूल का इस्तेमाल, समस्या हल करने के लिए भी किया जा सकता है.
यहां दिए गए सेक्शन में बताई गई जांचों से, यह समझने में मदद मिलती है कि आपके कॉन्फ़िगरेशन में कोई समस्या है या नहीं. साथ ही, सामान्य गड़बड़ी के मैसेज और उन समस्याओं को ठीक करने के सुझाव भी मिलते हैं.
इस लेख में निम्न सेक्शन शामिल हैं:
- कनेक्टिविटी की पुष्टि करना और LDAP क्वेरी चलाना
LDAP क्वेरी चलाने से, यह पुष्टि की जा सकती है कि सुरक्षित LDAP से कनेक्ट किया जा सकता है और क्वेरी की जा सकती हैं. - **ज़रूरत पड़ने पर, कनेक्टिविटी की सामान्य जांच करना**
अगर LDAP क्वेरी चलाने में गड़बड़ी आती है, तो नेटवर्क ऐक्सेस और पुष्टि की जांच करने के लिए, कनेक्टिविटी की सामान्य जांच करें.
ध्यान दें: अगर आपको इस प्रोसेस के दौरान, Google Workspace की सहायता टीम या Cloud Identity Premium की सहायता टीम से संपर्क करना है, तो कमांड का आउटपुट सेव करना न भूलें. सहायता टीम के साथ आउटपुट शेयर करने से पहले, उसमें से निजी जानकारी हटाना न भूलें.
कनेक्टिविटी की पुष्टि करना और LDAP क्वेरी चलाना
Google Admin console में सुरक्षित LDAP सेवा सेट अप करने के बाद, सुरक्षित LDAP से कनेक्टिविटी की पुष्टि करने के लिए, इन तीन सामान्य टूल में से किसी एक का इस्तेमाल किया जा सकता है: ldapsearch, ADSI या ldp.exe. ज़्यादा जानकारी और निर्देश पाने के लिए, यहां दिए गए सेक्शन देखें.
ldapsearch
LDAP की सामान्य क्वेरी करने के लिए, कमांड लाइन से ldapsearch यूटिलिटी का इस्तेमाल करें. LDAP क्वेरी का नतीजा सही होने का मतलब है कि LDAP क्लाइंट, टीएलएस सेशन, और टीसीपी कनेक्शन सही तरीके से काम कर रहे हैं.
ldapsearch की मदद से कनेक्टिविटी की जांच करने के लिए:
- LDAP क्लाइंट जोड़ें में दिए गए निर्देशों का पालन करके, LDAP कॉन्फ़िगरेशन बनाएं और सर्टिफ़िकेट डाउनलोड करें.
ध्यान दें: जांच के एनवायरमेंट को आसान बनाने के लिए, पक्का करें कि उस संगठनात्मक इकाई में कम से कम एक उपयोगकर्ता हो जिसके लिए, आपने LDAP क्लाइंट के ऐक्सेस की अनुमति दी है.
- LDAP क्वेरी चलाएं. इस उदाहरण में, किसी खास उपयोगकर्ता की क्वेरी की गई है. ज़्यादा जानकारी के लिए, OpenLDAP ldapsearch देखें.
LDAPTLS_CERT={crt_file} LDAPTLS_KEY={key_file} ldapsearch -H ldaps://ldap.google.com:636 -b dc={domain},dc={domain} '(mail={user_email})'प्लेसहोल्डर को इस तरह बदलें:
- {crt_file} .crt फ़ाइल का नाम
- {key_file} .key फ़ाइल का नाम
- {domain} डोमेन नेम का हर हिस्सा. उदाहरण के लिए, example.com, "dc=example,dc=com" बन जाएगा
- {user_email} डोमेन में मौजूद किसी उपयोगकर्ता का प्राइमरी ईमेल पता.
ldapsearch का इस्तेमाल करने के बारे में नोट
- अगर BindDN की कोई वैल्यू नहीं दी जाती है, तो ldapsearch, खोज की अनुमति देने के लिए कुंजी और सर्टिफ़िकेट का इस्तेमाल करता है.
- अगर BindDN की वैल्यू, Admin console में जनरेट किया गया कोई LDAP उपयोगकर्ता नाम है, तो ldapsearch, Admin console में कॉन्फ़िगर किए गए LDAP क्लाइंट की अनुमतियों का इस्तेमाल करेगा.
ldapsearch -H ldaps://ldap.google.com:636 -b dc={domain},dc={domain} -D {ldap_access_credentials_username} -W '(mail={user_email}) - अगर BindDN की वैल्यू, Workspace उपयोगकर्ता का कोई ईमेल पता या LDAP डिस्टिंग्विश्ड नेम है, तो ldapsearch, उस उपयोगकर्ता के क्रेडेंशियल का इस्तेमाल करके, उसकी अनुमतियों के आधार पर खोज करेगा.
ldapsearch -H ldaps://ldap.google.com:636 -b dc={domain},dc={domain} -D {workspace_username@domain} -W '(mail={user_email})'
stunnel के साथ ldapsearch का इस्तेमाल करना
अगर आपको डिप्लॉयमेंट के लिए stunnel का इस्तेमाल करना है, तो यह तरीका अपनाएं:
- Admin console में, ऐक्सेस क्रेडेंशियल जनरेट करें, ताकि ldapsearch के लिए ज़रूरी उपयोगकर्ता नाम और पासवर्ड मिल सके.
- यह कमांड इस्तेमाल करें:
ldapsearch -x -D "{username}" -w {password} -H ldap://{stunnel_host}:{stunnel_port} -b dc={domain},dc={domain} '(mail={user_email})'प्लेसहोल्डर को इस तरह बदलें:
- {username} Admin console में जनरेट किए गए क्रेडेंशियल से मिला उपयोगकर्ता नाम
- {password} Admin console में जनरेट किए गए क्रेडेंशियल से मिला पासवर्ड
- {stunnel_host} : आपके नेटवर्क में stunnel चलाने वाली मशीन का आईपी पता या होस्टनेम.
- {stunnel_port} : वह पोर्ट जहां stunnel चल रहा है. stunnel का कॉन्फ़िगरेशन देखें
- {user_email} डोमेन में मौजूद किसी उपयोगकर्ता का प्राइमरी ईमेल पता
ldapsearch कमांड का सही नतीजा
ldapsearch कमांड का सही आउटपुट, LDIF फ़ॉर्मैट में उस उपयोगकर्ता को दिखाएगा जिसका ईमेल पता (LDAP क्लाइंट बनाते समय बताया गया) है.
उदाहरण के लिए:
# extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# example.com
dn: dc=example,dc=com
objectClass: top
objectClass: domain
objectClass: dcObject
dc: example
# admin-group, Groups, example.com
dn: cn=admin-group,ou=Groups,dc=example,dc=com
objectClass: top
objectClass: groupOfNames
objectClass: posixGroup
cn: admin-group
displayName: admin-group
description:
gidNumber: 12345
member: uid=admin,ou=Users,dc=example,dc=com
memberUid: admin
googleAdminCreated: FALSE
# example-user, Users, example.com
dn: uid=example-user,ou=Users,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
uid: example-user
googleUid: example-user
posixUid: example-user
cn: example-user
cn: FirstName LastName
sn: FirstName
displayName: FirstName LastName
givenName: FirstName
mail: example-user@example.com
uidNumber: 12345
gidNumber: 12345
homeDirectory: /home/example-user
loginShell: /bin/bash
gecos:
इस तरह की गड़बड़ियां दिख सकती हैं
- OpenLDAP क्लाइंट और/या लाइब्रेरी, SNI की सुविधा के साथ कंपाइल नहीं की गई हैं
LDAP क्लाइंट (OpenLDAP के मामले में) के लिए, SNI (सर्वर नेम इंडिकेशन) की सुविधा उपलब्ध होना ज़रूरी है. अगर SNI की सुविधा उपलब्ध नहीं है, तो आपको इस तरह की गड़बड़ी दिख सकती है:SASL/EXTERNAL authentication startedldap_sasl_interactive_bind_s: Unknown authentication method (-6)additional info: SASL(-4): no mechanism available:
सुझाव:- अगर MacOS का इस्तेमाल किया जा रहा है, तो SASL डिफ़ॉल्ट रूप से चालू होता है. इसे "-x" विकल्प की मदद से बायपास किया जा सकता है.
- ldapsearch में
-d5विकल्प जोड़ें और आउटपुट में यह लाइन देखें:TLS certificate verification: depth: 0, err: 18, subject: /OU=No SNI provided; please fix your client.
-
ldapsearch, स्टेटस 0 (सफल) दिखाता है, लेकिन कोई उपयोगकर्ता आउटपुट नहीं होता
क्लाइंट सर्टिफ़िकेट के साथ, ldapsearch विकल्प-x(SASL पुष्टि का इस्तेमाल करें) की जानकारी देने पर, पुष्टि तो हो जाएगी, लेकिन डोमेन में मौजूद उपयोगकर्ताओं की सूची नहीं दिखेगी.
सुझाव:-xविकल्प हटाएं और फिर से कोशिश करें.
ADSI Edit (Windows)
- क्लाइंट सर्टिफ़िकेट इंस्टॉल करने के लिए, ldp.exe (Windows) में दिए गए पहले से 11वें चरण तक का तरीका अपनाएं.
- कार्रवाई > इससे कनेक्ट करें… पर जाएं
- कनेक्शन की ये सेटिंग डालें:
नाम: अपने कनेक्शन के लिए कोई नाम डालें. जैसे, Google LDAP.
कनेक्शन पॉइंट: "कोई डिस्टिंग्विश्ड नेम या नेमिंग कॉन्टेक्स्ट चुनें या टाइप करें"
अपना डोमेन नेम, डीएन फ़ॉर्मैट में डालें. उदाहरण के लिए, example.com के लिए dc=example,dc=com.
कंप्यूटर: "कोई डोमेन या सर्वर चुनें या टाइप करें"
ldap.google.com
एसएसएल पर आधारित एन्क्रिप्ट की सुविधा का इस्तेमाल करें: चुना गया - अडवांस... पर क्लिक करें और यह जानकारी डालें:
क्रेडेंशियल की जानकारी दें: चुना गया
उपयोगकर्ता नाम: Admin console से मिला ऐक्सेस क्रेडेंशियल का उपयोगकर्ता नाम
पासवर्ड: Admin console से मिला ऐक्सेस क्रेडेंशियल का पासवर्ड
पोर्ट नंबर: 636
प्रोटोकॉल: LDAP
सिंपल बाइंड पुष्टि: चुना गया - ठीक है पर क्लिक करें. इसके बाद, ठीक है पर दोबारा क्लिक करें.
- कनेक्टिविटी सही होने पर, बेस डीएन में डायरेक्ट्री का कॉन्टेंट, दाएं पैनल में दिखता है.
ldp.exe (Windows)
- OpenSSL इंस्टॉल करें.
- सर्टिफ़िकेट और कुंजी वाली फ़ाइलों को पीकेसीएस12 फ़ॉर्मैट वाली एक फ़ाइल में बदलें. कमांड प्रॉम्प्ट पर, यह डालें:
openssl pkcs12 -inkey ldap-client.key -in ldap-client.crt -export -out ldap-client.p12
आउटपुट फ़ाइल को एन्क्रिप्ट करने के लिए, कोई पासवर्ड डालें. - कंट्रोल पैनल पर जाएं.
- सर्च बॉक्स में, "सर्टिफ़िकेट" खोजें और उपयोगकर्ता सर्टिफ़िकेट मैनेज करें पर क्लिक करें.
- कार्रवाई > सभी टास्क > इंपोर्ट करें… पर जाएं
- **मौजूदा उपयोगकर्ता** को चुनें और **आगे बढ़ें** पर क्लिक करें.
- ब्राउज़ करें… पर क्लिक करें
- डायलॉग बॉक्स के सबसे नीचे दाएं कोने में मौजूद फ़ाइल टाइप ड्रॉपडाउन में, पर्सनल इन्फ़ॉर्मेशन एक्सचेंज (*.pfx;*.p12) को चुनें.
- दूसरे चरण में बनाई गई ldap-client.p12 फ़ाइल को चुनें. इसके बाद, खोलें पर क्लिक करें और फिर आगे बढ़ें पर क्लिक करें.
- दूसरे चरण में डाला गया पासवर्ड डालें और आगे बढ़ें पर क्लिक करें.
- निजी सर्टिफ़िकेट स्टोर को चुनें. इसके बाद, आगे बढ़ें पर क्लिक करें और फिर पूरा करें पर क्लिक करें.
- Ldp.exe चलाएं.
- कनेक्शन > कनेक्ट करें... पर जाएं
- कनेक्शन की यह जानकारी डालें:
सर्वर: ldap.google.com
पोर्ट: 636
कनेक्शनलेस: चुना नहीं गया
एसएसएल: चुना गया - ठीक है पर क्लिक करें.
- देखें > ट्री पर जाएं.
- बेस डीएन डालें. यह आपका डोमेन नेम, डीएन फ़ॉर्मैट में है. उदाहरण के लिए, example.com के लिए dc=example,dc=com.
- ठीक है पर क्लिक करें.
- कनेक्टिविटी सही होने पर, बेस डीएन में डायरेक्ट्री का कॉन्टेंट, दाएं पैनल में दिखता है.
ज़रूरत पड़ने पर, कनेक्टिविटी की सामान्य जांच करना
अगर आपको कनेक्टिविटी की पुष्टि करना और LDAP क्वेरी चलाना में सही नतीजा नहीं मिलता है, तो कनेक्टिविटी की जांच के लिए, इस सेक्शन में दिए गए निर्देशों का पालन करें. अगर ldapsearch से, उम्मीद के मुताबिक उपयोगकर्ता की जानकारी नहीं मिलती है और यह साफ़ तौर पर नहीं पता चलता कि टीएलएस सेशन सही तरीके से काम कर रहा है, तो OpenSSL क्लाइंट का इस्तेमाल करके पुष्टि करें कि OpenLDAP जिन नेटवर्क लेयर पर निर्भर करता है वे सही तरीके से काम कर रही हैं.
कनेक्टिविटी की सामान्य जांच करने के लिए:
अपने ऑपरेटिंग सिस्टम के लिए, openssl क्लाइंट यूटिलिटी इंस्टॉल करें.
ज़्यादातर GNU/Linux डिस्ट्रिब्यूशन में, पैकेज का नाम "openssl" होता है. अन्य ऑपरेटिंग सिस्टम के बारे में जानकारी देखें.
openssl क्लाइंट का इस्तेमाल करके, सुरक्षित LDAP सेवा से मैन्युअल तरीके से कनेक्ट करें:
openssl s_client -connect ldap.google.com:636पुष्टि करें कि एसएसएल नेगोशिएशन सही तरीके से हुआ है. इसके लिए, openssl s_client के आउटपुट के आखिर में यह लाइन देखें:
Verify return code: 0 (ok)
इस तरह की गड़बड़ियां दिख सकती हैं
OpenSSL क्लाइंट/लाइब्रेरी, SNI (सर्वर नेम इंडिकेशन) की सुविधा के साथ काम नहीं करती
कनेक्टिविटी की जांच के दौरान, यह आउटपुट मिल सकता है:
Verify return code: 18 (self signed certificate)
सुरक्षित LDAP सेवा के लिए, ऐसे टीएलएस क्लाइंट की ज़रूरत होती है जो SNI (सर्वर नेम इंडिकेशन) का इस्तेमाल करके, टीएलएस सेशन शुरू कर सके. अगर टीएलएस क्लाइंट, SNI की सुविधा के साथ काम नहीं करता है, तो टीएलएस सर्वर (ldap.google.com), सेल्फ़-साइन किया गया सर्टिफ़िकेट दिखाता है. यह सर्टिफ़िकेट, सीए की पुष्टि करने वाली जांचों में पास नहीं होगा. इससे यह पता चलता है कि SNI की ज़रूरत है.
इस व्यवहार की पुष्टि करने के लिए, OpenSSL क्लाइंट के आउटपुट में, आउटपुट की शुरुआत के आस-पास यह लाइन देखें:
depth=0 OU = "No SNI provided; please fix your client.", CN = invalid2.invalid
इस गड़बड़ी की वजहों में, OpenSSL का ऐसा वर्शन शामिल हो सकता है जो SNI की सुविधा के साथ काम नहीं करता. इसके अलावा, ऐसा कोई ऐप्लिकेशन भी हो सकता है जो OpenSSL लाइब्रेरी का इस्तेमाल करता है और जिसमें SNI की सुविधा साफ़ तौर पर बंद की गई हो.
कनेक्शन अस्वीकार किया गया
अगर यह आउटपुट मिलता है, तो टीएलएस नेगोशिएशन शुरू होने से पहले ही, टीसीपी कनेक्शन को अस्वीकार किया जा रहा है. यहां {timestamp} माइक्रोसेकंड में UNIX टाइमस्टैंप है:
{timestamp}:error:0200206F:system library:connect:Connection refused:crypto/bio/b_sock2.c:110:
{timestamp}:error:2008A067:BIO routines:BIO_connect:connect error:crypto/bio/b_sock2.c:111:connect:errno=111
ऐसा इन वजहों से हो सकता है:
- लोकल मशीन पर, ऐप्लिकेशन-लेवल या सिस्टम-लेवल फ़ायरवॉल
- एक ही फ़िज़िकल नेटवर्क या अपस्ट्रीम नेटवर्क पर मौजूद फ़ायरवॉल
यह पता लगाने के लिए कि कौन सा होस्ट कनेक्शन को अस्वीकार कर रहा है, tcptraceroute का इस्तेमाल करें. उदाहरण के लिए, tcptraceroute ldap.google.com 636.