કંપનીના પ્રોક્સી દ્વારા ઘણી વિનંતીઓ Kerberos સફળતાપૂર્વક વાપરે છે. એક વિનંતી પાસવર્ડ પ્રોમ્પ્ટ ઉત્પન્ન કરે છે. keytab બદલતા પહેલાં, તે ચોક્કસ વિનંતીએ કઈ પ્રમાણીકરણ નીતિ પસંદ કરી તે તપાસો.

ગેટવે નીતિ દ્વારા ક્ષેત્ર અને સમર્થિત સ્કીમ પસંદ કરી શકે છે. એક જ બ્રાઉઝરથી એક જ પ્રોક્સી પર પહોંચતા બે વ્યવહારોને સમાન પ્રમાણીકરણ જરૂરિયાતો મળવી જરૂરી નથી.

આ કાલ્પનિક ટ્રેસ ધ્યાનમાં લો:

વ્યવહારપ્રથમ મેળ ખાતી નીતિઉપલબ્ધ પ્રમાણીકરણ
મુખ્ય દસ્તાવેજસંચાલિત બ્રાઉઝિંગ નિયમNegotiate
બીજા હોસ્ટથી સ્ક્રિપ્ટઅગાઉનું ગંતવ્ય અપવાદBasic અથવા NTLM

પ્રથમ સફળ વિનિમય દર્શાવે છે કે એક પસંદ કરેલો માર્ગ કામ કરે છે. તે દર્શાવતું નથી કે બીજો વ્યવહાર તે માર્ગે પહોંચ્યો. ઓળખપત્ર માન્ય હોઈ શકે છે જ્યારે તેની પ્રમાણીકરણ પદ્ધતિ પસંદ કરતો નિયમ ખોટો હોય.

પસંદ કરેલ નિયમ અને તેનો ક્રમ ચકાસો

પડકારાયેલ વિનંતીના ગંતવ્ય અને સમયને ગેટવેની નીતિ ટ્રેસ સાથે સાંકળો. પ્રથમ લાગુ પડતો નિયમ જે ક્ષેત્ર, સ્કીમ પસંદગીઓ અને પ્રમાણીકરણ મોડ બનાવે છે તે ઓળખો. તે મૂલ્યોને એ જ ક્લાયન્ટની સફળ વિનંતી સાથે સરખાવો.

IP સાથે જોડાયેલી ઓળખ પર આધારિત નીતિ પણ કનેક્શન પર પ્રમાણીકરણ માંગતી નીતિથી અલગ વર્તન કરી શકે છે. નવું હેન્ડશેક ન હોવાનો અર્થ એ ન માનો કે એ જ ક્ષેત્ર પસંદ થયું છે.

જો સંસાધન અનિચ્છિત અપવાદમાં પડ્યું હોય, તો તે નિયમ અથવા તેનો વ્યાપ સુધારો અને પરિણામી ટ્રેસની સમીક્ષા કરો. બધે માન્ય પ્રમાણીકરણ પદ્ધતિઓ પહોળી કરવાથી વિસંગતિ છુપાઈ શકે છે, પરંતુ અસંબંધિત ટ્રાફિકના પ્રવેશ વર્તનને બદલે છે.

જો ઇચ્છિત ક્ષેત્ર પસંદ થાય અને અપેક્ષિત વિનિમય નિષ્ફળ જાય, તો ખાતા અને Kerberos પુરાવા તરફ આગળ વધો. ત્યારે ટિકિટ, સેવા નામ અથવા બેકએન્ડ નિદાન સંબંધિત બને છે.

સંબંધિત લેખો