Почему не работает Windows-аутентификация в 1С:Предприятие и как это исправить?

Системный администратор 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

Отказ аутентификации средствами операционной системы в клиент-серверном варианте работы 1С — ситуация крайне неприятная, особенно когда «вчера всё работало, а сегодня перестало». В таких случаях пользователи внезапно видят окно ввода логина и пароля 1С вместо привычного автоматического входа (для упрощения доступа можно использовать лаунчер для 1C с проверкой доменной авторизации). Проанализируем причины этой проблемы и разберем по шагам, как восстановить работоспособность системы.

Шаг 1. Проверка учетной записи службы сервера 1С:Предприятие

Первым делом проанализируем, под какой учетной записью запущена служба ragent (Агент сервера 1С:Предприятие). Для успешной Windows-аутентификации сервер 1С (состояние которого отслеживает монитор кластеров серверов) должен уметь взаимодействовать с контроллером домена для проверки подлинности пользователей.

Выясним, не изменилось ли состояние учетной записи:

  1. Откроем оснастку «Службы» (services.msc) и найдем службу Агент сервера 1С:Предприятие (для управления консолью может пригодиться запуск консоли кластера серверов любых версий).
  2. Убедимся, что она запущена от имени доменного пользователя, а не от локальной системы (LocalSystem).
  3. Важный момент для современных систем: если используется Managed Service Account (MSA), пароль этой учетной записи может «протухнуть» (истечь). В этом случае служба может продолжать работать, но функции проверки подлинности в домене будут заблокированы. Рассмотрим вариант рестарта службы: если она не запускается или выдает ошибку авторизации — дело в пароле учетной записи в Active Directory.
  4. Проверим, не потерял ли сам сервер (железо/виртуальная машина) доверительные отношения с доменом. Попробуем зайти на сервер под доменной учеткой.

Шаг 2. Расхождение настроек в Конфигураторе и Предприятии

Рассмотрим ситуацию, когда настройки пользователя в информационной базе противоречат друг другу. Бывают случаи, когда в справочнике Пользователи в режиме «Предприятие» галочка аутентификации ОС стоит, а в Конфигураторе — нет (проверить надежность учетных записей можно через инструмент для анализа паролей).

Проанализируем настройки:

  1. Зайдем в Конфигуратор — Администрирование — Пользователи.
  2. Найдем проблемного пользователя и проверим вкладку Основные.
  3. Убедимся, что флаг Аутентификация операционной системы установлен, а в поле Пользователь указан корректный путь в формате DOMAIN\UserName.
  4. Попробуем перевыбрать пользователя из списка домена. Если список домена не открывается, значит, у сервера 1С нет связи с контроллером домена.

Шаг 3. Влияние режима отладки сервера

Выясним интересную особенность, подмеченную практикующими администраторами: иногда включение режима отладки (параметр -debug или -http в строке запуска службы) может блокировать корректную передачу токенов аутентификации. Проверим эту гипотезу: попробуем временно отключить отладку и перезапустить службу ragent. Если аутентификация «взлетела», значит, проблема в сетевых ожиданиях или конфликте портов отладчика.

Шаг 4. Настройка SPN (Service Principal Name) и Kerberos

Теперь перейдем к более глубоким настройкам сетевой безопасности. Windows-аутентификация в 1С чаще всего опирается на протокол Kerberos. Если Kerberos не может построить цепочку доверия, система откатывается к NTLM, который может быть запрещен политиками безопасности.

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

  1. Проверим наличие дубликатов SPN, которые могут возникать после переименования серверов или переноса служб: 
    
setspn -X
  2. Если служба 1С работает от имени domain_user, зарегистрируем SPN вручную: 
    
setspn -A STS/ServerName:1540 domain_user
setspn -A STS/ServerName.domain.com:1540 domain_user

Шаг 5. Проблема «Двойного прыжка» (Double Hop)

Если сервер 1С и SQL-сервер разнесены на разные машины, мы сталкиваемся с проблемой передачи полномочий пользователя от одного сервера другому. Рассмотрим, как это работает: пользователь авторизуется на сервере 1С, и сервер 1С должен от имени этого пользователя «постучаться» в SQL Server.

Для решения этой задачи необходимо настроить Делегирование в Active Directory:

  1. Откроем оснастку Active Directory Users and Computers.
  2. Найдем учетную запись, под которой запущен сервер 1С.
  3. В свойствах перейдем на вкладку Delegation (Делегирование).
  4. Установим флаг Trust this user for delegation to any service (Kerberos only) или настроим ограниченное делегирование (Constrained Delegation) до службы MSSQLSvc на конкретном SQL-сервере.

Если делегирование не настроено, SQL Server увидит попытку входа как Anonymous Logon и отклонит её.

Шаг 6. Настройки сетевых протоколов SQL Server

Иногда проблема кроется не в 1С, а в самом SQL-сервере. Проанализируем настройки в SQL Server Configuration Manager:

  1. Проверим раздел SQL Server Network Configuration — Protocols for [InstanceName].
  2. Убедимся, что протокол TCP/IP включен.
  3. В свойствах TCP/IP проверим, что сервер слушает нужные IP-адреса и порт (по умолчанию 1433).
  4. Если используется динамический порт, убедимся, что служба SQL Browser запущена.

Посмотрим на состояние подключений с помощью SQL-запроса, чтобы понять, какой протокол используется в данный момент:


SELECT auth_scheme 
FROM sys.dm_exec_connections 
WHERE session_id = @@SPID;

Если результат NTLM, а вы настраивали KERBEROS, значит, настройки SPN или делегирования выполнены некорректно.

Шаг 7. Время и синхронизация

Не забудем про «классику» доменных сетей. Протокол Kerberos крайне чувствителен к расхождению времени между клиентом, сервером приложений и контроллером домена. Допустимая разница — не более 5 минут.

Проанализируем логи событий (Event Viewer) на сервере 1С и SQL. Ищем ошибки в разделе System от источника LsaSrv или Kerberos. Если видим ошибки о разности времени, выполним принудительную синхронизацию:


w32tm /resync

Шаг 8. Обновления Windows и шифрование AES

Если проблема появилась после планового обновления ОС, проанализируем настройки шифрования. В современных версиях Windows (начиная с обновлений конца 2022 года) по умолчанию может требоваться использование шифрования AES128/AES256 для Kerberos.

Проверим свойства учетной записи службы 1С в Active Directory: на вкладке Account убедимся, что установлены галочки:

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

Резюме

Мы рассмотрели основные причины, по которым может перестать работать аутентификация средствами ОС в 1С. Как показывает практика, чаще всего проблема скрывается в истечении пароля сервисной учетной записи, отсутствии прав на делегирование или неправильно настроенных SPN. Последовательно проверяя каждый из этих этапов, вы обязательно найдете «слабое звено» в вашей инфраструктуре.

← На главную