1с аутентификация операционной системы не работает
Обновлено: 07.07.2024
Заэкспарился пароль в винде. Пусть пользователь пароль поменяет.
Добавление - пользователи работают через терминальный доступ непосредственно на сервер 1С. т.е. истек срок действия пароля? данная проблема у всех пользователей. и на сервер через РДП они попадают без проблем
с сервера 1с не видится сервер AD . или поменяли чего на сервере AD (типа включили последнюю версию авторизации, а сервак 1с сидит на старой. )
по словам админов - ничего не менялось. Когда я открывают список пользователей и выбираю доменного юзера для конкретного пользователя - я вижу список доменов и список пользователей доменов. т.е. получается с сервера 1С видно и домены и пользователи?
Ты его открываешь не с сервера Ну и "Ничего не менялось, а аносамо" еще пользователю простительно сказать, но не админу.
судя по всему у Вас несколько доменов? сервер 1с в том-же домене, что и пользователи.
я заходу на сервер 1С через терминал под своей учеткой, открываю конфигуратор, в пользователе через список доменных пользователей указываю свою учетку, сохраняю, запускаю 1С - спрашивает окно авторизации. по поводу "оно само и ничего не менялось" возразить нечего. только доверять сказанному и работать с тем что есть
домен один. имеет два названия (одно для старых ОС, другое для новых). например ИмяКомпании_Нью и ИмяКомпании.Локал. При установке пользователю конкретной учетки - вижу оба домена и оба списка пользователей (одинаковых). Пробовал выбирать и тех и других. Результат один - выскакивает окно авторизации
забей руками в таком виде \ИмяДоменаДляСтаройСистемылогин
такой адрес подставляется автоматически, когда я выбираю доменного пользователя из списка (что для имя домена для старых ОС, что для новых) получается строка \ИмяКомпании_НьюИмяПользователя или \ИмяКомпании.ЛокалИмяПользователя
План такой: 1.Пишем обработку в которой вызываем метод глобального контекста ПользователиОС, и в полученной ТЗ смотрим на вторую колонку ИмяСервера. Там будет именно короткое имя. Это имя сервера-контроллера домена которое будет использовать 1С при аутентификации. 2.Пытаемся лукапить это короткое имя с компа, на котором стоит сервер 1С. Из командной строки вот так: nslookup.exe server_name 3.Смотрим какой возвращается айпишник и тот ли он, узнаем у админа, если не лукапится идем к админу и просим вежливо..
спасибо за такую развернутую инструкцию. Для обоих имен домена выдал имя контроллера домена. лукап по этому имени показал его ип-адрес. и имя и ип-адрес соответствуют контроллеру домена. по имени и по ип пингуются с сервера 1С..
Ну тогда мы имеем что-то мелкопакостное. Типа того: - системные часы, надо проверить время на сервере и на контроллере домена; - некорректная установка софта на сервак, возможно некорректные записи в реесте, возможно обновления надо поставить, возможно они криво встали и т.п. А сервер перегрузить пробовали?
сейчас сравнил время на контроллере и на сервере 1с через NET TIME. Время отличается. Это может быть причиной проблемы авторизации? P.S. как ни странно, проблема исчезла в пятницу и появилась снова сегодня.
ан нет, время как будто совпадает. разница в секунду, как раз момент между вызовами команды
это позволяет исключить танцы с резервным контролером АД. если есть резервный контроллер AD подставь его ап \IP_резервный_ADИмяПользователя
такое может быть при рассогласовании основного и резервного AD
до имени пользователя AD пишется не айпиадрес и не имя контроллера домена, а именно имя самого домена, это разные имена в принципе
Ошибка 0x80090324 denote "Time Skew" все-таки говорит о том что время на участниках процесса авторизации расходится, по-моему больше чем на 15 минут. Проверить нужно все контроллеры домена. Кроме того, обязательно нужно проверить часовые пояса. Вы можете видеть якобы одинаковое время, но если при этом будет другой часовой пояс или летнее/зимнее время, короче время, приведенное к мировому должно быть одинаковым
можно указывать имя или IP ЛЮБОГО сервера который может разрешить sid пользователя. Когда ты указываешь имя домена - то дополнительно идет поиск предподчительного сервера и подставляется в запрос. кроме того автору следует проверить ОБРАТНУЮ зону ДНС, то есть видимость с сервера AD сервера 1с ПО_ИМЕНИ
Бинго! Время сервера 1С и контроллера домена совпадало до секунды. Однако на трех резервных контроллерах было расхождение от 5 до 10 минут. Привели время вручную с точностью до 1 минуты. Авторизация заработала! Большое спасибо! Я люблю вас!
На будущее: с гуглем дружите. Все это было найдено минут за пять. Ну и время на контроллерах домена должно само синхронизироваться. А то в самое неподходящее время опять все обвалится
Платформа 1С:Предприятие 8.2 (8.2.18.96). УПП (1.3.23.1). Windows Server 2008 R2.
До сегодняшнего дня отлично работала аутентификация операционной системы. Сегодня аутентификация работать перестала. При старте 1С выскакивает окно авторизации.
Из действий, которые могут быть связаны - в 1С в режиме предприятия были созданы 3 пользователя с указанием аутентификация операционной системы (указаны пользователи домена). Как потом выяснилось такие пользователи уже были созданы с галкой Недействительный. (не знаю может быть ли это связано или нет).
В какую сторону копать?
Настроил ТЖ с параметрами conn и excp,
запись логов пошла, но к сожалению пока не могу по ним определить ошибку.
в разделе EXCP нашел следующие записи:
InitializeSecurityContext: Error 80090324!
InitializeSecurityContext: Error 80090324!
'server_addr=any:1560 descr=Ошибка сетевого доступ
'server_addr=any:1561 descr=Ошибка сетевого доступ
'server_addr=any:1562 descr=Ошибка сетевого доступ
'server_addr=any:1563 descr=Ошибка сетевого доступ
'addrBelongsToThisComputer2, address=localhost, result=true'
'Connected, client=(23)[::1]:59291, server=(23)[::1]:1541'
Clnt: MyUserName1: МойЛогин@МойДомен
Clnt: DstUserName1: ЛогинСервера1С@МойДомен StartProtocol: 0 Success
'addrBelongsToThisComputer2, address=ИмяСервера, result=true'
'Connected, client=(23)[::1]:59300, server=(23)[::1]:1560'
Clnt: MyUserName1: МойЛогин@МойДомен
Clnt: DstUserName1: ЛогинСервера1С@МойДомен StartProtocol: 0 Success
кто знает, в какую сторону копать?
Заэкспарился пароль в винде. Пусть пользователь пароль поменяет.Добавление - пользователи работают через терминальный доступ непосредственно на сервер 1С.
(1) т.е. истек срок действия пароля? данная проблема у всех пользователей. и на сервер через РДП они попадают без проблем
(2) по словам админов - ничего не менялось.
Когда я открывают список пользователей и выбираю доменного юзера для конкретного пользователя - я вижу список доменов и список пользователей доменов.
т.е. получается с сервера 1С видно и домены и пользователи?
Ну и "Ничего не менялось, а аносамо" еще пользователю простительно сказать, но не админу.
(4) судя по всему у Вас несколько доменов?
сервер 1с в том-же домене, что и пользователи.
по поводу "оно само и ничего не менялось" возразить нечего. только доверять сказанному и работать с тем что есть
(6) домен один. имеет два названия (одно для старых ОС, другое для новых). например ИмяКомпании_Нью и ИмяКомпании.Локал.
При установке пользователю конкретной учетки - вижу оба домена и оба списка пользователей (одинаковых). Пробовал выбирать и тех и других. Результат один - выскакивает окно авторизации
(9) такой адрес подставляется автоматически, когда я выбираю доменного пользователя из списка (что для имя домена для старых ОС, что для новых)
получается строка \\ИмяКомпании_Нью\ИмяПользователя или \\ИмяКомпании.Локал\ИмяПользователя
План такой:
1.Пишем обработку в которой вызываем метод глобального контекста ПользователиОС(), и в полученной ТЗ смотрим на вторую колонку ИмяСервера.
Там будет именно короткое имя.
Это имя сервера-контроллера домена которое будет использовать 1С при аутентификации.
2.Пытаемся лукапить это короткое имя с компа, на котором стоит сервер 1С.
Из командной строки вот так:
nslookup.exe server_name
3.Смотрим какой возвращается айпишник и тот ли он, узнаем у админа, если не лукапится идем к админу и просим вежливо..
(11) спасибо за такую развернутую инструкцию.
Для обоих имен домена выдал имя контроллера домена.
лукап по этому имени показал его ип-адрес.
и имя и ип-адрес соответствуют контроллеру домена.
по имени и по ип пингуются с сервера 1С..
Ну тогда мы имеем что-то мелкопакостное. Типа того:
- системные часы, надо проверить время на сервере и на контроллере домена;
- некорректная установка софта на сервак, возможно некорректные записи в реесте, возможно обновления надо поставить, возможно они криво встали и т.п.
А сервер перегрузить пробовали?
(13) сейчас сравнил время на контроллере и на сервере 1с через NET TIME. Время отличается. Это может быть причиной проблемы авторизации?
Настройка аутентификации Windows при расположении веб-сервера IIS и рабочих серверов на разных машинах
Не работает аутентификация операционной системы (windows) через IIS при использовании тонкого клиента или веб-клиента.
С точки зрения пользователей, будет видно окно с запросом логина и пароля.
Проблема может заключаться в том, что методы операционной системы в силу различных причин возвращают описание текущего пользователя сеанса в таком представлении, которое не совпадает ни с одним пользователем в списке пользователей информационной базы 1С
Решение проблемы
На сервере 1С включить технологический журнал, используя следующую настройку:
Воспроизвести ситуацию с неудачной аутентификацией операционной системы. Авторизоваться под пользователем операционной системы, указанным в свойствах пользователя 1С.
Открыть технологический журнал рабочего процесса и найти событие EXCP со следующим описанием: "Идентификация пользователя не выполнена
Неправильное имя или пароль пользователя"
Обратите внимание на предшествующее ему событие CONN и значение свойства DstUserName2 - именно в таком виде пользователь должен быть указан в свойствах пользователя информационной базы.
Заменить значение свойства "Пользователь" пользователя информационной базы согласно следующему формату "\\" + [Имя пользователя из свойства DstUserName2 без скобок].
Проверить работоспособность аутентификации средствами операционной системы, войдя в информационную базу, используя веб-клиент.
Расположение веб-сервера IIS и рабочих серверов 1С на разных машинах
В некоторых случаях, несмотря на корректно указанного пользователя операционной системы в пользователе информационной базы, при попытке входа в опубликованную базу через браузер аутентификация операционной системы не проходит. Такая ситуация может возникать, если веб-сервер IIS и сервер 1с находятся на разных машинах. В таком случае в технологическом журнале рабочего процесса можно наблюдать следующую картину:
При возникновении такой ситуации необходимо проверить следующие настройки:
1) Убедиться, что процессы сервера 1С запущены от имени доменной учетной записи, входящей в группу Domain Users.
2) Убедиться, что веб-сервер IIS настроен корректно.
В публикации информационной базы найти настройки аутентификации
В настройках аутентификации отключить анонимную аутентификацию и включить Windows-аутентификацию. В Windows-аутентификации упорядочить доступных провайдеров так, чтобы на первом месте был Negotiate.
Пул приложений публикации не нуждается в настройках, в нем можно оставить все по умолчанию.
После изменения настроек перезапустить веб-сервер с помощью команды iisreset в командной строке.
3) Убедиться, что в контроллере домена в свойствах компьютера, на котором запущен веб-сервер, на вкладке делегирование установлено "Доверять компьютеру делегирование любых служб (только Kerberos)"
Для этого откройте оснастку Active Directory Users and Computers (dsa.msc), в компьютерах найдите веб-сервер, перейдите в его свойства и на вкладке Делегирование установить значение "Доверять компьютеру делегирование любых служб (только Kerberos)" и нажать применить.
4) Убедиться, что на клиенте в свойствах обозревателя разрешена встроенная проверка подлинности Windows.
После выполнения всех действий необходимо перезагрузить клиентский компьютер (рабочие серверы перезагрузки не требуют) и убедиться, что аутентификация операционной системы успешно выполняется.
Важно: аутентификации Windows при расположении веб-сервера IIS и рабочих серверов на разных машинах в тонком клиенте работает, начиная с версии 8.3.10.2620 (для тестирования).
Аутентификация – проверка принадлежности предъявленного идентификатора (имени) конкретному пользователю системы, проверка подлинности. Система «1С:Предприятие» поддерживает несколько различных вариантов аутентификации, которые будут рассмотрены в следующих разделах.
1.1.1. Аутентификация средствами системы «1С:Предприятие»
Пользователь может быть аутентифицирован системой «1С:Предприятие» с помощью ввода его имени и пароля (в диалоге аутентификации, в виде параметров командной строки или строки соединения с информационной базой для внешнего соединения или automation-сервера). В этом случае проверка наличия пользователя и корректности ввода его пароля выполняет система «1С:Предприятие».
1.1.2. Аутентификация операционной системы
Пользователь может быть аутентифицирован неявно средствами операционной системы. Для этого пользователю должен быть поставлен в соответствие некоторый пользователь операционной системы. При старте системы, «1С:Предприятие» запрашивает у операционной системы пользователя, который аутентифицирован в системе в данный момент. Для этого в ОС Windows используется интерфейс SSPI, а в ОС Linux — GSS-API. Затем выполняется проверка, что данному пользователю операционной системы сопоставлен пользователь «1С:Предприятия». Если поиск заканчивается успешно – считается, что пользователь системы «1С:Предприятие» аутентифицирован успешно, и диалог аутентификации не отображается.
Примечание. Не поддерживается аутентификация пользователя средствами ОС в том случае, если клиентское приложение подключается к информационной базе через веб-сервер Apache, работающий под управлением ОС Windows.
Пользователь операционной системы указывается в формате: \\имя_домена\имя_пользователя.
Если необходимо принудительно выполнить аутентификацию средствами системы «1С:Предприятие», то в командной строке запуска клиентского приложения следует указать ключ командной строки -WA-. Соответственно, ключ командной строки –WA+ предназначен для принудительного применения аутентификации средствами операционной системы (действует по умолчанию).
1.1.3. Аутентификация с помощью OpenID
Примечание 1. Данный способ аутентификации не применим при обращении к веб-сервисам, опубликованным из «1С:Предприятия».
Примечание 2. В роли провайдера OpenID выступает информационная база «1С:Предприятия».
Общая схема работы выглядит следующим образом:
- Пользователь пытается выполнить вход в систему.
- Система определяет, что в информационной базе работает OpenID-аутентификация (по файлу публикации default.vrd).
- Провайдеру OpenID отправляется запрос на выполнение аутентификации.
- Если необходимо выполнить интерактивное действие (выполняется первая аутентификация для данного идентификатора или закончено время жизни признака аутентификации данного идентификатора), то провайдер сообщает системе о необходимости запросить имя и пароль пользователя. Система выполняет интерактивное действие и возвращает провайдеру OpenID запрошенные данные.
- Признак аутентифицированности пользователя хранятся в файлах cookie, которые размещаются в хранилище, индивидуальном для каждого веб-браузера. Тонкий клиент использует собственное хранилище.
- Если провайдер аутентифицирует пользователя, то системе возвращается признак того, что пользователь аутентифицирован.
В качестве OpenID-провайдера выступает информационная база системы «1С:Предприятие». В качестве OpenID-идентификатора используются имена пользователей информационной базы. Такая информационная база должна быть особым образом опубликована на веб-сервере (в файле публикации default.vrd расположен особый элемент) и доступна для информационной базы, которая желает выполнять аутентификацию с помощью OpenID.
В качестве OpenID-идентификатора пользователя выступает свойство Имя пользователя информационной базы OpenID-провайдера. Пароль пользователя также задается в информационной базе OpenID-провайдера. Пароль, заданный в информационной базе, которая является клиентом OpenID-провайдера, игнорируется при выполнении аутентификации с помощью OpenID.
Если необходимо принудительно выполнить аутентификацию с помощью OpenID, то в командной строке запуска клиентского приложения следует указать ключ командной строки -OIDA+ (действует по умолчанию). Соответственно, ключ командной строки –OIDA- предназначен для принудительного отключения аутентификации с помощью OpenID.
Подробнее о настройке веб-сервера для работы с OpenID-аутентификацией см. стр. 2.
Для того, чтобы система выполняла аутентификацию с помощью протокола OpenID необходимо, чтобы у пользователя был установлен флажок Аутентификация 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С» — не нужно обслуживать дополнительную локальную базу пользователей приложения.
Читайте также: