نام میزبان پراکسی بخشی از ورود Kerberos است
نام پراکسی سمت کلاینت را با principal سرویس HTTP و keytabی که پراکسی استفاده می‌کند هم‌تراز کنید.
احراز هویت خودکار دامنه در یک پراکسی HTTP می‌تواند از Negotiate و Kerberos استفاده کند. کلاینت به یک بلیت برای سرویس پراکسی نیاز دارد، نه فقط رمز عبور ذخیره‌شده یک وبگاه.
برای پراکسی‌ای که با نام proxy.example.net معرفی می‌شود، یک principal سرویس می‌تواند این شکل را داشته باشد:
HTTP/[email protected]نام میزبانی که کلاینت استفاده می‌کند، principal سرویس ثبت‌شده و keytab پراکسی باید با استقرار سازگار باشند. پیکربندی Kerberos در Squid، principal سرویس HTTP و نحوه استفاده کمک‌کننده از آن مواد کلیدی را مستند می‌کند.
استفاده از یک نشانی IP یا نام مستعار دیگر می‌تواند انتخاب عادی نام سرویس را تغییر دهد. پیش از تغییر رمزهای عبور کاربران، مشخص کنید کلاینت واقعاً از کدام نام پراکسی استفاده کرده و کدام سازوکار احراز هویت کامل شده یا شکست خورده است.
Negotiate یک سازوکار مذاکره است. Windows می‌تواند در شرایط قابل‌اعمال Kerberos را انتخاب کند یا به NTLM بازگردد؛ دیدن واژه Negotiate ثابت نمی‌کند که تبادل Kerberos موفق بوده است.
استفاده خودکار از اعتبارنامه‌ها را در چارچوب سیاست کلاینت و دامنه‌ای که برای این پراکسی در نظر گرفته شده نگه دارید. یک نشست عادی مرورگر و سرویسی که با حساب دیگری اجرا می‌شود می‌توانند اعتبارنامه‌ها و نتایج مجوزدهی متفاوتی به دست آورند.