DOMAIN \ username और username@domain.local के बीच कोई अंतर?


46

मैं एक अस्पष्ट प्रमाणीकरण त्रुटि का निवारण करने की कोशिश कर रहा हूं और कुछ पृष्ठभूमि जानकारी की आवश्यकता है।

  • क्या विंडोज (और आउटलुक जैसे कार्यक्रम) प्रक्रिया DOMAIN\usernameऔर के बीच कोई अंतर है username@domain.local?

  • इन दो उपयोगकर्ता नाम प्रारूपों के लिए उचित शब्द क्या हैं?

  • संपादित करें : विशेष रूप से, क्या कोई अंतर है कि विंडोज दो उपयोगकर्ता नाम प्रारूपों को कैसे प्रमाणित करता है?


आपको मेरे पिछले प्रश्न में से एक में दिलचस्पी हो सकती है ।
Belmin फर्नांडीज

जवाबों:


38

मान लें कि आपके पास सक्रिय निर्देशिका वातावरण है:

मेरा मानना ​​है कि बैकस्लैश प्रारूप DOMAIN \ USERNAME एक उपयोगकर्ता ऑब्जेक्ट के लिए डोमेन DOMAIN खोजेगा जिसका SAM खाता नाम USERNAME है।

UPN प्रारूप उपयोगकर्ता नाम @ डोमेन उपयोगकर्ता ऑब्जेक्ट के लिए वन खोजेगा जिसका उपयोगकर्ता सिद्धांत नाम उपयोगकर्ता नाम @ डोमेन है।

अब, सामान्यतः USERNAME के ​​SAM खाते के नाम वाले उपयोगकर्ता खाते में USERNAME @ DOMAIN का UPN होता है, इसलिए या तो प्रारूप को एक ही खाते का पता लगाना चाहिए, बशर्ते कम से कम AD पूरी तरह कार्यात्मक हो। यदि प्रतिकृति समस्याएं हैं या आप एक वैश्विक कैटलॉग तक नहीं पहुंच सकते हैं, तो बैकस्लैश प्रारूप उन मामलों में काम कर सकता है जहां यूपीएन प्रारूप विफल हो जाएगा। ऐसी (असामान्य) स्थितियां भी हो सकती हैं, जिनके तहत रिवर्स लागू होता है - शायद यदि कोई डोमेन नियंत्रक लक्ष्य डोमेन के लिए नहीं पहुंच सकता है, उदाहरण के लिए।

हालाँकि: आप UPN के लिए एक उपयोगकर्ता खाते को स्पष्ट रूप से कॉन्फ़िगर कर सकते हैं जिसका उपयोगकर्ता नाम SAM खाते के नाम से अलग है और जिसका डोमेन घटक डोमेन के नाम से अलग है।

सक्रिय निर्देशिका उपयोगकर्ता और कंप्यूटर में खाता टैब "उपयोगकर्ता लॉगऑन नाम (पूर्व-विंडोज 2000)" शीर्षक के तहत शीर्षक "उपयोगकर्ता लॉगऑन नाम" और एसएएम खाता नाम के तहत यूपीएन दिखाता है। इसलिए यदि आप विशेष उपयोगकर्ताओं से परेशान हैं, तो मैं जाँच करूँगा कि इन दोनों मूल्यों में कोई विसंगतियाँ नहीं हैं।

नोट: यह संभव है कि यदि मैं ऊपर वर्णित खोज को खाता नहीं पाता तो अतिरिक्त खोज की जाती है। उदाहरण के लिए, शायद निर्दिष्ट उपयोगकर्ता नाम दूसरे प्रारूप में परिवर्तित हो गया है (स्पष्ट तरीके से) यह देखने के लिए कि क्या मेल खाता है। भरोसेमंद डोमेन में खाते खोजने के लिए भी कुछ प्रक्रिया होनी चाहिए जो जंगल में नहीं हैं। मुझे नहीं पता कि सटीक व्यवहार कहाँ / क्या है।

बस समस्या निवारण को और अधिक जटिल बनाने के लिए, विंडोज क्लाइंट सफल इंटरेक्टिव लॉगऑन के बारे में डिफ़ॉल्ट कैश जानकारी के आधार पर करेंगे, ताकि आप उसी क्लाइंट में लॉग इन करने में सक्षम हो सकें, भले ही आपके उपयोगकर्ता खाते की सक्रिय निर्देशिका में जानकारी अप्राप्य हो।


1
मुझे यह उत्तर मेरे से बेहतर लगता है। अच्छी तरह से किया।
रयान रीस

यदि आप AD को ldapsearch के साथ क्वेरी कर रहे हैं, तो आपको msDS-PrincipalName विशेषता में निम्न-स्तरीय लॉगिन नाम मिलेगा, जिसे आपको "परिचालन विशेषता" के बाद से स्पष्ट रूप से अनुरोध करने की आवश्यकता है।
एरिक

22

मैं इस पर सही हो सकता है, लेकिन वास्तव में बहुत अंतर नहीं है।

डोमेन \ उपयोगकर्ता "पुराना" लॉगऑन प्रारूप है, जिसे डाउन-लेवल लॉगऑन नाम कहा जाता हैSAMAccountName और पूर्व-Windows 2000 लॉगऑन नाम से भी जाना जाता है ।

User@Domain.com एक UPN - उपयोगकर्ता प्रधान नाम है । यह "पसंदीदा", नया लॉगऑन प्रारूप है। यह एक इंटरनेट-शैली लॉगिन नाम है, जिसे उपयोगकर्ता ईमेल नाम पर मैप करना चाहिए। ( MSDN पर रेफरी )

UPNs के साथ लॉग इन करने के कारण मुझे लगता है कि ज्यादातर कॉस्मेटिक हैं - वे काल्पनिक रूप से आपके उपयोगकर्ताओं को आपकी कंपनी में एक ही नाम देते हैं जिसके साथ उनके वर्कस्टेशन पर लॉग इन करें जो उनके कॉर्पोरेट ईमेल पते के रूप में भी कार्य कर सकता है।

संपादित करें: अधिक विस्तार - यूपीएन का एक और फायदा यह है कि आप अपने उपयोगकर्ताओं के लिए लॉगऑन के लिए एक से अधिक वैध यूपीएन सेटअप कर सकते हैं। फिर, बड़े पैमाने पर कॉस्मेटिक। लेकिन महत्वपूर्ण बात यह है कि सभी एप्लिकेशन यूपीएन के साथ संगत नहीं हैं, और यह वही हो सकता है जो आप अनुभव कर रहे हैं।

# 2 संपादित करें: मुझे हैरी जॉनसन के दो अलग-अलग खोज प्रारूपों के बारे में नीचे दिए गए उत्तर पसंद हैं। यह समझ में आता है, और सबसे महत्वपूर्ण बात यह है कि यह वास्तव में आपकी समस्या की व्याख्या कर सकता है। :)


3
RFC 822 में UPNs का कोई उल्लेख नहीं है, "ARPA इंटरनेट टेक्स्ट संदेशों के प्रारूप के लिए मानक"। यूपीएन एक सक्रिय निर्देशिका "आविष्कार" है जो संबद्ध कंप्यूटर प्रणालियों के एक डोमेन (या "क्षेत्र") पर एकल-साइन-ऑन सेवाएं (एसएसओ) प्रदान करने के लिए केर्बरोस और एलडीएपी जानकारी को एक साथ बांधता है।
एडेप्टर

आह, क्षमा करें - मुझे मेरी जानकारी msdn.microsoft.com/en-us/library/windows/desktop/… से मिल रही थी ... अगर मुझे सही पता चलता है तो मैं अपना उत्तर संपादित करूँगा।
रायन रीस

1
@adaptr RFC 822 को 10 साल पहले रोका गया था - देखें rfc 2822.
जिम बी

@ ध्यान दें, मुझे लगता है कि सक्रिय निर्देशिका को दो अलग-अलग प्रारूपों के लिए अलग-अलग तरीकों से खोजा जाता है - मेरा उत्तर देखें।
हैरी जॉन्सटन

@ JimB मुझे लगता है कि आप पाएंगे कि नहीं, RFC822 अप्रचलित नहीं है; RFC2822 और वर्तमान RFC 5322 दोनों इसका उल्लेख करते हैं, साथ ही साथ अन्य मेल- और सामग्री से संबंधित RFC (शुरुआत के लिए 5321) की भीड़ भी है।
एडेप्टर

1

स्लॉस्ड प्रारूप ( DOMAIN\username) वास्तव NetBIOSमें डोमेन के DNS नाम ( domain.mycompany.local) के बराबर है । नाम 15 वर्णों तक सीमित है और नहीं हो सकते डॉट्स, अंडरस्कोर आदि
NetBIOS

यह पृष्ठ अधिक विस्तार से बताता है:
* जेफ शर्ट्ज़, 2012-08-20, अंडरस्टैंडिंग एक्टिव डायरेक्ट्री नेमिंग फॉर्मेट्स ( यहां संग्रहीत )।

जैसा कि @ harry-johnston द्वारा ऊपर उल्लेख किया गया है, इसका वास्तव में सिर्फ पुराना NT4 और Windows 2000 संगत प्रारूप है, लेकिन ऐसा लगता है कि यह एक पसंदीदा प्रारूप के रूप में अटक गया है (इसके प्रकार कम है!)। आखिरकार, विरासत का समर्थन विंडोज से जा सकता है।

यूपीएन प्रारूप का उपयोग करने की आदत में उपयोगकर्ताओं को प्राप्त करना शायद एक अच्छा विचार है क्योंकि यह उन मुद्दों से भी बचता है जहां उन्हें अपने उपयोगकर्ता नाम के साथ पीसी में लॉग इन करने में समस्या हो रही है और यह महसूस नहीं होता है कि विंडोज लॉगिन बॉक्स स्थानीय में डिफ़ॉल्ट है पीसी डोमेन (जैसे। pc01\fred) या जब वे अलग-अलग दूरस्थ डेस्कटॉप होस्ट से जुड़ते हैं और डोमेन को शामिल करने के साथ-साथ उनके उपयोगकर्ता नाम को भी याद रखना पड़ता है क्योंकि दूरस्थ डेस्कटॉप क्लाइंट पहले से उपयोग किए गए डोमेन नाम को कैश कर सकता है। हर बार यूपीएन प्रारूप से चिपके रहना अंत में कम समर्थन कॉल के लिए ही बनाता है।


यह संभावना नहीं है कि "पुराना प्रारूप" चला जाएगा, क्योंकि यह अभी भी गैर-एडी वातावरण के लिए उपयोग में है। ( Host\usernameनिश्चित रूप से, एडी के बिना कोई डोमेन नहीं)
MSalters

-1

निश्चित रूप से उन दो के बीच एक अंतर है केवल 99% उपयोगकर्ताओं को इसके साथ कोई समस्या नहीं होगी। मैं अंतर को समझाने की कोशिश करूंगा और जब ऐसी समस्या उत्पन्न होगी।

यदि आप किसी फ़ाइलशेयर तक पहुँचने का प्रयास करते समय डोमेन \ उपयोगकर्ता नाम का उपयोग करते हैं तो DNS पहले डोमेन को हल करेगा और फिर उपयोगकर्ता नाम की जाँच करेगा। यदि आप उपयोगकर्ता नाम @ डोमेन का उपयोग करते हैं तो यह सीधे जाँच करेगा कि उपयोगकर्ता ACL (एक्सेस कंट्रोल लिस्ट) पर है और उसकी एक्सेस है या नहीं। तो इससे क्या फर्क पड़ता है कि आप सोच सकते हैं ... अच्छा, यह तस्वीर:

DC01 नाम के साथ 1 डोमेन कंट्रोलर और सभी क्लाइंट डीएनएस प्राप्त करते हैं और इस डोमेन में हैं। आप माइग्रेट करना चाहते हैं और किसी ने उसी नाम से एक और सर्वर जोड़ा है। बाद वाला सर्वर भी एक डीसी बन जाएगा, इसलिए स्थानीय एसएएम का उपयोग नहीं किया जाएगा और फाइल शेयर भी होगी।

जब उपयोगकर्ता सर्वर से जुड़ेंगे तो उन्हें क्रेडेंशियल के लिए संकेत दिया जाएगा। यदि आप डोमेन \ उपयोगकर्ता नाम का उपयोग करते हैं तो यह नए डोमेन का उपयोग करने के बजाय पहले वर्तमान डोमेन की जांच करेगा और हमने फ़ाइल साझा पर नए डोमेन से खातों का उपयोग किया। तो एक बार जब यह वर्तमान डीसी मिल गया है और यह नहीं पाया जा सकता है उपयोगकर्ता नाम की जाँच करता है। (भले ही उपयोगकर्ता नाम और पासवर्ड मिल जाए और ठीक वही हो जो काम नहीं करेगा क्योंकि यह उपयोगकर्ता नाम का उपयोग यह सत्यापित करने के लिए नहीं करेगा कि यह ACL में अनुमति है या नहीं, लेकिन यह SID का उपयोग करेगा। साइड को बनाया जाएगा। AD में उपयोगकर्ता निर्माण का समय और आपके पास ट्रिलियन में 1 का परिवर्तन है कि यह समान है, महान हुह :-P)।


-1। मैं वास्तव में यहाँ क्या कह रहा हूँ का अनुसरण नहीं कर सकता। जहां आप कहते हैं "जब उपयोगकर्ता सर्वर से जुड़ेंगे" तो आप किस सर्वर से मतलब रखते हैं, पुराने DC01, या नए DC01? पुराने DC01 का वैसे भी क्या हुआ, क्या इसे डोमेन से हटा दिया गया, नाम बदल दिया गया, या क्या? क्या पहले इसे ठीक से डिमोट किया गया था? "नए डोमेन" से आपका क्या मतलब है, क्योंकि आपने किसी भी बिंदु पर नए डोमेन के निर्माण का वर्णन नहीं किया है? यदि आप "डोमेन \ उपयोगकर्ता नाम" का उपयोग करते हैं, तो इसे हमेशा उस डोमेन को खोजना चाहिए जिसे आपने स्पष्ट रूप से निर्दिष्ट किया है, क्या आप एक ऐसे मामले का वर्णन कर रहे हैं जहां यह नहीं है?
हैरी जॉन्सटन

इसके अलावा, "यह ACL में अनुमति देने पर उपयोगकर्ता नाम सत्यापित करने के लिए उपयोग नहीं करेगा, लेकिन यह SID का उपयोग करेगा" अपेक्षित व्यवहार है - यह हमेशा करना चाहिए, चाहे आप डोमेन \ उपयोगकर्ता नाम या उपयोगकर्ता नाम @ डोमेन का उपयोग करें। क्या आप एक ऐसे मामले के बारे में बात कर रहे हैं जहाँ एक ही नाम के दो डोमेन हैं, या कुछ इसी तरह के पैथोलॉजिकल हैं?
हैरी जॉनसन

DNS पहले डोमेन को हल करेगा और फिर उपयोगकर्ता नाम की जाँच करेगा । DNS उपयोगकर्ता नाम की जाँच करेगा? क्या?
बह्रप
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.