2011-02-19 12 views
5

मेरा आवेदन LDAP के माध्यम से अधिकृत उपयोगकर्ताओं को परिभाषित करता है (आमतौर पर सक्रिय निर्देशिका):LDAP उपयोगकर्ता प्रमाणीकरण

  1. ग्राहक एक LDAP सर्वर (TreeA) और एक समूह (GroupA) को परिभाषित करता है। ग्रुपए में कोई भी उपयोगकर्ता एप्लिकेशन का उपयोग कर सकता है।
  2. लॉगिन समय, यदि कोई उपयोगकर्ता अपने उपयोगकर्ता नाम और पासवर्ड भेजता है - अगर उनकी पहचान के साथ LDAP TreeA करने के लिए एक बाँध से काम करता है, और उनके उपयोगकर्ता खाते एक GroupA में है, वे

मैं जाने के लिए अच्छे हैं एक ऐसी स्थिति पर आते हैं जहां दो सक्रिय निर्देशिकाएं एक दूसरे पर भरोसा करती हैं, और ट्रीए में निर्दिष्ट समूह ए में ट्रीबी के उपयोगकर्ता शामिल होते हैं। तो चरण # 2 विफल रहता है क्योंकि मैं TreeA के खिलाफ UserB (TreeB से) प्रमाणीकृत करने का प्रयास कर रहा हूं।

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

क्या इससे संपर्क करने का कोई बेहतर तरीका है?
क्या ट्रीए को ऐसे बाध्य अनुरोधों को स्वचालित रूप से ट्रीबी को अग्रेषित किया जाना चाहिए क्योंकि ट्रस्ट रिलेशनशिप है ??

+0

पेड़ और पेड़बी के बीच यह किस तरह का विश्वास है? क्या वे एक ही जंगल में हैं? –

उत्तर

1

यह हो सकता है कि आपके पास एलडीएपी सर्वर (ट्रीए) पर केवल कॉन्फ़िगरेशन समस्या हो। आपने लिखा है कि ट्रीए और ट्रीबी के बीच विश्वास है, ताकि आप ट्रीए में ग्रुप ए के सदस्य के रूप में यूजरबी (ट्रीबी से) जोड़ सकें। यदि आप ऐसा कर सकते हैं, तो आपने ट्रीए और ट्रीबी के बीच सही दिशा में सफलतापूर्वक विश्वास स्थापित किया है। आपको समझना चाहिए, कि ट्रस्ट का मतलब केवल सक्रिय निर्देशिका बी केवल उपयोगकर्ता पासवर्ड को सत्यापित करता है, लेकिन डिफ़ॉल्ट रूप से UserB को सक्रिय निर्देशिका ए से किसी भी संसाधन तक पहुंच नहीं होगी। उपयोगकर्ता बी को सर्वर ए से एलडीएपी बांधने की अनुमति नहीं है। इस मामले में उपयोगकर्ता को सर्वर ए पर रिमोट लॉगिन अनुमति प्रदान करके हल किया जाएगा और ग्रुप ए में पढ़ने की पहुंच होगी और संभवतः ओयू को पढ़ने की अनुमति होगी जहां ग्रुप ए मौजूद है। आप अनुमति समस्याओं को स्थानीयकृत करने के लिए एडी पहुंच की निगरानी के लिए Insight for Active Directory आज़मा सकते हैं।

आपकी समस्या का अन्य संभावित कारण एपीआई का उपयोग हो सकता है जिसे आप एलडीएपी एक्सेस में उपयोग करते हैं। आप में सवाल है कि आपने एपीआई के बारे में कोई जानकारी नहीं लिखी है। क्या आप Win32 API का उपयोग ldap_bind_s या .NET में DirectoryEntry का उपयोग करते हैं? दोनों मामलों में यह महत्वपूर्ण हो सकता है कि आप बाध्यकारी के दौरान खाता नाम (उपयोगकर्ता बी के लिए) के साथ स्पष्ट रूप से डोमेन नाम का उपयोग करें या null दोनों उपयोगकर्ता नाम उपयोगकर्ता नाम के लिए नाम और पासवर्ड दोनों के लिए उपयोग करें।

ट्रीए से सभी खातों के लिए ट्रीए से निश्चित खाते का उपयोग (उपयोगकर्ताबी के बारे में परीक्षण के लिए भी) समस्या को हल कर सकता है, लेकिन यह संभवतः कुछ प्रकार का एप्लिकेशन उपयोग संभव हो सकता है।

