Настраивая Squid часто сталкивался с ошибками при настойке авторизации через Kerberos и решая некоторые ошибки не мог найти их в интернете, а информации в логе было недостаточно для диагностирования причины.

Небольшая врезка по настройке лога

Синтаксис debug_options [Section,Level] [Section,Level] ...

В файле squid.conf:

debug_options ALL,1 33,2 28,2 50,2 # подробный лог для debug

  • Section: Номер раздела кода Squid:

    • ALL — означает все разделы.

    • 33 — аутентификация

    • 28 — ACL, 50 — DNS)

    • 84— хелперы (external_acl)

  • Level: Уровень детализации от 0 (только критические ошибки) до 9 (полный дамп данных и трассировка функций).

# Вывод лога доступа в файл
access_log stdio:/opt/squid/var/log/squid/access.log
# Вывод лога ошибок и debug в файл
cache_log stdio:/opt/squid/var/log/squid/cache.log

Ошибка "Minor code may provide more information. Bad encryption type"

# Из лога
2026/03/14 15:34:51 kid1| ERROR: Negotiate Authentication validating user. Result: {result=BH, notes={message=gss_accept_sec_context() failed: Unspecified GSS failure.  Minor code may provide more information. Bad encryption type }}
    current master transaction: master54

Самая проблемная ошибка, т.к. сложно сразу сказать о причине ее появления.

"Могу предположить, что при смене keytab у пользователей были закешированы старые тикеты (tgs), и они отсылали их на squid без попытки получить новые (зашифрованные новым ключом) от kdc. Когда сквид получал данные - он не мог просто свою часть расшифровать и подтвердить подлинность пользователя. Т.е. klist purge (win) / kdestroy(nix) на клиенте мог помочь. К вечеру были получены новые билеты." - Нашел эту цитату на каком то форуме.

Процесс решения

# Узнать кто главный сервер в домене
Get-ADDomain | Select-Object PDCEmulator

На этом сервере выполняем:

# Смотрим и удаляем SPN (Старый SPN, если создавали до этого для пользователя AD)
setspn -L squid
setspn -D HTTP/testSquidPc.domain.ru userAD

Сбрасываем пароль пользователя squid в AD "userAD" на нужный нам любым способом (например, чрез оснастку "Пользователи и компьютеры")

