किन एउटा प्रोक्सी अनुरोधले पासवर्ड माग्छ जबकि अरूका लागि Kerberos काम गर्छ

धेरै अनुरोधहरू कम्पनीको प्रोक्सीमार्फत Kerberos सफलतापूर्वक प्रयोग गर्छन्। एउटा अनुरोधले पासवर्ड सोध्ने सन्देश ल्याउँछ। keytab बदल्नुअघि त्यो विशेष अनुरोधले कुन प्रमाणीकरण नीति छान्यो जाँच्नुहोस्।

गेटवेले नीतिमार्फत क्षेत्र र समर्थित स्किम छान्न सक्छ। एउटै ब्राउजरबाट एउटै प्रोक्सीमा पुग्ने दुई कारोबारले एउटै प्रमाणीकरण आवश्यकता पाउनुपर्ने छैन।

यो काल्पनिक ट्रेस विचार गर्नुहोस्:

पहिलो सफल आदानप्रदानले एउटा छानिएको बाटो काम गर्छ भन्ने देखाउँछ। यसले दोस्रो कारोबार त्यो बाटोमा पुग्यो भनी देखाउँदैन। प्रमाणपत्र वैध हुन सक्छ तर त्यसको प्रमाणीकरण संयन्त्र छान्ने नियम गलत हुन सक्छ।

छानिएको नियम र त्यसको क्रम जाँच्नुहोस्

चुनौती पाएको अनुरोधको गन्तव्य र समयलाई गेटवेको नीति ट्रेससँग जोड्नुहोस्। पहिलो लागू हुने नियमले बनाउने क्षेत्र, स्किम छनोट र प्रमाणीकरण मोड पहिचान गर्नुहोस्। ती मानहरूलाई एउटै क्लाइन्टको सफल अनुरोधसँग तुलना गर्नुहोस्।

IP सँग जोडिएको पहिचानमा आधारित नीति पनि जडानमा प्रमाणीकरण माग्ने नीतिभन्दा फरक व्यवहार गर्न सक्छ। नयाँ ह्यान्डशेक नहुनु भनेको एउटै क्षेत्र छानियो भन्ने नठान्नुहोस्।

स्रोत अनपेक्षित अपवादमा पर्यो भने त्यो नियम वा त्यसको दायरा सुधार्नुहोस् र नतिजा ट्रेस समीक्षा गर्नुहोस्। सबै ठाउँमा अनुमत प्रमाणीकरण विधि फराकिलो बनाउँदा असमझदारी लुकाउन सकिन्छ, तर असम्बन्धित ट्राफिकको पहुँच व्यवहार बदलिन्छ।

इच्छित क्षेत्र छानियो र अपेक्षित आदानप्रदान असफल भयो भने खाता र Kerberos प्रमाणतर्फ जानुहोस्। त्यसबेला टिकट, सेवा नाम वा ब्याकएन्ड निदान सान्दर्भिक हुन्छ।