Апрель 27, 2018, 08:35:07

Автор Тема: 1C 8.2.12-96 на Ubuntu Server 10.04 x64 и аутентификация в домене AD.  (Прочитано 46663 раз)

SeaLancer

  • Опытный пользователь
  • ***
  • Сообщений: 115
  • Карма: +1/-0
    • Просмотр профиля
Столкнулись с этой же проблемой при переходе с 8.1 на 8.2. Делали всё по инструкции, тесты успешны, 1С авторизует только через пароль. В итоге опытным путём было обнаружено, что если в настройках пользователя 1С в разделе Аутентификация Windows в ручную изменить предлагаемый путь вида \\DOMAIN\user на \\DOMAIN.RU\user авторизация начинает работать. В указанном примере DOMAIN.RU - полное имя нашего домена.
!!!!! Охренеть! Ведь пробовал же раньше так, не работало! А тепереь вообще без проблем аутентифицировалось!

P.S. Хотя я , возможно, пробовал так делать на предыдущей платформе, а на текущей (8.2.13.219) только стандартную настройку проводил.
« Последнее редактирование: Июль 11, 2011, 06:54:14 от SeaLancer »

SeaLancer

  • Опытный пользователь
  • ***
  • Сообщений: 115
  • Карма: +1/-0
    • Просмотр профиля
Блин, обновили до 14.519 платформу, опять не работает... :-(

SeaLancer

  • Опытный пользователь
  • ***
  • Сообщений: 115
  • Карма: +1/-0
    • Просмотр профиля
UPD.
1) Пересоздал файлик keytab.
2) chown -R usr1cv82:grp1cv82 /opt/1c

Все работает.
« Последнее редактирование: Август 10, 2011, 05:53:01 от SeaLancer »

Virtul

  • Новичок
  • *
  • Сообщений: 6
  • Карма: +0/-0
    • Просмотр профиля
