1с не работает доменная авторизация
После повышения уровня леса с 2003 до 2008 перестала работать доменная авторизация в 1С. Версия 1С 8.2.13.219. Никто с таким не сталкивался?
Константин, обитатели этого форума испытывают когнитивный диссонанс от Вашего профессионального жаргона
Опишу ситуацию подробней. Вчера после обеда подняли функциональный уровень AD с 2003 до 2008, вроде бы все было нормально, ничего не отвалилось. Утром начались звонки от пользователей что у них 1С запрашивает логин и пароль (раньше стояла сквозная авторизация, логины 1С не использовались. Причем у тех людей, которые со вчера не перезагружались - все нормально, после перезагрузки авторизация уже не проходит.
Здесь 1С никаким боком, просто нет прав у пользователя на доступ к серваку, где база 1С. Если была бы база оракл, орала бы не хуже
В AD тоже есть понятия леса и деревьев. Как другими словами описать процедуру поднятия функционального уровня AD я не знаю.
Беру свои замечания назад. Перечитал свой пост - я нигде не указал что слово лес относится к AD. Спасибо за замечание.
К файловой базе точно нужен виндовый доступ. К ключам 1С тоже кстати тоже нужен виндовый ! К СКЛ базе не уверен. Вероятно, ключ на серваке недоступен.
Ключ на сервере доступен, да и ошибка в таком случае была бы другая. Пользователи, у которых заданы 1С логин и пароль, входят в 1С без проблем.
попробуй у пользователя заново задать параметр "пользователь операционной системы" и посмотри что получится
изменение влияют только на проблеммы с видимостью при заведении win логина, нужно тупо текстовую строку вставлять и все, сама 1с нормально работает и со старой NT авторизацией и с новой. попробуй сервера перезагрузить
Сервера приложений попробовал, вот только что. Теперь если пользователь перелогинился - заходит с доменной авторизацией, если нет - опять запрашивается пароль. Но перелогон помогает не всем пользователям (может дело времени).
+ и еще 1с криво работает с доменами типа r.int вместо r.local точнее криво работает не 1с а админы :)
можно ещё программно попробовать залогиниться в 1с и обработать исключение посмотреть что за ошиибка, кстати правильно пишет всю сеть нужно перезагружать
как показывает практика если вы действительно понимаете что делаете, то достаточно остановить и через минуту запустить соответстсвующие службы
как показывает практика такое бывает из-за рассинхронизации серверов АД, в этом случае нужно оставить только основной сервер АД, все остальные выключить и на них убрать АД совсем (а потом востановить, не раньше чем все у всех заработает, лучше неделю подождать. ) пусть админы логи посмотрят на предмет ошибок репликации АД
Доменная аутентификация ОС при бесшовной интеграции 1С:Документооборот 8 КОРП, редакция 2.1 (2.1.27.1) и 1С:ERP Управление предприятием 2 (2.4.13.103) (в клиент-серверном режиме). Проблема: «После перехода на новую платформу перестала работать доменная аутентификация».
Доменная аутентификация ОС при бесшовной интеграции 1С:Документооборот 8 КОРП, редакция 2.1 (2.1.27.1) и 1С:ERP Управление предприятием 2 (2.4.13.103) (в клиент-серверном режиме)
Обратился клиент с проблемой: «После перехода на новую платформу перестала работать доменная аутентификация» (рисунок 1)
Рисунок 1. Ошибка аутентификации
Продолжительный поиск в сети позволил сделать следующее заключение – если база 1С:ERP работает в клиент-серверном режиме, все запросы на подключение к веб-сервису 1С:Документооборот пойдут через сервер 1С, и авторизоваться будет пользователь, под которым запущен rphost. Пробросить доменное имя пользователя с клиента на сервер нельзя, т.к. это не позволяет сделать платформа 1С:Предприятие (8.3.16.1876).
Однако опытным путем был найден способ обойти это ограничение.
Для того, чтобы победить и заставить авторизацию работать так как мы хотим нужно сделать следующие шаги:
Важно! При выполнении последующих условий интегрированный функционал при доменной аутентификации работает для всех пользователей.
1) Включить доменную авторизацию на операционной системе сервера (Windows)
2) Запустить службы 1С под системной учетной записью 1С (полные права, через домен) (рисунок 2).
Рисунок 2. Запуск службы
3) Настройки для пользователей в ДО и ERP (рисунок 3)
Рисунок 3. Настройки пользователей
4) Первый вход после перезапуска должен быть выполнен под системной учетной записью 1С.
В результате проведенных действий при входе в интегрированную в 1С:ERP (2.4.13.103) систему 1С:Документооборот 8 КОРП (2.1.27.1), не потребуется ввода пароля пользователя, т.к. будет срабатывать аутентификация операционной системы.
Специальные предложения
Добрый день. Уточните, пожалуйста, "при входе в интегрированную в 1С:ERP (2.4.13.103) систему 1С:Документооборот 8 КОРП (2.1.27.1), не потребуется ввода пароля пользователя, т.к. будет срабатывать аутентификация операционной системы." - пользователь в этом случае будет авторизован в 1С:ДО под своим сетевым именем (и видеть свои задачи) или под "системной учетной записью 1С"?
(3) извините, но это в корне неверное утверждение
См. примечание в описании настроек
Цитата (для тех, у кого нет доступа на ИТС):
"ВНИМАНИЕ! При работе интегрируемого прикладного решения в клиент-серверном варианте для Windows-авторизации будут использоваться данные той учетной записи, под которой работает служба сервера 1С:Предприятия."
Веб-соединение, инициализированное на стороне интегрируемого 1С-приложения будет открыто из под пользователя учетной записи службы сервера, непосредственно обслуживающего эту ИБ (в случае клиент-серверного варианта развертывания интегрируемой ИБ). Собственно, для этого нам и нужен пользователь USR1CV8 в базе ДО (в Вашем примере 1cservice).
Таким образом, если в интегрируемом приложении в настройках интеграции, например, взвести флаг "Задачи и процессы" - пользователь, открывший базу, на форме задач в интегрируемой ИБ увидит не свои задачи, а задачи пользователя 1cservice.
Заявляю это все весьма ответственно, так как не просто прочитал ИТС, но и протестировал.
Так что вариант такой авторизации подходит только в том случае, если у вас все задачи и прочее - "общим скопом" и неважно, что кому назначено и кто что согласует и т.д.
(14) Кстати, вариант увидеть "свои" задачи все-таки есть. Для этого надо открыть интегрируемое приложение в толстом клиенте из-под пользователя с доменной авторизацией. Ну и такой же пользователь должен быть создан в базе ДО. В этом случае веб-соединение инициализируется на клиентском ПК и доменная авторизация проходит под пользователем, открывшим толстый клиент.
Поделитесь опытом у кого получилось. Сделали все по пунктам, но в учетной системе просит логин и пароль пользователя ДО.
БИД 1.1.15.1 Платформа 8.3.17.1496
Добрый день. Платформа 1С:Предприятие 8.2 (8.2.18.96). УПП (1.3.23.1). Windows Server 2008 R2. До сегодняшнего дня отлично работала аутентификация операционной системы. Сегодня аутентификация работать перестала. При старте 1С выскакивает окно авторизации. Из действий, которые могут быть связаны - в 1С в режиме предприятия были созданы 3 пользователя с указанием аутентификация операционной системы (указаны пользователи домена). Как потом выяснилось такие пользователи уже были созданы с галкой Недействительный. (не знаю может быть ли это связано или нет). В какую сторону копать? Настроил ТЖ с параметрами conn и excp, запись логов пошла, но к сожалению пока не могу по ним определить ошибку. в разделе EXCP нашел следующие записи: 'server_addr=any:1560 descr=Ошибка сетевого доступ NetDataExchangeException 'server_addr=any:1561 descr=Ошибка сетевого доступ NetDataExchangeException 'server_addr=any:1562 descr=Ошибка сетевого доступ NetDataExchangeException 'server_addr=any:1563 descr=Ошибка сетевого доступ NetDataExchangeException в разделе CONN: 22.05.2014 13:35:27 Clnt: DstUserName1: ЛогинСервера1С@МойДомен StartProtocol: 0 Success 22.05.2014 13:35:29 Clnt: DstUserName1: ЛогинСервера1С@МойДомен StartProtocol: 0 Success кто знает, в какую сторону копать?
Добавление - пользователи работают через терминальный доступ непосредственно на сервер 1С. т.е. истек срок действия пароля? данная проблема у всех пользователей. и на сервер через РДП они попадают без проблем
с сервера 1с не видится сервер AD . или поменяли чего на сервере AD (типа включили последнюю версию авторизации, а сервак 1с сидит на старой. )
по словам админов - ничего не менялось. Когда я открывают список пользователей и выбираю доменного юзера для конкретного пользователя - я вижу список доменов и список пользователей доменов. т.е. получается с сервера 1С видно и домены и пользователи?
Ты его открываешь не с сервера Ну и "Ничего не менялось, а аносамо" еще пользователю простительно сказать, но не админу.
я заходу на сервер 1С через терминал под своей учеткой, открываю конфигуратор, в пользователе через список доменных пользователей указываю свою учетку, сохраняю, запускаю 1С - спрашивает окно авторизации. по поводу "оно само и ничего не менялось" возразить нечего. только доверять сказанному и работать с тем что есть
домен один. имеет два названия (одно для старых ОС, другое для новых). например ИмяКомпании_Нью и ИмяКомпании.Локал. При установке пользователю конкретной учетки - вижу оба домена и оба списка пользователей (одинаковых). Пробовал выбирать и тех и других. Результат один - выскакивает окно авторизации
такой адрес подставляется автоматически, когда я выбираю доменного пользователя из списка (что для имя домена для старых ОС, что для новых) получается строка \ИмяКомпании_НьюИмяПользователя или \ИмяКомпании.ЛокалИмяПользователя
План такой: 1.Пишем обработку в которой вызываем метод глобального контекста ПользователиОС, и в полученной ТЗ смотрим на вторую колонку ИмяСервера. Там будет именно короткое имя. Это имя сервера-контроллера домена которое будет использовать 1С при аутентификации. 2.Пытаемся лукапить это короткое имя с компа, на котором стоит сервер 1С. Из командной строки вот так: nslookup.exe server_name 3.Смотрим какой возвращается айпишник и тот ли он, узнаем у админа, если не лукапится идем к админу и просим вежливо..
спасибо за такую развернутую инструкцию. Для обоих имен домена выдал имя контроллера домена. лукап по этому имени показал его ип-адрес. и имя и ип-адрес соответствуют контроллеру домена. по имени и по ип пингуются с сервера 1С..
Ну тогда мы имеем что-то мелкопакостное. Типа того: - системные часы, надо проверить время на сервере и на контроллере домена; - некорректная установка софта на сервак, возможно некорректные записи в реесте, возможно обновления надо поставить, возможно они криво встали и т.п. А сервер перегрузить пробовали?
сейчас сравнил время на контроллере и на сервере 1с через NET TIME. Время отличается. Это может быть причиной проблемы авторизации? P.S. как ни странно, проблема исчезла в пятницу и появилась снова сегодня.
это позволяет исключить танцы с резервным контролером АД. если есть резервный контроллер AD подставь его ап \IP_резервный_ADИмяПользователя
до имени пользователя AD пишется не айпиадрес и не имя контроллера домена, а именно имя самого домена, это разные имена в принципе
Ошибка 0x80090324 denote "Time Skew" все-таки говорит о том что время на участниках процесса авторизации расходится, по-моему больше чем на 15 минут. Проверить нужно все контроллеры домена. Кроме того, обязательно нужно проверить часовые пояса. Вы можете видеть якобы одинаковое время, но если при этом будет другой часовой пояс или летнее/зимнее время, короче время, приведенное к мировому должно быть одинаковым
можно указывать имя или IP ЛЮБОГО сервера который может разрешить sid пользователя. Когда ты указываешь имя домена - то дополнительно идет поиск предподчительного сервера и подставляется в запрос. кроме того автору следует проверить ОБРАТНУЮ зону ДНС, то есть видимость с сервера AD сервера 1с ПО_ИМЕНИ
Бинго! Время сервера 1С и контроллера домена совпадало до секунды. Однако на трех резервных контроллерах было расхождение от 5 до 10 минут. Привели время вручную с точностью до 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С» — не нужно обслуживать дополнительную локальную базу пользователей приложения.
Читайте также: