ERROR: Error while binding to ldap server with SASL/GSSAPI: Can’t contact LDAP server

Я не понял, ты отключаешь DC1 через который проводится аутентификация squid и удивляешься, почему он работать перестает?

Интересно..

А если тебе руки отрубить, то варенье с верхней полки ты тоже достать не сможешь. А если пришить обратно - сможешь.

Загадка?

1. С SRV-записями все в порядке? ext_kerberos_ldap_group_acl использует SRV-записи, а не те КД, что прописаны в krb5.conf.

2. Из логов непонятно, пытается ли вообще ext_kerberos_ldap_group_acl контактировать со вторым КД. Включи дебаг (опция -d).

Последовательно делаешь следующее:

1) Настроить krb5.conf на резолв параметров домена через DNS(dns_lookup_realm, dns_lookup_kdc), ручное перечисление контроллеров НЕ НУЖНО;
2) Посмотреть в tcpdump что именно squid шлет перед неуспешной авторизацией;

Если пункт 1) не сработает, к пункту 2) не переходить, чинить DNS(dcdiag с контроллера домена, вот это вот всё).

Лог дебага

Лог дебага, при выключенном DC1 https://pastebin.com/Yfh0iBgk

[boll@prx ~]# dig _kerberos._udp.domen.local SRV | grep ^_kerberos _kerberos._udp.domen.local. 600 IN SRV 0 100 88 DC2.domen.local. _kerberos._udp.domen.local. 600 IN SRV 0 100 88 DC1.aat.local

2. Логи https://pastebin.com/Yfh0iBgk

Да, все нормально. В логах видно, что после «ERROR: Error while binding to ldap server with SASL/GSSAPI» она переключается на воторой КД и успешно авторизует пользователя. Значит, эту единственную ошибку, которая есть в логах, можно игнорировать.

А как выглядит access.log - есть ли имя пользователя в запросах после того, как ты выключаешь КД?

Тогда такое предложение - сбросить кэш тикетов на виндовом клиенте (klist.exe purge).

Если не поможет, то повышать уровень логирования (ошибок-то, за которые можно зацепиться, в логах нет). Если не поможет, то снифить HTTP и Kerberos трафик.

1. Да, согласен. Подключается к DC2 и проверяет наличие юзера в группе. А ошибка говорит о том, что просто не может подключиться к DC1 - все верно.
2. Что происходит в момент отключения DC1: Я перезахожу в домен (на всякий, по факту нет разницы). Открываю браузер и не грузится никакая страница, просто пишет ERR_TIMEOUT (Chrome). Никакого запроса пароля и прочего. В этот момент в access.log сыпятся сообщения о блокировки страниц, которые я запрашивал. В основном DENIED/407 либо DENIED/403. Если включить в этот момент DC1, то все моментально начинает работать как надо. P.S. bigbit, спасибо тебе, коллега, что помогаешь.. я просто уже не знаю что ему надо. Думал может дело в параметрах TTL?(хелпера) Либо есть мб какой-нить чек-лист, я может базовое что-то не включил.

Когда логируется 407 ошибка, есть ли в логе имя пользователя, или вместо него стоит прочерк?

Если перезапустить squid после выключения КД, это что-то меняет?

Да, стоит прочерк. О чем говорит? Лог с denied: https://pastebin.com/zriwrXXQ

Отключил на ночь DC1, вот что в логах cache.log https://pastebin.com/R8te0Sqa

Вот что в логах при нормальной работе: https://pastebin.com/gnfcUr3f

Говорит о том, что не проходит даже аутентификация пользователя, не говоря уже об авторизации.

Видел аналогичную ситуацию - керберизованный апач не мог авторизовать пользователей после того, как выключили старые домен-контроллеры (всего их было на порядок больше, чем 2).

После рестарта апача магически все заработало.

Потом пост-фактум разглядывали графики мониторинга, и в статистике netstat было видно несколько сотен тысяч connection refused именно в этот промежуток времени, т.е. похоже, что тупой mod_kerberos долбился в старые КД.

Поэтому мне интересно - помогает ли тебе рестарт сквида?

ручное перечисление контроллеров НЕ НУЖНО

Не соглашусь. Далеко не всякий софт, умеющий в SRV-записи из DNS, умеет также и сайты AD.

Допустим, имеется 4 КД в Москве, 4 в Лондоне, пара в Нью-Йорке и еще парочка в Сингапуре.

SSSD вот знает, что такое сайт, и будет соединяться с ближайшим КД в том же сайте. А всякие mod_kerberos и эта Kerberos-приблуда к сквиду - нет. В результате они будут соединяться с первым попавшимся КД. А аутентификация на КД, находящемся в другом полушарии - это дикие тормоза.

Так что ручное перечисление нужно, надо просто знать, зачем это делается.

Выключил DC1, cделал рестарт сквида, перезашел в домен - всё так же. Лог такой же, с прочерками.

Глянул tcpdump, идут arp запросы на dc1 со сквида (who has ip dc1.domen.local tell me proxy.domen.local) На dc2 нету запросов

Может он действительно долбится только к DC1, а про второй и знать не знает? Как это проверить?

Кстати, ещё такой момент. Не знаю насколько это важно, но в AD «компьютер» сквида не отображается, т.е. в AD - юзер (для сквида) и группы.

DC1 - он случайно не DNS по совместительству?
Вообще при отвале DNS-сервера тормоза ожидаемы.
Попробуй в krb5.conf указать IP-адреса kdc и рестартунуть сквид, или вообще убрать DC1 из /etc/resolv.conf.

Ты это - смелее давай - увеличивай уроваень логирования сквида, влезай в его все процессы lsof'ом и strace'ом, смотри, что они делают, чего ждут. Надо понять, что происходит в системе.

lsof покажет не только файлы, но и сетевые соединения. Именно они и интересуют - будет видно, куда ломится процесс.

tcpdump'ом активнее пользуйся, ARP-запросы мало о чем говорят. В качестве фильтра tcpdump'у можешь указать «host <DC1_IP> or host <DC2_IP>».

Ты прав, DC1 - DNS1, DC2 - DNS2. Сейчас так и сделал, добился того, чтобы при выключенном DC1 - прокся работала. Что поменял выставил основным DNS => DNS2 (DC2). И поставил параметр auth_param negotiate keep_alive ON (было off).

Теперь странное поведение в логах: То открывает туннель 200, то denied 407.

Так, виновник частично найден. Это - DNS. Повторюсь, оба DC - оба DNS. Сейчас поставил в конфигурации сети и конфигурации сквида DNS только DC2 - и прокся работает. Но в логах видно что половина запросов обрабатывается(виден доменный юзер), а у половины прочерк…

Там порождается 60 дочерних процессов для аутентификации (children 60). У каждого свой собственный резолвер. Видимо, часть процессов уже переключилась на DC2, а часть - нет.

Стоит уменьшить число? Юзеров не более 50.

Так, виновник частично найден. Это - DNS

попробуй добавить в resolv.conf

options rotate timeout:1

ОСь - centos 7, network-manager вроде заменит там любую запись? Или не должен?

ipv4.dns-options

Понял, спасибо!

Странно.. вернул все конфиги как были, теперь при включенном DC1 происходит следующее: Все сайты открываются (согласно ACL), все работает. Но в access.log чередуются «tunnel/200» (с доменным логином) и denied/407 (с прочерком).

Но в access.log чередуются «tunnel/200» (с доменным логином) и denied/407 (с прочерком).

ЕМНИП, это и есть нормальная работа. Только сначала браузер без аутентификации получает 407, а потом выполняет запрос уже с аутентификацией

Понял. Спасибо коллега!)

В общем, видимо решение проблемы заключается в том, чтобы squid быстрее «понимал», что dns1(dc1) не доступен и запрашивал dns2(dc2). Отпишусь, по результату.

Победа!) router, bigbit огромное спасибо коллеги за помощь!) Оптимизировал скорость переключения между DNS, и всё как надо заработало. После выключения DC1, проходит секунды 3 и доступ в интернет возвращается. Спасибо!