У нас есть филиал в Коста-Рике, где в то время мы реализовали прокси-сервер Squid с SSO с использованием AD, и он отлично работал. Буквально недавно мы внедрили RODC на сайте. Как только это произошло, никто не смог пройти аутентификацию, и я не смог решить проблему. Я удалил объект AD, используемый для аутентификации Kerberos, и выполнил эту команду:
msktutil -c -b "CN=COMPUTERS" -s HTTP/PROXY.domain.com -k /etc/squid3/PROXY.keytab --computer-name PROXY-K --upn HTTP/PROXY.domain.com --server dc1.domain.com --verbose
Эта команда фактически создает объект в AD, но не устанавливает пароль. Я получаю следующую ошибку:
Ошибка: ошибка krb5_set_password_using_ccache (Невозможно связаться с любым KDC для запрашиваемой области)
msktutil -c -b "CN=COMPUTERS" -s HTTP/PROXY.domain.com -k /etc/squid3/PROXY.keytab --computer-name PROXY-K --upn HTTP/PROXY.domain.com --server dc1.domain.com --verbose
Эта команда фактически создает объект в AD, но не устанавливает пароль. Я получаю следующую ошибку:
Ошибка: ошибка krb5_set_password_using_ccache (Невозможно связаться с каким-либо KDC для запрашиваемой области)
msktutil -c -b "CN=COMPUTERS" -s HTTP/PROXY.domain.com -k /etc/squid3/PROXY.keytab --computer-name PROXY-K --upn HTTP/PROXY.domain.com --server dc1.domain.com --verbose
Эта команда фактически создает объект в AD, но не устанавливает пароль. Я получаю следующую ошибку:
Ошибка: ошибка krb5_set_password_using_ccache (Невозможно связаться с каким-либо KDC для запрашиваемой области) Ошибка: сбой set_password
Я убедился, что этот компьютер может разрешить контроллеры домена.
На этом этапе я потерялся. Боролся с этим в течение месяца то и дело, и действительно мог использовать некоторые рекомендации. У меня есть четыре других идентичных прокси-сервера Squid, которые работают без RODC и отлично работают.
Я решил для создания нового прокси-сервера в более позднем выпуске Ubuntu с использованием последней версии msktutil, и он действительно работает. Думаю, я просто перенесу все данные и поменяю IP-адреса во время следующего периода обслуживания.
Я предполагаю, что RODC работает правильно, то есть: Kerberos в порядке, AD DS запущен и работает и т. Д.?
Я думаю, что следующим шагом будет захват сети trace, фильтруя только DNS и Kerberos, а затем посмотрите, что делают клиенты.
--- 01.07.2017 ---
Я вижу, что между 172.26.48.25 происходит рукопожатие Kerberos. и 172.21.1.19. Однако два ответа AS-REQ (запрос службы аутентификации) терпят неудачу с регулярно наблюдаемым KRB5KDC_ERR_PREAUTH_REQUIRED. Это ожидается ОДИН РАЗ с Kerberos 5. Если увидеть это дважды, это нечетно, и обычно указывает на проблемы синхронизации времени между KDC и клиентом Kerberos.
Однако затем мы видим, что клиент запрашивает билет службы. Часть службы выдачи билетов (TGS) KDC отвечает KRB5_NT_UNKNOWN (тип имени Kerberos неизвестен). Поэтому я бы, возможно, немного исследовал эту ошибку, так как обычно я не ожидал бы, что клиент будет продолжать запрашивать билет службы, если его первоначальная аутентификация не удалась.