☰

Серверы OpenLDAP и Kerberos на Ubuntu Server 22.04; Krb5 не создает /var/lib/krb5kdc/principal

tag-icon • tag-icon ubuntu openldap kerberos
Серверы OpenLDAP и Kerberos на Ubuntu Server 22.04; Krb5 не создает /var/lib/krb5kdc/principal

У меня есть существующий сервер openldap на Ubuntu Server 22.04, и я пытаюсь настроить на нем сервер Kerberos, следуя этому руководству:https://ubuntu.com/server/docs/service-kerberos-with-openldap-backend

Учетные записи созданы и протестированы, они работают нормально (я ссылаюсь на них по cn, но у них есть uid; я просто создал их в apache directory studio сначала). Я сделал "dpkg-reconfigure krb5-config" и отредактировал /etc/krb5.conf, чтобы добавить свой сервер и область. Одна вещь, которой нет в этом документе, но которую я видел в другом месте, — это создание раздела "[domain_realm]" и добавление в него моего домена, что я и сделал, но это не помогло. Я создал раздел журналирования, который требует изменения служб systemd, чтобы разрешить запись в /var/log/kerberos, но это нормально. Затем я запускаю команду "kdb5_ldap_util", как указано, и после ввода паролей она, похоже, успешно завершается. Я делаю stash для паролей kdc-service и kadmin-service, что завершается успешно. Я создаю файл kadm.acl, он работает нормально, но когда я пытаюсь запустить службу, я получаю следующее в krb5kdc.log:

krb5kdc[712216](Error): Cannot find master key record in database - while fetching master keys list for realm SUBDOMAIN.DOMAIN.COM

Если я затем запущу «kadmin.local», то получу следующее:

Authenticating as principal root/[email protected] with password.
kadmin.local: Cannot find master key record in database while initializing kadmin.local interface

Как оказалось, файл /var/lib/krb5kdc/principal так и не создается. Я не уверен, что еще тут можно исправить, но на этом этапе я застрял, и любые указания будут оценены. Файлы конфигурации ниже, с измененным доменом и поддоменом:

/etc/krb5.conf:

[libdefaults]
        default_realm = SUBDOMAIN.DOMAIN.COM

# The following krb5.conf variables are only for MIT Kerberos.
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true

# The following encryption type specification will be used by MIT Kerberos
# if uncommented.  In general, the defaults in the MIT Kerberos code are
# correct and overriding these specifications only serves to disable new
# encryption types as they are added, creating interoperability problems.
#
# The only time when you might need to uncomment these lines and change
# the enctypes is if you have local software that will break on ticket
# caches containing ticket encryption types it doesn't know about (such as
# old versions of Sun Java).

#       default_tgs_enctypes = des3-hmac-sha1
#       default_tkt_enctypes = des3-hmac-sha1
#       permitted_enctypes = des3-hmac-sha1

# The following libdefaults parameters are only for Heimdal Kerberos.
        fcc-mit-ticketflags = true

[logging]
        kdc = FILE:/var/log/kerberos/krb5kdc.log
        admin_server = FILE:/var/log/kerberos/kadmin.log
        default = FILE:/var/log/kerberos/krb5lib.log

[realms]
        SUBDOMAIN.DOMAIN.COM = {
                kdc = hostname.subdomain.domain.com
                admin_server = hostname.subdomain.domain.com
                default_domain = subdomain.domain.com
                database_module = openldap_ldapconf
        }

[domain_realm]
        .subdomain.domain.com = SUBDOMAIN.DOMAIN.COM
        subdomain.domain.com = SUBDOMAIN.DOMAIN.COM

[dbdefaults]
        ldap_kerberos_container_dn = cn=krbContainer,dc=subdomain,dc=domain,dc=com

[dbmodules]
        openldap_ldapconf = {
                db_library = kldap

                # if either of these is false, then the ldap_kdc_dn needs to
                # have write access
                disable_last_success = true
                disable_lockout  = true

                # this object needs to have read rights on
                # the realm container, principal container and realm sub-trees
                ldap_kdc_dn = "cn=kdc-service,ou=accounts,dc=subdomain,dc=domain,dc=com"

                # this object needs to have read and write rights on
                # the realm container, principal container and realm sub-trees
                ldap_kadmind_dn = "cn=kadmin-service,ou=accounts,dc=subdomain,dc=domain,dc=com"

                ldap_service_password_file = /etc/krb5kdc/service.keyfile
                ldap_servers = ldapi:///
                ldap_conns_per_server = 5
        }