Доброго дня, ставил 1С по этому ману, с керберосом вроде никаких проблем нет, всё работает штатно
Но вот в логах всё тот же No principal in keytab matches desired name и, соответственно, доменная аутентификация не работает =(

Подскажите зачем вообще нужна учётка в домене (usr1cv8)? И, тем более, зачем её сопоставлять с локальной учёткой на сервере?
По ману получается нужно её просто создать, но нигде не использовать...

SeaLancer

  • Опытный пользователь
  • ***
  • Сообщений: 115
  • Карма: +1/-0
    • Просмотр профиля
Доброго дня, ставил 1С по этому ману, с керберосом вроде никаких проблем нет, всё работает штатно
Но вот в логах всё тот же No principal in keytab matches desired name и, соответственно, доменная аутентификация не работает =(

Подскажите зачем вообще нужна учётка в домене (usr1cv8)? И, тем более, зачем её сопоставлять с локальной учёткой на сервере?
По ману получается нужно её просто создать, но нигде не использовать...
На сколько я понимаю, с помощью учетной записи usr1cv82 в домене сервер 1С проверяет пользователей в АД. Т.е. к этой учетке привязан keytab, с помощью которого мы получаем kerberos ticket без ввода пароля (в обычном варианте, получение тикета выполняется командой kinit "юзверь" и вводом пароля этого юзверя).

Выложите содержание krb.conf/ А аткже проверьте ещё раз получение тикета с помощью логина-пароля, а затем с помощью фалика keytab

Virtul

  • Новичок
  • *
  • Сообщений: 6
  • Карма: +0/-0
    • Просмотр профиля
На сколько я понимаю, с помощью учетной записи usr1cv82 в домене сервер 1С проверяет пользователей в АД. Т.е. к этой учетке привязан keytab, с помощью которого мы получаем kerberos ticket без ввода пароля (в обычном варианте, получение тикета выполняется командой kinit "юзверь" и вводом пароля этого юзверя).

Выложите содержание krb.conf/ А аткже проверьте ещё раз получение тикета с помощью логина-пароля, а затем с помощью фалика keytab

т.е. этой учётке в домене никаких прав давать не нужно?

cat /etc/krb5.conf
Цитировать
[libdefaults]
default_realm = CM
dns_lookup_realm = false
dns_lookup_kdc = true
ticket_lifetime = 24h
forwardable = yes
default_tgs_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
default_tkt_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
preferred_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC

[domain_realm]
.cm = CM
cm = CM
.CM = CM
CM = CM

[dbdefaults]
ldap_kerberos_container_dn = "cn=kerberos,ou=kdcroot,dc=cm"

[dbmodules]
cm = {
    db_library = kldap
    ldap_kdc_dn = cn=kdc,ou=kdcroot,dc=cm
    ldap_kadmind_dn = cn=kadmin,ou=kdcroot,dc=cm
    ldap_service_password_file = /var/lib/kerberos/krb5kdc/cm.ldapkey
    ldap_servers = ldap://localhost/
    ldap_conns_per_server = 5
}
[realms]
CM = {
    default_domain = cm
    database_module = cm
}

[kdc]
Profile = /var/kerberos/krb5kdc/kdc.conf

[appdefaults]
Pam = {
    Debug = true
    ticket_lifetime = 36000
    renew_lifetime = 36000
    forwardable = false
    krb4_convert = false
}

с получением билетиков вроде проблемы нет:
[root@vcisrv05 /]# kinit admin
Password for admin@CM:
[root@vcisrv05 /]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin@CM

Valid starting     Expires            Service principal
09/20/11 10:33:51  09/20/11 20:33:56  krbtgt/CM@CM
        renew until 09/21/11 10:33:51


klist -e -k -t /opt/1C/v8.2/i386/usr1cv82.keytab
Цитировать
Keytab name: FILE:/opt/1C/v8.2/i386/usr1cv82.keytab
KVNO Timestamp         Principal
---- ----------------- --------------------------------------------------------
   4 01/01/70 03:00:00 usr1cv82/vcisrv05.cm@CM (ArcFour with HMAC/md5)


kinit -k -t /opt/1C/v8.2/i386/usr1cv82.keytab usr1cv82/vcisrv05.cm@CM
не выдаёт ничего

klist
Цитировать
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: usr1cv82/vcisrv05.cm@CM

Valid starting     Expires            Service principal
09/20/11 10:45:05  09/20/11 20:45:07  krbtgt/CM@CM
        renew until 09/21/11 10:45:05

Virtul

  • Новичок
  • *
  • Сообщений: 6
  • Карма: +0/-0
    • Просмотр профиля
и в логах вот это:
02:28.9215-0,EXCP,2,process=rphost,t:clientID=21,Descr='GSS-API error gss_acquire_cred: Unspecified GSS failure.  Minor code may provide more information
02:28.9216-0,EXCP,2,process=rphost,t:clientID=21,Descr='GSS-API error gss_acquire_cred: No principal in keytab matches desired name

и ещё
KRB5CCNAME environment variable is not set!
« Последнее редактирование: Сентябрь 20, 2011, 07:39:45 от Virtul »

shurale

  • Новичок
  • *
  • Сообщений: 40
  • Карма: +1/-0
    • Просмотр профиля
Все работает. Версия 1С 8.2.13.202. Действительно пользователя надо прописывать \\FQDN домена\пользователь. Спасибо за подсказки.

Virtul

  • Новичок
  • *
  • Сообщений: 6
  • Карма: +0/-0
    • Просмотр профиля
Все работает. Версия 1С 8.2.13.202. Действительно пользователя надо прописывать \\FQDN домена\пользователь. Спасибо за подсказки.
а можно Ваш krb5.conf увидеть?

в отличии от этой статьи на команду klist -e -k -t /opt/1C/v8.2/x86_64/usr1cv82.keytab у меня выводится
Цитировать
4 01/01/70 03:00:00 usr1cv82/vcisrv05.cm@CM (DES cbc mode with CRC-32)
а в статье DES cbc mode with RSA-MD5
может из-за этого проблема?...
поменял в krb5.conf строки:
default_tkt_enctypes = des-cbc-crc des-cbc-md5
default_tgs_enctypes = des-cbc-crc des-cbc-md5
не помогло =(

SeaLancer

  • Опытный пользователь
  • ***
  • Сообщений: 115
  • Карма: +1/-0
    • Просмотр профиля
Вот мой текущий рабочий файлик, единственное замечание, у меня CentOS 5.5 (платформа 533) а не убунта:

[root@mskdb1 httpd]# 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 = SAR.BIZ
 dns_lookup_realm = false
 dns_lookup_kdc = false
 default_tkt_enctypes = rc4-hmac
 default_tgs_enctypes = rc4-hmac

[realms]
 SAR.BIZ = {
  kdc = mskdc1.sar.biz:88
  default_domain = sar.biz
 }

[domain_realm]
 .sar.biz = .SAR.BIZ
 sar.biz = SAR.BIZ
 .SAR.BIZ = .SAR.BIZ
 SAR.BIZ = SAR.BIZ

[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf

[appdefaults]
 pam = {
   debug = true
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = false
   krb4_convert = false
 }
[root@mskdb1 httpd]#
« Последнее редактирование: Октябрь 03, 2011, 01:23:01 от SeaLancer »

Virtul

  • Новичок
  • *
  • Сообщений: 6
  • Карма: +0/-0
    • Просмотр профиля
Вот мой текущий рабочий файлик, единственное замечание, у меня CentOS 5.5 (платформа 533) а не убунта:
у меня тоже не убунта
всё равно CRC-32 и не работает авторизация
перейти чтоли на другой дистрибутив...

SeaLancer

  • Опытный пользователь
  • ***
  • Сообщений: 115
  • Карма: +1/-0
    • Просмотр профиля
Вот мой текущий рабочий файлик, единственное замечание, у меня CentOS 5.5 (платформа 533) а не убунта:
у меня тоже не убунта
всё равно CRC-32 и не работает авторизация
перейти чтоли на другой дистрибутив...
В процессе поиска решения по аутентификации, я набредал на статью, где описана активация дополнительных алгоритмов на контроллере домена, я это в свое время проделывал (правда тогда это ничего не изменило)... Но сейчас уже не помню, что и как, помню что это касалось DC на Windows 2008.
Может поумолчанию контроллер не поддерживает HMAC/md5, поэтому при генерации кейтаба он и не использовал его...

У меня выводит на кейтаб вот это:

[root@mskdb1 httpd]# klist -e -k -t /opt/1C/v8.2/x86_64/usr1cv82.keytab
Keytab name: FILE:/opt/1C/v8.2/x86_64/usr1cv82.keytab
KVNO Timestamp         Principal
---- ----------------- --------------------------------------------------------
  28 01/01/70 03:00:00 usr1cv82/mskdb1.sar.biz@SAR.BIZ (ArcFour with HMAC/md5)
[root@mskdb1 httpd]#
« Последнее редактирование: Сентябрь 28, 2011, 12:57:52 от SeaLancer »

SeaLancer

  • Опытный пользователь
  • ***
  • Сообщений: 115
  • Карма: +1/-0
    • Просмотр профиля
На 533 платформе опять не работает аутентификация. ******* как же надоели эти **** из 1с со своими кривыми руками....

damon

  • Новичок
  • *
  • Сообщений: 10
  • Карма: +0/-0
    • Просмотр профиля
    • Email
Работает авторизация  в 533 релизе. CentOS 6.0 . Windows 2003R2
CentOS Linux release 6.0 (Final)
2.6.32-131.12.1.el6.x86_64 #1 SMP Mon Sep 26 10:13:43 BST 2011 x86_64 x86_64 x86_64 GNU/Linux
postgresql-9.0.3-3.1C

SeaLancer

  • Опытный пользователь
  • ***
  • Сообщений: 115
  • Карма: +1/-0
    • Просмотр профиля
Работает авторизация  в 533 релизе. CentOS 6.0 . Windows 2003R2
Значит дело в Центосе, а точнее в версии кербероса, который он использует. В 5,5 версия 1.6.1 и обновлений нет.
А какой алгоритм использовали при генерации keytab?
« Последнее редактирование: Октябрь 13, 2011, 08:06:26 от SeaLancer »