अनेक विनंत्या कंपनीच्या प्रॉक्सीमधून Kerberos यशस्वीपणे वापरतात. एक विनंती मात्र पासवर्ड विचारते. keytab बदलण्यापूर्वी त्या विशिष्ट विनंतीने कोणते प्रमाणीकरण धोरण निवडले ते तपासा.

गेटवे धोरणाद्वारे क्षेत्र आणि समर्थित स्कीम निवडू शकतो. एकाच ब्राउझरमधून एकाच प्रॉक्सीवर पोहोचणाऱ्या दोन व्यवहारांना समान प्रमाणीकरण आवश्यकता मिळणे बंधनकारक नाही.

हा काल्पनिक माग पाहा:

व्यवहारपहिले जुळणारे धोरणउपलब्ध प्रमाणीकरण
मुख्य दस्तऐवजव्यवस्थापित ब्राउझिंग नियमNegotiate
दुसऱ्या होस्टकडून स्क्रिप्टपूर्वीचा गंतव्य अपवादBasic किंवा NTLM

पहिली यशस्वी देवाणघेवाण दाखवते की एक निवडलेला मार्ग काम करतो. ती दाखवत नाही की दुसरा व्यवहार त्या मार्गापर्यंत पोहोचला. क्रेडेन्शियल वैध असू शकते, पण त्याची प्रमाणीकरण पद्धत निवडणारा नियम चुकीचा असू शकतो.

निवडलेला नियम आणि त्याचा क्रम तपासा

आव्हान मिळालेल्या विनंतीचे गंतव्य आणि वेळ गेटवेच्या धोरण मागाशी जोडा. पहिल्या लागू होणाऱ्या नियमाने तयार होणारे क्षेत्र, स्कीम निवडी आणि प्रमाणीकरण मोड ओळखा. ती मूल्ये त्याच क्लायंटच्या यशस्वी विनंतीशी तुलना करा.

IP शी जोडलेल्या ओळखीवर आधारित धोरण देखील कनेक्शनवर प्रमाणीकरण मागणाऱ्या धोरणापेक्षा वेगळे वागू शकते. नवीन हँडशेक नसणे म्हणजे तेच क्षेत्र निवडले असे गृहीत धरू नका.

संसाधन अनपेक्षित अपवादात पडले असल्यास तो नियम किंवा त्याची व्याप्ती दुरुस्त करा आणि परिणामी माग तपासा. सर्वत्र अनुमत प्रमाणीकरण पद्धती रुंदावल्यास विसंगती लपू शकते, पण असंबंधित रहदारीचे प्रवेश वर्तन बदलते.

इच्छित क्षेत्र निवडले गेले आणि अपेक्षित देवाणघेवाण अयशस्वी झाल्यास खाते आणि Kerberos पुराव्याकडे जा. तेव्हाच तिकीट, सेवा नाव किंवा बॅकएंड निदान संबंधित ठरते.

संबंधित लेख