Многие системные администраторы и пользователи 1С сталкиваются с тем, что доменная авторизация в 1С периодически дает сбои. Вместо автоматического входа, система неожиданно запрашивает логин и пароль, хотя все настройки, казалось бы, корректны. Это может проявляться выборочно: у одного пользователя авторизация проходит успешно, а у другого, работающего с той же базой, возникают проблемы. Давайте подробно разберем, почему возникают такие ситуации и какие шаги мы можем предпринять для устранения этой проблемы.
Основная причина таких сбоев часто кроется в некорректной работе или настройках компонентов, отвечающих за аутентификацию по протоколу Kerberos. В этот процесс вовлечены контроллеры домена Active Directory, DNS-серверы, серверы 1С, а иногда и веб-серверы (если 1С опубликована через IIS или Apache), а также сетевое оборудование и клиентские машины.
Сердцем доменной авторизации в 1С является протокол Kerberos. Он обеспечивает взаимную аутентификацию клиента и сервера, гарантируя, что обе стороны доверяют друг другу. Если в работе Kerberos возникают неполадки, это немедленно сказывается на возможности входа в 1С без запроса пароля.
Неправильно настроенные SPN (Service Principal Names): Одной из наиболее частых причин проблем являются некорректные или отсутствующие имена служб (SPN). SPN — это уникальный идентификатор службы в домене, необходимый для Kerberos-аутентификации. Если служба сервера 1С:Предприятия запускается под одной учетной записью, а ее SPN зарегистрировано на другую, или если SPN вовсе отсутствует, Kerberos-аутентификация не сможет быть выполнена корректно. Это может привести к ошибкам вроде KRB_AP_ERR_MODIFIED.
На форуме был случай, когда проблема решилась простой очисткой поля "Имя службы (SPN) сервера 1С:Предприятие:" в настройках параметров рабочего сервера 1С. Видимо, кто-то по ошибке указал там имя самого сервера, не ознакомившись с инструкцией "3.1.6.1.1. Создание имени службы сервера для Kerberos-аутентификации". Важно помнить, что если 1С опубликована через веб-сервер, могут потребоваться дополнительные настройки SPN для веб-сервера.
Для управления SPN мы используем утилиту setspn. Если вы хотите явно зарегистрировать SPN для сервисной учетной записи, под которой работает сервер 1С, или для веб-сервера, вы можете использовать команды следующего вида:
Для учетной записи сервера 1С:
setspn -s 1C/Server1C domain\ServiceAccount1C
setspn -s 1C/Server1C.domain.local domain\ServiceAccount1C
Для веб-сервера (если 1С опубликована через HTTP):
setspn -s HTTP/WebSiteName domain\ServiceAccountIIS
setspn -s HTTP/WebSiteName.domain.local domain\ServiceAccountIIS
Где Server1C - имя сервера 1С, WebSiteName - имя веб-сайта, domain\ServiceAccount1C и domain\ServiceAccountIIS - учетные записи, под которыми работают соответствующие службы.
Проблемы с контроллерами домена: Сбои, временная недоступность или некорректная работа контроллеров домена (Active Directory) напрямую препятствуют успешной аутентификации. Если клиент не может найти или связаться с контроллером домена, он не сможет получить билет Kerberos и авторизоваться. Мы можем проверить доступность контроллеров домена с помощью команды nltest /dsgetdc:<DomainName> /force /kdc, где <DomainName> – имя вашего домена.
Событие Event ID 37 (Kerberos-Key-Distribution-Center): На контроллерах домена в журналах событий Windows мы иногда можем обнаружить событие с Event ID 37. Это означает, что Центр распространения ключей (KDC) столкнулся с билетом, который не содержал необходимой информации об учетной записи пользователя при обработке запроса на другой билет. Эта проблема часто связана с обновлениями Microsoft, особенно после 2021 года, которые изменили процесс обработки Ticket PAC (Privilege Attribute Certificate). В таких случаях временным решением может быть перезагрузка клиентского компьютера или обновление контроллеров домена.
Kerberos Negative Caching: Операционные системы Windows могут временно кэшировать неудачные попытки Kerberos-аутентификации. Этот механизм призван снизить нагрузку на KDC, но он может создавать задержки, если причина сбоя уже устранена. Например, после исправления SPN или DNS, авторизация все еще может не работать некоторое время, пока не истечет срок кэша неудачных попыток. Изменение сетевых настроек или перезагрузка клиента может помочь обновить этот кэш.
Ограничение MaxTokenSize: Если пользователь является членом очень большого количества групп Active Directory, Kerberos-токен, выдаваемый ему, может превысить максимально допустимый размер (MaxTokenSize). Это приводит к сбоям аутентификации и может сопровождаться сообщениями о нехватке памяти. Значение MaxTokenSize по умолчанию для Windows Server 2012 и более поздних версий составляет 48000 байт. Мы можем изменить это значение в реестре Windows на контроллерах домена и клиентских машинах, если обнаружим, что пользователи состоят в слишком большом количестве групп.
Credential Guard: На форуме упоминалась проблема, связанная с Credential Guard. Этот компонент безопасности Windows предназначен для защиты учетных данных. В некоторых случаях он может влиять на работу Kerberos. Если у вас возникли подозрения на его влияние, рекомендуется обратиться в службу поддержки арендуемых машин или к специалисту по безопасности, чтобы проанализировать его конфигурацию и взаимодействие с Kerberos.
Важную роль в процессе доменной авторизации играют настройки самого сервера 1С и учетных записей пользователей и служб.
Учетная запись службы сервера 1С: Нам необходимо убедиться, что учетная запись, под которой запущена служба сервера 1С:Предприятия, обладает достаточными правами доступа в домене и ее пароль не истек. Служба 1С должна иметь возможность обращаться к Active Directory для проверки учетных данных пользователей. Если пароль истек или права недостаточны, сервер 1С не сможет корректно взаимодействовать с доменной инфраструктурой.
Сопоставление пользователей в 1С: Для успешной доменной авторизации важно, чтобы в настройках пользователей 1С была включена "Аутентификация операционной системой". Кроме того, имя пользователя в 1С должно в точности соответствовать имени его учетной записи в домене Windows, включая регистр. Если база 1С опубликована на веб-сервере, нам также необходимо включить "Аутентификацию операционной системы" в настройках публикации.
DNS-разрешение: Проблемы с разрешением имен DNS могут помешать серверу 1С или клиентскому компьютеру правильно определить расположение контроллеров домена или других сетевых ресурсов. Убедитесь, что все машины корректно разрешают имена друг друга и доменных контроллеров по DNS. Неправильные или устаревшие записи DNS могут серьезно нарушить процесс Kerberos-аутентификации.
Обновление NativeClient на SQL-сервере: В одном из сообщений упоминалось, что обновление NativeClient на SQL-сервере помогло решить аналогичную проблему. Это может быть связано с улучшением взаимодействия между сервером 1С, SQL-сервером и Active Directory через обновленные драйверы.
Сетевая инфраструктура играет критическую роль. Любые помехи на пути обмена данными между клиентом, сервером 1С и контроллером домена могут привести к сбоям.
Брандмауэры и прокси: Программы фильтрации трафика, такие как брандмауэры (файрволлы), антивирусы или прокси-серверы, могут блокировать порты, необходимые для работы Kerberos (например, порт 88 TCP/UDP) или LDAP (389 TCP/UDP), а также препятствовать проверке отзыва сертификатов, если вы используете защищенные соединения (SSL/TLS). Нам следует тщательно проверить настройки всех сетевых экранов, чтобы убедиться, что трафик разрешен на всех необходимых портах между клиентскими машинами, контроллерами домена и целевым сервером 1С.
Проблема с WinRM (ошибка 8344): На форуме также упоминалась ошибка "Службе WinRM не удалось создать следующие имена участников-служб. Была получена ошибка "8344"". Эта ошибка часто указывает на проблемы с регистрацией SPN для службы WinRM, что является частью более широкой проблемы с Kerberos. Даже если она напрямую не связана с 1С, она сигнализирует о фундаментальных проблемах в конфигурации Kerberos в домене.
Сбои оборудования, сети или виртуализации: Обрывы сетевых соединений, проблемы с маршрутизацией, потеря сетевых пакетов, а также конфликты или перегрузки на уровне виртуализации (если серверы 1С размещены на виртуальных машинах) могут вызывать нестабильную работу 1С и периодические сбои авторизации. Нам нужно убедиться в стабильности работы всей сетевой инфраструктуры.
Для эффективного устранения проблемы нам потребуется использовать ряд диагностических инструментов:
Технологический журнал 1С: Включение технологического журнала 1С с записью событий CONN (соединения) и EXCP (исключения) является одним из первых шагов — для этого пригодится инструмент анализа технологического журнала и серверных показателей. Он может показать, как 1С получает имя пользователя операционной системы при неудачной аутентификации, и дать подсказки о характере ошибки.
Для настройки технологического журнала мы обычно создаем файл logcfg.xml (или изменяем существующий) в папке с bin-файлами сервера 1С или клиента, указывая в нем необходимые события:
<log>
<event>
<id>CONN</id>
<level>5</level>
</event>
<event>
<id>EXCP</id>
<level>5</level>
</event>
<dump type="none"/>
</log>
Журнал CAPI2 Windows: Если вы используете защищенные соединения (SSL/TLS) и есть подозрения на проблемы с сертификатами, включение журнала CAPI2 в Просмотре событий Windows может помочь диагностировать ошибки проверки отзыва сертификатов.
Инструменты Kerberos: Для диагностики проблем Kerberos-аутентификации нам могут пригодиться следующие утилиты:
klist: Позволяет просмотреть список Kerberos-билетов, кэшированных на текущей машине. Помогает понять, был ли получен билет Kerberos и какой.nltest: Используется для тестирования защищенных каналов между клиентом и контроллером домена, а также для получения информации о контроллерах домена. Мы уже упоминали команду nltest /dsgetdc:<DomainName> /force /kdc для проверки доступности КД.setspn: Утилита для управления Service Principal Names (SPN), о которой мы говорили ранее.Пока мы ищем и устраняем первопричину, существуют временные меры, которые могут помочь восстановить работоспособность доменной авторизации:
Команда gpupdate /force: Эта команда принудительно обновляет групповые политики на клиентской машине. В некоторых случаях это помогает, так как Kerberos-политики и кэши могут быть обновлены. На форуме было отмечено, что это помогает, но проблема может возобновиться через несколько дней. Мы можем попробовать добавить эту команду в автозапуск или выполнять ее по расписанию, как это делали некоторые пользователи.
Перезапуск сервера 1С: Перезапуск службы сервера 1С:Предприятия может временно решить проблему, так как при этом очищаются кэши, переинициализируются соединения и службы. Некоторые пользователи настраивают ежедневный перезапуск сервера 1С в нерабочее время (например, в 4 часа ночи) как временное решение.
Очистка кэша пользователя 1С: В некоторых случаях, если проблема связана с поврежденными данными кэша на стороне клиента, очистка кэша пользователя 1С может помочь. Кэш обычно находится по пути, схожему с %APPDATA%\1C\1CE\.... Удаление соответствующей папки базы данных может быть полезно, но это не является системным решением.
Проверка обновлений контроллеров домена: В одном из сообщений упоминалась тема 2022 года и eventid 37, что косвенно указывает на возможные проблемы после установки обновлений безопасности Microsoft. Нам следует проверить, какие обновления были установлены на контроллерах домена незадолго до возникновения проблемы, и искать информацию о возможных известных проблемах с Kerberos, связанных с этими обновлениями.
Проблема периодической неработоспособности доменной авторизации в 1С является комплексной и требует систематического подхода к диагностике. Нам предстоит последовательно исключать возможные причины, начиная с настроек Kerberos (SPN, Event ID 37), проверяя учетные записи служб 1С, сетевые настройки и, при необходимости, используя временные обходные пути. Помните, что платформа 1С редко является первопричиной таких сбоев, чаще всего корень проблемы лежит в инфраструктуре домена и сети.