Почему 1С периодически запрашивает пароль при использовании доменной авторизации?

Ситуация, когда пользователи, работающие под доменными учетными записями, внезапно сталкиваются с окном авторизации 1С, является довольно распространенной. При этом проблема носит плавающий характер: база может запросить пароль, но после перезапуска или нескольких попыток входа пускает пользователя без лишних вопросов. Разберем подробно причины такого поведения и шаги, которые необходимо предпринять для стабилизации работы системы.

Анализ синхронизации времени (Kerberos)

Первым делом проанализируем состояние службы времени в домене. Протокол Kerberos, который обеспечивает сквозную аутентификацию, крайне чувствителен к расхождению системного времени между клиентом, сервером приложений 1С и контроллером домена. Разберем основные моменты:

1. Критический порог: Если разница во времени между участниками процесса авторизации превышает 5 минут, билет Kerberos не может быть выписан или проверен. Это приводит к откату системы на менее приоритетные (или вовсе заблокированные) методы проверки подлинности.
2. Проверка службы времени: На сервере, где запущен кластер 1С, необходимо проверить состояние Служба времени Windows (W32Time). Убедимся, что она запущена и синхронизируется с контроллером домена (PDC Emulator).
3. Просмотр журналов: Изучим журналы событий Windows (System) на предмет ошибок от источника Time-Service. Даже кратковременные скачки времени могут вызывать те самые «рандомные» запросы пароля.

Диагностика взаимодействия с контроллером домена

Выясним, не теряет ли сервер приложений 1С связь с доменной средой. Процесс rphost (рабочий процесс 1С) выступает посредником при проверке прав пользователя. Если в момент запроса авторизации сервер 1С не может достучаться до контроллера домена (DC), происходит сбой.

Проанализируем журналы безопасности на стороне контроллера домена. Нас интересуют события отказов в аутентификации или ошибки Kerberos. Если в логах DC фиксируются «отказы в доступе» или «неизвестные имена участников», проблема может крыться в настройках безопасности самой ОС Windows Server 2012 R2.

Настройка Service Principal Name (SPN)

Рассмотрим техническую деталь, о которой часто забывают: регистрация имен SPN. Для корректной работы Kerberos-авторизации служба 1С должна иметь зарегистрированные уникальные идентификаторы в Active Directory. Разберем алгоритм действий:

1. Если служба 1С (ragent) запущена от имени доменного пользователя, необходимо вручную прописать SPN для этой учетной записи.
2. Используем утилиту setspn для проверки и добавления записей вида HOST/ServerName и HOST/ServerName.domain.com.
3. Если SPN дублируются (принадлежат разным пользователям или компьютеру и пользователю одновременно), авторизация будет работать нестабильно, периодически требуя ввода логина и пароля вручную.

Проверка прав учетной записи службы 1С

Проанализируем права, которыми обладает пользователь, под которым крутится кластер 1С. Для полноценного делегирования прав доменных пользователей серверу требуются специфические привилегии в локальной политике безопасности (secpol.msc):

• Имитация клиента после проверки подлинности (SeImpersonatePrivilege).
• Работа в режиме операционной системы (SeTcbPrivilege).

Отсутствие этих прав приводит к тому, что сервер 1С «иногда» не может подтвердить личность вошедшего пользователя через механизмы ОС.

Влияние сетевых протоколов и DNS

Посмотрим на сетевую составляющую. Ошибки авторизации могут быть вызваны некорректным разрешением имен (DNS). Проверим следующее:

1. Обратные зоны DNS (PTR): Kerberos требует наличия корректных PTR-записей для сервера 1С. Если IP-адрес сервера не разрешается обратно в его имя, процесс авторизации может завершиться по таймауту.
2. Протокол IPv6: Платформа 1С 8.3 иногда некорректно работает в сетях, где включен IPv6, но не настроен должным образом. В качестве диагностической меры попробуем временно отключить IPv6 на сервере 1С или понизить его приоритет через реестр.
3. Размер токена Kerberos: Если ваши пользователи состоят в очень большом количестве доменных групп, размер Kerberos-токена может превысить стандартные лимиты. Это лечится увеличением параметра MaxTokenSize в реестре на сервере и контроллерах.

Диагностика средствами 1С

Если системные логи не дают четкого ответа, перейдем к инструментам самой платформы. Рассмотрим использование Технологического журнала (ТЖ). Настроим сбор событий AUTH и EXCP. В файле настроек logcfg.xml это будет выглядеть примерно так:

<log location="C:\LOGS\AUTH" history="24">
    <event>
        <eq property="Name" value="AUTH"/>
    </event>
    <event>
        <eq property="Name" value="EXCP"/>
    </event>
</log>

Анализ этих логов позволит увидеть, на каком именно этапе платформа получает отказ от операционной системы при попытке доменного входа.

Очистка кэша и настройки клиента

В завершение разберем клиентскую часть. В старых версиях платформы (как 8.3.8) встречались ошибки кэширования учетных данных. Попробуем выполнить следующие действия:

• Очистить локальный кэш пользователя (папки %LOCALAPPDATA%\1C\1Cv8 и %APPDATA%\1C\1Cv8).
• Убедиться, что в настройках списка баз для конкретной ИБ стоит флаг Выбирать автоматически в поле Вариант аутентификации.
• Если используется доступ через веб-сервер, добавим адрес сервера 1С в зону «Местная интрасеть» в настройках браузера.