നിരവധി അഭ്യർത്ഥനകൾ കമ്പനിയുടെ പ്രോക്സി വഴി Kerberos വിജയകരമായി ഉപയോഗിക്കുന്നു. ഒരു അഭ്യർത്ഥന പാസ്‌വേഡ് പ്രോംപ്റ്റ് ഉണ്ടാക്കുന്നു. keytab മാറ്റുന്നതിന് മുമ്പ് ആ പ്രത്യേക അഭ്യർത്ഥന ഏത് പ്രാമാണീകരണ പോളിസിയാണ് തിരഞ്ഞെടുത്തതെന്ന് പരിശോധിക്കുക.

ഗേറ്റ്‌വേയ്ക്ക് പോളിസി വഴി മേഖലയും പിന്തുണയ്ക്കുന്ന സ്കീമുകളും തിരഞ്ഞെടുക്കാം. ഒരേ ബ്രൗസറിൽ നിന്ന് ഒരേ പ്രോക്സിയിലേക്ക് എത്തുന്ന രണ്ട് ഇടപാടുകൾക്ക് സമാനമായ പ്രാമാണീകരണ ആവശ്യകതകൾ ലഭിക്കണമെന്നില്ല.

ഈ സാങ്കൽപ്പിക ട്രെയ്‌സ് പരിഗണിക്കുക:

ഇടപാട്ആദ്യം പൊരുത്തപ്പെടുന്ന പോളിസിലഭ്യമായ പ്രാമാണീകരണം
പ്രധാന രേഖനിയന്ത്രിത ബ്രൗസിംഗ് നിയമംNegotiate
മറ്റൊരു ഹോസ്റ്റിൽ നിന്നുള്ള സ്ക്രിപ്റ്റ്മുൻ ലക്ഷ്യസ്ഥാന ഒഴിവ്Basic അല്ലെങ്കിൽ NTLM

ആദ്യത്തെ വിജയകരമായ കൈമാറ്റം തിരഞ്ഞെടുത്ത ഒരു പാത പ്രവർത്തിക്കുന്നുവെന്ന് കാണിക്കുന്നു. രണ്ടാമത്തെ ഇടപാട് ആ പാതയിലെത്തിയെന്ന് അത് കാണിക്കുന്നില്ല. ക്രെഡൻഷ്യൽ സാധുവായിരിക്കാം, പക്ഷേ അതിന്റെ പ്രാമാണീകരണ സംവിധാനം തിരഞ്ഞെടുക്കുന്ന നിയമം തെറ്റാണ്.

തിരഞ്ഞെടുത്ത നിയമവും അതിന്റെ ക്രമവും പരിശോധിക്കുക

വെല്ലുവിളിക്കപ്പെട്ട അഭ്യർത്ഥനയുടെ ലക്ഷ്യസ്ഥാനവും സമയവും ഗേറ്റ്‌വേയുടെ പോളിസി ട്രെയ്‌സുമായി ബന്ധിപ്പിക്കുക. ആദ്യം ബാധകമാകുന്ന നിയമം സൃഷ്ടിക്കുന്ന മേഖല, സ്കീം തിരഞ്ഞെടുപ്പുകൾ, പ്രാമാണീകരണ മോഡ് എന്നിവ തിരിച്ചറിയുക. ആ മൂല്യങ്ങൾ അതേ ക്ലയന്റിൽ നിന്നുള്ള വിജയകരമായ അഭ്യർത്ഥനയുമായി താരതമ്യം ചെയ്യുക.

IP-യുമായി ബന്ധിപ്പിച്ച ഐഡന്റിറ്റിയെ അടിസ്ഥാനമാക്കിയ പോളിസിയും കണക്ഷനിൽ പ്രാമാണീകരണം ആവശ്യപ്പെടുന്ന പോളിസിയിൽ നിന്ന് വ്യത്യസ്തമായി പ്രവർത്തിക്കാം. പുതിയ ഹാൻഡ്‌ഷേക്ക് ഇല്ലാത്തത് അതേ മേഖല തിരഞ്ഞെടുത്തുവെന്ന് അർത്ഥമാക്കുന്നില്ല എന്ന് കരുതരുത്.

വിഭവം ഉദ്ദേശിക്കാത്ത ഒഴിവിൽ വീണാൽ, ആ നിയമമോ അതിന്റെ പരിധിയോ തിരുത്തി ഫലമായുണ്ടാകുന്ന ട്രെയ്‌സ് അവലോകനം ചെയ്യുക. അനുവദനീയമായ പ്രാമാണീകരണ രീതികൾ എല്ലായിടത്തും വിശാലമാക്കുന്നത് പൊരുത്തക്കേട് മറയ്ക്കാം, പക്ഷേ ബന്ധമില്ലാത്ത ട്രാഫിക്കിന്റെ പ്രവേശന സ്വഭാവം മാറ്റും.

ഉദ്ദേശിച്ച മേഖല തിരഞ്ഞെടുക്കപ്പെടുകയും പ്രതീക്ഷിച്ച കൈമാറ്റം പരാജയപ്പെടുകയും ചെയ്താൽ, അക്കൗണ്ട്, Kerberos തെളിവുകളിലേക്ക് തുടരുക. അപ്പോഴാണ് ടിക്കറ്റ്, സേവന നാമം, അല്ലെങ്കിൽ ബാക്കെൻഡ് ഡയഗ്നോസ്റ്റിക്സ് പ്രസക്തമാകുന്നത്.

അനുബന്ധ ലേഖനങ്ങൾ