ولې یوه پراکسي غوښتنه پټنوم غواړي پداسې حال کې چې Kerberos د نورو لپاره کار کوي
هغه د پالیسۍ قاعده ومومئ چې یوې غوښتنې ته ناڅاپي پراکسي د تصدیق ساحه ورکوي، حتی کله چې نورې غوښتنې Kerberos په بریالیتوب سره کاروي.
څو غوښتنې د شرکت پراکسي له لارې Kerberos په بریالیتوب سره کاروي. یوه غوښتنه د پټنوم غوښتنه رامنځته کوي. د keytab د بدلولو دمخه وګورئ چې هغې ځانګړې غوښتنې کومه د تصدیق پالیسي غوره کړې ده.
دروازه کولای شي د پالیسۍ له لارې ساحه او ملاتړ شوي سکیمونه وټاکي. دوه معاملې چې له یوې براوزر څخه یوې پراکسي ته رسیږي اړتیا نلري چې ورته د تصدیق غوښتنې ترلاسه کړي.
دا فرضي تعقیب په پام کې ونیسئ:
| معامله | لومړنۍ سمون ورکوونکې پالیسي | شته تصدیق |
|---|---|---|
| اصلي سند | مدیریت شوې کتنې قاعده | Negotiate |
| له بل کوربه سکریپټ | پخوانی د منزل استثنا | Basic یا NTLM |
لومړنی بریالی تبادله ښیي چې یوه ټاکل شوې لاره کار کوي. دا نه ښیي چې دوهمه معامله هغې لارې ته رسیدلې. اعتبارنامه کیدای شي سمه وي، خو هغه قاعده چې د تصدیق میکانیزم ټاکي کیدای شي غلطه وي.
ټاکل شوې قاعده او د هغې ترتیب وګورئ
د ننګول شوې غوښتنې منزل او وخت د دروازې د پالیسۍ تعقیب سره ونښلوئ. هغه ساحه، د سکیم انتخابونه او د تصدیق حالت چې لومړنۍ تطبیقیدونکې قاعده یې جوړوي وپیژنئ. هغه ارزښتونه له هماغه کلینټ بریالۍ غوښتنې سره پرتله کړئ.
د IP سره تړلې هویت پر بنسټ پالیسي هم کیدای شي د هغې پالیسۍ څخه توپیر ولري چې په اړیکه کې تصدیق غواړي. دا مه فکر کوئ چې د نوي لاس ورکولو نه شتون مانا دا ده چې هماغه ساحه ټاکل شوې.
که سرچینه ناغوښتل شوې استثنا ته ولویده، هغه قاعده یا د هغې حد اصلاح کړئ او پایله تعقیب وګورئ. د اجازه ورکړل شوو د تصدیق میتودونو پراخول هرچیرې کیدای شي ناهمغږي پټه کړي، خو د بېلابېلو ترافیکو د لاسرسي چلند بدلوي.
که پام شوې ساحه وټاکل شي او تمه شوې تبادله پاتې راشي، د حساب او Kerberos شاهدانو ته لاړ شئ. هغه وخت ټیکټ، د خدمت نوم یا د بیکنډ تشخیص اړوند کیږي.