Как работает доменная авторизация в 1С

Доменная авторизация в 1С — это механизм, при котором пользователь входит в информационную базу без ввода логина и пароля: платформа 1С доверяет тому факту, что человек уже прошёл проверку подлинности в домене Active Directory при входе в Windows. В терминах 1С этот режим называется «аутентификация операционной системы», а в инфраструктуре Microsoft — Windows-аутентификация или Integrated Security.

Смысл механизма прост: вместо хранения паролей в самой базе 1С используется билет Kerberos (или протокол NTLM как запасной вариант), который выдала система при входе пользователя на компьютер. Платформа 1С получает от операционной системы имя учётной записи в формате ДОМЕН\Пользователь, ищет в списке пользователей информационной базы запись с таким сопоставлением и, если находит, открывает сеанс под этим пользователем.

Такой подход снимает сразу несколько проблем: сотрудники не запоминают отдельный пароль для 1С, администратор управляет доступом централизованно через группы Active Directory, а при увольнении сотрудника достаточно отключить его доменную учётную запись — доступ в 1С закроется автоматически. Ниже разберём, как механизм устроен технически, как его настроить в файловом и клиент-серверном вариантах и где чаще всего возникают ошибки.

Как устроен механизм доменной авторизации

Когда пользователь запускает тонкий или толстый клиент 1С и выбирает базу с доменной авторизацией, платформа не показывает окно ввода логина и пароля. Вместо этого клиент через системные вызовы Windows получает маркер доступа текущего пользователя. Если база клиент-серверная, в процесс включается сервер 1С:Предприятия, который сам проверяет подлинность через ОС сервера или передаёт проверку на уровень СУБД.

Основной протокол — Kerberos: контроллер домена выдаёт пользователю билет при входе в систему, и этот билет предъявляется службам, которым доверяет домен. Если Kerberos недоступен (например, обращение идёт по IP-адресу вместо имени сервера), Windows может переключиться на NTLM — это рабочий, но менее безопасный и более медленный вариант, который к тому же не поддерживает делегирование.

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

Что потребуется перед настройкой

Минимальное условие — компьютеры пользователей и серверы должны входить в один домен Active Directory или в домены с настроенными доверительными отношениями. Рабочая группа без домена не подходит: Windows-аутентификация между машинами без общего центра проверки подлинности в 1С полноценно не работает.

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

Также проверьте, что пользователи обращаются к серверу по имени, а не по IP-адресу, и что на клиентских машинах корректно работает разрешение имён DNS. Эти мелочи — причина большинства случаев, когда «домен есть, а авторизация не проходит».

Настройка сопоставления пользователей в конфигураторе

Сопоставление доменной учётной записи с пользователем 1С выполняется в конфигураторе: раздел «Администрирование» → «Пользователи». В карточке пользователя или при создании нового нужно установить флажок «Аутентификация операционной системы» и указать учётную запись в формате \\ДОМЕН\ИмяПользователя. Удобнее использовать кнопку выбора — платформа сама найдёт учётную запись через диалог выбора пользователей Windows и подставит имя в правильном виде.

Флажки «Аутентификация 1С:Предприятия» и «Аутентификация операционной системы» можно включать одновременно. Тогда пользователь сможет входить обоими способами: автоматически через домен на своём рабочем компьютере и по логину с паролем, например, при подключении с недоменного устройства. Это удобно как запасной вариант на период миграции.

Если нужно, чтобы вход выполнялся строго доменным способом, снимите флажок аутентификации 1С и очистите пароль. Но перед массовым отключением парольного входа убедитесь, что хотя бы у одного администратора сохраняется альтернативный способ входа, иначе при сбое домена можно потерять управление базой.

1. 1
   Откройте конфигуратор под учётной записью администратора
2. 2
   Перейдите: Администрирование → Пользователи
3. 3
   Создайте пользователя или откройте существующего
4. 4
   Установите флажок «Аутентификация операционной системы»
5. 5
   Через кнопку выбора укажите доменную учётную запись
6. 6
   Назначьте роли и сохраните изменения
7. 7
   Попросите пользователя запустить базу — вход должен произойти без запроса пароля

Особенности файлового и клиент-серверного вариантов

Файловая база

В файловом варианте всё просто: клиент 1С получает имя учётной записи от локальной ОС и ищет сопоставление в списке пользователей базы. Промежуточных звеньев нет, поэтому доменная авторизация работает, даже если сам файл базы лежит на сетевом ресурсе. Главное — чтобы компьютер пользователя был в домене и вход в Windows выполнялся под доменной учётной записью.

Клиент-серверный вариант

В клиент-серверной архитектуре добавляется звено — сервер 1С:Предприятия. Клиент передаёт серверу данные для Windows-аутентификации, и сервер проверяет их через ОС. Здесь критично, под какой учётной записью работает служба агента сервера: если она локальная и не имеет доступа к домену, проверка может завершаться ошибкой. Часто службу запускают под специально созданной доменной учётной записью с минимально необходимыми правами.