/etc/krb5kdc/kadm5.acl:

*/[email protected] *

/etc/krb5kdc/kdc.conf:

[kdcdefaults]
    kdc_ports = 750,88

[realms]
    SUBDOMAIN.DOMAIN.COM = {
        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
        kdc_ports = 750,88
        max_life = 10h 0m 0s
        max_renewable_life = 7d 0h 0m 0s
        master_key_type = des3-hmac-sha1
        #supported_enctypes = aes256-cts:normal aes128-cts:normal
        default_principal_flags = +preauth
    }

Редактировать: Согласно комментарию user1686, теперь я вижу, что у меня есть потенциальная проблема с доступом к учетным записям. Я немного не в себе в этом, но используя 'slapcat -b cn=config' у меня есть следующие правила olcAccess:

olcAccess: {0}to * by dn="cn=admin,dc=subdomain,dc=domain,dc=com" manage by dn="cn=surfrock66,ou=accounts,dc=subdomain,dc=domain,dc=com" manage by dn="cn=ldapbinduser,ou=accounts,dc=subdomain,dc=domain,dc=com" read by * break
olcAccess: {1}to dn.children="ou=accounts,dc=subdomain,dc=domain,dc=com" attrs=userPassword,shadowExpire,shadowInactive,shadowLastChange,shadowMax,shadowMin,shadowWarning by self write by anonymous auth
olcAccess: {2}to attrs=krbPrincipalKey by anonymous auth by dn.exact="cn=kdc-service,ou=accounts,dc=subdomain,dc=domain,dc=com" read by dn.exact="cn=kadmin-service,ou=accounts,dc=subdomain,dc=domain,dc=com" write by self write by * none
olcAccess: {3}to dn.subtree="cn=krbContainer,dc=subdomain,dc=domain,dc=com" by dn.exact="cn=kdc-service,ou=accounts,dc=subdomain,dc=domain,dc=com" read by dn.exact="cn=kadmin-service,ou=accounts,dc=subdomain,dc=domain,dc=com" write by * none
olcAccess: {4}to dn.subtree="dc=subdomain,dc=domain,dc=com" by self read

2022.12.08-08-36 PST Редактирование: Итак, я продвинулся гораздо дальше и сделал следующее:

addprinc ldap/[email protected]
ktadd -k /etc/ldap/kerberos.ldap.hostname.subdomain.domain.com.keytab ldap/hostname.subdomain.domain.com
chown openldap:openldap /etc/ldap/kerberos.ldap.hostname.subdomain.domain.com.keytab
chmod 640 /etc/ldap/kerberos.ldap.hostname.subdomain.domain.com.keytab

Я отредактировал /etc/default/slapd и добавил в него следующее:

export KRB5_KTNAME="FILE:/etc/ldap/kerberos.ldap.hostname.subdomain.domain.com.keytab"

Когда я перезапустил службу, testsaslauthd все еще работает, но ldapsearch -D нет. Интересно, нужно ли мне изменить конфигурацию в ldap? Из одного из ресурсов, с которыми я работал, я создал этот ldif для конфигурации, но в конечном счете я не думаю, что понимаю, что он будет делать и правильно ли это:

dn: cn=config
changetype: modify
add: olcSaslHost
olcSaslHost: hostname.subdomain.domain.com
-
add: olcSaslRealm
olcSaslRealm: SUBDOMAIN.DOMAIN.COM
-
add: olcAuthzRegexp
olcAuthzRegexp: {0}"cn=([^/]*),cn=subdomain.domain.com,cn=GSSAPI,cn=auth" "cn=$1,ou=accounts,dc=subdomain,dc=domain,dc=com"
-
add: olcAuthzRegexp
olcAuthzRegexp: {1}"cn=host/([^/]*).subdomain.domain.com,cn=subdomain.domain.com,cn=GSSAPI,cn=auth" "cn=$1,ou=hosts,dc=subdomain,dc=domain,dc=com"
-
add: olcAuthzRegexp
olcAuthzRegexp: {2}"uid=ldap/admin,cn=subdomain.domain.com,cn=GSSAPI,cn=auth" "cn=admin,dc=subdomain,dc=domain,dc=com"

