Суть: сменили пользователя для SSO аутентификации по протоколу Kerberos. Сгенерировали новый кейтаб, всё работало в течение нескольких минут, что проверяли, потом ушли домой и на утро вход в KSMG перестал работать.
Ситуация в картинках. Попытка логина:
В логе /var/log/kaspersky/ksmg/extra/webapi.log при этом появляются такие записи:
[pid: 5321|app: 0|req: 1/11] 10.10.1.56 () {64 vars in 1416 bytes} [Thu Jun 15 10:26:38 2023] GET /web/api/get-session-info?session_autorenew=false => generated 12 bytes in 26 msecs (HTTP/1.1 401) 4 headers in 132 bytes (1 switches on core 0)
Thu Jun 15 10:26:38 2023 - announcing my loyalty to the Emperor...
ERROR:root:GSSError: (('Unspecified GSS failure. Minor code may provide more information', 851968), ('Request ticket server HTTP/*****@*****.tld kvno 9 not found in keytab; keytab is likely out of date', 100005))
[pid: 5321|app: 0|req: 2/12] 10.10.1.56 () {66 vars in 4240 bytes} [Thu Jun 15 10:26:38 2023] GET /web/api/get-session-info?session_autorenew=false => generated 224 bytes in 15 msecs (HTTP/1.1 403) 3 headers in 93 bytes (1 switches on core 0)
[pid: 5321|app: 0|req: 3/13] 10.10.1.56 () {64 vars in 1410 bytes} [Thu Jun 15 10:26:38 2023] GET /web/api/get-auth-info?session_autorenew=false => generated 207 bytes in 8 msecs (HTTP/1.1 200) 3 headers in 86 bytes (1 switches on core 0)
Видим, что используемое при поиске тикета значение KVNO равно 9. Смотрим в загруженный тикет:
[root@ksmg ~]# klist -k /var/opt/kaspersky/ksmg/service_keytab
Keytab name: FILE:/var/opt/kaspersky/ksmg/service_keytab
KVNO Principal
---- --------------------------------------------------------------------------
3 HTTP/*****@*****.tld
Видим значение 3. Ладно, смотрим значение msDS-KeyVersionNumber у пользователя, используемого для SSO:
Видим тоже 3.
Вопрос: откуда взялось 9 и как это побороть? Перезагрузка и прочее не помогли, как будто закэшировался предыдущий пользователь и его кейтаб.
P.S. Приметили, что если KVNO выше 5, то KSMG не работает с такими пользователями. В документации об этом ни слова.
