Ноябрь 24, 2017, 01:08:42

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

damon

  • Новичок
  • *
  • Сообщений: 10
  • Карма: +0/-0
    • Просмотр профиля
    • Email
по дефолту

ktpass -princ usr1cv82/dbs.domain.local@DOMAIN.LOCAL -mapuser user1c -pass password -out usr1cv82.keytab
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
    • Просмотр профиля
В общем я лох чилийский и мне очень стыдно.
Зачем то в конфиге кербероса я поставил точку, которая мне казалась логичной. Итог, керберос не работал, а я убил 3 дня на поиски:

Было:

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

Надо:

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


Короче, СентОС 5.5 + 537-ой релиз, полет нормальный.

shurale

  • Новичок
  • *
  • Сообщений: 40
  • Карма: +1/-0
    • Просмотр профиля
2 Virtul. Вот мой krb5.conf

cat /etc/krb5.conf

[libdefaults]
   default_realm = GEPVOCE.LOCAL
   dns_lookup_realm = false
   dns_lookup_kdc = false
   default_tkt_enctypes = rc4-hmac
   default_tgs_enctypes = rc4-hmac

# The following krb5.conf variables are only for MIT Kerberos.
   krb4_config = /etc/krb.conf
   krb4_realms = /etc/krb.realms
   kdc_timesync = 1
   ccache_type = 4
   forwardable = true
   proxiable = true

[realms]
   GEPVOCE.LOCAL = {
      kdc = vega.gepvoce.local:88
      kdc = gamma.gepvoce.local:88
      admin_server = vega.gepvoce.local
      default_domain = gepvoce.local
   }

[domain_realm]
   .gepvoce.local = GEPVOCE.LOCAL
   gepvoce.local = GEPVOCE.LOCAL
   GEPVOCE.LOCAL = GEPVOCE.LOCAL
   .GEPVOCE.LOCAL = GEPVOCE.LOCAL

[login]
   krb4_convert = true
   krb4_get_tickets = false

Ситх

  • Новичок
  • *
  • Сообщений: 1
  • Карма: +0/-0
    • Просмотр профиля
За прошедший месяц кто-нибудь достиг успехов в аутентификации в домене?

SeaLancer

  • Опытный пользователь
  • ***
  • Сообщений: 115
  • Карма: +1/-0
    • Просмотр профиля
На CentOS 5.5, 5.6 и 6.0 все работает корректно, на Ubuntu проблемы, потому лучше выбрать другой дистрибутив.

zmn

  • Новичок
  • *
  • Сообщений: 1
  • Карма: +0/-0
    • Просмотр профиля
Может уже и поздно отвечаю, но по поводу вот этой ошибки:

Цитировать
09:07.5331-0,EXCP,2,process=rphost,t:clientID=6,Descr='GSS-API error gss_acquire_cred: No principal in keytab matches desired name'


скорей всего проблема в том что в файле /etc/hosts не прописано fqdn имя.
Например там должно вместо имени  (srv1c)  надо писать полностью имя:  (srv1c.example.com) то есть оно должно совпадать с principal именем в файле keytab (ktpass -princ usr1cv82/srv1c.example.com@EXAMPLE.COM -mapuser usr1cv8 -pass pass1cv8 -out usr1cv82.keytab) , а оно соответственно srv1c.example.com

Хотелось бы получить подтверждение этого предположения.
« Последнее редактирование: Март 30, 2012, 08:46:57 от zmn »

vaikea

  • Новичок
  • *
  • Сообщений: 1
  • Карма: +0/-0
    • Просмотр профиля
возможно кому-то будет полезна следующая информация.
у меня debian 6
делал все по инструкции, но, как водится, ничего не заработало.
сначала сервер 1с ругался на отсутствие libgssapi_krb5.so, после создания симлинка - на wrong principal.
klist,kinit,wbinfo и проч. - работает отлично. с DNS проблем нет. Пользователя прописывал и как //домен/юзер, и как //домен.полное.имя/юзер. Тоже не помогло.
А помогло вот что! Я взял и скачал krb5libs от 5й центоси.
Например, здесь: http://mirror.centos.org/centos/5/os/x86_64/CentOS/krb5-libs-1.6.1-70.el5.i386.rpm
взял оттуда libgssapi_krb5.so.2.2
переименовал в libgssapi_krb5.so.2.3
скопировал его в /usr/lib
создал симлинк libgssapi_krb5.so.
после таких плясок все заработало. :) УРА!

railman

  • Новичок
  • *
  • Сообщений: 1
  • Карма: +0/-0
    • Просмотр профиля
Прошу прощения за глупый вопрос, а зачем вообще нужна аутентификация в домене, если можно заходить в базу через логин и пароль?

altuhov

  • Новичок
  • *
  • Сообщений: 1
  • Карма: +0/-0
    • Просмотр профиля
Если у кого ещё проблема Wrong principal in request.

Так вот. Если ошибка "Wrong principal in request" - значит КЛИЕНТ (платформа 1С на рабочей станции) неверно отправляет имя домена или неполное имя домена.

Например. Имеем рабочую станцию Windows 7 или сервер Windows 2008 R2.
Попробуйте залогиниться на рабочей станции (войти в Windows) как user@domain (без .local). И получите ошибку Wrong principal in request.

Но стоит залогиниться с полным именем user@domain.local и всё работает.

Решения чтобы работало и user@domain пока не нашёл.