Вход в 1С по учётной записи Windows: как связать базу с доменом

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

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

Как работает вход в 1С через домен Windows

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

Цепочка выглядит так:

1. 🖥️ Сотрудник входит в Windows под CORP\ivanov.
2. 🔑 Клиент 1С запрашивает у ОС подтверждение личности через механизм SSPI (на Windows) или Kerberos (на Linux).
3. 🗄️ Сервер 1С или сам клиент (в файловом варианте) получает имя \\CORP\ivanov.
4. 👤 Платформа ищет пользователя базы, у которого в поле «Пользователь» записано именно это имя.
5. ✅ Нашла — запускает сеанс с правами этого пользователя. Не нашла — показывает окно ввода логина и пароля 1С.

Отсюда важное следствие: если окно ввода пароля всё-таки появилось, сбой мог случиться на любом из пунктов. Сначала определите, на каком.

В клиент-серверном варианте проверку выполняет сервер 1С. Клиент передаёт ему билет Kerberos, а если Kerberos не сработал — пытается договориться через NTLM. На Windows-сервере в домене NTLM часто выручает незаметно. На Linux-сервере запасного варианта нет: без корректного Kerberos доменная авторизация не заработает.

Настройка доменной авторизации у пользователей базы 1С

Привязку можно сделать в Конфигураторе или в режиме 1С:Предприятие. В типовых конфигурациях на БСП (Бухгалтерия 3.0, ЗУП 3.1, УТ 11) работайте в пользовательском режиме: так карточка справочника «Пользователи» и пользователь базы останутся согласованными.

В типовой конфигурации

1. Откройте Администрирование → Настройки пользователей и прав → Пользователи.
2. Откройте карточку сотрудника.
3. Убедитесь, что вход в программу разрешён (флажок в верхней части карточки).
4. Включите флажок «Аутентификация операционной системы».
5. В поле пользователя ОС выберите учётную запись через кнопку выбора или впишите её вручную: \\CORP\ivanov.
6. Запишите карточку.

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

В Конфигураторе

Путь: Администрирование → Пользователи, затем откройте пользователя. На вкладке «Основные» те же два флажка и поле «Пользователь». Кнопка выбора открывает список учётных записей домена и локального компьютера.

Массовая привязка кодом

Когда пользователей сотни, руками долго. Для нетиповой базы или базы без БСП подойдёт обработка с таким кодом на сервере:

ПользовательИБ = ПользователиИнформационнойБазы.НайтиПоИмени("Иванов И.И.");
Если ПользовательИБ <> Неопределено Тогда
    ПользовательИБ.АутентификацияОС = Истина;
    ПользовательИБ.ПользовательОС = "\\CORP\ivanov";
    ПользовательИБ.Записать();
КонецЕсли;

Одну доменную учётную запись связывайте только с одним пользователем базы. Если человеку нужны две роли, например «бухгалтер» и «администратор», дайте ему одного пользователя с нужным набором ролей или второго пользователя с входом по паролю.

Сервер 1С и кластер: служебная учётная запись, SPN и keytab

В клиент-серверном варианте пользователь проверяется на стороне сервера 1С. Поэтому львиная доля проблем с доменным входом сидит именно тут.

Сервер 1С на Windows

При установке служба «Агент сервера 1С:Предприятия 8.3» по умолчанию создаётся под локальной учётной записью USR1CV8. Для доменной авторизации надёжнее запускать службу под доменной служебной учётной записью, например CORP\usr1cv8.

Порядок действий:

1. Создайте в Active Directory учётную запись для службы. Пароль без ограничения срока действия, вход только как служба.
2. Выдайте ей права на каталог кластера (по умолчанию C:\Program Files\1cv8\srvinfo) и на каталоги платформы.
3. В свойствах службы агента сервера на вкладке «Вход в систему» укажите эту учётную запись.
4. Зарегистрируйте SPN для Kerberos на эту учётную запись.

Команда регистрации SPN выполняется под учётной записью администратора домена:

setspn -S usr1cv8/srv1c.corp.local CORP\usr1cv8
setspn -S usr1cv8/srv1c CORP\usr1cv8

Проверить, что зарегистрировано, и найти дубликаты:

setspn -L CORP\usr1cv8
setspn -X

Дубликат SPN — тот же префикс и имя сервера на двух разных учётных записях — ломает Kerberos. Ключ -S в отличие от -A проверяет дубликаты перед добавлением, поэтому используйте его.

Сервер 1С на Linux

Здесь нужен полноценный Kerberos. Три обязательных условия:

• 🕒 Время на сервере синхронизировано с контроллером домена. Расхождение больше пяти минут Kerberos не прощает.
• 🌐 DNS: сервер разрешает имена контроллеров домена, а прямая и обратная записи сервера 1С совпадают.
• 📄 Keytab-файл с ключом для имени usr1cv8/srv1c.corp.local@CORP.LOCAL.

Keytab создают на контроллере домена командой ktpass и привязывают к служебной учётной записи:

ktpass -princ usr1cv8/srv1c.corp.local@CORP.LOCAL -mapuser CORP\usr1cv8 -pass * -crypto ALL -ptype KRB5_NT_PRINCIPAL -out usr1cv8.keytab

Файл копируют на сервер 1С. По умолчанию платформа ищет usr1cv8.keytab в каталоге установленной версии платформы. Владельцем файла должен быть пользователь usr1cv8, а права — только на чтение для него. Проверить ключ можно командой klist -k с путём к файлу.

Администраторы кластера

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

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

Когда база опубликована на веб-сервере, между пользователем и 1С появляется IIS. Он и должен подтвердить личность пользователя, а затем передать её модулю 1С.

Настройка IIS

1. Установите компонент роли «Проверка подлинности Windows» (в диспетчере сервера: веб-сервер → безопасность).
2. Опубликуйте базу из Конфигуратора: Администрирование → Публикация на веб-сервере. Конфигуратор нужно запускать от имени администратора.
3. В диспетчере IIS выберите опубликованное приложение и откройте «Проверка подлинности».
4. Включите «Проверка подлинности Windows».
5. Отключите «Анонимная проверка подлинности».
6. В поставщиках проверки подлинности Windows оставьте Negotiate первым и NTLM вторым.

Пул приложений для публикации 1С 8.3 должен разрешать 32-разрядные приложения, если установлен 32-разрядный модуль веб-расширения. Для 64-разрядной платформы этот флажок выключают. Несовпадение разрядности даёт ошибку 500 ещё до попытки авторизации.

Настройка браузера

IIS запросит учётные данные у браузера. Отдаст ли браузер их молча — решают его настройки:

• 🔷 Edge и Chrome на Windows используют параметры зоны «Местная интрасеть». Добавьте адрес веб-сервера в эту зону через групповую политику. Для Chrome дополнительно есть политика AuthServerAllowlist.
• 🦊 Firefox — параметр network.negotiate-auth.trusted-uris в about:config с адресом сервера.

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

На Apache под Linux та же задача решается модулем mod_auth_gssapi и keytab-файлом для имени HTTP/web.corp.local.

Права доступа и запуск: ключи /WA+ и /WA-

Доменная авторизация только отвечает на вопрос «кто вошёл». Что человек может делать в базе, по-прежнему определяют роли и профили групп доступа.

В типовых конфигурациях права раздают в Администрирование → Настройки пользователей и прав → Группы доступа. Сотрудника добавляют в группу, у группы есть профиль с набором ролей. Связь с доменом на это не влияет.

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

Как войти под другим пользователем

С включённой доменной авторизацией 1С пускает в базу молча, под тем, кто сидит за компьютером. Чтобы войти под другим именем, например администратору на компьютере бухгалтера, запустите 1С с ключом /WA-:

"C:\Program Files\1cv8\common\1cestart.exe" ENTERPRISE /WA-

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

В списке баз этот ключ можно прописать навсегда: в окне запуска выделите базу, нажмите «Изменить» и на последнем шаге впишите /WA- в поле дополнительных параметров запуска.

Ошибки доменной авторизации и как их устранить

Чаще всего пользователь видит окно ввода пароля вместо автоматического входа или сообщение Идентификация пользователя не выполнена. Подберите свой симптом:

Если не помогло

Проверьте сам механизм, без 1С. На компьютере пользователя выполните klist: в списке должны быть билеты Kerberos, в том числе на имя usr1cv8/srv1c.corp.local, если пользователь уже пытался подключиться. Пустой список или ошибка получения билета говорят о проблеме с доменом, а не с 1С.

Следующий шаг — технологический журнал на сервере 1С. Включите сбор событий по исключениям (EXCP) и посмотрите текст ошибки в момент неудачного входа. Технологический журнал заметно нагружает диск, поэтому включайте его на короткое время и не забудьте отключить.

Как запасной вариант на время разбирательства разрешите сотруднику вход по паролю 1С. Работа не остановится, а вы спокойно найдёте причину.

Безопасность доменного входа и правила эксплуатации

Доменная авторизация закрывает основную проблему парольного входа: пароли 1С, записанные на стикерах, и общие учётки «Бухгалтер1». Но у неё свои риски.

Что важно соблюдать:

• 🔒 Блокировка экрана. Кто сел за незаблокированный компьютер, тот вошёл в 1С с правами хозяина. Включите автоблокировку через групповую политику.
• 🚪 Увольнение. Отключение учётной записи в AD закрывает доменный вход. Но если у пользователя оставлен вход по паролю 1С, он по-прежнему может войти. Запрещайте вход в карточке пользователя 1С при увольнении.
• 👑 Администраторы. Для пользователя с полными правами оставьте вход по паролю 1С как запасной. При сбое домена иначе в базу не попадёт никто.
• 🧾 Служебная учётная запись службы 1С — без интерактивного входа и без прав администратора домена.
• 🖧 Общие компьютеры и терминальные серверы. На ферме RDP каждый работает в своей сессии под своей учётной записью — доменный вход работает корректно. Общая учётная запись Windows на несколько человек с доменной авторизацией 1С несовместима по смыслу: все войдут под одним пользователем базы.

Не связывайте одну доменную учётную запись с пользователем, у которого роль «Полные права», если этой учётной записью пользуются для повседневной работы. Любая программа, запущенная под ней, сможет подключиться к базе через COM-соединение с полными правами.

Раз в квартал полезно сверять список пользователей 1С с AD: отключённые в домене учётные записи не должны оставаться активными в базе.

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