Автоматичното удостоверяване в домейн през HTTP прокси може да използва Negotiate и Kerberos. Клиентът се нуждае от билет за услугата на прокси сървъра, а не само от запомнена парола за сайт.

За прокси сървър, обявен като proxy.example.net, service principal може да има следния вид:

HTTP/[email protected]

Името на хоста, което клиентът използва, регистрираният service principal и keytab файлът на прокси сървъра трябва да съответстват на внедряването. Конфигурацията на Kerberos в Squid документира HTTP service principal и използването на този ключов материал от помощния процес.

Използването на IP адрес или друг псевдоним може да промени обичайния избор на име на услуга. Преди да променяте пароли на потребители, установете кое име на прокси сървъра клиентът действително е използвал и кой механизъм за удостоверяване е успял или се е провалил.

Negotiate е механизъм за договаряне. Windows може да избере Kerberos или да премине към NTLM при приложими условия; самата дума Negotiate не доказва, че Kerberos обменът е успял.

Дръжте автоматичното използване на идентификационни данни в рамките на клиентската и домейн политиката, предназначена за това прокси. Обикновена сесия на браузър и услуга, работеща под друг акаунт, могат да получат различни идентификационни данни и резултати от оторизация.

Подобни статии