LDAP में, वास्तव में एक बाँध DN क्या है?

19

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

ldapsearch -h 1.2.3.4 -D dc=example,dc=com [query]

-D dc=example,dc=comइस के भाग का उद्देश्य और कार्य क्या है ? हमें निर्देशिका पदानुक्रम में किसी विशेष स्थान से बाध्य होने की आवश्यकता क्यों है? क्या यह स्थापित करना है कि निर्देशिका के किस हिस्से पर मेरे प्रश्नों को लागू करना चाहिए? जैसे अगर डायरेक्टरी का रूट नोड है dc=com, और इसके दो बच्चे ( dc=fooऔर dc=bar) हैं, तो शायद मैं चाहता हूं कि मेरी क्वेरी dc=foo,dc=comसबट्री के खिलाफ हो न कि dc=bar,dc=comसबट्री के खिलाफ ?

ldap

— dirtside
स्रोत

18

एक बाँध DN एक ऐसी वस्तु है जिसे आप LDAP के अंदर बाँधते हैं जिससे आप जो भी करने की कोशिश कर रहे हैं उसे करने की अनुमति दे सकें। कुछ (कई?) LDAP उदाहरण अनाम बाइंड्स की अनुमति नहीं देते हैं, या कुछ कार्यों को अनाम बाइंड्स के साथ संचालित करने की अनुमति नहीं देते हैं, इसलिए आपको उस ऑपरेशन को करने के लिए एक पहचान प्राप्त करने के लिए एक bindDN निर्दिष्ट करना होगा।

एक समान गैर-तकनीकी तरीके से - और यह एक खिंचाव है - एक बैंक आपको किसी भी प्रकार की आईडी दिए बिना उनकी ब्याज दरों को देखने और चलने की अनुमति देगा, लेकिन खाता खोलने या पैसे निकालने के लिए, आपके पास है एक पहचान के बारे में वे जानते हैं - वह पहचान bindDN है।

— जॉन
स्रोत

क्या bindDN हमेशा डायरेक्टरी में नोड के अनुरूप है? या यह एक मनमाना स्ट्रिंग हो सकता है?

— dirtside

हाँ। यह एक नोड के अनुरूप होना चाहिए जिसमें पासवर्ड विशेषता को ले जाने की क्षमता हो या अन्यथा के खिलाफ प्रमाणित किया जा रहा हो।

— जॉन

तोमायो, टॉमहोटो। 🍅 उपयोगकर्ता नाम, डीएन को बांधें। :00🤷🏻 18

— emallove

31

आधार और bindDN के बीच भ्रमित न हों ।

BaseDN एक खोज के शुरुआती बिंदु है। जहां इसकी खोज शुरू होगी। सुंदर आत्म-व्याख्यात्मक।

BindDN डीएन मूल रूप से क्रेडेंशियल यदि आपके पास LDAP के खिलाफ प्रमाणित करने के लिए उपयोग कर रहे हैं। एक bindDN का उपयोग करते समय यह आमतौर पर इसके साथ जुड़े पासवर्ड के साथ आता है।

दूसरे शब्दों में जब आप एक bindDN निर्दिष्ट करते हैं तो आप LDAP ट्री के माध्यम से जाने के लिए उस ऑब्जेक्ट सुरक्षा पहुंच का उपयोग कर रहे हैं।

अब, स्ट्रिंग dc = उदाहरण, dc = com एक bindDN के लिए सबसे अच्छा उदाहरण नहीं है क्योंकि यह LDAP ट्री के लिए "डोमेन" है। dc का मतलब डोमेन कंपोनेंट है और हर LDAP ट्री इसकी जड़ को dc = string, dc = string के रूप में एक स्ट्रिंग के साथ परिभाषित करता है, ... लेकिन ये तार बाकी के पेड़ की तरह "पथ" नहीं हैं।

मान्य उदाहरण हैं:

डीसी = उदाहरण के लिए, डीसी = कॉम
डीसी = mydomain
डीसी = एवरी, डीसी = लंबे, डीसी = सूची, डीसी = की, डीसी = डोमेन

लेकिन, ये जड़ तत्व अविभाज्य हैं। वे ऐसे दिखते हैं जैसे वे कई तत्व हैं जो पेड़ के बाकी हिस्सों की तरह एक पथ का प्रतिनिधित्व करते हैं, लेकिन वे नहीं हैं । उदाहरण के लिए, अंतिम उदाहरण में dc = of, dc = डोमेन मौजूद नहीं है।

अपने C: नामकरण की कल्पना करें जैसे "D: \ my \ folder \" ड्राइव। वहाँ हर पथ कुछ ऐसा दिखेगा जैसे "D: \ my \ folder \ my \ real \ path" जो वास्तविक फ़ाइल पथ के रूप में भ्रामक होगा my \ real \ path सही होगा? ठीक है, कि एलडीएपी का आधार (रूट) उसी तरह दिखता है, जैसे डीसी = तत्वों के एक सेट के साथ।

प्रासंगिक लिंक: http://docs.oracle.com/cd/E19199-01/816-6400-10/lsearch.html

— मार्सेलो
स्रोत

7

यह एक अनावश्यक रूप से भ्रमित डिजाइन की तरह लगता है, लेकिन आपका स्पष्टीकरण समझ में आता है।

— dirtside

1

हाँ मै सह्मत हूँ। अपने रूट का नामकरण भी एक पथ की तरह दिखता है सबसे अच्छा विकल्प नहीं है, लेकिन मुझे लगता है कि इसके कारण होने चाहिए। अब आप जानते हैं कि सभी DN dc = घटकों की श्रृंखला के साथ क्यों समाप्त होते हैं। =)

— मार्सेलो