Доброго дня! Коллеги, кто сталкивался с проблемой?
Имеем WinSrv 2019 Standart, MSSQL 2014, платформа 8.3.27.1936. Аутентификация в домене с использованием kerberos. Агент сервера 1С запускается под доменной учетной записью. Аутентификация пользователей 1С - по операционной системе. Раз в 24 часа отваливается доменная аутентификация: при попытке подключения к базе 1С вываливается диалог на ввод пароля. kerberos обновляет сертификаты раз в 6 часов. Перезапуск агента сервера устраняет проблему, но через 24 часа проблема повторяется. Web не используется. SPN для учетной записи настроен согласно инструкциям. Кроме одного: делегирование запрещено. Делегирование запрещено внутренней политикой информационной безопасности. Вопрос: может ли это критично влиять на возникновение описанной проблемы? Куда еще копать для её (проблемы) устранения?

Через техжурнал уже пробовали отловить?
https://its.1c.ru/db/metod8dev/content/5944/hdoc

(1) Спасибо, пробовали, не результат не далО. По ссылке попробую еще раз, но меня смущает в данной рекомендации то, что у нас Web не используется.

(2) Если нет даже попытки доменной авторизации это тоже показатель
Может настройка перезапуска rphost поможет?

(3) Перезапуск rphost не помогает. Только перезапуск агента сервера. По rphost'у было предположение, что может влиять размер, но на другой платформе (для разработки, 8.3.27.1859) rphost не достигает даже 1 гБ, но симптомы те же: раз в 24 часа отваливается.

Тех. журнал ничего не дает. Кроме самого факта, что событие EXCP зарегистрировано в журнале. Дальше сообщения ...EXCP,1 (или 2, или 3) ничего.
Еще раз обращу внимание, что доменная аутентификация после рестарта агента сервера работает вполне хорошо. Но по истечении 24 часов учетная запись, от которой запускается агент сервера, не может получить от домена учетку, под которой проходит аутентификация пользователя. При этом под этой учетной записью (под которой запущен агент сервера) можно войти в домен. То есть доверительные отношения с доменом не теряются, но идентифицировать подключающегося пользователя не возможно. До рестарта агента сервера. Я уже голову сломал и все, что можно, перерыл. Везде речь именно про Web. Но у нас только тонкий клиент. Без Web'а.

А если создать регламентное с фоновым на сервере, которое периодически пробует к некой сетевой шаре стучаться с доменной учеткой?
Например каждые полчаса

Интересно произойдет отвал или нет

(5) Ну так понятно что на агенте протухает токен выданный Kerberos. Вот почему он новый токен не может получить - это нужно смотреть доменную политику безопасности

(6) Попробовать можно. Вопрос - зачем? Какой именно результат планируется получить? Ведь доменная учетка при потере доменной аутентификации продолжает быть активной. Под ней можно войти в домен. Но вот как некий "шлюз", через который агент сервера прогоняет учетную запись пользователя для проверки в домене при аутентификации в 1С, работать перестает. Пока не рестартует агент сервера.
(7) Согласен. Понятно. Но админы этим вопросам заниматься не хотят, а на домен-контроллер не пускают. Для начала запрашивают логи 1С. А какие там могут быть логи? Тех. журнал информации не дает. Логи сервера тоже. Максимум, что можно получить, что в такой-то момент отказ в аутентификации под доменной учеткой пользователя (когда падает доменная аутентификация). Но этой инфы им недостаточно. Поэтому и интересуюсь: в какую сторону еще можно копать, не имея возможности ковырять логи домен-контроллера? Надеялся, что кто-нибудь уже сталкивался с подобной проблемой и имеет опыт решения.
В любом случае, спасибо за советы и внимание. От дальнейших советов не отказываюсь, в случае решения поделюсь опытом.

(8) Вот и попробуй как можно чаще программно обращаться и получать разрешение для доменной учетки
Еще и на разные ресурсы

Или запрашивая разное из Active Directory, можно и через COM из 1С или через PowerShell

Что у агента сервера 1С ragent.exe, что у рабочих процессов 1С rphost.exe кэш по идее должен быть общим
Если одно может то почему не может другое