Как настроить доменную аутентификацию в 1С и почему не отображается список пользователей AD

Настройка сквозной аутентификации (Single Sign-On) в среде 1С:Предприятие — задача, с которой рано или поздно сталкивается любой системный администратор. Часто возникают ситуации, когда при попытке выбрать пользователя из домена Active Directory (AD) в конфигураторе, список оказывается пустым, либо выбранное имя в формате company.local\username отказывается работать, требуя изменения на короткое NetBIOS-имя. Рассмотрим подробно, почему так происходит и как привести систему к стабильной работе.

Разбор проблемы: NetBIOS против FQDN

В современных сетях Windows сосуществуют два типа имен домена: короткое NetBIOS-имя (например, COMPANY) и полное DNS-имя (FQDN, например, company.local). Когда мы открываем настройки пользователя в 1С и пытаемся сопоставить его с пользователем ОС, платформа обращается к системным диалогам Windows для выбора объектов Active Directory.

Проанализируем ситуацию: если при выборе company.local пользователи отображаются, а при выборе COMPANY — нет, это первый признак того, что механизмы разрешения имен или права доступа к контроллеру домена работают некорректно. Основная проблема заключается в том, что 1С по умолчанию ожидает формат \\ИМЯ_ДОМЕНА\логин. Если система подставляет \\company.local\username, аутентификация может не проходить из-за того, что сервер 1С пытается использовать протокол Kerberos, который требует строго настроенных имен служб (SPN), в то время как короткое имя принудительно инициирует проверку через NTLM.

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

Выясним главную причину «пустых списков». По умолчанию агент сервера 1С (ragent) часто устанавливается под локальной системной учетной записью (LocalSystem) или специально созданной локальной учеткой (usr1cv8).

Важный момент: локальная учетная запись сервера не имеет прав на чтение данных из Active Directory. Когда вы запускаете конфигуратор со своего рабочего места под доменным логином, список пользователей подтягивается вашими правами. Однако сам процесс авторизации и финальная проверка прав при входе в базу выполняются на стороне сервера. Для корректной работы выполним следующие шаги:

1. Создадим в домене специального пользователя, например, domain\s-1c-service.
2. Включим его в группу Domain Users (Пользователи домена). Особых административных прав этой учетке не требуется, достаточно прав на чтение свойств объектов пользователей.
3. На сервере, где установлен «1С:Предприятие», зайдем в оснастку «Службы» (services.msc).
4. Найдем службу Агент сервера 1С:Предприятия, перейдем на вкладку «Вход в систему» и укажем нашу доменную учетную запись.
5. Перезапустим службу. Внимание: не забудьте дать этой учетной записи полные права на папки с данными сервера 1С (обычно это C:\Program Files\1cv8\srvinfo).

Почему формат .local не работает для входа

Проанализируем ситуацию, когда запись вида \\company.local\username приводит к ошибке авторизации. Это происходит из-за особенностей работы протокола аутентификации. Платформа 1С в связке с Windows Server 2012/2016 и выше предпочитает стандарт Domain\User.

Если в окне выбора пользователя вы видите формат sAMAccountName (просто логин), а 1С дописывает суффикс .local, попробуйте следующее решение: при сопоставлении пользователя в поле «Пользователь Windows» вручную вводите путь, используя именно NetBIOS-имя (короткое). Это гарантирует, что система авторизации однозначно идентифицирует домен через контроллер домена без лишних DNS-запросов.

Ограничение в 100 пользователей в новых версиях Windows Server

Разберем еще одну «фичу», которая часто пугает администраторов после миграции на Windows Server 2016 и выше. При открытии списка выбора пользователей AD справа отображаются только первые 100 записей.

Это не ошибка 1С, а поведение стандартного компонента Windows IDsObjectPicker. Чтобы найти нужного пользователя, если его нет в первой сотне:

• Используйте поле поиска в диалоговом окне выбора.
• Введите первые буквы фамилии или логина и нажмите «Проверить имена».
• Система автоматически подтянет нужного человека из базы AD, даже если он скрыт из общего списка «топ-100».

Диагностика механизма аутентификации

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

• TCP/UDP 389 — протокол LDAP.
• TCP 3268 — Глобальный каталог (Global Catalog), если в лесу несколько доменов.
• TCP/UDP 88 — Kerberos (необходим для тикетов).
• TCP/UDP 445, 135-139 — службы RPC и SMB для работы с именами NetBIOS.

Рассмотрим пример настройки через конфигурационный файл, если вы используете веб-сервер. При публикации базы на IIS важно убедиться, что в файле web.config включена Windows-аутентификация:

<system.webServer>
    <security>
        <authentication>
            <windowsAuthentication enabled="true" />
            <anonymousAuthentication enabled="false" />
        </authentication>
    </security>
</system.webServer>

Итоги и рекомендации

Подводя итог, можно сказать, что «правильная» доменная авторизация в 1С строится на трех столпах:

1. Служба сервера 1С работает от доменного пользователя. Это снимает все вопросы с получением списка пользователей из Active Directory.
2. Использование NetBIOS-имен. Запись \\COMPANY\username является максимально совместимой и надежной.
3. Наличие прав на чтение AD у компьютерной учетной записи сервера. Если вы все же решили оставить LocalSystem, убедитесь, что в AD объект «Компьютер» (ваш сервер) имеет права на чтение учетных записей пользователей.

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