прозрачная авторизация через kerberos в squid не работает. проблема с шифрованиаем

Поправил тебе форматирование, но в следующий раз давай уже сам. Там вон даже ссылка есть на разметку специальная, если сам в МД не умеешь. А читать неоформленные портянки такое себе удовольствие, и помогать никто не будет.

прошу прощения

После экспорта keytab’а пароль привязанной учетки не менял?

Смена пароля => смена kvno => старый keytab превращается в тыкву

Тогда бы он писал, что не может найти принципал с данным kvno в кейтабе. А здесь пишет, что нашел, но не может расшифровать тикет.

Попробуй очистить все керберос тикеты в системе

kdestroy -A

Попробуй очистить все керберос тикеты в системе kdestroy -A

не помогает. тоже самое

После экспорта keytab’а пароль привязанной учетки не менял?

нет. не менял. на всякий случай несколько раз пробовал перегенерировать кейтаб и заново его закачивать на squid. все тоже самое

[X] 0x00000010 AES256-CTS-HMAC-SHA1-96

[ ] 0x00000020 AES256-CTS-HMAC-SHA1-96-SK

там два варианта для aes256-cts. с виндой мало работал, не уверен, что эта команда показывает именно то, что нужно. проверь через графическую морду из rsat https://serverfault.com/a/1043213/166198

2. на всякий слуйчай посмотри, что есть в keytab’е

klist -kte /path/to/keytab

3. можно поробовать включить трассировку и попробовать авторизоваться с использованием этого keytab’а. Может в выводе будут какие-то подробности

KRB5_TRACE=/tmp/trace_kinit -- kinit -kt /path/to/keytab service_user

service_user - тот, что привязан к принципалам твоего прокси. ну т.е. когда ты экспортировал keytab для прокси, его для экспорта нужно привязать к какой-то сервисной учетке

там два варианта для aes256-cts. с виндой мало работал, не уверен, что эта команда показывает именно то, что нужно. проверь через графическую морду из rsat https://serverfault.com/a/1043213/166198

в rsat включены обе галки связанные с aes как на скрине который вы привели

klist -kte /path/to/keytab

Keytab name: FILE:/tmp/proxy.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   2 22.04.2024 13:50:48 HTTP/srv-proxy.mydomain.ru@MYDOMAIN.RU (aes256-cts-hmac-sha1-96)
   2 22.04.2024 13:50:48 HTTP/srv-proxy.mydomain.ru@MYDOMAIN.RU (aes128-cts-hmac-sha1-96)
   2 22.04.2024 13:50:48 HTTP/srv-proxy.mydomain.ru@MYDOMAIN.RU (DEPRECATED:arcfour-hmac)

KRB5_TRACE=/tmp/trace_kinit – kinit -kt /path/to/keytab service_user

ничего интересного здесь не вижу, но может вы увидите https://pastebin.com/uv2QNPRz

[88466] 1713928645.863908: Decrypted AS reply; session key is: aes256-cts/1C4A

Да вроде как все получилось

Не знаю, по какой инструкции настраивали сервер. Может нужно перезапустить squid и то, что отвечает за gssapi

smbd -b | grep USES

я дико извиняюсь но я запустил

KRB5_TRACE=/tmp/trace_kinit – kinit -kt /path/to/keytab service_user

на стороне контроллера домена. На стороне squid стоит freebsd и там KRB5_TRACE почему-то ничего не выводит.

у меня еще была идея, что на одном сервере MIT kerberos, а на другом heimdal , но

 smbd -b | grep _USES_

показывает на обоих сторонах

SAMBA4_USES_HEIMDAL

еще используя kinit на стороне сервера с freebsd и в качестве юзера SPN к которому сгененерирован keytab я успешно получаю тикет.

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

еще заметил что в keytab файле kvno с номером 2

а когда получаю тикет через кейтаб во freebsd и выполняю klist -v , то вижу следующее

Ticket etype: aes256-cts-hmac-sha1-96, kvno 1

тут почему-то kvno 1 , это важно?

а если во freebsd ввожу

kvno HTTP/srv-proxy.mydomain.ru@MYDOMAIN.RU

то получаю

kvno HTTP/srv-proxy.mydomain.ru@MYDOMAIN.RU = 2

KRB5_TRACE=/tmp/trace_kinit – kinit -kt /path/to/keytab service_user

это у меня был лишний «–»

export KRB5_TRACE=/tmp/trace_kinit kinit -kt /path/to/keytab service_user

или

export KRB5_TRACE=/tmp/trace_kinit
kinit -kt /path/to/keytab service_user

это у меня был лишний «–» да это-то я исправил но все равно никак не выводит KRB5_TRACE почему-то в freebsd. неважно в файл или /dev/stdout. на линуксах все нормально.

ну и как я говорил

kinit -kt /path/to/keytab service_use

проходит успешно. билет я получаю

какая-то уникальная у меня проблема похоже

aПопробуй поставить пакет

apt install -y libsasl2-modules-gssapi-mit

У меня была какая-то похожая проблема с настройкой доменной авторизации на squid, посмотрел историю команд, ставил этот пакет, ну и krb5-user тоже должен стоять.

И ещё одно, в свойствах браузера подключение к proxy серверу должно быть указано по его FQDN имени, а не по IP.

aПопробуй поставить пакет apt install -y libsasl2-modules-gssapi-mit

пакета с таким названием нет, но я так понимаю

cyrus-sasl-gssapi.x86_64

это оно и есть и он стоит

krb5-user

такого тоже нет. ну и еще на винде введенной в этот же домен поведение точно такое же.

И ещё одно, в свойствах браузера подключение к proxy серверу >должно быть указано по его FQDN имени, а не по IP.

у меня так и выставлено

проблема решилась генерацией кейтаб файла с windows server :D до этого с самой самбы пробовал через samba-tool export keytab. я незнаю чего не так с кейтабом , который генерируется самбой