यहाँ कैसे ValidateCredentials(string, string)
काम करता है। यदि यह विफल हो जाता है, तो यह SimpleBind
और SecureSocketLayer
के साथ फिर से प्रयास करता है।
समस्या यह है कि NT4 (AKA "विरासत", AKA "डाउन-लेवल नाम") प्रारूप (DOMAIN\UserName
, या अधिक सही, NetBiosName\SamAccountName
) नेगोशिएट के साथ काम नहीं करता है। लेकिन यह SimpleBind के साथ काम करता है।
तो 2-पैरामीटर ValidateCredentials()
विधि को कॉल करते समय शायद क्या हो रहा है, यह है कि यह पहली बार नेगोशिएट का उपयोग करने में विफल रहता है क्योंकि इसे NT4 प्रारूप पसंद नहीं है, और फिर सरल बाइंड का उपयोग करते समय फिर से विफल हो जाता है।
अपने स्वयं के परीक्षण के दौरान, मुझे पता चला है कि सरल बाइंड का उपयोग करने के बाद भी यह विफल होने का कारण यह है कि यह केवल सिंपलबिंड का उपयोग नहीं कर रहा है। यह SimpleBind
प्लस SecureSocketLayer
का उपयोग कर रहा है। इसका अर्थ यह है कि अगर यह सक्रिय निर्देशिका सर्वर एसएसएल (परीक्षण वातावरण के लिए एक सामान्य परिदृश्य) का उपयोग करने के लिए सही ढंग से सेट नहीं किया गया है तो यह अभी भी असफल हो जाएगा।
जैसा कि टिप्पणियों में से एक में उल्लेख किया गया था, आप कभी भी SimpleBind
का उपयोग नहीं करना चाहते हैं (SecureSocketLayer
के बिना), अन्यथा आपके पासवर्ड सादे पाठ में नेटवर्क पर भेजे जाते हैं।
जंगली में, मैंने देखा है कि कुछ सक्रिय निर्देशिका प्रणालियां सरल बाइंड्स के उपयोग की अनुमति नहीं देती हैं, इसलिए आपको इसे वार्तालाप के साथ काम करना होगा।
मैं इस समस्या से निपटने के 2 तरीके पाया है:
1) सब कुछ एक ही डोमेन पर हो रहा है, तो आप केवल उपयोगकर्ता नाम के साथ ValidateCredentials
कॉल करने के लिए (एसएएम खाता नाम), बाहर छोड़ने के लिए सक्षम होना चाहिए "DOMAIN \" भाग। फिर, यह नेगोशिएट के साथ पहली बार ठीक से काम करेगा।
2) यदि डोमेन भाग महत्वपूर्ण है क्योंकि इसमें कई डोमेन शामिल हो सकते हैं (यानी Domain1\UserA
और Domain2\UserA
अलग-अलग लोग हैं), तो यह थोड़ा और जटिल हो जाता है। इस मामले में मैंने जो किया वह एनटी 4 नाम (DOMAIN \ उपयोगकर्ता) को "उपयोगकर्ता प्रिंसिपल नेम" प्रारूप (उदाहरण के लिए [email protected]
) में अनुवाद कर रहा था। ऐसा करने के कुछ अलग तरीके हैं।संभवतः UserPrincipal.FindByIdentity()
के 3-पैरामीटर अधिभार का उपयोग करने के लिए सबसे आसान है, और उसके परिणामस्वरूप UserPrincipalName
संपत्ति का मान लें। मान वाले उपयोगकर्ता की userPrincipalName
संपत्ति के लिए DirectorySearcher
और LDAP://domain
पर एक और तरीका उपयोग करना होगा। नोट: यह समाधान केवल तभी काम करेगा जब सभी डोमेन एक ही जंगल में हों।
संपूर्ण विधि को शामिल करने के लिए प्रश्न संपादित किया गया। ContextOption सुझाव का प्रयास करेंगे। धन्यवाद। –
बी-वर्षा, ContextOption संदर्भ ने मुझे सही दिशा में इंगित किया। कॉन्टेक्स्टऑप्शन का उपयोग करके समाप्त हो गया। एडी और कॉन्टेक्स्टऑप्शन पर मेरी कॉल पर बातचीत करें। मान्य प्रमाण-पत्रों पर सरल बाइंड। सरल बाइंड मेरे लिए काम करेगा क्योंकि साइट एसएसएल सुरक्षित होगी। आपकी मदद के लिए धन्यवाद। –
दोनों प्रश्न और उत्तर को ऊपर उठाया क्योंकि इससे मुझे मेरी स्थिति में भी मदद मिली। मेरे मामले में, मेरी देव मशीन (जहां निर्दिष्ट संदर्भ के बिना लॉगिन काम करता है) नेटवर्क पर सुरक्षित क्षेत्र में है, लेकिन वेब सर्वर (जहां लॉगिन निर्दिष्ट संदर्भ के बिना काम नहीं करता है) DMZ में है। मैंने @ बिली लोगान के समान कॉन्फ़िगरेशन का उपयोग किया - मान्य कॉल पर एडी और सिंपलबिंड को कॉल पर बातचीत करें। – arootbeer