У нас есть филиал в Коста-Рике, где тогда мы внедрили прокси-сервер 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 для запрошенной области) Ошибка: сбой set_password
Я убедился, что этот компьютер может разрешить контроллеры домена.
На данный момент я потерялся. В течение месяца боролся с этим то и дело, и мне действительно пригодились некоторые рекомендации. У меня есть четыре других идентичных прокси-сервера Squid, которые работают без RODC и отлично работают.
Я решил создать новый прокси-сервер в более поздней версии Ubuntu с использованием последней версии msktutil, и он действительно работает. Думаю, я просто перенесу все данные и поменяю IP-адреса во время следующего периода обслуживания.
Я предполагаю, что RODC работает правильно, то есть: Kerberos в порядке, AD DS работает и т. Д.?
Я думаю, что следующим шагом будет захват сетевой трассировки, фильтрация только DNS и Kerberos, а затем просмотр того, что делают клиенты.
--- 01.07.2017 ---
Я вижу, что между 172.26.48.25 и 172.21.1.19 происходит рукопожатие Kerberos. Однако два ответа AS-REQ (запрос службы аутентификации) терпят неудачу, с регулярно наблюдаемым KRB5KDC_ERR_PREAUTH_REQUIRED. Это ожидается ОДИН РАЗ с Kerberos 5. Увидеть это дважды - странно, и как обычно указывает на проблемы синхронизации времени между KDC и клиентом Kerberos.
Однако затем мы видим, что клиент запрашивает билет службы. Часть службы выдачи билетов (TGS) KDC отвечает KRB5_NT_UNKNOWN (тип имени Kerberos неизвестен). Поэтому я бы, возможно, немного исследовал эту ошибку, так как обычно я не ожидал бы, что клиент будет спешить с запросом билета службы, если его первоначальная аутентификация не удалась.