Меню

Ошибка mit kerberos v5 ошибка инициализации аутентификационных данных krb5 пользователя

— ОШИБКА:

Не удалось отправить широковещательное сообщение ‘bc-check-dc:.domena.net’:Сеть недоступна

Сеть не настроена или настроена не полностью:

Настройка сети через interfaces:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
     address i.i.i.i
     netmask 255.255.m.m
     gateway g.g.g.g

Если во время настройки и перезагрузки сети появляются ошибки, например «Failed to bring up eth0», то можно «очистить» интерфейс командой:

ip addr flush eth0

ald-client join


— ОШИБКА:

Не удалось отправить широковещательное сообщение ‘bc-check-dc:.da’: Сеть недоступна

— ОШИБКА:

Astra Linux Directory не сконфигурирована.

Заполните конфигурационный файл ‘/etc/ald/ald.conf’.

Не указан gateway в настройках сети клиента.

Не заполнен /etc/ald/ald.conf

ald-client join


— ОШИБКА:

Не удалось отправить широковещательное сообщение ‘bc-check-dc:.da’: Сеть недоступна

— ПРЕДУПРЕЖДЕНИЕ:

ALD сервер домена ‘.da’ не обнаружен.

— ОШИБКА:

Не удалось отправить широковещательное сообщение ‘bc-check-dc:.da’: Сеть недоступна

Не указан gateway в настройках сети клиента.

ald-client status


— ОШИБКА:

Не удалось отправить широковещательное сообщение ‘bc-check-dc:.da’: Сеть недоступна

— ПРЕДУПРЕЖДЕНИЕ:

ALD сервер домена ‘.da’ не обнаружен.

Не указан gateway в настройках сети клиента.

ald-client join server.da


— ПРЕДУПРЕЖДЕНИЕ:

Ошибка разрешения имени компьютера ‘server.da’.

Некорректно настроены имя и ip адрес, например в /etc/hosts отсутствует длинное имя машин:

127.0.0.1 localhost
192.168.1.1  myserver
192.168.1.2	 client

ald-init init


— ОШИБКА:

Триггер ‘ald-cfg-nfs:DoNFSInitFS’ вызвал исключение!

Ошибка RPC: Ошибка Krb5 сервера ALD: Ошибка проверки сообщения KRB-PRIV. в ADKrb5Server.cpp:248(decode)

:> Incorrect net address

:> (rpc-creds)

Ошибка может быть вызвана применением антивируса или изменением правил iptables.

ald-init init или ald-client join


— ОШИБКА: Ошибка аутентификации пользователя ‘admin/admin’: Ошибка MIT Kerberos V5:

Ошибка инициализации интерфейса администрирования kadm5. в ALDKadm5Connection.cpp:345(ConnectPassword)

:> GSS-API (or Kerberos) error

Некорректно настроены имя и ip адрес, например в /etc/hosts (разрешение имен может быть настроено и с помощью сервера DNS) следует указать ip, длинное и короткое имя и исключить запись «127.0.1.1 myserver»:

127.0.0.1 localhost
192.168.1.1 myserver.example.ru myserver
192.168.1.2	client.example.ru client

В /etc/ald/ald.conf не указаны длинное имя машины и домен:

DOMAIN=.example.ru
 
SERVER=myserver.example.ru

Недостаточно энтропии во время инициализации домена.

  • При вводе клиента (ald-client join), ошибка(345) возникает из-за несовпадения времени на машинах.

Утилита hostname должна выдавать короткое имя. После внесения изменений в файл /etc/hostname необходимо перезагрузить машину.

ald-init init или ald-client join


— ОШИБКА:

Ошибка OpenLDAP при GSSAPI соединения — Local error в ALDLDapConnection.cpp:734(Connect)

:> SASL(1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server ldap/dc.test.test not found in Kerberos database)

Разрешение имен настроено не верно, перепутаны местами длинное и короткое имя, пример:

127.0.0.1 localhost
192.168.1.1  myserver myserver.example.ru
192.168.1.2  client client.example.ru

ald-admin test-integrity —admin=ald-admin


Вход от имени пользователя ‘ald-admin’…

