Ошибка 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 не внесены данные о резервном сервере.

Источник

— ОШИБКА:

Не удалось отправить широковещательное сообщение ‘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

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

—

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) возникает из-за несовпадения времени на машинах.

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)

—

При выполнении: 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

asked Oct 8, 2014 at 12:33

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

Instead of specifying the principal name with the absolute path, just mention with the accout_name@FullyQualifiedDomainName.
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.

answered Nov 14, 2014 at 12:20

user3714699user3714699

611 gold badge1 silver badge3 bronze badges

First of all, this is serverfault.

3269 is not Kerberos, this is SSL-backed global catalog. Pure LDAP not Kerberos. Not interesting here.
Do not put KDC IP addresses in the krb5.conf but rather rely on DNS SRV records just like Windows does.
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-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.

Источник

Содержание

Astra Linux 1.5 проблема с ALD
Astra.
Astra Linux 1.5 проблема с ALD
Astra Linux 1.5 проблема с ALD
Ошибки инициализации домена
17 Комментариев
Дмитрий Анохов
Дмитрий Анохов
Дмитрий Анохов
Дмитрий Анохов
Дмитрий Анохов
Константин Ковалевский
Дмитрий Андреев
Дмитрий Андреев
Дмитрий Анохов
Дмитрий Андреев
Константин Ковалевский
Егор Сураев
Константин Ковалевский
Егор Сураев
Дмитрий Анохов
Марина Яловега
Константин Ковалевский
‘Ald-rpc не найден’ на Astra Linux 1.6
Irbis88
CrashBldash
Irbis88
Установка Astra Linux Directory
Краткое описание служб каталогов ALD
Планируемая схема установки
Подготовка операционных систем
Настройка сервера Astra Linux Directory
Настройка BIND
Установка служб Astra Linux Directory
Проверка работы серверных служб ALD
Создание тестовых пользователей
Присоединение клиента к домену ALD
Процесс присоединения к домену
Проверка работы клиента ALD
Установка Astra Linux Directory : 8 комментариев

Astra Linux 1.5 проблема с ALD

Столкнулся с такой проблемой собрал домен на Астре (domain.mil.zs), вроде бы собрался без ошибок. Но при попытке подключить подключить клиент выдает «Домен domain.mil.zs не обнаружен». Кто знает в каком направлении копать?

Astra.

Интересно) давай глуши, нужно более детально все рассказать.

Астра она такая, непредсказуемая. Был опыт работы с АЛД, можешь поподробнее описать, все делал по инструкции из руководства пользователя? Напишешь на почту? chekin88@yandex.ru

Нужно настраивать по руководству администратора, ч.2.

ошибка наверху лежит. что есть у тебя в файле /etc/hosts, /etc/resolv.conf, /etc/network/interfaces?

Есть ль возможность подключиться удаленно?

Astra Linux 1.5 проблема с ALD

Прилагаю содержимое файлов:

/etc/hosts 127.0.0.1 localhost 10.20.120.35 ns1.domain.mil.zs ns1

/etc/resolv.conf domain domain.mil.zs search domain.mil.zs nameserver 10.20.120.35

/etc/network/interfaces auto eth0 iface eth0 inet static address 10.20.120.35 netmask 255.255.255.224 gateway 10.20.120.34 network 10.20.120.0 broadcast 10.20.120.255 dns-nameserver 10.20.120.35

У тебя настройки сети в тьме какой-то.

Адрес сети не бьёт..

А клиент как настроен? На самом сервере авторизацтя проходит?

Astra Linux 1.5 проблема с ALD

С доменом разобрались. С почтой поможешь? Проблема тоже на Астре.

Источник

Ошибки инициализации домена

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

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

ip addr flush eth0

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

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

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

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

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

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

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

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

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

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

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

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

:> Incorrect net address

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

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

:> GSS-API (or Kerberos) error

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

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

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

Ошибка 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)

Вход от имени пользователя ‘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

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

17 Комментариев

Дмитрий Анохов

ald-init init возникает ошибка:

Ошибка при установке ALD соединения.

Ошибка 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)

Дмитрий Анохов

При попытки ввести на сервере Ald-init init выводит ошибку:
— ОШИБКА:
Триггер ‘ald-cfg-parsec-ald:DoInitParsecAudLdapSchema’ Вызвал исключение!
Не удалось именить права доступа к ‘/etc/ldap/slapd.d/cn=config.ldif’.
—

— ОШИБКА:
Не удалось создать базу данных LDAP.
—

Дмитрий Анохов

Но при попытке подключить АРМ к домену ald-client join ns1. astra.da.nu происходит следующее, сначала выходит сообщение:

домен astra.da.nu не обнаружен.

компьютер будет подключен к домену astra.da.nu .

Дмитрий Анохов

Ошибка аутентификации пользователя ‘admin/admin’: Ошибка MIT Kerberos V5: Ошибка инициализации аутентификационных данных krb5 пользователя. в ALDKadm5Connection.cpp:283(ConnectPassword)

:> Client ‘admin/admin@168.32.216’ not found in Kerberos database

Нет записи в hosts на обоих машинах. ald-client join по ip.

Дмитрий Анохов

:> Client ‘admin/admin@NU.DA’ not found in Kerberos database

Неверная запись имени сервера в hosts клиента

Константин Ковалевский

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

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

Дмитрий Андреев

root@server:/home/u# ald-init init
— ОШИБКА:
Конфигурационный параметр ‘DOMAIN’ содержит неверное значение ‘.domain.ald ‘.
—

При попадании табов и пробелов в конце имени домена в параметре DOMAIN=.domain.ald файла /etc/ald/ald.conf

Дмитрий Андреев

Ошибка MIT Kerberos V5: Ошибка получения ключей принципала Kerberos ‘host/client@DA.NU’. в ALDKadm5Connection.cpp:1581(KeytabAddPrincipal)

:> Principal does not exist

В /etc/hosts указано не длинное имя клиента.

Дмитрий Анохов

Не указано длинное имя клиента* ?

Дмитрий Андреев

Константин Ковалевский

[31m— ERROR:RPC error: Ошибка Krb5 сервера ALD: Ошибка проверки сообщения KRB-PRIV. в ADKrb5Server.cpp:263(decode):> Incorrect net address:> (rpc-creds)

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

Проблема оказалась в Dr. Web ESS 10. Spider Gate блокирует порты RPC, его необходимо отключать. При чём, настройки Spider Gate для Linux недоступны, необходимо отключать Spider Gate в ЦУ Dr. Web для группы Everyone для Windows. Ну, или использовать на клиентах не Dr. Web for Workstations а Dr.Web for Fileservers, где этой проблемы не наблюдается.

Егор Сураев

Ошибка при установке ALD соединения.

:> Client ‘admin/admin@NU.DA’ not found in Kerberos database

Ошибка может быть вызвана вводом неправильного пароля при ald-init promote резервного сервера.

Константин Ковалевский

Если при перезапуске ALD выходит ошибка:

— ОШИБКА:
Триггер ‘ald-cfg-smb:DoSambaStartFS’ вызвал исключение!
Не удалось запустить сервис nmbd. Код возврата 256.
—

А перезапуск сервиса nmbd выводит такую информацию:
root@server:/home/u# systemctl status nmbd
● nmbd.service
Loaded: masked (/dev/null; bad)
Active: inactive (dead)

Необходимо выполнить команды:

systemctl unmask nmbd
systemctl enable nmbd
systemctl restart nmbd

Егор Сураев

cpp:144 чето там при попытке администрирования из графики — означает, что ранее уже был получен билет администратора и необходимо сначала уничтожить предыдущий билет командой:

Далее получить новый уже из графики.

Дмитрий Анохов

Ошибка MIT Kerberos V5: Ошибка получения ключей принципала Kerberos ‘host/arm@DOMAIN’. В ALDKadm5Connection.cpp:1528(KeytabAddPrincipal) Principal does not exist.

Если на контроллере домена создаётся принципал с именем ‘host/arm@DOMAIN’, тогда выполните на клиенте ald-client update-svc-keytab ‘host/arm@DOMAIN’.

Марина Яловега

При возникновении ошибки 111 ( Смоленск 1.5):

Решение от клиента

Добавить в конфигурационный файл /etc/ald/ald.conf параметр USE_RPC, равный нулю

2. Выполнить ald-init restart

Константин Ковалевский

При создании резервного сервера командой sudo ald-init init —slave выходит ошибка:

Источник

‘Ald-rpc не найден’ на Astra Linux 1.6

Irbis88

New member

;source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet static
address 192.168.73.74
netmask 255.255.255.0
gateway 192.168.73.1
dns-domain test.ru
dns-nameservers 192.168.73.1

source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet static
address 192.168.73.73
netmask 255.255.255.0
gateway 192.168.73.1
dns-domain test.ru
dns-nameservers 192.168.73.1

CrashBldash

New member

Irbis88

New member

Мною найдена иная информация:

Host-only/VMnet1. Второго рода сеть соединяет гостевую виртуальную машину и хостовый компьютер, образуя частную сеть. Данное подключение обеспечивает сетевое соединение между виртуальной машиной и физическим компьютером (хостом), используя виртуальный сетевой адаптер доступный операционной системе хоста.
При этом типе подключения, виртуальная машина не имеет доступ к локальной сети и Интернету. Поскольку виртуальные машины не имеют доступа к физической сети, VMware Workstation предусматривает использование DHCP службы для назначения TCPIP параметров виртуальным машинам. Для host-only виртуальной сети используется определенная подсеть, в нашем случае это 192.168.52.0-254, где виртуальный адаптер на физическом компьютере имеет IP адрес 192.168.52.1, а все гостевые виртуальные машины использующие host-only подключение получают адреса от VMware DHCP server.
Виртуальные машины использующие host-only сеть могут взаимодействовать между собой в этой сети.

Источник

Установка Astra Linux Directory

В этой статье будет рассмотрена установка Astra Linux Directory – реализация службы каталогов от компании АО «НПО РусБИТех» (Astra Linux). Особо отмечу, что речь идет про бесплатную версию Astra Linux Directory, а не Pro версию.

Цель статьи – это подготовить руководство для быстрого старта, которое позволило бы вам в разумные строки развернуть стенд для тестирования службы каталогов Astra Linux Directory.

Краткое описание служб каталогов ALD

Существует две версии продукта – Astra Linux Directory и Astra Linux Directory Pro. Как бы это странно не звучало, но технически это два разных продукта. Astra Linux Directory используются свой вариант каталога, а в основе служб каталогов Astra Linux Directory Pro лежит FreeIPA.

Astra Linux Directory доступна из коробки в бесплатной редакции Astra Linux Common Edition.

Кратко опишу основные возможности бесплатной версии Astra Linux Directory:

Позволяет организовать централизованное хранение и управление учетными записями пользователей и групп.
Предоставляет сквозную аутентификацию пользователей в домене с использованием протокола Kerberos.
Обеспечивает функционирование глобального хранилища домашних директорий, доступных по Samba/CIFS.

К основным особенностям я бы отнес следующие:

Поддерживает только клиенты с ОС Astra Linux.
Добавление машины ОС MS Windows в домен ALD штатными средствами ОС MS Windows невозможно.
Одновременной работы нескольких серверов ALD не предусмотрено.
Переключение на резервный сервер ALD только вручную.
«Плоская» иерархия пользователей и ПК, т.е. нет возможности, например, создавать OU.

Все приведенные мной выше умозаключения отражают только мое видение продукта и относятся к версии 1.7.37.

Планируемая схема установки

Планируемая к развертыванию схема приведена ниже:

Она включает в себя один сервер (ADC01) и один клиент (ACLT01). В качестве службы разрешения имен я буду использовать сервер BIND. В целом для такой схемы можно вообще не использовать BIND, а просто сделать соответствующие записи в /etc/hosts.

Подготовка операционных систем

У Astra Linux Directory Common Edition нет градации на серверных и клиентские редакции ОС. Поэтому предварительная подготовка сервера и клиента ничем не отличаются.

Во всех примерах этой статьи использовалась версия Astra Linux Directory Common Edition релиза “Орёл” (2.12.43). Версия ядра – 5.10.0.-1038.40-hardened.

Итого подготовка серверной и клиентской системы включает в себя следующие шаги:

1. Установка и первоначальная настройка операционной системы. Можете использовать как физическое устройство, так и виртуальную машину. В целом можно использовать стандартные параметры установки, но вот версия ядра должна быть именно “hardened”:

2. Актуализация репозиториев:

3. Обновление установленных пакетов:

Настройка сервера Astra Linux Directory

Установка Astra Linux Directory включает в себя следующие верхнеуровневые шаги:

Настройка BIND.
Установка и настройка серверных служб ALD.

Предварительно неоходимо указать в качестве DNS сервера на сетевом интерфейсе адрес самого сервера.

Настройка BIND

Устанавливаем пакет BIND:

2. Устанавливаем пакет утилит для работы с DNS (например, в этот пакет входит утилита dig):

3. Корректируем настройка BIND. Нужно указать на каких IP-адресах сервера прослушивать запросы и на какие внешние DNS следует перенаправлять запросы. Открываем на редактирование конфигурационный файл:

Нам нужно скорректировать секции “forwarders” и “listen-on”. В секции “forwarders” нужно указать на какие внешние DNS перенаправлять запросы, а в секции “listen-on” нужно указать локальные адреса, на которых сервер будет прослушивать подключения. Пример моего файла конфигурации:

4. Теперь необходимо внести информацию и прямой и обратной зоне. В моем случае DNS-имя зоны будет itproblog.ru. Открываем на редактирование конфигурационный файл:

Пример моего конфигурационного файла named.conf.local:

В секции type указан тип зоны (основная зона), а в секции file расположение файла с текстом зоны (его мы настроим далее).

5. Создаем каталог для файлов DNS зон, создаем пустые файлы зон и назначаем необходимые разрешения:

6. Редактируем файл с прямой зоной:

Пример моего файла прямой зоны:

7. Редактируем файл с обратной зоной:

Пример моего файла обратной зоны:

8. Проверяем корректность заполнения конфигурационного файла и файлов зон:

Если ваш вывод на консоль отличается от вывода со скриншота выше, то, вероятно, нужно скорректировать ошибки в конфигурационных файлах.

9. Перезагружаем сервис BIND:

10. Проверяем разрешение имени через наш DNS сервер:

т.е. имена сервера и клиента успешно разрешаются в IP-адреса.

Установка служб Astra Linux Directory

Устанавливаем основной пакет ALD сервера и графический интерфейс администрирования Fly:

В процессе установки нас попросят указать пароль администратора LDAP. Указываем его:

2. Указываем полное доменное имя сервера:

Да, полное доменное имя применилось корректно.

3. Перезагружаем сервер.

4. Теперь необходимо создать домен. Переходим по следующему пути в графическом режиме: “Пуск” – “Панель управления” – “Сеть” – “Доменная политика безопасности“.

5. Указываем пароль, который мы задали на этапе установки сервера ALD.

6. Поскольку пока еще сервер ALD не настроен, то могут возникать ошибки в диалоговых окна. Пока просто игнорируем их.

7. Указываем пароль базы данных Kerberos, пароль администратора ALD.

Я также отметил опцию “Использовать свои настройки сети” и выбрал IP-адрес для службы. После этого нажимаем кнопку “Создать сервер”.

8. Нажимаем “Да” в подтверждении о том, что мы согласны с тем, что предыдущая БД будет перезаписана (если она имеется).

9. В случае успешного завершения создания сервера мы получим соответствующее уведомление:

10. Перезагружаем сервер.

Проверка работы серверных служб ALD

Выполнил проверку сервиса ALD:

Сообщение говорит о том, что сервис сконфигурирован, клиент и сервис работают корректно.

Теперь попробуем открыть графическую оснастку администрирования. Переходим по следующему пути в графическом режиме: “Пуск” – “Панель управления” – “Сеть” – “Доменная политика безопасности“:

Нажимаем кнопку “Подключиться”.

Указываем пароль администратора ALD:

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

Создание тестовых пользователей

Для того, чтобы проверить подключение клиента и работу под доменной УЗ создадим две учетные записи – user1 и user2.

Переходим по следующему пути в графическом режиме: “Пуск” – “Панель управления” – “Сеть” – “Доменная политика безопасности“. Указываем пароль администратора ALD.

В контекстном меню элемента “Пользователи” выбираем пункт “Создать“:

Заполняем имя пользователя и указываем первичную группу “Domain Users”:

Подтверждаем наши намерения создать пользователя (зеленая галочка).

Создаем пароль для учетной записи:

Выполняем аналогичные действия для учетной записи user2.

Итого, в нашей директории должно быть два пользователя – user1 и user2:

Предварительно на клиентском ПК необходимо указать в качестве DNS сервера наш сервер с ALD, т.к. именно там мы настроили BIND DNS.

Перезагружаем клиент и проверяем, что имя нашего сервера ALD разрешается в IP:

Указываем полное доменное имя клиента:

1. Устанавливаем необходимые пакеты:

2. Для разнообразия присоединим клиент через командную строку. Это можно сделать вот такой небольшой командой:

где последним параметром передается имя контроллера домена ALD.

3. На этапе выбора пользователя с правами присоединения к домену нажимаем Enter и указываем пароль администратора ALD.

4. В случае успешного присоединения вы должны увидеть следующий вывод:

Если теперь посмотреть в консоль управления ALD на сервере, то вы можете увидеть новый объект компьютера:

Проверка работы клиента ALD

Если мы попробуем сейчас выполнить вход на клиентский компьютер под доменной учетной записью user1, то увидим следующее сообщение – “Доступ запрещен”:

С кем это связано? Все дело в том, что в оснастке управления ALD для учетной записи пользователя необходимо явно указать – на какие клиентские ПК ему разрешен доступ. Давайте добавим доменному user1 разрешения локального входа на доменный ПК aclt01.itproblog.ru.

Для этого на сервере ALD необходимо открыть оснастку управления ALD и в свойствам УЗ user1 на вкладке “Привилегии домена” добавим компьютер aclt01.itproblog.ru:

Сохраните внесенные изменения.

Попробуем выполнить вход теперь:

Да теперь мы успешно выполнили вход под доменной учетной записью.

Установка Astra Linux Directory : 8 комментариев

Добрый день!
Вход в домен приходиться выполнять каждый раз (ald-client join domain). Авторизация проходит успешно. После перезагрузки все по новой. Это нормальное поведение? Как можно автоматизировать вход с пк в домен?

Добрый день! Нет, так не должно быть. ald-client join domain – это разовая операция.

После перезагрузки не получается под доменной УЗ аутентифицироваться? Какая-то ошибка генерируется?

Здравствуйте
в привилегиях домена не появился подключенный компьютер, там вообще пусто, в разделе компьютеров он есть, все делалось в точности, версия астры 1.6 Смоленск, никаких бюллетеней поверх не установлено

Добрый день! А КД и клиент точно видят друг друга? В процессе присоединения клиента никаких ошибок не генерировалось? Попробуйте еще вот этой командой на клиенте статус проверить: sudo ald-client status

Еще из вариантов – последовательно перезагрудить КД и клиента и выполнить проверку снова.

делал по вашей инструкции но при подключении клиента к домену появляется ошибка: ошибка openldap при gssapi соединения local error в aldldapconnection.cpp:747 connect
Как ее исправить?

Добрый день! Разрешение имен точно работает корректно? КД по имени разрешает IP-адрес клиента и наоборот? Обсуждение подобной проблемы есть на форуме вендора – https://forum.astralinux.ru/threads/484/. Из обсуждения я понял, что по итогу былаиз-за ошибок в файлах конфигурации зоны в bind. Я бы на вашем месте проверил всю подсистему разрешения имен.

Здравствуйте, Роман! спасибо, действительно были опечатки в конфигурационных файлах DNS

DNS – это уже почти классика дебага:
– Это точно не DNS.
– Это не может быть DNS.
– Это был DNS.

Источник

Время прочтения
7 мин

Просмотры 104K

В продолжение давней темы про использование двухфакторной аутентификации в ОС GNU/Linux позвольте рассказать про схему работы и настройку аутентификации с помощью Kerberos. В этой статье мы рассмотрим процесс настройки MIT Kerberos для аутентификации пользователей по сертификатам и ключевым парам, находящимся на USB-токене. Также материалы, изложенные в статье, можно использовать для настройки аутентификации в домене Windows.

Краткое введение

Для начала проведем небольшой ликбез по терминологии Kerberos и рассмотрим доступные реализации этого протокола в ОС на базе GNU/Linux. Сразу оговорюсь, что мне не удалось найти однозначного перевода терминов, использующихся в Kerberos, поэтому для избежания путаницы основные термины я буду дублировать на английском.
Итак, начнем. Если процитировать Википедию, то

Kerberos – сетевой протокол аутентификации, позволяющий передавать данные через незащищённые сети для безопасной идентификации. Ориентирован, в первую очередь, на клиент-серверную модель и обеспечивает взаимную аутентификацию – оба пользователя через сервер подтверждают личности друг друга.

Стоит отметить, что Kerberos в первую очередь является протоколом, а не конкретной системой аутентификации. Его реализации используются в различных операционных системах, в том числе и в Windows, как метод аутентификации пользователей в домене. Существует несколько open source реализаций протокола Kerberos, например оригинальная MIT Kerberos и Heimdal. Такой зоопарк возник из-за ограничений США на экспорт криптографических средств защиты информации, на сегодня эта ситуация вокруг MIT Kerberos уже улеглась. В статье мы рассмотрим процесс настройки для MIT Kerberos V5.

Билет (ticket) – временные данные, выдаваемые клиенту для аутентификации на сервере, на котором располагается необходимая служба.
Клиент (client) – некая сущность в сети (пользователь, хост или сервис), которая может получить билет от Kerberos.
Центр выдачи ключей (key distribution center, KDC) – сервис, выдающий билеты Kerberos.
Область (realm) – сеть, используемая Kerberos, состоящая из серверов KDC и множества клиентов. Имя realm регистрозависимо, обычно пишется в верхнем регистре и совпадает с именем домена.
Принципал (principal) – уникальное имя для клиента, для которого разрешается аутентификация в Kerberos. Записывается в виде root[/instance]@REALM.

Файлы настроек Kerberos

На сервере:

/etc/krb5kdc/kdc.conf — настройки KDC

На клиенте и сервере:

/etc/kbr5.conf — настройки сервера аутентификации (описание realms, доменных имен и других настроек)

Настройка рабочего окружения

Для начала необходимо развернуть среду, в которой будет производиться аутентификация. Наиболее просто это сделать, взяв две виртуальные машины, находящиеся в одной подсети. Достаточно установить на одну виртуальную машину какую-нибудь Ubuntu (это будет наш сервер), а затем клонировать ее и получить клиента. При написании статьи я воспользовался свежей Ubuntu 12.10 (x86) и виртуальной машиной от VMWare. Чтобы виртуальным машинам было удобнее видеть друг друга по сети, стоит переключить сетевые карты в Bridged-режим.
Важно! Следите за тем, чтобы время на клиенте и сервере было синхронизировано, это необходимо для корректной работы Kerberos.

Настройка сети

Клиенты Kerberos ищут свои сервера по доменным именам, поэтому необходимо настроить DNS и убедиться, что имена серверов успешно разрешаются. В нашем примере достаточно занести доменное имя сервера в /etc/hosts, что я и сделал. Схема «сети» изображена ниже.

Установка необходимых пакетов

На сервере нам потребуются:

krb5-kdc – сервис KDC
krb5-admin-server – административный сервер Kerberos (он ведет контроль учетных записей пользователей)
krb5-pkinit – модуль расширения Kerberos для аутентификации по сертификатам

На клиент надо поставить следующие пакеты:

krb5-user – базовый набор утилит для работы клиентской аутентификации
krb5-config – файлы настроек Kerberos
krb5-pkinit
libpam-krb5 – модуль PAM для использования Kerberos-аутентификации
pcscd, opensc, libengine-pkcs11-openssl – пакеты, необходимые для работы с токенами

При установке пакетов у нас спросят настройки по умолчанию, мы будем использовать следующие:

Default realm: AKTIV-TEST.RU
Имена серверов (admin server и KDC): aktiv-test.ru (он же прописан в /etc/hosts на клиенте)
Пользователь: testuser@AKTIV-TEST.RU

Настройка Kerberos

Базовые настройки

После установки пакетов на сервере нужно инициализировать realm командой

$ sudo krb5_newrealm

А на клиенте – обновить файлы конфигурации:

$ sudo dpkg-reconfigure krb5-config

Также на клиенте и сервере надо добавить следующие строки в /etc/krb5.conf:

[domain_realm]
.aktiv-test.ru = AKTIV-TEST.RU
aktiv-test.ru = AKTIV-TEST.RU

Теперь создадим на сервере нового пользователя c именем testuser

$ sudo kadmin.local
# username = testuser
# password = test
# добавляем нового пользователя и устанавливаем его пароль
kadmin.local:$ addprinc testuser
# ...
kadmin.local:$ quit

На клиенте теперь можно проверить, правильно ли мы настроили сеть и Kerberos:

$ kinit testuser@AKTIV-TEST.RU
# вводим пароль пользователя
$ klist
# и видим выданный ticket, после чего его можно удалить следующей командой
$ kdestroy

Настройка аутентификации по открытому ключу

Для работы модуля pkinit нам придется воспользоваться openssl в качестве мини-УЦ, чтобы создать ключевые пары и сертификаты клиента и сервера.

На сервере:

Создадим ключевую пару и сертификат нашего «УЦ». Здесь мы сгененируем ключ УЦ и создадим самоподписанный сертификат с помощью openssl. В реальном мире ключ естественно надо надежно защитить от попадания в чужие руки.

$ openssl genrsa -out cakey.pem 2048 
# ...
$ openssl req -key cakey.pem -new -x509 -out cacert.pem
# ...

Создадим ключевую пару для KDC, заявку на сертификат и выпишем его сами себе.
Здесь нам потребуется специальный файл расширений OpenSSL (pkinit_extensions), в котором будут указаны дополнительные поля сертификатов, используемых в Kerberos. В частности, мы зададим:

Extended Key Usage (EKU) – идентификатор (OID), говорящий о том, как планируется использовать сертификат
otherName – поле, задающее нашего принципала, для которого выписывается сертификат

$ openssl genrsa -out kdckey.pem 2048 
# создание запроса
$ openssl req -new -out kdc.req -key kdckey.pem
# подпись запроса
$ REALM=AKTIV-TEST.RU; export REALM
$ CLIENT=aktiv-test.ru; export CLIENT
# содержимое файла pkinit_extensions см. по ссылке выше
$ openssl x509 -req -in kdc.req -CAkey cakey.pem -CA cacert.pem -out kdc.pem -extfile pkinit_extensions -extensions kdc_cert –CAcreateserial

После этого перенесем следующие файлы в /var/lib/krb5kdc/:

kdc.pem
kdckey.pem
cacert.pem

На сервере отредактируем настройки Kerberos (файл /etc/krb5kdc/kdc.conf) для использования ключей и сертификатов сервера и УЦ:

[kdcdefaults]
    kdc_tcp_ports = 88
    pkinit_identity = FILE:/var/lib/krb5kdc/kdc.pem,/var/lib/krb5kdc/kdckey.pem
    pkinit_anchors = FILE:/var/lib/krb5kdc/cacert.pem
[realms]
    AKTIV-TEST.RU = {
        database_name = /var/lib/krb5kdc/principal
        admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
        acl_file = /etc/krb5kdc/kadm5.acl
        key_stash_file = /etc/krb5kdc/stash
        max_life = 10h 0m 0s
        max_renewable_life = 7d 0h 0m 0s
        master_key_type = des3-hmac-sha1
        supported_enctypes = aes256-cts:normal arcfour-hmac:normal des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3
        default_principal_flags = +preauth
    }

Далее на сервере необходимо включить предварительную аутентификацию для нашего пользователя.

$ kadmin.local
kadmin.local$: modprinc +requires_preauth testuser

Дальнейшие действия будем выполнять на клиенте

Отформатируем токен

$ pkcs15-init --erase-card -p rutoken_ecp
$ pkcs15-init --create-pkcs15 --so-pin "87654321" --so-puk ""
$ pkcs15-init --store-pin --label "User PIN" --auth-id 02 --pin "12345678" --puk "" --so-pin "87654321" –finalize

Сгенерируем на токене ключевую пару RSA 2048 бит и создадим заявку на сертификат. Важно заметить, что пути до библиотек engine_pkcs11.so и opensc-pkcs11.so на вашей системе могут отличатся, поэтому сначала стоит проверить их расположение.

# на данном шаге важно запомнить ID ключевой пары, его мы используем позже
$ pkcs15-init -G rsa/2048 --auth-id 02 --id 42 --label "testuser's key" --public-key-label "testuser's public key"
# ...
$ openssl
# на multiarch-системах opensc-pkcs11.so и engine_pkcs11.so могут лежать в других местах
OpenSSL> engine dynamic -pre SO_PATH:/usr/lib/openssl/engines/engine_pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:opensc-pkcs11.so
(dynamic) Dynamic engine loading support
[Success]: SO_PATH:/usr/lib/openssl/engines/engine_pkcs11.so
[Success]: ID:pkcs11
[Success]: LIST_ADD:1
[Success]: LOAD
[Success]: MODULE_PATH:opensc-pkcs11.so
Loaded: (pkcs11) pkcs11 engine
OpenSSL> req -engine pkcs11 -new -key 1:42 -keyform engine -out client.req -subj "/C=RU/ST=Moscow/L=Moscow/O=Aktiv/OU=dev/CN=testuser/emailAddress=testuser@mail.com"
engine "pkcs11" set.
PKCS#11 token PIN: 
OpenSSL> quit

После этого мы получим файл-заявку client.req, которую необходимо поместить на сервер и выписать сертификат пользователя на основе данных УЦ:

$ REALM=AKTIV-TEST.RU; export REALM
$ CLIENT=testuser; export CLIENT
$ openssl x509 -CAkey cakey.pem -CA cacert.pem -req -in client.req -extensions client_cert -extfile pkinit_extensions -out client.pem

Затем стоит перезапустить сервер и KDC:

$ /etc/init.d/krb5-admin-server restart
$ /etc/init.d/krb5-kdc restart

На выходе работы openssl мы получим файл с сертификатом клиента client.pem. Его нужно перенести на клиентскую машину, положить в /etc/krb5/ и записать на токен:

$ pkcs15-init --store-certificate client.pem --auth-id 02 --id 42 --format pem

И в завершение нам потребуется внести в файл конфигурации Kerberos настройку, которая укажет, какие данные использовать для аутентификации (в нашем случае это сертификат УЦ и путь до модуля PKCS#11). В документации MIT Kerberos указаны различные параметры, которые позволяют настроить выбор аутентификационных данных на токене, в нашем же случае мы просто указываем модуль PKCS#11, поскольку в данной ситуации этого достаточно.

[libdefaults]
    default_realm = AKTIV-TEST.RU
# путь к сертификату УЦ
    pkinit_anchors = FILE:/etc/krb5/cacert.pem
# путь к модулю PKCS#11
    pkinit_identities = PKCS11:/usr/lib/opensc-pkcs11.so

Проверим, можем ли мы получить ticket на клиенте, используя данные с токена:

$ kinit testuser
# на этом этапе у нас должны спросить PIN-код от токена
$ klist

Настройка PAM-аутентификации с использованием Kerberos

Ранее при настройке клиентской машины мы поставили пакет libpam-krb5. Он поможет нам выполнить аутентификацию в Kerberos при входе в систему, а также в приложениях, использующих системную аутентификацию (например login, lightdm и проч.). Для подключения модуля PAM достаточно выполнить команду

$ sudo pam-auth-update

и выбрать в диалоге необходимые модули аутентификации. Для более тонкой настройки можно заглянуть в файл /etc/pam.d/common-auth и отредактировать его по желанию. Структуру файла я описывал в предыдущей статье.

Заключение

Применение протокола Kerberos для централизованной аутентификации в связке с централизованным созданием хранением и раздачей учетных записей (например, посредством каталога на базе OpenLDAP) позволяет создать «домен UNIX», полностью состоящий из машин под управлением свободного программного обеспечения. Такое решение может применяться в корпоративном секторе, а аутентификация по смарт-картам будет приятным бонусом как для администраторов, так и для пользователей сети компании.

Полезные ссылки

Описание протокола Kerberos
Официальная документация
Инструкция по настройке от сообщества Ubuntu
Настройка PKINIT

Источник

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.

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

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

Debian 8, krb5-admin-server 1.12.1.

Источник