Проблемы с доменной аутентификацией в связке 1С:Предприятие и Kerberos часто носят «плавающий» характер, но иногда они приобретают строгую цикличность. Одной из самых неприятных ситуаций является стабильный отказ аутентификации ровно через 24 часа после запуска сервера или службы. В этой ситуации пользователи, привыкшие входить в базу без ввода пароля, внезапно видят диалоговое окно авторизации 1С, а в технологическом журнале фиксируются ошибки исключений без детальных пояснений.
Рассмотрим подробно причины возникновения этой проблемы на современных операционных системах (Windows Server 2019/2022) и разберем по шагам методы её устранения.
Разберем механику работы Kerberos. Когда агент сервера 1С ragent.exe запускается под доменной учетной записью, он получает от контроллера домена (DC) специальный билет — TGT (Ticket Granting Ticket). Этот билет имеет определенный срок жизни, который регулируется групповыми политиками домена (Default Domain Policy).
В стандартной конфигурации Kerberos билет имеет два временных лимита:
Однако в некоторых организациях из соображений безопасности на уровне политик Active Directory или специфических групп безопасности устанавливается жесткое ограничение на обновление билета или сертификата — 24 часа. Проанализируем, что происходит: служба успешно работает, Kerberos обновляет «короткие» сертификаты каждые несколько часов, но как только наступает отметка в 24 часа, механизм продления блокируется политикой. Служба 1С перестает быть доверенным «шлюзом» для проверки прав пользователей в домене, и аутентификация «отваливается» до перезапуска процесса.
Как показала практика, корень проблемы часто кроется в членстве сервисной учетной записи в группах с повышенным контролем безопасности. Рассмотрим алгоритм действий для системного администратора:
ragent.exe. Если она включена в группу Protected Users, Kerberos будет вести себя максимально жестко: делегирование будет запрещено, а время жизни билетов ограничено.Default Domain Policy в разделе: Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Account Policies -> Kerberos Policy.Решение: Перенесите сервисную учетную запись 1С в отдельное подразделение (OU) или группу, где срок обновления билета (Renewal) составляет стандартные 7 дней. Это не решает проблему «протухания» билета в принципе, но отодвигает необходимость перезапуска службы на неделю, что позволяет совместить это с регламентными работами.
Выясним причину, по которой обычные учетные записи доставляют столько хлопот. Обычный пользователь или сервисный аккаунт требует ручного или полуавтоматического обновления секретов. Современный и наиболее надежный способ для работы 1С на Windows Server 2019 — это переход на gMSA.
Учетные записи gMSA обладают следующими преимуществами:
Для настройки 1С под gMSA необходимо создать такую учетную запись в домене и разрешить серверу 1С использовать её. При этом SPN должен быть зарегистрирован именно на эту виртуальную учетную запись.
Если изменить политики домена невозможно, проанализируем вариант принудительного обновления билета без перезапуска службы 1С. Поскольку агент сервера 1С работает в сессии 0 (неинтерактивной), обычная команда klist purge, запущенная под администратором, не поможет. Нам нужно очистить и обновить кэш билетов именно для сессии службы.
Рассмотрим пример PowerShell-скрипта, который можно запускать через планировщик задач каждые 12 часов:
# Получаем идентификатор сессии системы или конкретной учетной записи
# Обычно для системы это 0x3e7
klist -li 0x3e7 purge
# Инициируем обращение к контроллеру домена для получения нового TGT
# Можно выполнить простую команду проверки прав в AD
$searcher = [adsisearcher]"(&(objectClass=user)(sAMAccountName=$env:USERNAME))"
$searcher.FindOne()
Такой подход заставляет подсистему LSA (Local Security Authority) перевыпустить билет, так как старый был принудительно удален из кэша, а обращение к AD требует валидного токена.
Многие задаются вопросом: критично ли отсутствие делегирования для работы Kerberos в 1С? Разберем этот момент. Если ваша задача — просто впускать пользователей в базу под их доменными именами (Single Sign-On), то делегирование не требуется. Оно необходимо только в том случае, если сервер 1С должен «передать» личность пользователя дальше — например, на сервер MSSQL для аутентификации в базе данных средствами Windows.
Однако, если вы используете constrained delegation (ограниченное делегирование), это может повысить стабильность работы протокола в сложных доменных структурах. Если политика безопасности запрещает делегирование, убедитесь, что в свойствах учетной записи пользователя в AD не стоит флаг Account is sensitive and cannot be delegated, если вы все же планируете использовать сложные схемы авторизации.
Проанализируем еще одну возможную причину сбоев на Windows Server 2019. Старые алгоритмы шифрования (например, RC4) считаются небезопасными и могут блокироваться современными ОС после определенных обновлений. Это приводит к тому, что билет вроде бы есть, но сервер не может его расшифровать.
Убедитесь, что в свойствах учетной записи службы 1С в Active Directory на вкладке Account установлены следующие флаги:
После установки этих флагов рекомендуется один раз перезапустить службу 1С и обновить пароль учетной записи, чтобы Kerberos начал использовать стойкое шифрование AES.
Если вы столкнулись с проблемой «24 часов», выполните следующие действия в указанном порядке:
Renewal lifetime.klist purge для сессии службы.Помните, что перезапуск rphost (рабочих процессов) в данном случае не помогает, так как за взаимодействие с LSA и получение билета отвечает основной процесс ragent. Только комплексная настройка Kerberos на уровне ОС и домена позволит добиться аптайма сервера 1С более 24 часов без деградации сервиса аутентификации.