Сквозная авторизация 1с это
Обновлено: 06.07.2024
По хорошему при серьезном подходе к автоматизации нужно запрещать неавторизованный вход в программу.
Исключение могут составлять крайне редкие случаи, например, демо-версия конфигурации или конфигурация публичного пользования.
Но как правило, наряду с заведением пользователей в конфигураторе имеет смысл сделать в конфигурации справочник "Пользователи", в котором хранить пользователей, соответствующих пользователям в конфигураторе.
Это дает возможность некоторых вещей, например привязки к пользователю некоторых прав, которыми нельзя управлять с помощью метаданного "Роль", построение системы ограничения прав RLS, привязанной к текущему пользователю, сохранение в справочниках и документах информации об авторах объектов, индивидуальные особенности интерфейса, настроек отчетов, событий и т. д.
Итак. Для выполнения этой задачи в конфигурации требуется сделать нижеперечисленные настройки.
Добавляем в конфигурацию план обмена "РаспределенныеБазы".
Добавляем в конфигурацию иерархический справочник "Пользователи", подчиненный плану обмена "РаспределенныеБазы".
Добавляем в конфигурацию параметр сеанса "ТекущийПользователь" типа "СправочникСсылка.Пользователи".
Добавляем в конфигурацию параметр сеанса "ТекущийУзелРаспределеннойБазы" типа "ПланОбменаСсылка.РаспределенныеБазы".
Добавляем в конфигурацию константу "ЗапретитьЗапускПрограммыНовымПользователям" типа "Булево".
В модуль приложения в процедуру ПередНачаломРаботыСистемы() вставляем код
В модуль внешнего соединения в процедуру ПриНачалеРаботыСистемы() вставляем код
В модуль сеанса, в котором фирма "1С" рекомендует устанавливать параметры сеанса, в процедуру УстановкаПараметровСеанса() вставляем код
Туда же (в модуль сеанса) вставляем процедуру глУстановитьПараметрСеансаТекущийПользователь() и функцию глЕстьДействующиеПользователи()
Собственно все. Теперь программа не запустится, если список пользователей в конфигураторе пустой.
И напоследок немного по логике работы.
Параметр сеанса "ТекущийПользователь" вместо комбинации двух одноименных экспортных переменных "глТекущийПользователь" в модуле приложения и модуле внешнего соединения выбран потому, что к нему можно привяхать RLS, а к глобальной переменной нет.
Константа "ЗапретитьЗапускПрограммыНовымПользователям" создана для того, чтобы при необходимости запретить автоматически программно создавать новых пользователей в справочнике "Пользователи". Может пригодиться в принципе кому-нибудь.
В модуле внешнего соединения проверка авторизованности пользователя выполняется в процедуре ПриНачалеРаботыСистемы(), а не в процедуре ПередНачаломРаботыСистемы() потому, что в модуле внешнего соединения нет события ПередНачаломРаботыСистемы().
Именно поэтому отказаться от запуска программы уже нельзя, но. нужно, поэтому вызываем исключение с заданным текстом ошибки.
1С 7.7 не хватает гибридной авторизации. Иногда это довольно неудобно. Пользователю требуется вводить дополнительно пароль, выбирать учетную запись из всех возможных. А часто и опасно, например, если один пользователь случайно узнает пароль другого, то может узнать конфиденциальные данные или просто что-то испортить. К тому же любомй пользователю всегда доступен список всех пользователей.
Данная разработка является попыткой реализовать сквозную Windows авторизацию пользователей.
Если выбран набор прав или нашлась единственная подходящая учетная запись, то процесс 1С размораживается,
отключается проверка пароля 1С,
в скрытом окне авторизации происходит подстновка нужной учетной записи и подтверждается вход.
Процесс 1С освобождается и продолжает работу в штатном режиме.
Что это дает:
Плюсы:
- Обеспечивается сквозная авторизация в 1С.
- Исключается возможность входа пользователя под чужой учетной записью 1С.
- Исключается необходимость ввода пароля при доменой авторизации.
----------------------
+ Не требует установки.
+ Файлы 1С не изменяются никаким образом.
Минусы:
- Необходимо изменить список пользователей ,что не всегда удобно.
- Отключается проверка пароля 1С.
Как это заставить работать:
Требуется SQL версия 1С 7.7 (тестировалось на 27 релизе).
Эта версия скорее всего не будет работать с другими версиями 1С, т.к. использется прямое чтение из памяти процесса. В других версиях возможна другое срасположение переменных в памяти.
1. Список пользователей изменяется таким образом, чтобы имена учетных записей 1С соответствовали доменным именам. В случае наличия у одного пользователя нескольких учетных записей требуется добавить к имени индекс (1,2,3 и т.д.).
2. В папку BIN платформы 1С добавляется исполняемый файл LogonTo1C.
2а. в случае использования LogonTo1C_bin.exe, файл 1Cv7s.exe переименовывается в 1Cv7s.bin, а LogonTo1C_bin.exe в 1Cv7s.exe.
4. Ярлык 1С меняется на ярлык LogonTo1C.
5. В случае Windows Server 2008 утилиту нужно запускать "с правами админстратора". (собственно, то же самое требуется самой 1С).
Как это выглядит для пользователя:
При запуске 1С происходит либо непосредственно вход в базу либо выбор набора прав в окне,
напоминающем окно авторизации 1С.
Даная версия утилиты распространяется бесплатно. Запрещено коммерческое использование без уведомления автора.
Приветствую всех, если вас заинтересовала статься значит вы тем или иным образом стыкались или интересовались данным вопросом, либо просто почитать.
Данный кейс с реальной практики, проект начался в начале 2019 и все "n" баз были переведены в течении полугода на доменную авторизацию (надеюсь все понимают, что это значит), но мне больше нравится SSO.
Значит что имеем:
Windows Server 2016 + AD (не рассматриваем как настраивать)
CentOS 7 + Haproxy + Comodo SSL Wildcard
Windows Server 2016 + IIS + 1C
Примерная схема работы
Вроде все понятно, конечно если об этом вы слышите в первый раз, то нужно будет почитать дополнительные материалы как настраивается каждый сервис.
Двигаемся дальше и приступаем к настройке наших сервисов
Можно так же использовать сертификаты Let's Encrypt но у меня есть подписанный ЦС, а еще может быть что клиент 1С на разных ОС будет ругаться на Let's Encrypt. Если у вас кластер 1С тогда нужно добавить еще один сервер rt_db_srv02 в backend rt_db_server
Настройка IIS, тут уже будет больше картинок.
После инстала IIS, включаем только 80й порт остальные нам не нужны так как ssl будет занимается haproxy. На картинке ниже роли, которые нужно поднять:
компоненты IIS
Я это все делаю с помощью Ansible, поэтому готовых команд PS под рукой нет. Идем дальше и не к настройке IIS, а к установке 1С:
Ставим все кроме хранилища, ковертора и проверки целосности
По стандарту заходим в консоль администрирования 1С подключаем базу и тд. В клиенте 1С на сервере на котором бы будем делать публикацию прописываем имя сервера (у нас же AD и DNS внутренний) можно без порта, но естественно если порт у вас отличный от стандартного (например, подняли еще одну службу на 1640), то его писать тоже нужно типа server1С1:1641, но если у вас кластер тогда пишем так server1С1;server1С2 (server1С1:1641;server1С2:1641) и нормальные имена нужно прописывать обязательно, так как это пойдет в конфиг IIS. Чуть не забыл, после инсталляции 1С службу, которую она создаст, необходимо запустить от имени доменного пользователя, на сервер 1С его нужно будет сделать админом, а в домене может быть обычным пользователем. главное что б мог читать пользователей с AD. Например
запуск службы от доменного пользователя
Публикуем базу как обычно, все по дефолту, с необходимыми галочками в hs/ws
Настройки веб-сайт
Веб сайт есть, а далее вместе с ним создается и пул приложений. который нам больше всего и нужно, так как в нем мы задаем кто будет авторизовать креды пользователей в 1С и расшифровывать karberos. Для этого нам нужен еще один доменный пользователь желательно отдельный, например iis_service (создаём помним пароль)))
Так он выглядит стандартно:
Приводим его в нужный вид, редактируя удостоверение:
Тюним, Режим управления выставляем Классический и нужно что б это удостоверение использовалось для этого делаем в редакторе конфигурации сервер (путь system.webServer/security/authentication/windowsAuthentication).
делаем так
С этим все готово. Для корректной работы, необходимо в AD прописать spn запись, это просто заходим на домен контроллер и запускаем команды, в которых пишем нашу публикацию и нашего пользователя, который расшифровывает kerberos:
В 1С пользователю вставляем авторизацию как на картинке:
Со списка доменов нужно выбрать тот, что большими буквами и в виде короткой записи.
на этом пока все. возможно еще подкорректирую статью, пост был важен для меня, так как при работе с проектом нужно было много разбираться и собирать по кусочкам. а что-то и самому изобретать. Надеюсь, статья будет полезна тем, кому необходимо решить аналогичный кейс.
В следующей статье напишу про то, как мы сделали веб страничку с сеансами пользователей и возможностью их удаления.
В данной статье мы рассмотрим настройку сервера «1С:Предприятие» для использования Microsoft AD в качестве системы авторизации клиентов 1С. Статья представляет собой описание успешно внедрённого решения, за основу брались различные статьи из открытых источников, в частности официальная документация разработчика 1С.
Преамбула.
У нас имеется работающий на ОС Linux (CentOS7) сервер «1С:Предприятие». Сервер работает на хосте srv-app01, входящем в домен local.domain.name.
1. Настройка кластера сервера 1С:Предприятие
Настройка и управление кластером сервера «1С:Предприятие» происходит с компьютера с ОС Windows, так что для управления сервером нужно использовать традиционную оснастку mmc для Windows «Администрирование серверов 1С:Предприятие», которую следует установить из дистрибутива технологической платформы для Windows (ссылка).
Обязательно нужно настроить «Параметры рабочего сервера», как показано ниже:
Свойства кластера 'Критический объем памяти процессов', 'Режим распределения нагрузки' или свойства рабочего сервера 'Критический объем памяти процессов', 'Временно допустимый объем памяти процессов', 'Интервал превышения допустимого объема памяти процессов', 'Безопасный расход памяти за один вызов', 'Количество ИБ на процесс' содержат значения, отличные от значений по умолчанию.
Использование этих функций возможно только для лицензий на платформу уровня КОРП.
Это связано с тем, что «..начиная с версий платформы «1С:Предприятие» 8.3.12.1852, 8.3.13.1791 и 8.3.14.1592, вводятся ограничения на техническом уровне, не позволяющие использовать функциональность КОРП». Подробнее можно посмотреть здесь.
2. Настройка Kerberos-аутентификации
Для решения поставленной задачи настроим Kerberos-аутентификацию сервера «1С:Предприятие».
а) Настройка контроллера домена
Имя сервера srv-app01 обязательно должно разрешаться DNS-сервером (если его ввели в домен, то соответствующая запись в DNS-сервере есть).
Создать в домене учетную запись пользователя, с которой будут ассоциироваться запросы авторизации к серверу 1С:Предприятие. Имя может быть произвольное. В нашем случае это будет пользователь usr1cv8x с паролем XxXxXx. В свойствах этой уч`тной записи на вкладке «Учётная запись» в секции «Параметры учётной записи:» следует сбросить флажок «Use DES encryption types with this account»:
Для пользователя usr1cv8x следует сгенерировать файл с секретным ключом на компьютере с ОС Windows. Для этого используется утилита ktpass, входящая в состав в пакета Windows Support Tools (его можно найти в подкаталоге SUPPORT установочного диска Windows).
В командной строке запустим утилиту ktpass, которая «свяжет» доменного пользователя с пользователем, от имени которого работает сервер «1С:Предприятие»:
usr1cv8x, указываемое в параметре mapuser, — это имя доменного пользователя, которого мы создали.
В параметре pass передаётся пароль доменной учётной записи usr1cv8x.
В параметре out указывается имя файла с ключом. В нашем случае это usr1cv8.keytab.
б) Настройка центрального сервера кластера «1С:Предприятие»
Убедимся, что все в порядке:
Как видно, мы получили от KDC (Key Distribution Center — центр распределения ключей, эту функцию выполняет контроллер домена) так называемый ticket-granting ticket. После этого следует с помощью команды kdestroy очистить локальный кэш тикетов, чтобы вернуться в исходное состояние.
Далее любым способом следует передать файл с секретным ключом usr1cv8.keytab, полученный во время настройки контроллера домена, на центральный сервер кластера «1С:Предприятия». Этот файл следует скопировать в директорию, где установлен сервер «1С:Предприятие» (по умолчанию это /opt/1C/v8.3/x86_64), и установить права и владельца файла как показано ниже:
При желании файл можно разместить в любом другом месте, нужно только изменить переменную SRV1CV8_KEYTAB в конфигурационном файле (/etc/sysconfig/srv1cv83), чтобы она указывала на новое местоположение файла с секретным ключом.
После этого с помощью команды klist проверяем, всё ли мы сделали правильно. Для этого выполним команду:
Мы видим, что файл с секретным ключом содержит именно то, что нам нужно — в колонке Principal указано то самое имя службы, которое мы задавали при создании файла с секретным ключом, и правильный алгоритм шифрования (arcfour-hmac для RC4-HMAC).
Теперь посмотрим на результаты работы с помощью команды klist. В случае успеха мы увидим примерно следующее:
Если что-то настроено не так, то эта команда выведет следующее:
Если проверка работоспособности прошла успешно, это значит, что с данного момента сервер кластера «1С:Предприятия» способен обрабатывать запросы на аутентификацию. При этом перезапуск сервера не требуется, кроме того случая, когда в конфигурационном файле было изменено место расположения файла с секретным ключом.
в) Настройка пользователей в информационных БД «1С:Предприятие»
Для настройки аутентификации пользователей в информационной БД «1С:Предприятие» с помощью доменной учетной записи нужно запустить БД под Администратором.
Перейти в «Администрирование», слева в списке выбрать «Пользователи».
В появившемся окне «Пользователи» выбрать нужного пользователя.
В свойствах пользователя выбрать «Аутентификация операционной системы» и в поле «Пользователь» нажать на кнопку «. ».
В списке «Пользователи» выбрать нужного пользователя и нажать на кнопку «Выбрать». Должно получиться как на скриншоте:
Эти действия нужно повторить для всех пользователей БД.
В результате мы получаем решение, при котором пользователю не требуется совершать дополнительных действий по вводу логина и пароля для запуска приложения. Система определяет пользователя операционной системы, запускающего приложение, и соотносит с имеющейся ролью в конфигурации «1С». Использование единой системы авторизации в прикладных приложениях удобно как для пользователя, так и для администратора конфигурации «1С» — не нужно обслуживать дополнительную локальную базу пользователей приложения.
Читайте также: