← На главную

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

Разберем детально, почему это происходит в рабочей группе (Workgroup) при отсутствии контроллера домена Active Directory, как функционирует механизм сквозной проверки подлинности и какие шаги необходимо предпринять для устранения проблемы.

Принцип работы Windows-аутентификации в архитектуре клиент-сервер

Проанализируем базовый механизм авторизации. В клиент-серверном варианте работы 1С:Предприятия проверку подлинности осуществляет служба кластера серверов 1С (процесс ragent / rphost). Клиентское приложение передает учетные данные пользователя вызывающей операционной системы серверу.

Рассмотрим, как распределяются роли при аутентификации в зависимости от топологии сети:

1. В доменной сети Active Directory: Компьютер пользователя и сервер 1С доверяют единому центру аутентификации (контроллеру домена). Клиент передает серверу билет Kerberos или NTLM-токен, сервер валидирует его в домене, определяет уникальный SID пользователя и сопоставляет с учетной записью в базе 1С.
2. В рабочей группе (без домена): Централизованной базы учетных записей нет. Компьютер-клиент проверяет пользователя по своей локальной базе SAM (Security Account Manager), а сервер 1С обращается к своей локальной базе SAM. Сервер ничего не знает о локальных учетных записях клиентского компьютера, поэтому отклоняет попытку автоматического сопоставления.

Способ 1. Создание зеркальных учетных записей на клиенте и сервере

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

Разберем по шагам порядок настройки:

1. Создание пользователей: Создадим на сервере 1С локальную учетную запись Windows, имя которой в точности совпадает с именем пользователя на рабочей станции клиента (например, Иванов).
2. Синхронизация паролей: Зададим для созданной учетной записи на сервере 1С точно такой же пароль, как и на клиентском компьютере. Пароль обязательно должен быть непустым, так как политики безопасности Windows по умолчанию блокируют сетевую аутентификацию для учетных записей с пустым паролем.
3. Привязка в конфигураторе 1С: В свойствах пользователя 1С (в окне «Пользователи») включим флаг «Аутентификация операционной системы» и укажем путь к учетной записи сервера. Формат записи должен иметь вид ИмяСервера1С\ИмяПользователя, а не имя клиентской рабочей станции.

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

Способ 2. Корректировка локальных политик безопасности Windows

Посмотрим на настройки операционной системы, которые могут препятствовать нормальной работе NTLM-авторизации в рабочей группе. Даже при наличии зеркальных пользователей вход может блокироваться из-за гостевого режима доступа.

Разберем необходимые параметры оснастки secpol.msc (Локальная политика безопасности):

1. Перейдем в раздел «Параметры безопасности» -> «Локальные политики» -> «Параметры безопасности».
2. Найдем политику «Сетевой доступ: модель общего доступа и безопасности для локальных учетных записей» (Sharing and security model for local accounts).
3. Установим значение в режим «Обычная — локальные пользователи удостоверяются как они сами» (Classic). Если оставить значение «Гостевая» (Guest only), все входящие сетевые подключения будут транслироваться в гостевую запись, что делает невозможной идентификацию конкретного пользователя в 1С.
4. Проверим параметр «Сетевая безопасность: уровень проверки подлинности LAN Manager» (LmCompatibilityLevel). На клиенте и сервере должны быть выставлены совместимые параметры (рекомендуется «Отправлять только NTLMv2-ответы»).

Способ 3. Использование ключей командной строки

Проанализируем параметры запуска платформы. Если у пользователя настроено несколько вариантов входа, или платформа не пытается инициировать запрос к ОС, полезно явно задать параметры в строке запуска информационных баз.

Для управления аутентификацией используются следующие ключи:

1. /WA+ — принудительно задействовать аутентификацию операционной системы при старте сеанса.
2. /WA- — запретить автоматическую аутентификацию ОС и сразу открыть стандартное окно авторизации 1С:Предприятия.

Способ 4. Публикация базы через веб-сервер (IIS или Apache)

Рассмотрим альтернативное архитектурное решение, позволяющее избежать сложностей с сопоставлением локальных баз SAM при работе с тонким клиентом или браузером.

Если база 1С публикуется на веб-сервере Microsoft IIS:

1. На веб-сервере активируется модуль «Проверка подлинности Windows» (Windows Authentication) и отключается «Анонимная проверка подлинности».
2. Клиент обращается к публикации по протоколу HTTP/HTTPS. Веб-сервер берет на себя процесс согласования учетных данных через Negotiate/NTLM и передает подтвержденную личность пользователя процессу 1С.

Аутентификация при программных подключениях (COM и Web-сервисы)

Разберем особенности работы внешних механизмов интеграции:

1. Подключение через COM-соединение: Объект COMConnector при вызове метода Connect() без параметров логина и пароля (Usr и Pwd) пытается выполнить вход с учетными данными того процесса ОС, в контексте которого был запущен COM-объект.
2. Вызов Web/HTTP-сервисов: Аутентификация вызывающей стороны настраивается на уровне заголовков HTTP-запроса (Authorization: Basic или Negotiate) либо определяется настройками пула приложений веб-сервера.