Введите пароль администратора ALD ‘ald-admin’: *

Проверка конфигурации домена…………………………….ok

Проверка модулей LDAP…………………………………..ok

Проверка индексов LDAP………………………………….ok

Проверка ограничений уникальности LDAP……………………ok

Проверка системных принципалов…………………………..— ОШИБКА:

Ошибка RPC: Ошибка MIT Kerberos V5: Не удалось получить список принципалов Kerberos. в ALDKadm5Connection.cpp:924(Principals)

:> Operation requires «list» privilege

:> (rpc-princ-list)

После добавления astra-admin в ALLOWED_LOCAL_GROUPS и выполнения ald-init commit-config снять права администратора домена, применить, установить права администратора домена, применить.

  • При выполнении: ald-client commit-config

— ОШИБКА:
Ошибка OpenLDAP при запросе ‘cn=client.ru,ou=hosts,dc=ru (objectClass=x-ald-host-object)’ — Can’tcontact LDAP server в ALDLdapConnection.cpp:213(Search)

На клиенте в файле /etc/hosts не внесены данные о резервном сервере.

I’m working on configuring SSO in obiee 11.1.1.7.14, where in which I’m facing issue in the step while configuring krb5.conf and executing the kinit command.

few notes regarding the Active Directory

  • we have more than one domain controller and to balance the request we are maintaing the load balancer with port 3269.
  • And the integration between obiee and MSAD is successfully done with the load balancer name as host and port as 3269.
  • and few certificates have been added in the demotrust.jks and to the ovd store and SSL is enabled in the new provider.
  • Keytab file generated and placed in obiee domain home, krb5.conf and krb5Login.conf file modified accordingly.

I have created the keytab file and placed it in the obiee domain home, then modified the krb5.conf by keeping kdc as the one of the ip address of the domain controller and admin-server as the name of the domain controller. And while executing the

kinit -V -k -t /location/keytabfile.keytab HTTP/obiee_host_name

i have got and error «kinit(v5): Client not found in Kerberos database while getting initial credentials» . Please share your ideas/suggestions to solve this issue.

thanks in advance

Robin Moffatt's user avatar

asked Oct 8, 2014 at 12:33

user3714699's user avatar

1

We have a Active Directory server where 2 domain controllers are used for it. And a load balancer with port 3269 is used to connect to the Active directory from OBIEE and similar connections can be used in the krb5.conf and where ever required.
And consider the base domain as DOM1 and all our groups are created under sub-domain SUBDOM. So the SPN is set at the SUBDOM.DOM1.COM.

Here are the few suggestions we have followed to integrate AD with OBIEE and Solved the most of the kinit issues

  1. Instead of specifying the principal name with the absolute path, just mention with the accout_name@FullyQualifiedDomainName.

  2. Changes in KRB5.conf

    1. Since the attribute «crypto» is specified as «all» while creating keytab and setting the SPN, all the encryption types which is present in the keytab file as to be mentioned in the krb5.conf (default_tkt_enctypes and default_tgs_enctypes).

    2. Have included the primary domain controller IP address for the attribute kdc in [realms] section, this will be same as Michael-O specified in point 2.

    3. in [domain_realm] of krb5.conf keep as .subdom.dom1.com=DOM1.COM.

    4. include the host name of load balancer name in the admin_server attribute of [realms] section in krb5.conf

Once all the above changes are done, most of the kinit issues would be solved and the kinit command will be executed successfully by creating the initial ticket in the desired directory.

Stephen Ostermiller's user avatar

answered Nov 14, 2014 at 12:20

user3714699's user avatar

user3714699user3714699

611 gold badge1 silver badge3 bronze badges

First of all, this is serverfault.

  1. 3269 is not Kerberos, this is SSL-backed global catalog. Pure LDAP not Kerberos. Not interesting here.
  2. Do not put KDC IP addresses in the krb5.conf but rather rely on DNS SRV records just like Windows does.
  3. You cannot kinit with a SPN. kinit expects a UPN (from AD) from the keytab. Something like accountname$@EXAMPLE.COM if this is a machine account. Always remember, a SPN is always bound to some account, whether machine or functional.

answered Oct 10, 2014 at 10:00

Michael-O's user avatar

Michael-OMichael-O

18k6 gold badges54 silver badges119 bronze badges

I updated my master key for my Kerberos 5 server following the MIT Kerberos 5 instructions. I restarted the kdc and kadmind services and used krb5-prop to push the changes to the other servers.

Now I am unable to connect with kadmin from any server, including the admin server:

$kadmin
Authenticating as principal jacob/admin@THE.REALM with password.
Password for jacob/admin@THE.REALM:
kadmin: GSS-API (or Kerberos) error while initializing kadmin interface

From my searching I’ve found that a common reason for this is time syncronization issues, but the machines are matching within a second and it fails even from the server running kadmind.

I’m not sure how to troubleshoot this. My version of kadmind doesn’t have any kind of debug argument or verbose logging level that I’ve found. I’ve tried running it from the command line with -nofork and it’s very quiet there.

The password is accepted. I can kinit as the target principle and if I type the password wrong it tells me.

kadmin: Incorrect password while initializing kadmin interface

If The kadmind service isn’t running it also gives a different error.

kadmin: Communication failure with server while initializing kadmin interface

I didn’t test kadmin just before updating the master password, but I’ve used it recently and no other configuration changes have been made. I’ve tried checking my key version numbers (kvno) and they appear to be correct.

What else could be causing this? Where else can I check? How can I debug kadmind?

Debian 8, krb5-admin-server 1.12.1.

Как и многие другие протоколы аутентификации, вы часто можете столкнуться с проблемами при настройке Linux для аутентификации с помощью Kerberos. Конечно, проблемы всегда различаются в зависимости от вашего этапа аутентификации.

В этой статье рассматриваются некоторые проблемы, которые могут возникнуть. Некоторые из вопросов, которые мы включаем здесь:

  • Проблемы, возникающие при настройке системы
  • Проблемы, возникающие из-за клиентских утилит и сбоев в использовании или управлении средой Kerberos
  • Проблемы с шифрованием KDC
  • Проблемы с клавиатурой

Примечательно, что проблемы, с которыми вы можете столкнуться при использовании Linux Kerberos, часто начинаются на этапе установки. И единственный способ свести к минимуму проблемы с настройкой и мониторингом — это выполнить следующие шаги:

Шаг 1: Убедитесь, что на обеих машинах правильно установлен работающий протокол Kerberos.

Шаг 2: Синхронизируйте время на обеих машинах, чтобы убедиться, что они работают в одинаковых временных рамках. В частности, используйте сетевую синхронизацию времени (NTS), чтобы компьютеры находились в пределах 5 минут друг от друга.

Шаг 3: Проверьте, все ли узлы в сетевой службе домена (DNS) имеют правильные записи. При этом убедитесь, что каждая запись в файле хоста имеет соответствующие IP-адреса, имена хостов и полные доменные имена (FQDN). Хорошая запись должна выглядеть так:

IP_address 
FQDN hostname

Устранение неполадок клиентской утилиты Linux Kerberos

Если вам сложно управлять клиентскими утилитами, вы всегда можете использовать следующие три метода для решения проблем:

Способ 1: использование команды Klist

Команда Klist поможет вам визуализировать все билеты в любом кэше учетных данных или ключи в файле вкладки ключей. Получив билеты, вы можете отправить данные для завершения процесса аутентификации. Вывод Klist для устранения неполадок клиентских утилит будет выглядеть следующим образом:

bash-2.05$ klist
Ticket cache: /tmp/krb5cc_1002
Default principal: HTTP/sol8sunone.test.com @TEST.COM
Valid starting                    Expires                    Service principal

Tue Nov 22 16:14:03 2022         Tue Nov 22 22:46:03 2014   krbtgt/ www.MaxDestroyer@ANDREYEX.RU

Способ 2: использование команды Kinit для проверки проблем на клиенте KDC