Отдельный случай — когда Windows-аутентификация используется ещё и на уровне SQL Server. Тогда сервер 1С подключается к СУБД под учётной записью своей службы, и именно ей должны быть выданы права на базу данных. Это не то же самое, что доменная авторизация пользователей в 1С: проверка пользователя и подключение к СУБД — два независимых процесса, и путать их не стоит.

Сравнение вариантов

Файловая база

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

Клиент-серверная база

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

Веб-клиент через IIS/Apache

Требует включения Windows-аутентификации на веб-сервере и настройки делегирования; самый сложный в настройке вариант

Доменная авторизация через веб-клиент

При работе через браузер цепочка удлиняется: браузер должен передать данные Windows-аутентификации веб-серверу (IIS или Apache), а тот — серверу 1С. На IIS для этого включается проверка подлинности Windows в настройках виртуального каталога публикации, при этом анонимная проверка отключается. Браузер пользователя должен считать адрес сервера зоной местной интрасети, иначе он не станет автоматически передавать учётные данные и покажет окно ввода логина и пароля.

Если веб-сервер и сервер 1С находятся на разных машинах, возникает задача делегирования — передачи учётных данных пользователя дальше по цепочке. Для этого в Active Directory настраивается делегирование Kerberos для учётной записи службы веб-сервера. Без делегирования типичный симптом — браузер запрашивает логин и пароль, но даже правильные данные не пускают в базу.

Проверка результата и диагностика проблем

Признак корректной работы: пользователь запускает базу из списка и сразу попадает в интерфейс без окна ввода логина и пароля, а в журнале регистрации фиксируется событие входа под его именем. Если вместо этого появляется окно авторизации 1С — значит, платформа не смогла выполнить вход по учётной записи ОС и предлагает запасной вариант.

Типичные причины отказа: пользователь вошёл в Windows под локальной, а не доменной учётной записью; в карточке пользователя 1С указано имя в неверном формате (например, без домена или с устаревшим именем домена); клиент обращается к серверу по IP-адресу, из-за чего Kerberos не работает; служба сервера 1С запущена под учётной записью без доступа к домену. Диагностику стоит начинать с проверки, какое именно имя видит платформа: это видно в сообщении об ошибке «пользователь не найден» — там указывается имя, которое 1С пыталась сопоставить.

Контрольные точки

Как проверить результат

Вход в базу

Норма

База открывается без запроса пароля

Тревожный признак

Появляется окно ввода логина и пароля 1С

Журнал регистрации

Норма

Событие входа с именем нужного пользователя

Тревожный признак

Ошибки «Пользователь не найден» или отказ в аутентификации

Имя в ошибке

Норма

Формат ДОМЕН\Пользователь совпадает с карточкой в конфигураторе

Тревожный признак

Локальное имя компьютера вместо доменного

Обращение к серверу

Норма

В списке баз указано имя сервера

Тревожный признак

Указан IP-адрес — Kerberos не сработает

Типичные ошибки и ограничения

Самая распространённая ошибка — переименование пользователя или перенос его в другой домен без обновления сопоставления в 1С. Сопоставление хранится по имени, и после смены логина в AD вход перестаёт работать, пока администратор не укажет новое имя в карточке пользователя. Вторая частая ситуация — несколько баз на одном сервере, где в одной сопоставление настроено, а в другой забыли: пользователь считает, что доменная авторизация «сломалась», хотя в конкретной базе его просто нет.

Важное ограничение: доменная авторизация управляет только входом, но не правами. Роли по-прежнему назначаются внутри 1С индивидуально или через профили групп доступа. Синхронизации «вошёл в группу AD — получил роль в 1С» штатно нет, её при необходимости реализуют отдельными средствами или регламентными заданиями в конкретных конфигурациях.

Частые вопросы

Можно ли использовать доменную авторизацию без домена Active Directory?

Полноценно — нет. Механизм опирается на централизованную проверку подлинности Windows. В рабочей группе теоретически возможна аутентификация по локальным учётным записям на отдельном компьютере с файловой базой, но для клиент-серверной работы и нескольких пользователей это неприменимо.

Что будет, если контроллер домена недоступен?

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

Как массово создать пользователей 1С из домена?

В типовых конфигурациях на БСП есть обработки и механизмы загрузки пользователей, а в конфигураторе можно программно создавать пользователей через объект ПользовательИнформационнойБазы, заполняя свойство «ПользовательОС». Для больших компаний обычно пишут скрипт синхронизации с группой AD.

Почему браузер запрашивает пароль, хотя включена доменная авторизация?

Браузер передаёт учётные данные автоматически только для сайтов из зоны местной интрасети. Добавьте адрес сервера в эту зону через настройки браузера или групповую политику. Также проверьте, что на веб-сервере включена именно Windows-аутентификация, а анонимная отключена.

Безопаснее ли доменная авторизация, чем пароль 1С?

При корректной настройке — да: пароли не хранятся в базе 1С, действуют доменные политики сложности и блокировки, а доступ отзывается централизованно. Но безопасность зависит от доменной инфраструктуры: скомпрометированная учётная запись Windows автоматически даёт доступ и в 1С.

Нужно ли заново настраивать сопоставление после переустановки платформы?

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