Где в 1С хранится настройка «Вход в программу разрешен»

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

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

Где хранится основной признак доступа: список пользователей информационной базы

Базовый уровень — это список пользователей информационной базы, который платформа ведет независимо от конфигурации. Открыть его можно двумя путями: через конфигуратор (меню «Администрирование» → «Пользователи») или в режиме предприятия в типовых конфигурациях (раздел «Администрирование» → «Пользователи» или «Пользователи и права»). Физически этот список хранится внутри самой базы: в файловом варианте — в файле 1Cv8.1CD, в клиент-серверном — в служебных таблицах базы данных на СУБД.

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

Важно понимать разницу: пользователь информационной базы (объект платформы) и элемент справочника «Пользователи» в конфигурации — это связанные, но разные сущности. В типовых решениях при создании пользователя в справочнике платформа автоматически создает запись и в списке пользователей ИБ, но при ручных манипуляциях в конфигураторе связь может нарушиться, и тогда вход либо невозможен, либо создается «лишний» пользователь.

Настройка входа в типовых конфигурациях: справочник «Пользователи» и группы доступа

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

На практике это выглядит так: пользователь может существовать в базе, аутентификация включена, но если он не входит ни в одну группу доступа или все его группы отключены, после входа он получит пустой интерфейс или сообщение о недостаточности прав. Поэтому при диагностике «не пускает в программу» проверяйте цепочку целиком: пользователь ИБ → элемент справочника «Пользователи» → группы доступа → профиль → роли.

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

Блокировка входа всех пользователей: где она включается и где хранится

Отдельный сценарий — ситуация, когда в базу не может войти никто, а при попытке входа выводится сообщение вроде «Вход в программу временно невозможен» или «Работа пользователей заблокирована». Это результат установки блокировки соединений с информационной базой, которую администраторы включают перед обновлением или регламентными операциями.

В клиент-серверном варианте блокировка хранится в свойствах информационной базы в консоли кластера серверов 1С: откройте консоль управления сервером, найдите нужную базу, откройте ее свойства — там параметры «Блокировка начала сеансов включена», время начала и окончания, сообщение для пользователей и код разрешения. В файловом варианте аналогичная функция доступна из режима предприятия: «Администрирование» → «Обслуживание» → «Блокировка работы пользователей» (в типовых конфигурациях), параметры сохраняются в служебных настройках базы.

1. 1
   Определите режим работы базы: файловая или клиент-серверная (посмотрите строку подключения в списке баз).
2. 2
   Для клиент-серверной базы откройте консоль кластера, свойства информационной базы и проверьте флаг блокировки начала сеансов.
3. 3
   Для файловой базы войдите под пользователем с правами администратора и откройте «Администрирование» → «Обслуживание» → «Блокировка работы пользователей».
4. 4
   Снимите блокировку или дождитесь времени окончания, указанного в параметрах.
5. 5
   Если задан код разрешения, пользователи могут войти, указав его в параметре запуска /UC или в строке подключения.
6. 6
   Проверьте результат: войдите под обычным пользователем без кода разрешения.

Если блокировка установлена с кодом разрешения, администратор может войти, добавив параметр запуска. Для тонкого клиента это выглядит как параметр командной строки /UCКодРазрешения либо указание кода в свойствах базы в стартере. Это штатный механизм, а не обход защиты: код задает тот, кто включал блокировку.

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

Для администраторов и разработчиков платформа предоставляет объектную модель работы с пользователями информационной базы — менеджер ПользователиИнформационнойБазы. Через него можно получить список пользователей, прочитать и изменить свойства: аутентификацию, роли, пароль, язык. Типовой сценарий — проверка, существует ли пользователь и включена ли у него аутентификация.

ПользовательИБ = ПользователиИнформационнойБазы.НайтиПоИмени("Иванов");
Если ПользовательИБ = Неопределено Тогда
    Сообщить("Пользователь не найден в списке пользователей ИБ");
Иначе
    Сообщить("Аутентификация 1С: " + ПользовательИБ.АутентификацияСтандартная);
    Сообщить("Аутентификация ОС: " + ПользовательИБ.АутентификацияОС);
КонецЕсли;

Для выполнения такого кода нужны административные права. Удобнее всего запускать его через внешнюю обработку или консоль кода в режиме предприятия. Изменения, внесенные через объектную модель (например, установка АутентификацияСтандартная = Истина и вызов метода Записать()), эквивалентны правке в конфигураторе и применяются немедленно.

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

Типичные причины, почему вход не разрешен, и как их диагностировать

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

Отдельно стоит упомянуть режим совместимости аутентификации и проверку сложности паролей: в новых версиях платформы могут действовать требования к паролям, и пользователь со «слабым» паролем при определенных настройках будет вынужден сменить его при входе. Это не запрет, но со стороны выглядит как проблема со входом.

Если база опубликована на веб-сервере, добавляется еще один слой: настройки публикации и возможная аутентификация на уровне веб-сервера. Проверяйте, проходит ли вход через тонкий клиент напрямую — если да, проблема в публикации, а не в правах пользователя.

Ограничения и меры предосторожности при работе с доступом

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

Перед любыми экспериментами с доступом сделайте резервную копию: для файловой базы — копию каталога с файлом 1Cv8.1CD при отсутствии активных сеансов, для клиент-серверной — штатный бэкап средствами СУБД. Это единственная надежная страховка от ошибок при массовых изменениях прав.

FAQ: частые вопросы о разрешении входа в 1С