# Заново создаем SPN и keytab
ktpass /princ HTTP/testSquidPc.domain.ru@DOMAIN.RU`
	/mapuser userAD@DOMAIN.RU `
	/crypto ALL `
	/ptype KRB5_NT_PRINCIPAL `
	/pass password`
	/out C:\squid.keytab

# Принудительная репликация всех разделов между всеми партнерами DC
repadmin /syncall /AdeP

На сервере Squid:

# Копируем keytab на сервер squid и настраиваем права:
systemctl stop squid
chown proxy:proxy /opt/squid/etc/squid.keytab
chmod 600 /opt/squid/etc/squid.keytab

# Проверяем
klist -kte /opt/squid/etc/squid.keytab
# Можно сравнить knvo и princ с тем что в MS DC

На клиенте почистить старые ключи

klist purge

Запускаем Squid

systemctl start squid

Проверяем

Скрытый текст

Я бы скорее назвал это решение "с обходом", главное что не придется ждать 10-24 часа...

Ошибка "Service key not available"

Проблема с доступом к файлу:

# Из лога:
2026/03/13 19:44:14 kid1| ERROR: Negotiate Authentication validating user. 
Result: {result=BH, notes={message=gss_accept_sec_context() failed: 
Unspecified GSS failure.  Minor code may provide more information. Service key not available }}
    current master transaction: master54

  1. Несовпадение версии ключа (KVNO - Key Version Number) — У каждого ключа в Active Directory и в файле keytab есть номер версии

    1. Когда вы меняете пароль пользователю в AD или пересоздаете keytab, KVNO увеличивается (например, было 11, стало 12).

    2. Если клиент (браузер) получил билет от контроллера домена, зашифрованный ключом KVNO 12, а в вашем файле squid.keytab лежит ключ только с KVNO 11, то Squid не сможет расшифровать билет. Он скажет: "Я вижу имя HTTP/..., но у меня нет ключа версии 12 для него".

      # Посмотрите KVNO в вашем файле на сервере squid:
klist -kte /opt/squid/etc/squid.keytab
#	Keytab name: FILE:/opt/squid/etc/squid.keytab
#	KVNO Timestamp           Principal
#	---- ------------------- ------------------------------------------------------
#	  14 01/01/1970 03:00:00 HTTP/testSquidPc.domain.ru@DOMAIN.RU (DEPRECATED:des-cbc-crc)

# Посмотрите текущий KVNO на Контроллере Домена (Windows). Запустите PowerShell на DC:
Get-ADUser -Identity "userAD" -Properties msDS-KeyVersionNumber | Select-Object msDS-KeyVersionNumber
# msDS-KeyVersionNumber UserPrincipalName
# --------------------- -----------------
#                    15 HTTP/testSquidPc.domain.ru@DOMAIN.RU
    
# Или при создании "...vno 15..."
Targeting domain controller: DC1.domain.ru
Using legacy password setting method
Successfully mapped HTTP/testSquidPc.domain.ru to userAD.
Key created.
Output keytab to C:\temp\squid.keytab:
Keytab version: 0x502
keysize 99 HTTP/testSquidPc.domain.ru ptype 1 (KRB5_NT_PRINCIPAL) vno 15 etype 0x12 (AES256-
keylength 32 (0x1fd...)

  2. Проблема имени сервиса (Service Principal Name mismatch): Squid ищет ключ для имени, которое чуть-чуть отличается от того, что записано в файле (например, из-за сокращенного имени хоста vs FQDN).

# Возбмите имя от сюда и скопируйте его в файл squid.conf
klist -kte /opt/squid/etc/squid.keytab

Можно проверить, правильно ли имя и knvo читается из файла keytab

sudo -u proxy kinit -kt /opt/squid/etc/squid.keytab HTTP/testSquidPc.domain.ru
# Если команда успешна (нет вывода, просто возврат в консоль): 
# Значит файл читается, ключи верные, криптография работает. 
# Проблема в том, как Squid запускает хелпер.

Ошибка negotiate_kerberos_auth - Bad encryption type

# Из лога
2026/03/13 15:16:33 kid1| ERROR: Negotiate Authentication validating user. Result: {result=BH, notes={message=gss_accept_sec_context() failed: Unspecified GSS failure.  Minor code may provide more information. Bad encryption type }}

Клиент и сервер не смогли договориться о кодировке. Проверьте что в файле squid.keytab присутствуют нужные krb daemon кодировки.

klist -kte /opt/squid/etc/squid.keytab
#	Keytab name: FILE:/opt/squid/etc/squid.keytab
#	KVNO Timestamp           Principal
#	---- ------------------- ------------------------------------------------------
#	  11 01/01/1970 03:00:00 HTTP/testSquidPc.domain.ru@DOMAIN.RU (DEPRECATED:des-cbc-crc)
#	  11 01/01/1970 03:00:00 HTTP/testSquidPc.domain.ru@DOMAIN.RU (DEPRECATED:des-cbc-md5)
#	  11 01/01/1970 03:00:00 HTTP/testSquidPc.domain.ru@DOMAIN.RU (DEPRECATED:arcfour-hmac)
#	  11 01/01/1970 03:00:00 HTTP/testSquidPc.domain.ru@DOMAIN.RU (aes256-cts-hmac-sha1-96)
#	  11 01/01/1970 03:00:00 HTTP/testSquidPc.domain.ru@DOMAIN.RU (aes128-cts-hmac-sha1-96)

И в /etc/krb5.conf:

[libdefaults]
# Используйте для отключения контроля кодировки (default_tgs_enctypes, default_tkt_enctypes, permitted_enctypes - закоментируйте, что бы не переопределяли allow_weak_crypto)
# allow_weak_crypto = true

# Установить определенный AES
default_tgs_enctypes = aes256-cts-hmac-sha1-96
default_tkt_enctypes = aes256-cts-hmac-sha1-96
permitted_enctypes = aes256-cts-hmac-sha1-96

Ошибка icmp_sock/ERROR: Unable to start ICMP pinger.

# Из лога
2026/03/13 14:56:42 pinger| Initialising ICMP pinger ...
2026/03/13 14:56:42 pinger| Open  icmp_sock: (1) Operation not permitted
2026/03/13 14:56:42 pinger| ERROR: Unable to start ICMP pinger.
2026/03/13 14:56:42 pinger| Open  icmp_sock: (1) Operation not permitted
2026/03/13 14:56:42 pinger| ERROR: Unable to start ICMPv6 pinger.
2026/03/13 14:56:42 pinger| FATAL: Unable to open any ICMP sockets.

Исправление: 

setcap cap_net_raw+ep /opt/squid/libexec/pinger