Я уже несколько дней пытаюсь запустить squid с помощью kerberos, но мне очень больно. Я дважды проверил все файлы конфигурации, все в порядке.
Вот мой вопрос, сегодня я захватил пакеты с помощью wirehark и увидел, что мой клиентский браузер отправляет и получает HTTP-пакеты. прежде чем получить билеты от KDC.
Я могу подключиться к Интернету через squid, но он использует NTLM вместо Kerberos, я думаю, что авторизация откатывается на NTLM, потому что он пытается Kerberos Auth перед он получает билет от KDC. (билеты можно получить позже)
Что может привести к тому, что KDC не сможет отправлять билеты во время периода аутентификации?
Если нужно; вы можете получить полный журнал wirehark отсюда.
Обновить: обновите логи wirehark, пожалуйста Проверь это вместо первого
update2: файл конфигурации squid: http://pastebin.com/k1pafHfH
Большое спасибо.
Я не вижу проблем со стороны прокси для аутентификации в отправленной вами трассировке. Единственный трафик Kerberos, который я вижу, - это TGT для Realm: LABRISTEST.COM, выданный для test1.
Если бы прокси-сервер принудительно выполнял аутентификацию, я бы ожидал, что прокси будет возвращать трассировку с «StatusCode: 407, требуется аутентификация прокси». Видеть http://technet.microsoft.com/en-us/library/bb984870.aspx например вероятного следа, когда прокси требует авторизации.
Я не вижу никаких аутентификаций на основе NTLM или Kerberos для прокси.
Клиент будет запрашивать билеты только в случае необходимости (например, прокси говорит, что требуется авторизация). До тех пор он не знает, какие билеты запрашивать, и пытается анонимно. Таким образом, вы должны увидеть запрос билета после анонимного доступа к прокси. И это тоже, только если на стороне клиента нет локально кешированного билета. Также возможно, что, несмотря на отсутствие локального кеширования билета, вы не видите никакого запроса из-за отрицательного кеширования (кэшируется тот факт, что предыдущий запрос билета не удался).
Также отмечу, что вы не используете IE (UserAgent: Mozilla / 5.0 (Windows NT 6.1; rv: 8.0) Gecko / 20100101 Firefox / 8.0) для тестирования этого. Я предлагаю вам использовать IE для тестирования, если вы не уверены, что firefox настроен для правильного ответа на запросы аутентификации.
Обновление (16 января): Перед сбором следов всегда следует очищать кеш DNS (ipconfig / flushdns) и кеш Kerberos. Это позволяет увидеть DNS-трафик, связанный с обнаружением KDC, и успешные / неудачные запросы билетов Kerberos.
Также важно знать, как вы настраиваете параметры прокси-сервера в браузере, поскольку это влияет на запрашиваемые тикеты. Порт прокси-сервера выглядит как 3128, а имя - labris-1. Таким образом, вам, вероятно, потребуется зарегистрировать http / labris-1: 3128 и http / labris-1.labristest.com: 3128 SPN на объекте AD, используемом прокси-службой. Также нужно добавить ключ reg из http://support.microsoft.com/default.aspx?scid=kb;EN-US;908209 для всех IE выше V6. Убедитесь, что keytab обновлен и доступен на сервере squid.