1С 8.3.20, CentOS 9, Win srv 2019 и kerberos авторизация.
Всем здравствуйте.
Возникла проблема с керберос, над которой всю ночь ломаю голову.
Итак, имеется сервер:
- Linux CentOS 9
- 1С 8.3.20
- Установлена Samba, сервер введён в домен AD
- Сгенерирован usr1cv83.keytab, лежит на сервере в положенном месте. Пробовал генерировать так:
и так:
- Домен AD на Win srv 2019
- В самом линухе с файлом usr1cv83.keytab всё в порядке:
В 1С у пользователя стоит галка "Аутентификация в операционной системе" и прописано "\\local.typical-admin.ru\masha".
Вроде всё правильно. Да и не первый раз я это делаю.
Вот статья, в которой в самом низу описан весь процесс настройки керберос авторизации, но только для 1С 8.2
https://typical-admin.ru/obshaya/linux-fedora/1c-linux
И это рабочая статья, проверено лично мною - на 8.2 керберос-авторизация работала, настроенная именно по этой статье.
А вот на 8.3 никак... Кто-то сталкивался? Подскажите, что я неправильно делаю?
Возникла проблема с керберос, над которой всю ночь ломаю голову.
Итак, имеется сервер:
- Linux CentOS 9
- 1С 8.3.20
- Установлена Samba, сервер введён в домен AD
- Сгенерирован usr1cv83.keytab, лежит на сервере в положенном месте. Пробовал генерировать так:
ktpass /crypto ALL /princ usr1cv83/1c-serv.local.typical-admin.ru@LOCAL.TYPICAL-ADMIN.RU /mapuser usr1cv8 /pass pass1cv8 /out C:\distrib\usr1cv83.keytab /ptype KRB5_NT_PRINCIPAL
и так:
ktpass /crypto ALL /princ usr1cv83/1c-serv.local.typical-admin.ru@LOCAL.TYPICAL-ADMIN.RU /mapuser usr1cv8 /pass pass1cv8 /out C:\distrib\usr1cv83.keytab
- Домен AD на Win srv 2019
- В самом линухе с файлом usr1cv83.keytab всё в порядке:
klist -e -k -t /opt/1cv8/x86_64/usr1cv83.keytab
Keytab name: FILE:/opt/1cv8/x86_64/usr1cv83.keytab
KVNO Timestamp Principal
---- ------------------- ------------------------------------------------------
4 01.01.1970 05:00:00 usr1cv83/1c-serv.local.typical-admin.ru@LOCAL.TYPICAL-ADMIN.RU (DEPRECATED:des-cbc-crc)
4 01.01.1970 05:00:00 usr1cv83/1c-serv.local.typical-admin.ru@LOCAL.TYPICAL-ADMIN.RU (DEPRECATED:des-cbc-md5)
4 01.01.1970 05:00:00 usr1cv83/1c-serv.local.typical-admin.ru@LOCAL.TYPICAL-ADMIN.RU (DEPRECATED:arcfour-hmac)
4 01.01.1970 05:00:00 usr1cv83/1c-serv.local.typical-admin.ru@LOCAL.TYPICAL-ADMIN.RU (aes256-cts-hmac-sha1-96)
4 01.01.1970 05:00:00 usr1cv83/1c-serv.local.typical-admin.ru@LOCAL.TYPICAL-ADMIN.RU (aes128-cts-hmac-sha1-96)
Показать
# kinit -k -t /opt/1cv8/x86_64/usr1cv83.keytab usr1cv83/1c-serv.local.typical-admin.ru@LOCAL.TYPICAL-ADMIN.RU
# klist
Ticket cache: KCM:0
Default principal: usr1cv83/1c-serv.local.typical-admin.ru@LOCAL.TYPICAL-ADMIN.RU
Valid starting Expires Service principal
02.02.2022 04:09:00 02.02.2022 14:09:00 krbtgt/LOCAL.TYPICAL-ADMIN.RU@LOCAL.TYPICAL-ADMIN.RU
renew until 09.02.2022 04:09:00
ПоказатьВ 1С у пользователя стоит галка "Аутентификация в операционной системе" и прописано "\\local.typical-admin.ru\masha".
Вроде всё правильно. Да и не первый раз я это делаю.
Вот статья, в которой в самом низу описан весь процесс настройки керберос авторизации, но только для 1С 8.2
И это рабочая статья, проверено лично мною - на 8.2 керберос-авторизация работала, настроенная именно по этой статье.
А вот на 8.3 никак... Кто-то сталкивался? Подскажите, что я неправильно делаю?
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(7) нет. Я уже и тех.поддержку мучаю. Они сначала попытались отбрехаться, мол ничё не знаем, CentOS 9 не поддерживается. Поддерживается лишь CentOS 7.
Ну я чё, я взял и на CentOS 7 попробовал. Там тоже не работает.
Вряд ли тут дело в ОС. Где-то в самой 1С похоже подвох.
Ну я чё, я взял и на CentOS 7 попробовал. Там тоже не работает.
Вряд ли тут дело в ОС. Где-то в самой 1С похоже подвох.
В скрипте запуска демона 1С ( файл /etc/init.d/srv1cv83) нарыл, что, по умолчанию, 1С ищет файлик usr1cv8.keytab, расположенный в каталоге:
Т.е. в моём случае это /opt/1cv8/x86_64/8.3.20.1674/. Пробовал положить файлик туда, переименовав в usr1cv8.keytab. Не помогло. Пробую что-то ещё выяснить, но пока безуспешно.
/opt/1cv8/${G_VER_ARCH}/${G_VER_MAJOR}.${G_VER_MINOR}.${G_VER_BUILD}.${G_VER_RELEASE}"
Т.е. в моём случае это /opt/1cv8/x86_64/8.3.20.1674/. Пробовал положить файлик туда, переименовав в usr1cv8.keytab. Не помогло. Пробую что-то ещё выяснить, но пока безуспешно.
Добрый день!
Проблема один-в-один как выше.
ОС: CentOS 7
Платформа:
Домен - Windows 2016
В домене создан пользователь root\usr1cv8
Файл keytab корректно создан:
На Linux машине, при проверке авторизации Kerberos всё проходит успешно:
Включаю логирование событий:
И в журнале rphost, при попытке авторизоваться в домене, вижу следующее:
У кого могут быть мысли?
Проблема один-в-один как выше.
ОС: CentOS 7
[root@1cl02 ~]# cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)
[root@1cl02 ~]# uname -r
3.10.0-1160.59.1.el7.x86_64
Платформа:
8.3.20.1674
Домен - Windows 2016
В домене создан пользователь root\usr1cv8
Файл keytab корректно создан:
ktpass -crypto all -kvno 1 -ptype KRB5_NT_PRINCIPAL -princ usr1cv8/1cl02.root.local@ROOT.LOCAL -mapuser usr1cv8 -pass SuperPass100 -out C:\SYSTEM\usr1cv8-crypto-all.keytab
На Linux машине, при проверке авторизации Kerberos всё проходит успешно:
[root@1cl02 ~]# klist -e -k -t /opt/1cv8/x86_64/8.3.20.1674/usr1cv8.keytab
Keytab name: FILE:/opt/1cv8/x86_64/8.3.20.1674/usr1cv8.keytab
KVNO Timestamp Principal
---- ------------------- ------------------------------------------------------
1 01/01/1970 03:00:00 usr1cv8/1cl02.root.local@ROOT.LOCAL (des-cbc-crc)
1 01/01/1970 03:00:00 usr1cv8/1cl02.root.local@ROOT.LOCAL (des-cbc-md5)
1 01/01/1970 03:00:00 usr1cv8/1cl02.root.local@ROOT.LOCAL (arcfour-hmac)
1 01/01/1970 03:00:00 usr1cv8/1cl02.root.local@ROOT.LOCAL (aes256-cts-hmac-sha1-96)
1 01/01/1970 03:00:00 usr1cv8/1cl02.root.local@ROOT.LOCAL (aes128-cts-hmac-sha1-96)
Показать
[root@1cl02 ~]# kinit -k -t /opt/1cv8/x86_64/8.3.20.1674/usr1cv8.keytab usr1cv8/1cl02.root.local@ROOT.LOCAL
[root@1cl02 ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: usr1cv8/1cl02.root.local@ROOT.LOCAL
Valid starting Expires Service principal
03/29/2022 13:40:18 03/30/2022 03:40:18 krbtgt/ROOT.LOCAL@ROOT.LOCAL
renew until 03/30/2022 13:40:18
ПоказатьВключаю логирование событий:
[root@1cl02 ~]# cat /opt/1cv8/x86_64/8.3.20.1674/conf/logcfg.xml
<?xml version="1.0"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="/var/log/1c" history="12">
<event>
<eq property="name" value="excp"/>
</event>
<event>
<eq property="name" value="excpcntx"/>
</event>
<event>
<eq property="name" value="admin"/>
</event>
<event>
<eq property="name" value="clstr"/>
</event>
<event>
<eq property="name" value="conn"/>
</event>
<event>
<eq property="name" value="sesn"/>
</event>
<event>
<eq property="name" value="proc"/>
</event>
<event>
<eq property="name" value="DBPOSTGRS"/>
<ge property="Durationus" value="10000000"/>
</event>
<property name="all"/>
</log>
<plansql/>
</config>
ПоказатьИ в журнале rphost, при попытке авторизоваться в домене, вижу следующее:
30:25.559000-0,EXCP,2,process=rphost,OSThread=27977,t:clientID=538,Descr='GSS-API error gss_acquire_cred: Unspecified GSS failure. Minor code may provide more information
'
30:25.559001-0,EXCP,2,process=rphost,OSThread=27977,t:clientID=538,Descr='GSS-API error gss_acquire_cred: No key table entry found matching usr1cv8/1cl02@
'
30:25.638002-0,CLSTR,2,process=rphost,p:processName=testbase,OSThread=28523,t:clientID=538,t:applicationName=1CV8C,t:computerName=dev,t:connectID=411,Event=Successful service call,RmngrURL=tcp://1cl02.root.local:1541,ServiceName=SessionDataService,InfoBase=testbase,ExtData=1CV8C,SessionID=ed92ee6c-d0ad-402d-9bf1-334d070d782d,TargetCall=0
30:25.640001-0,EXCP,2,process=rphost,p:processName=testbase,OSThread=28523,t:clientID=538,t:applicationName=1CV8C,t:computerName=dev,t:connectID=411,SessionID=565,Exception=a01f465c-ed70-442e-ada5-847668d7a41c,Descr='src/vrsbase/src/VResourceInfoBaseServerImpl.cpp(2154):
a01f465c-ed70-442e-ada5-847668d7a41c: Идентификация пользователя не выполнена
Неправильное имя или пароль пользователя'
30:25.640002-0,EXCP,2,process=rphost,p:processName=testbase,OSThread=28523,t:clientID=538,t:applicationName=1CV8C,t:computerName=dev,t:connectID=411,SessionID=565,Exception=580392e6-ba49-4280-ac67-fcd6f2180121,Descr='src/vrsbase/src/VResourceInfoBaseImpl.cpp(1143):
580392e6-ba49-4280-ac67-fcd6f2180121: Неправильное имя пользователя или пароль
Ошибка при выполнении запроса POST к ресурсу /e1cib/login:'
ПоказатьУ кого могут быть мысли?
(9)
Не то чтобы я специалист-ка, но Ваш линукс правильно настроен на работу с доменом? Файлик krb5.conf - все верное имеет внутри?
И еще...обычно когда кейтаб создают, предварительно надо SPN сделать...но это не точно, это в общем случае для линуксовых служб, конкретно для 1С - не уверена. Да...почему-то в инструкции от 1С этого нет....ну может так и надо.
На всякий случай ссылку на документацию укажу:https://its.1c.ru/db/v8319doc#bookmark:cs:TI000000106
Там и пример krb5.conf есть.
У кого могут быть мысли?
Не то чтобы я специалист-ка, но Ваш линукс правильно настроен на работу с доменом? Файлик krb5.conf - все верное имеет внутри?
И еще...обычно когда кейтаб создают, предварительно надо SPN сделать...но это не точно, это в общем случае для линуксовых служб, конкретно для 1С - не уверена. Да...почему-то в инструкции от 1С этого нет....ну может так и надо.
На всякий случай ссылку на документацию укажу:
Там и пример krb5.conf есть.
(13)
Если посмотреть выше, то из самой ОС корректно проходит проверка авторизации через Kerberos, а именно:
Если бы файл krb5.conf был настроен не правильно, то подключение к KDC бы не произошло.
Содержимое krb5.conf
Если посмотреть выше, то из самой ОС корректно проходит проверка авторизации через Kerberos, а именно:
[root@1cl02 ~]# kinit -k -t /opt/1cv8/x86_64/8.3.20.1674/usr1cv8.keytab usr1cv8/1cl02.root.local@ROOT.LOCAL
[root@1cl02 ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: usr1cv8/1cl02.root.local@ROOT.LOCAL
Valid starting Expires Service principal
03/29/2022 13:40:18 03/30/2022 03:40:18 krbtgt/ROOT.LOCAL@ROOT.LOCAL
renew until 03/30/2022 13:40:18
ПоказатьЕсли бы файл krb5.conf был настроен не правильно, то подключение к KDC бы не произошло.
Содержимое krb5.conf
[root@1cl02 ~]# cat /etc/krb5.conf
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = ROOT.LOCAL
dns_lookup_realm = false
dns_lookup_kdc = false
default_tkt_enctypes = rc4-hmac
default_tgs_enctypes = rc4-hmac
[realms]
ROOT.LOCAL = {
kdc = dc1.root.local:88
default_domain = root.local
}
[domain_realm]
root.local = ROOT.LOCAL
.root.local = ROOT.LOCAL
ROOT.LOCAL = ROOT.LOCAL
.ROOT.LOCAL = ROOT.LOCAL
[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf
[appdefaults]
pam = {
debug = true
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = false
krb4_convert = false
}
Показать
Техническая поддержка 1С помогла решить проблему.
Проблема была в файле /etc/hosts
Первым именем для IP адреса должно быть FQDN имя.
Было (не верно)
Стало (верное)
После правки файла и рестарта сервиса авторизация Kerberos заработала
Проблема была в файле /etc/hosts
Первым именем для IP адреса должно быть FQDN имя.
Было (не верно)
[root@1cl02 ~]# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
10.50.43.182 1cl02 1cl02.root.local
Стало (верное)
[root@1cl02 ~]# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
10.50.43.182 1cl02.root.local
После правки файла и рестарта сервиса авторизация Kerberos заработала
Доброго времени суток. Настраиваю доменную аутентификацию. Настроил пользователя в домене. Использовал такие команды
В домене
ktpass /crypto ALL /princ usr1cv8/qwe.domain.local@DOMAIN.LOCAL /mapuser usr1cv8 /pass **** /out C:\usr1cv83.keytab
и такую же команду с принципалом.
Права накинуты корректно.
Сервер linux ubuntu 20.04
Не работает аутентификация.
В ТЖ выдает следующую ошибку:
35:55.638003-0,EXCP,2,process=rphost,p:processName=T3,OSThread=95107,t:clientID=23,t:applicationName=1CV8C,t:computerName=W10-23,t:connectID=4,Descr='GSS-API error gss_acquire_cred: Unspecified GSS failure. Minor code may provide more information
'
35:55.638004-0,EXCP,2,process=rphost,p:processName=T3,OSThread=95107,t:clientID=23,t:applicationName=1CV8C,t:computerName=W10-23,t:connectID=4,Descr='GSS-API error gss_acquire_cred: No key table entry found matching usr1cv8/qwe.domain.local@
'
35:55.644001-0,EXCP,2,process=rphost,p:processName=T3,OSThread=95107,t:clientID=23,t:applicationName=1CV8C,t:computerName=W10-23,t:connectID=4,SessionID=4,AppID=1CV8C,Exception=a01f465c-ed70-442e-ada5-847668d7a41c,Descr='src/vrsbase/src/VResourceInfoBaseServerImpl.cpp(2617):
a01f465c-ed70-442e-ada5-847668d7a41c: Идентификация пользователя не выполнена
Неправильное имя или пароль пользователя'
в конфигураторе при вводе стоит \\DOMAIN.LOCAL\asd
файлик книт проглатывает и все хорошо.
И в /etc/hosts стоит FQDN имя первое.
Аутентификация не проходит.
П.С на аналогичном сервере все работает прекрасно.
В домене
ktpass /crypto ALL /princ usr1cv8/qwe.domain.local@DOMAIN.LOCAL /mapuser usr1cv8 /pass **** /out C:\usr1cv83.keytab
и такую же команду с принципалом.
Права накинуты корректно.
Сервер linux ubuntu 20.04
Не работает аутентификация.
В ТЖ выдает следующую ошибку:
35:55.638003-0,EXCP,2,process=rphost,p:processName=T3,OSThread=95107,t:clientID=23,t:applicationName=1CV8C,t:computerName=W10-23,t:connectID=4,Descr='GSS-API error gss_acquire_cred: Unspecified GSS failure. Minor code may provide more information
'
35:55.638004-0,EXCP,2,process=rphost,p:processName=T3,OSThread=95107,t:clientID=23,t:applicationName=1CV8C,t:computerName=W10-23,t:connectID=4,Descr='GSS-API error gss_acquire_cred: No key table entry found matching usr1cv8/qwe.domain.local@
'
35:55.644001-0,EXCP,2,process=rphost,p:processName=T3,OSThread=95107,t:clientID=23,t:applicationName=1CV8C,t:computerName=W10-23,t:connectID=4,SessionID=4,AppID=1CV8C,Exception=a01f465c-ed70-442e-ada5-847668d7a41c,Descr='src/vrsbase/src/VResourceInfoBaseServerImpl.cpp(2617):
a01f465c-ed70-442e-ada5-847668d7a41c: Идентификация пользователя не выполнена
Неправильное имя или пароль пользователя'
в конфигураторе при вводе стоит \\DOMAIN.LOCAL\asd
файлик книт проглатывает и все хорошо.
И в /etc/hosts стоит FQDN имя первое.
Аутентификация не проходит.
П.С на аналогичном сервере все работает прекрасно.
Может быть кому поможет, ибо мне помогло на Ubuntu 22.04
Замените /etc/hostname на полное FQDN имя, пример:
Было: 1c01
Стало: 1c01.corp.domain.ru
Ребут.
Проверяем:
root@1c01:/home/admin-itilion# hostnamectl status
Static hostname: 1c01.corp.domain.ru
Icon name: computer-desktop
Chassis: desktop
Machine ID:
Boot ID:
Operating System: Ubuntu 22.04.5 LTS
Kernel: Linux 5.15.0-130-generic
Architecture: x86-64
Hardware Vendor: ASUS
Hardware Model: System Product Name
Замените /etc/hostname на полное FQDN имя, пример:
Было: 1c01
Стало: 1c01.corp.domain.ru
Ребут.
Проверяем:
root@1c01:/home/admin-itilion# hostnamectl status
Static hostname: 1c01.corp.domain.ru
Icon name: computer-desktop
Chassis: desktop
Machine ID:
Boot ID:
Operating System: Ubuntu 22.04.5 LTS
Kernel: Linux 5.15.0-130-generic
Architecture: x86-64
Hardware Vendor: ASUS
Hardware Model: System Product Name
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот