VPN प्रमाणीकरण रियल्म: कोणते खाते नामस्थान जिंकते?

प्रत्येक VPN लॉगिन काही खाते नामस्थानात पोहोचते, आणि रियल्म हा ते कोणते हे ठरवणारा निवडक आहे। तो देश, सर्व्हरचे स्थान किंवा विश्वासाची पातळी याबद्दल काहीही सांगत नाही। दोन एकसारखी वापरकर्तानावे वेगवेगळ्या रियल्ममध्ये राहू शकतात, म्हणून बरोबर पासवर्ड कधीकधी चुकीच्या खात्याचे प्रमाणीकरण करतो। ही रनबुक प्रथम ओळखीचा आकार ठरवते, नंतर विनंती प्रत्यक्षात उत्तर देणाऱ्या प्रणालीपर्यंत पोहोचवते।

रियल्म काय निवडतो

गेटवे वापरकर्तानाव घेतो आणि ते कुठे तपासायचे हे ठरवले पाहिजे। रियल्म म्हणजे त्या नावाचा भाग, किंवा त्याच्या बाजूचे गुणवैशिष्ट्य, जे डेटाबेस निवडते: एक डिरेक्टरी, RADIUS पूल, स्थानिक खाते फाइल। Microsoft चे NPS याला रियल्म नाव म्हणते आणि त्याद्वारे कनेक्शन विनंत्या मार्गदर्शित करते, तर EAP नेटवर्क प्रवेश ओळखपत्र RFC 7542 मध्ये at चिन्हानंतरचा प्रत्यय म्हणून तीच कल्पना बाळगते। दोन्ही निवडक आहेत, आणि यापैकी कोणतेही क्रेडेन्शियल चांगले आहे की नाही हे ठरवत नाही।

हा विभाजन दोन अगदी वेगळ्या अयशस्वीता निर्माण करतो। बरोबर मार्गदर्शन करणारा रियल्म चुकीच्या पासवर्डसह एक नकार देतो, तर चुकीच्या डेटाबेसकडे वळवणारा रियल्म बरोबर पासवर्ड नाकारू शकतो किंवा दुसऱ्याचा स्वीकारू शकतो। कोणतीही त्रुटी रियल्मचा उल्लेख करत नाही, म्हणून पहिले निदान नेहमी सारखेच असते: कोणत्या प्रणालीने उत्तर दिले हे शोधणे।

रियल्मचा आकार तैनातीचा भाग आहे। काही सेवांना पात्रता नसलेले नाव आणि गुणवैशिष्ट्य हवे असते, इतरांना user@domain हवे असते, आणि काही ठराविक बॅकस्लॅश असलेला आकार अपेक्षितात ज्याचा उल्लेख बहुतेक मार्गदर्शक करत नाहीत।

बॅकएंड ज्या आकाराची अपेक्षा करतो तो वापरा

ट्युटोरियलमधील प्रत्यय वापरून पाहण्यापूर्वी ऑपरेटरला कोणता आकार टाइप करायचा ते विचारा। साध्या नावाची अपेक्षा करणाऱ्या बॅकएंडपर्यंत पोहोचणारे डोमेन-पात्र नाव सहसा पासवर्ड तपासणीत नाही तर शोधात अयशस्वी होते। दोन डिरेक्टरींमध्ये एकच लहान नाव ही अशी परिस्थिती आहे जिथे गहाळ रियल्म सर्वाधिक नुकसान करतो।

व्यवस्थापन खात्याला पुरावा मानू नका। सेवा व्यवस्थापित करणारा वेब कन्सोल स्थानिक फाइलाशी प्रमाणीकरण करू शकतो, तर टनेल पूर्णपणे वेगळी डिरेक्टरी तपासते। खऱ्या वापरकर्त्याने वापरतील अशा क्रेडेन्शियलसह, खरा वापरकर्ता वापरेल अशा इंटरफेसवर चाचणी करा। यशस्वी कन्सोल लॉगिन गेटवे VPN प्रमाणीकरणावर लागू करत असलेल्या रियल्मबद्दल काहीही सांगत नाही।

