Проблема со сбоями сквозной аутентификации операционной системы (OS Authentication / Active Directory) в 1С:Предприятии — особенно на старых версиях платформ вроде 8.3.9 или 8.3.15 в клиент-серверном варианте — встречается довольно часто. Она имеет глубокие технические корни, выходящие далеко за рамки банального очищения локального кэша платформы. В этой статье мы подробно разберем, почему возникает данная неполадка, как провести ее комплексную диагностику и какие шаги необходимо предпринять для ее окончательного устранения.
Начнем с проверки базовых настроек сопоставления пользователя в Конфигураторе. Откроем список пользователей информационной базы, найдем целевую учетную запись и перейдем на вкладку «Администрирование». Нам необходимо удостовериться, что флаг «Аутентификация операционной системы» активен, а в поле выбора пользователя правильно прописан доменный аккаунт. Для автоматизации этого процесса и исключения ручных ошибок при сопоставлении можно использовать обработку для синхронизации пользователей базы 1С с Active Directory.
Рассмотрим важную деталь, упомянутую участниками обсуждения: регистр символов и формат доменного имени. Строковое сравнение имен пользователей в 1С выполняется чрезвычайно жестко. Малейшее несовпадение регистра (например, использование строчных букв вместо заглавных) или формата домена приведет к тому, что платформа проигнорирует сквозной вход и выдаст стандартное диалоговое окно авторизации 1С. Выясним разницу между двумя основными форматами записи доменного имени:
DOMAIN\username (где DOMAIN — это краткое имя вашего домена, обычно пишется заглавными буквами).domain.local\username (часто пишется строчными буквами).Проанализируем поведение системы при настройке. При выборе пользователя из списка Active Directory в Конфигураторе система обращается к контроллеру домена. Если в этот момент ошибок не возникает, значит, связь с AD стабильна. Попробуйте вручную переписать имя пользователя в разных регистрах или переключить формат записи с NetBIOS на FQDN, чтобы исключить строковое несовпадение.
Чтобы исключить влияние интерфейсных настроек и кэша стартера 1С, протестируем запуск системы в принудительном режиме сквозной авторизации. Для этого запустим базу из командной строки или добавим в свойства подключения в окне запуска специальный параметр.
Добавим в поле «Дополнительные параметры запуска» следующий ключ:
/WA+
Разберем, как работает этот параметр. Ключ /WA+ жестко предписывает платформе использовать аутентификацию операционной системы, полностью блокируя вывод стандартного окна ввода пароля 1С. Если после добавления этого ключа база запускается без вопросов — проблема решена. Если же система выдает ошибку доступа, это подтверждает, что контекст безопасности Windows передается на сервер приложений 1С некорректно, либо учетная запись не сопоставлена должным образом на стороне сервера.
Когда визуальная проверка в Конфигураторе не дает результатов, необходимо точно узнать, в каком именно виде операционная система передает имя пользователя на сервер приложений 1С. Для этого настроим сбор Технологического журнала (ТЖ) на сервере приложений 1С. Чтобы упростить последующий анализ логов, можно задействовать инструмент для парсинга и удобного разбора технологического журнала.
Создадим или отредактируем файл конфигурации logcfg.xml, расположенный в каталоге настроек сервера 1С (обычно это C:\Program Files\1cv8\conf\). Нам потребуется отслеживать события подключения CONN и исключений EXCP. Пример настройки файла конфигурации:
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\v8logs" history="24">
<event>
<eq property="Name" value="CONN"/>
</event>
<event>
<eq property="Name" value="EXCP"/>
</event>
<property name="all"/>
</log>
</config>
После настройки ТЖ перезапустим попытку входа под доменным пользователем. Откроем сформированные лог-файлы в каталоге C:\v8logs и найдем событие CONN, соответствующее моменту входа. Обратим особое внимание на свойство DstUserName2. Значение этого свойства показывает реальное имя пользователя, переданное операционной системой. Скопируем это значение «символ в символ» и пропишем его в свойствах пользователя в Конфигураторе 1С.
В клиент-серверном варианте работы сквозная аутентификация опирается на протоколы безопасности Kerberos или NTLM. Если служба сервера приложений 1С (ragent) запущена от имени доменной учетной записи (а не от имени локальной системы LocalSystem), для корректной работы Kerberos администратору домена необходимо вручную зарегистрировать имена участников службы — SPN (Service Principal Name).
Если SPN не настроен, протокол Kerberos дает сбой. 1С пытается переключиться на резервный протокол NTLM, но если в доменных политиках безопасности вашей организации использование NTLM ограничено или полностью отключено, аутентификация Windows завершится ошибкой.
Решить эту проблему может администратор домена с помощью утилиты командной строки setspn. Рассмотрим пример регистрации SPN для службы сервера 1С:
setspn -A MSSQLSvc/server1c.domain.local:1541 domain\usr-1cserver
setspn -A HOST/server1c domain\usr-1cserver
setspn -A HOST/server1c.domain.local domain\usr-1cserver
Здесь server1c.domain.local — это имя вашего сервера приложений 1С, а domain\usr-1cserver — доменная учетная запись, от имени которой запущена служба сервера 1С. После регистрации SPN выполним перезапуск службы сервера 1С и проверим работоспособность сквозного входа.
Проанализируем техническую деталь, упомянутую автором вопроса: проблема часто возникает на старых версиях платформы (например, 8.3.9 или 8.3.15). Старые релизы платформы 1С осуществляют запросы к службе каталогов Active Directory по протоколам, которые со временем претерпели изменения в целях безопасности Windows Server.
При переносе доменных ролей или обновлении контроллеров домена до версий Windows Server 2016/2019/2022 старые версии платформы 1С теряют возможность корректно опрашивать домен по протоколу LDAP. Это приводит к тому, что в Конфигураторе список пользователей AD может выглядеть пустым, а механизм SSPI перестает распознавать авторизованных пользователей. В данном случае единственным надежным решением является обновление платформы 1С:Предприятие на сервере приложений до актуальных поддерживаемых версий.
Выясним еще одну неочевидную причину сбоя сквозной аутентификации, кроющуюся в механизме запуска клиентского приложения 1С. В файле списка баз пользователей (ibases.v8i) по умолчанию для параметров запуска баз используется автоматический выбор клиента:
App=Auto
При таком сценарии стартер 1С сначала запускает Тонкий клиент, после чего система может переопределить тип приложения и инициировать повторный запуск Толстого клиента (или наоборот). При такой двойной инициализации контекст безопасности SSPI (Security Support Provider Interface) операционной системы может теряться или передаваться некорректно.
Чтобы решить эту проблему, в настройках запуска конкретной информационной базы жестко укажем тип используемого клиента (например, только «Тонкий клиент») вместо автоматического выбора. В файле настроек это выглядит следующим образом:
App=ThinClient
Если ваши конфигурации (особенно ЗУП/ЗиК) опубликованы на веб-сервере для работы через браузер или тонкий клиент по HTTP/HTTPS, в настройках публикации (файл default.vrd) или параметрах базы может быть задействована аутентификация по протоколам OpenID или OpenID Connect. Эти современные веб-стандарты авторизации могут перехватывать приоритет у классической Windows-аутентификации.
Чтобы диагностировать данный конфликт, попробуем отключить OpenID-идентификацию для сеанса пользователя, добавив в строку запуска базы специальный запускной ключ:
/OIDA-
Если после этого сквозной вход под доменной учетной записью успешно восстановился, следует пересмотреть параметры публикации на веб-сервере IIS или Apache и перенастроить приоритеты методов авторизации.
В современных операционных системах Windows 10/11 пользователи часто авторизуются под глобальными учетными записями Microsoft (например, вида username@outlook.com) или учетными записями Azure AD (Entra ID). Важно понимать, что классическая сквозная аутентификация в 1С (SSPI) разработана для работы в локальном домене Active Directory (on-premises).
Если рабочая станция пользователя авторизована через облачную учетную запись Microsoft, а сервер 1С находится в локальной рабочей группе или локальном домене, сквозной бесшовный вход работать не будет. В этом случае необходимо либо перевести рабочую станцию в локальный домен, либо использовать классическую авторизацию 1С с вводом логина и пароля.
Подводя итоги, отметим, что стабильная работа сквозной аутентификации в 1С требует комплексного подхода: от проверки точного написания имени домена до глубокой настройки сетевых протоколов Kerberos и регулярного обновления платформы 1С. Последовательное выполнение описанных шагов позволит вам выявить слабое место в инфраструктуре и настроить бесшовный и безопасный вход для ваших пользователей.