Я думаю, что это последний недостающий шаг? Что-то в конфигурации, указывающее LDAP на sasl? Или я неправильно к этому подхожу?

решение1

principalэто файл, содержащий базу данных KDC в формате DB2. Он не создается в вашей системе, потому что выне используетсябэкэнд db2– вы используете LDAP, который заменяетвселокальное хранилище для KDC – поэтому локальный файл базы данных не нужен и не имеет отношения к проблеме, с которой вы столкнулись.

Если вы выполнили все kdb5_ldap_util createсогласно инструкциям, вам следует проверить через LDAP, действительно ли он создал необходимые записи – как минимум должна быть запись для K/M@<realm>и еще одна для krbtgt/<realm>@<realm>. Сообщение об ошибке касается записи «K/M», которая является псевдопринципалом, содержащим mkey базы данных (который зашифрован паролем «главного ключа»).

Обязательно проверьте LDAP, используя учетную запись KDC, на всякий случай, если ей не предоставлены необходимые привилегии для чтения объектов Kerberos LDAP. (Учетные записи ненуждатьсяиметь uid; они используются только как учетные записи привязки LDAP, а не как локальные учетные записи Unix.)

Поскольку Ubuntu иногда использует AppArmor, обязательно проверьте dmesgналичие сообщений об отказе AVC — возможно, KDC не разрешено читать «service.keyfile» или получать доступ к вашему сокету OpenLDAP.

Кроме того, включите statsуровень журнала на вашем сервере LDAP, чтобы он регистрировал все запросы — это может, например, показать, что KDC ищет под другим DN (обычно «ldap_kerberos_container_dn» устанавливается рядом с другими параметрами dbmodules).

Наконец, если strace kadmin.localпоказывает, что инструмент на самом деле не подключается к LDAP, а пытается получить доступ к локальному файлу db2, то возможно, что у вас есть конфигурация kdc.conf(специфичный для KDC файл конфигурации), которая переопределяет общесистемные настройки в krb5.conf. Обычно конфигурация KDC загружается из /var/lib/krb5kdc/kdc.confглобальных настроек krb5.conf и имеет приоритет над ними.