ब्राउझर आणि मेल क्लायंट कधीकधी मागील ओळख साठवतात आणि ती शांतपणे पुन्हा पाठवतात। नोंदवलेले वापरकर्तानाव टाइप केलेल्यापेक्षा वेगळे असल्यास प्रथम तेच कॅशे पाहा।

प्रॉक्सीद्वारे विनंतीचा मागोवा घ्या

FreeRADIUS फ्रंट एंडवर रियल्म प्रॉक्सी कॉन्फिगरेशनमध्ये घोषित केले जातात, आणि घोषित प्रत्यय कोणता होम सर्व्हर विनंती घेईल हे ठरवतो। काहीही बदलण्यापूर्वी ती फाइल वाचा, कारण कोणत्याही रियल्मशी जुळत नसलेली विनंती डीफॉल्टनुसार स्थानिक पातळीवर हाताळली जाते।

grep -n -A4 '^realm' /etc/freeradius/3.0/proxy.conf
radtest '[email protected]' 'wrong-password' 10.20.30.10 0 testing123
journalctl -u freeradius --since '-10 min' | grep -iE 'realm|stripped'

grep कोणते प्रत्यय आहेत आणि प्रत्येक कोणत्या पूलला लक्ष्य करतो हे दाखवते। radtest कॉल रियल्म असलेले नाव आणि मुद्दाम चुकीचा पासवर्ड पाठवतो, त्यामुळे नकार हे मार्गदर्शन आणि क्रेडेन्शियल तपासणी दोन्ही झाल्याचे सिद्ध करतो। त्या प्रयत्नाभोवतीच्या जर्नल ओळी प्रॉक्सीपूर्वी नाव काढले गेले का आणि कोणत्या होम सर्व्हरने ते घेतले हे दाखवतात। लॉगमध्ये रियल्मचा जुळणी अजिबात दिसत नसेल, तर विनंती स्थानिक सर्व्हर कधीच सोडली नाही आणि समस्या पासवर्ड नाही तर प्रत्यय आहे।

एका वेळी एकच गोष्ट बदला आणि प्रयत्न पुन्हा करा, कारण इनपुट धावांमध्ये वेगळे असेल तेव्हाच लॉग मार्गदर्शन आणि क्रेडेन्शियल अयशस्वीता वेगळे करतो। सामायिक रहस्य shell इतिहासाबाहेर ठेवा, जिथे साधन फाइल किंवा प्रॉम्प्टमधून वाचनाला पाठिंबा देते।

प्रयत्न गळती न करता नोंदवा

अयशस्वीता प्रशासकाला कृती करता येईल अशा स्वरूपात लिहा: इंटरफेस, ओळखीचा आकार, रियल्म होता का, आणि तंतोतंत गैर-गुप्त त्रुटी। सक्रिय वापरकर्तानाव सार्वजनिक अहवालांबाहेर आणि रियल्म आत ठेवा। प्रत्येक ओळख एकाच प्लेसहोल्डरमध्ये रूपांतरित करणे हे तुम्ही शोधत असलेली विसंगतीच लपवते। गेटवे, प्रॉक्सी आणि डिरेक्टरी स्वतंत्र लॉग ठेवतात, म्हणून वेळेची नोंदही महत्त्वाची आहे।

नंतर वापरकर्त्यांसाठी जिंकलेला आकार दस्तऐवज करा, कारण पुढची व्यक्ती तो चुकीचा टाइप करेल आणि तेच तिकीट उघडेल। पासवर्ड रीसेट चुकीच्या नामस्थानात पोहोचत राहणाऱ्या विनंतीला दुरुस्त करत नाही। रियल्म हा मार्गदर्शनाचा निर्णय आहे, आणि मार्गदर्शनाचे निर्णय त्यांना योग्य नाव देऊन दुरुस्त होतात।