किसी भी तरह से आपके प्रश्न में अधिक जानकारी समस्या को हल करने और समस्या को हल करने के तरीकों को सीमित कर सकती है।

+0

मैं ldap_bind ... कार्यों का उपयोग करता हूं। वर्तमान में उपयोगकर्ता लॉग इन करते समय अपना डोमेन नाम नहीं भेजते हैं - और अब जब आप इसका उल्लेख करते हैं, तो यह संभवतः समस्या है (कोशिश करेगा!)। – DougN

+0

@DougN: क्या आपकी समस्या को हल करने में आपकी कोई प्रगति है? यदि आपको आवश्यकता है और आपकी मदद के कोड में कोड के टुकड़े शामिल करना चाहिए। ऑपरेशन सिस्टम के बारे में अधिक जानकारी जो आप उपयोग करते हैं और पर्यावरण भी सहायक हो सकता है। – Oleg

0

शायद आपको एलडीएपी प्रतिकृति का उपयोग करना चाहिए जैसे कि ऑब्जेक्ट्स हमेशा दोनों सर्वरों में मौजूद होते हैं?

+0

यह अच्छा होगा, लेकिन वे मेरे सर्वर नहीं हैं इसलिए मेरे पास यह विकल्प नहीं है। – DougN

0

आवेदन TreeA की पहुंच है, तो मैं यह GroupA में देखते हैं और वहाँ UserB देख सकते हैं लगता है। लेकिन यह कैसे पता चलेगा कि इसे उपयोगकर्ता नाम और पासवर्ड प्रमाणीकृत करने के लिए ट्रीबी को अनुरोध भेजने की आवश्यकता है?

GroupA में member विशेषता प्रत्येक सदस्य का पूरा विशिष्ट नाम (dn) है, जो की तरह कुछ लग सकता है दे देंगे:

member: CN=User1,OU=People,DC=TreeA,DC=foobar,DC=com 
member: CN=User2,OU=People,DC=TreeB,DC=foobar,DC=com 

तो, जब 'User 2 के प्रयास को प्रमाणित करने के लिए, आप मेल खा सकते हैं सीएन और जानते हैं कि आपको 'ट्रीए' के ​​बजाय 'ट्रीबी' के खिलाफ प्रमाणीकरण करना चाहिए। (संभवतः आपके पास एडी सर्वर होस्टनाम में डीएन मैपिंग की किसी प्रकार की तालिका होगी।) या, यदि आप 'TreeA' से 'ऐसा कोई उपयोगकर्ता नहीं' प्राप्त करते हैं, तो आप इसे केवल बलपूर्वक बल दें और 'ट्रीबी' आज़माएं।

आपको दो पेड़ों में डुप्लिकेट उपयोगकर्ता नामों के मामले को संभालने का निर्णय लेने की आवश्यकता होगी - क्या कोई दूसरे पर प्राथमिकता लेता है?

एक अन्य दृष्टिकोण उपयोगकर्ताओं को यह निर्दिष्ट करने की आवश्यकता होगी कि वे किस पेड़ के खिलाफ प्रमाणीकरण कर रहे हैं, उदाहरण के लिए '[email protected]' जैसे लॉगिन नाम से लॉग इन करके।

0

मान लीजिए कि आप डोमेन एक और डोमेन बी कि एक दूसरे पर भरोसा किया है, और यदि आप किसी ऐसे डोमेन के सर्वर पर डोमेन ए के खिलाफ डोमेन बी से उपयोगकर्ता B प्रमाणीकरण करना चाहते हैं तो आप क्या करना है कर रहे हैं दो:

  1. Win32 एपीआई का उपयोग करके डोमेन ए पर उपयोगकर्ता बी का प्रतिरूपण करें।

  2. DirectoryEntry का उपयोग कर डोमेन ए के विरुद्ध उपयोगकर्ता बी प्रमाणीकृत करें, तो आप असाइन किए गए समूहों जैसे अन्य उपयोगकर्ता जानकारी के लिए डोमेन ए के एडी तक पहुंच सकते हैं।

मैंने इसे एक एएसपी.NET एप्लिकेशन में लागू किया है जो विंडोज प्रमाणीकरण का उपयोग करता है।

उम्मीद है कि यह मदद करता है,