(Кроме того, если выбыли(При использовании db2 основная база данных по-прежнему не будет создана автоматически при первом запуске — это необходимо сделать вручную, запустив kdb5_util create [-s]и указав главный ключ шифрования, как вы это делали для бэкэнда LDAP с помощью «kdb5_ldap_util create».)

Единственное, чего нет в этом документе, но что я видел в другом месте, — это создание раздела «[domain_realm]» и добавление в него моего домена. Я это сделал, но это не помогло.

Это необходимо только для клиентов Kerberos при получении билетов для имени хоста, которое не соответствует 1:1 его области (типичный пример — mit.edu → ATHENA.MIT.EDU). Это не имеет отношения к запуску KDC.

Я создал раздел журналирования, который требует изменения служб systemd, чтобы разрешить запись в /var/log/kerberos,

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

Разве этого нет, поскольку мое хранилище находится в LDAP?

Нет, файл /etc/krb5.keytab не является частью базы данных KDC — он принадлежитхозяинкак "член домена" и хранит эквивалент пароля Kerberos учетной записи машины. Каждая машина в вашей области Kerberos должна иметь свой собственный /etc/krb5.keytab с как минимум основным host/<fqdn>.

Я пытаюсь заставить работать LDAP passthrough auth, чтобы пароль kerberos был настоящим; я нахожу, что большая часть документации устарела. Я вижу, что большинство людей рекомендуют saslauthd, который я, как мне кажется, настроил, но теперь он ищет /etc/krb5.keytab

Для OpenLDAP, да, обычно нужен saslauthd.

  1. При привязке к DN, имеющему userPassword: {SASL}foo@BAR, slapd будет использовать функции libsasl «проверка пароля».
  2. В зависимости от конфигурацииpwcheck_method, libsasl свяжется с saslauthd для проверки пароля.
  3. saslauthd будет использовать бэкэнд, настроенный с помощью его -aопции, для выполнения фактической проверки.
  4. С помощью -a krb5бэкэнда saslauthd попытается получить начальный билет Kerberos от KDC с предоставленными именем пользователя и паролем (эквивалентно kinit).
  5. Если первоначальный билет был успешно приобретен, saslauthd дополнительно запроситбилет на обслуживание для себяи попытается расшифровать его с помощью ключа машины.
  6. Если бы можно было приобрести билет на обслуживаниеи расшифровал,пароль принят.

Последний шаг необходим для предотвращения атак спуфинга KDC. Традиционно Kerberos KDC выпускали билеты без проверки вашего пароля (неправильный пароль просто означал, что клиент не мог расшифровать полученный билет), и вредоносный KDC все еще может это сделать — «предварительная аутентификация» не является обязательной на уровне протокола. Поэтому saslauthd должен сделать то же самое, что делает любая другая служба с поддержкой Kerberos, чтобы проверить, что билет является законным — попытаться расшифровать его с помощью служебной keytab. (И pam_krb5, и даже Windows делают то же самое во время входа в AD.)

Я создал host/hostname.fqdn@REALM и ldap/hostname.fqdn@REALM. Я создал keytab для ldap; я преобразовал пароль 1 пользователя в "{SASL}name@REALM". Используя testsaslauthd для этого пользователя, я получаю успех. Используя ldapsearch для этого пользователя, недействительные учетные данные. Я думаю, что ldap не взаимодействует с saslauthd? В разделе "Аутентификация Kerberos" здесь я добавил конфигурации: help.ubuntu.com/community/OpenLDAPServer, но когда я делаю "ldapsearch -Y GSSAPI", я получаю "Ошибка GSSAPI: не предоставлены учетные данные...

-Y GSSAPIявляетсяпрямойАутентификация Kerberos – полностью отделена от saslauthd и пароля passthrough. То есть, slapd даже не получает пароль Kerberos – он получает только Kerberosбилети проверяет его внутренне с помощью служебного ключа.

  1. Для SASL GSSAPI сама служба slapd, а не saslauthd, нуждается в keytab для ldap/<fqdn>. (По умолчанию все службы ищут свои ключи в системном /etc/krb5.keytab, но для безопасности может быть лучше разделить эти вещи и указать для KRB5_KTNAME slapd другой путь — в этом случае вам не придется предоставлять ему доступ на чтение к системному keytab.)

  2. Клиенту также необходимознатьчто он предназначен для запроса билета для ldap/<fqdn>, поэтому подключение к IP-адресу, скорее всего, не сработает (если только у него не настроен правильный rDNS) — вам следует подключаться конкретно к ldap://<fqdn>. (Это очень похожая проблема с TLS SNI или именами хостов в сертификатах TLS).

    Если вы сомневаетесь, выполните экспорт KRB5_TRACE=/dev/stderrперед вызовом клиента, чтобы выяснить, для какого принципала он пытается создать TGS-REQ (или посмотрите журналы KDC или сетевой захват).

  3. Клиент уже должен иметьисходныйБилет Kerberos (krbtgt/REALM) присутствует, то есть вы должны kinitзаранее. Если у вас еще нет TGT, клиенты Kerberosне буду спрашиватьдля вашего пароля – они просто сразу же не смогут пройти аутентификацию.

Сквозная передача пароля актуальна только для "простых" привязок ( ldapsearch -D <user_dn> -W) и привязок SASL PLAIN. Сначала протестируйте "простую" привязку (в основном вы можете игнорировать SASL PLAIN).

решение2

Вам необходимо установить libsasl2 в вашей ОС и предоставить право собственности на krb5.keytab пользователю openldap.

на дебиане:

sudo apt install libsasl2-2 libsasl2-modules-gssapi-mit

а потом

sudo chown openldap:openldap /etc/krb5.keytab или другой keytab

Редактировать: но будьте осторожны с несколькими клавишами на одной машине/контейнере (с несколькими серверами).

Связанный контент