HTTP პროქსიზე ავტომატური დომენური ავთენტიფიკაცია შეიძლება იყენებდეს Negotiate-სა და Kerberos-ს. კლიენტს სჭირდება ბილეთი პროქსის სერვისისთვის და არა მხოლოდ დამახსოვრებული ვებსაიტის პაროლი.

proxy.example.net სახელით გამოცხადებული პროქსისთვის სერვისის principal-ს შეიძლება ჰქონდეს ეს ფორმა:

HTTP/[email protected]

კლიენტის მიერ გამოყენებული ჰოსტის სახელი, რეგისტრირებული სერვისის principal და პროქსის keytab უნდა შეესაბამებოდეს განლაგებას. Squid-ის Kerberos კონფიგურაცია აღწერს HTTP სერვისის principal-ს და დამხმარის მიერ ამ გასაღების მასალის გამოყენებას.

IP მისამართის ან სხვა ფსევდონიმის გამოყენებამ შეიძლება შეცვალოს სერვისის სახელის ჩვეულებრივი არჩევანი. მომხმარებლების პაროლების შეცვლამდე დაადგინეთ, რომელი პროქსის სახელი გამოიყენა კლიენტმა რეალურად და რომელი ავთენტიფიკაციის მექანიზმი დასრულდა ან ვერ მოხერხდა.

Negotiate მოლაპარაკების მექანიზმია. Windows-ს შეუძლია აირჩიოს Kerberos ან შესაბამის პირობებში გადავიდეს NTLM-ზე; სიტყვა Negotiate-ის დანახვა არ ამტკიცებს, რომ Kerberos გაცვლა წარმატებით დასრულდა.

შეინახეთ სერთიფიკატების ავტომატური გამოყენება ამ პროქსისთვის განკუთვნილი კლიენტისა და დომენის პოლიტიკის ფარგლებში. ჩვეულებრივმა ბრაუზერის სესიამ და სხვა ანგარიშით მომუშავე სერვისმა შეიძლება მიიღონ განსხვავებული სერთიფიკატები და ავტორიზაციის შედეგები.

დაკავშირებული სტატიები