Вы также можете использовать команду Kinit, чтобы подтвердить, есть ли у вас какие-либо проблемы с вашим хостом KDC и клиентом KDC. Утилита Kinit поможет вам получить и кэшировать билет на выдачу билетов для субъекта-службы и пользователя. Проблемы с клиентской утилитой всегда могут возникать из-за неправильного имени участника или неправильного имени пользователя.

Ниже приведен синтаксис Kinit для принципала пользователя:

kinit username

Вышеупомянутая команда запросит пароль, поскольку она создает участника-пользователя. При выполнении команды убедитесь, что вы заменили имя пользователя действительной записью из вашего каталога.

С другой стороны, синтаксис Kinit для субъекта-службы аналогичен деталям на снимке экрана ниже. Обратите внимание, что это может варьироваться от одного хоста к другому:

kinit -k[-t keytab_file] principal_name

Интересно, что команда Kinit для субъекта-службы не будет запрашивать никаких паролей, поскольку для проверки подлинности субъекта-службы используется файл вкладки ключа в квадратных скобках.

Способ 3: использование команды kinit для проверки проблем с SMP

Вы также можете запустить приведенную ниже команду независимо от того, сработала ли приведенная выше команда комплекта или нет. Это помогает определить, есть ли какие-либо проблемы с хостом SMP. Примечательно, что это более полезно при тестировании вашего сервера на mail.company.com.

Ваша команда kinit будет иметь следующую структуру:

kbd>kinit -S host/mail.company.com@SERVER01.COMPANY.COM

Способ 4: использование команды ktpass

Иногда проблема может быть связана с вашими паролями. Чтобы убедиться, что это не является причиной ваших проблем с Linux Kerberos, вы можете проверить версию утилиты ktpass.

Устранение проблем с поддержкой KDC

Kerberos часто может дать сбой из-за множества проблем. Но иногда проблемы могут быть связаны с поддержкой шифрования KDC. Примечательно, что такая проблема приведет к следующему сообщению:

kinit: KDC has no support for encryption type while getting initial credentials

Если вы получили указанное выше сообщение, выполните следующие действия:

  • Убедитесь, что ваши настройки KDC блокируют или ограничивают какие-либо типы шифрования.
  • Убедитесь, что в вашей учетной записи сервера проверены все типы шифрования.

Устранение неполадок с Keytab

Вы можете предпринять следующие шаги, если у вас возникнут какие-либо проблемы с ключевыми вкладками:

Шаг 1: Убедитесь, что расположение и имя файла вкладки ключа для хоста аналогичны данным в файле krb5.conf.

Шаг 2: Убедитесь, что хост и клиентские серверы имеют основные имена.

Шаг 3: Подтвердите тип шифрования перед созданием файла вкладки ключа.

Шаг 4: Проверьте правильность файла вкладки ключа, выполнив приведенную ниже команду kinit:

kinit -t C:LinuxMaxDestroyer.keytab HTTP/MaxDestroyer@ANDREYEX.RU

kinit host/fqdn@ANDREYEX.COM

Приведенная выше команда не должна возвращать ошибку, если у вас есть действительный файл вкладки ключа. Но в случае ошибки вы можете проверить действительность имени участника-службы с помощью этой команды:

kinit -t C:LinuxMaxDestroyer.keytab HTTP/MaxDestroyer@ANDREYEX.RU

kinit host/fqdn@ANDREYEX.COM

Вышеупомянутая утилита предложит вам ввести пароль. Отсутствие запроса пароля означает, что ваше имя участника-службы недействительно или его невозможно идентифицировать. Как только вы введете правильный пароль, команда не вернет никаких ошибок.

Выше приведены некоторые распространенные проблемы, с которыми вы можете столкнуться при настройке или аутентификации с помощью Linux Kerberos. Эта статья также содержит возможные решения для каждой из проблем, с которыми вы можете столкнуться.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии

А вот еще интересные материалы:

  • Яшка сломя голову остановился исправьте ошибки
  • Ясность цели позволяет целеустремленно добиваться намеченного исправьте ошибки
  • Ясность цели позволяет целеустремленно добиваться намеченного где ошибка
  • Ошибка msvcp100 dll что делать windows 10 64 bit как исправить
  • Ошибка missing operating system на ноутбуке