Проверьте что в my.ini все пути правильно прописанны в часности:
lc-messages-dir
lc-messages
basedir
datadir
Если ставили вручную из zip архива возможно нужно будет в консоле указать где лежит сам конфиг.

В целом kerberos ticket действует только в приделах сессии и когда браузер закрывается то закрывается и сессия, чтобы получить новый тикет нужно повторно проходить аутентификацию. Из простого можно сохранить пароль, чтобы его не набирать каждый раз, но нажимать кнопку OK все равно придется.
И ещё параметры auth_param negotiate в данном случае относятся только к kerberos аутентификации. Все параметры auth_param basic относятся только к базовой не шифрованной аутентификации открытым текстом, нужно это только тем программам которые не умеют более сложные алгоритмы аутентификации.

Ах да, /usr/lib64/squid/basic_pam_auth -n squid по прежнему выдает ERR, но в браузере пользователя можно вводить и как username@domain.ru и как domain\username )))) а вот просто username не проходит. В общем, у меня все наоборот. Centos7, Srv2012, Squid 3.5.

Я совсем ничего не понимаю. В общем, видимо какая-то особенность не MS браузеров. Если выходить в сеть через IE, то после запроса логина и пароля система получает kerberos ticket и и IE и сторонние браузеры успешно работают. Если не получать kerberos ticket и выйти, к примеру, через chrome, то авторизация не проходит (точнее проходит единожды после рестарта squid, и сохраняется на время сессии (до закрытия браузера)). Помогает auth_param negotiate keep_alive off — тогда все браузеры успешно проходят авторизацию. Но все же тикет получает ТОЛЬКО IE (Edge не проверял), соответственно браузеры просят авторизацию каждый раз после закрытия. Полагаю, что за это отвечает опция auth_param basic credentialsttl 2 hours, не отрабатывает, видимо.

Этот хелпер не имеет ключей для дебага, можно настроить дебаг через конфиги самого pam, но я без этого обходился.
А так все правильно нужно добиться чтобы хелпер
/usr/lib64/squid/basic_pam_auth -n squid
Выдавал ответ OK
В данном случае для pam используются два файла
/etc/pam.d/squid — какие библиотеки и настройки использовать для аутентификации.
/etc/krb5.conf — здесь нужно внимательно проверить параметры из секции pam
При правильной настройке хелпер может принимает логины двух видов:
username
username@domain.ru
Логины в формате domain\username неправильно обрабатываются поэтому их можно даже не пытаться набирать.
Если на сервере хелпер заработает тогда можно смотреть на клиентах.

Да, видимо я уже запутался. В общем, наблюдаю сейчас картину. Авторизация доменных машин по auth_param negotiate работает исправно, даже группы правильно берет. А вот при попытке выйти в сеть с недоменной машины выходит окно запроса логина и пароля, при вводе в cache.log:
ERROR: Negotiate Authentication validating user. Result: {result=BH, notes={message: received type 1 NTLM token; }}
а по systemctl status squid вижу:
proxy (basic_pam_auth)[30623]: pam_krb5[30623]: error resolving user name ‘%username%’ to uid/gid pair
попробовал скормить логин и пасс
/usr/lib64/squid/basic_pam_auth -n squid
в любом варианте ввода ERR. Есть у хелпера дебаг вообще? Как понять, что не так?

Странно ошибка
ERROR: Negotiate Authentication validating user. Result: {result=BH, notes={message: received type 1 NTLM token; }}
Обычно бывает если указать неполное или неправильное FQDN имя прокси сервера в настройке браузера.

Да есть такая проблема не все браузеры умеют использовать kerberos, выхода два либо использовать нормальные браузеры (IE, firefox, chrome offline installer) либо настраивать древний ntlm вместо kerberos. А вот к примеру skype с недавних пор вообще через прокси перестал работать и это не лечится.