Le nom d'hôte du proxy fait partie d'une connexion Kerberos
Alignez le nom du proxy côté client avec le principal de service HTTP et le keytab utilisés par le proxy.
L'authentification de domaine automatique auprès d'un proxy HTTP peut utiliser Negotiate et Kerberos. Le client a besoin d'un ticket pour le service du proxy, et pas seulement d'un mot de passe de site mémorisé.
Pour un proxy annoncé comme proxy.example.net, un principal de service peut avoir cette forme :
HTTP/[email protected]
Le nom d'hôte utilisé par le client, le principal de service enregistré et le keytab du proxy doivent correspondre au déploiement. La configuration Kerberos de Squid documente le principal de service HTTP et l'utilisation de ce matériel de clé par l'auxiliaire.
Utiliser une adresse IP ou un autre alias peut modifier la sélection habituelle du nom de service. Avant de changer les mots de passe des utilisateurs, établissez quel nom de proxy le client a réellement utilisé et quel mécanisme d'authentification a abouti ou échoué.
Negotiate est un mécanisme de négociation. Windows peut choisir Kerberos ou revenir à NTLM dans les conditions applicables ; voir le mot Negotiate ne prouve pas que l'échange Kerberos a réussi.
Maintenez l'utilisation automatique des informations d'identification dans la politique de client et de domaine prévue pour ce proxy. Une session de navigateur normale et un service exécuté sous un autre compte peuvent obtenir des informations d'identification et des résultats d'autorisation différents.