☰

Ubuntu Server 22.04의 OpenLDAP 및 Kerberos 서버; Krb5가 /var/lib/krb5kdc/principal을 생성하지 않습니다.

tag-icon • tag-icon ubuntu openldap kerberos
Ubuntu Server 22.04의 OpenLDAP 및 Kerberos 서버; Krb5가 /var/lib/krb5kdc/principal을 생성하지 않습니다.

Ubuntu Server 22.04에 기존 openldap 서버가 있고 이 가이드에 따라 Kerberos 서버를 설정하려고 합니다.https://ubuntu.com/server/docs/service-kerberos-with-openldap-backend

계정이 생성되고 테스트되었으며 잘 작동합니다(cn으로 참조했지만 uid가 있습니다. 먼저 Apache 디렉터리 스튜디오에서 생성했습니다). "dpkg-reconfigure krb5-config"를 수행하고 /etc/krb5.conf를 편집하여 서버와 영역을 추가했습니다. 해당 문서에는 없지만 다른 곳에서 본 것 중 하나는 "[domain_realm]" 섹션을 만들고 여기에 내 도메인을 추가하는 것인데, 해봤지만 도움이 되지 않았습니다. /var/log/kerberos에 쓸 수 있도록 systemd 서비스를 수정해야 하는 로깅 섹션을 만들었지만 괜찮습니다. 그런 다음 나열된 대로 "kdb5_ldap_util" 명령을 실행하고 비밀번호를 입력한 후 성공적으로 완료된 것으로 보입니다. 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"

서비스를 다시 시작해도 testaslauthd는 계속 작동하지만 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

principalDB2 형식 KDC 데이터베이스가 포함된 파일입니다. 귀하의 시스템에 생성되지 않았습니다.사용하지 않음백엔드 db2– 대체 LDAP를 사용하고 있습니다.모두KDC용 로컬 저장소 – 따라서 로컬 데이터베이스 파일은 불필요하며 현재 발생한 문제와 관련이 없습니다.

지침에 따라 실행한 경우 LDAP를 통해 필요한 항목이 실제로 생성되었는지 확인해야 합니다. 최소한 에 대한 항목 과 에 대한 kdb5_ldap_util create항목이 있어야 합니다 . 오류 메시지는 데이터베이스 mkey("마스터 키" 비밀번호로 암호화됨)를 보유하는 의사 주체인 "K/M" 항목에 관한 것입니다.K/M@<realm>krbtgt/<realm>@<realm>

Kerberos LDAP 개체를 읽는 데 필요한 권한이 부여되지 않은 경우를 대비하여 KDC 계정을 사용하여 LDAP를 확인하십시오. (계좌는 그렇지 않습니다.필요uid를 갖고; 로컬 Unix 계정이 아닌 LDAP 바인딩 계정으로만 사용됩니다.)

Ubuntu는 때때로 AppArmor를 사용하므로 AVC 거부 메시지를 확인하십시오 dmesg. KDC가 "service.keyfile"을 읽거나 OpenLDAP 소켓에 액세스하는 것이 허용되지 않을 수 있습니다.

또한 statsLDAP 서버에서 로그 수준을 활성화하여 모든 쿼리를 기록하도록 합니다. 예를 들어 KDC가 다른 DN을 찾고 있음을 나타낼 수 있습니다(일반적으로 "ldap_kerberos_container_dn"은 다른 dbmodules 매개변수 옆에 설정됩니다).

마지막으로 strace kadmin.local도구가 실제로 LDAP에 연결하지 않고 대신 로컬 db2 파일에 액세스하려고 시도하는 것으로 표시되면 kdc.confkrb5의 시스템 전체 설정을 재정의하는 구성(KDC 관련 구성 파일)이 있을 수 있습니다. conf. 일반적으로 KDC 구성은 /var/lib/krb5kdc/kdc.confkrb5.conf 전역 설정에서 로드되며 이 설정보다 우선순위가 높습니다.

(추가로 만약 당신이~이었다kdb5_util create [-s]db2를 사용하더라도 처음 시작 시 주 데이터베이스가 자동으로 생성되지 않습니다. 이 작업은 "kdb5_ldap_util create"를 사용하여 LDAP 백엔드에 대해 수행한 것처럼 마스터 암호화 키를 실행하고 제공하여 수동으로 수행해야 합니다 .)

해당 문서에는 없지만 다른 곳에서 본 것 중 하나는 "[domain_realm]" 섹션을 만들고 여기에 내 도메인을 추가하는 것인데, 해봤지만 도움이 되지 않았습니다.

이는 영역에 1:1로 매핑되지 않는 호스트 이름에 대한 티켓을 얻을 때 Kerberos 클라이언트에만 필요합니다(일반적인 예는 mit.edu → ATHENA.MIT.EDU). KDC의 창업과는 관련이 없습니다.

/var/log/kerberos에 쓸 수 있도록 systemd 서비스를 수정해야 하는 로깅 섹션을 만들었습니다.

대신 에 로그인하면 그렇지 않습니다 SYSLOG. 이는 Ubuntu용 시스템 서비스를 작성한 사람의 의도일 가능성이 높습니다.

내 저장소가 LDAP에 있기 때문에 거기에 있지 않습니까?

아니요, /etc/krb5.keytab 파일은 KDC 데이터베이스의 일부가 아닙니다.주인"도메인 구성원"으로 지정되며 시스템 계정의 Kerberos 비밀번호와 동일한 비밀번호를 저장합니다. Kerberos 영역의 각 시스템에는 최소한 주체가 포함된 자체 /etc/krb5.keytab이 있어야 합니다 host/<fqdn>.

Kerberos 비밀번호가 실제 비밀번호가 되도록 LDAP 패스스루 인증을 작동시키려고 합니다. 많은 문서가 오래된 것으로 나타났습니다. 대부분의 사람들이 내가 설정한 saslauthd를 추천하는 것을 보았지만 지금은 /etc/krb5.keytab을 찾고 있습니다.

OpenLDAP의 경우 예, 일반적으로 saslauthd가 필요합니다.

  1. 가 있는 DN에 바인딩할 때 userPassword: {SASL}foo@BARslapd는 libsasl "비밀번호 확인" 기능을 사용합니다.
  2. 구성된 내용에 따라pwcheck_method, libsasl은 saslauthd에 접속하여 비밀번호를 확인합니다.
  3. saslauthd는 옵션을 통해 구성된 백엔드를 사용하여 -a실제 확인을 수행합니다.
  4. 백엔드를 사용하면 -a krb5saslauthd는 제공된 사용자 이름과 비밀번호(와 동일)를 사용하여 KDC에서 초기 Kerberos 티켓을 얻으려고 시도합니다 kinit.
  5. 초기 티켓을 성공적으로 획득한 경우 saslauthd는 추가로 티켓을 요청합니다.자체 서비스 티켓그리고 시스템의 키 탭을 사용하여 암호 해독을 시도합니다.
  6. 서비스 이용권을 취득할 수 있는 경우그리고 해독했고,비밀번호가 승인되었습니다.

KDC 스푸핑 공격을 방지하려면 마지막 단계가 필요합니다. 전통적으로 Kerberos KDC는 비밀번호를 확인하지 않고 티켓을 발행했으며(잘못된 비밀번호는 클라이언트가 수신된 티켓을 해독할 수 없음을 의미함) 악의적인 KDC가 여전히 그렇게 할 수 있습니다. 프로토콜 수준에서 "사전 인증"은 필수가 아닙니다. 따라서 saslauthd는 티켓이 합법적인지 확인하기 위해 다른 Kerberos화된 서비스와 동일한 작업을 수행해야 합니다. 즉, 서비스 키 탭을 사용하여 티켓의 암호를 해독하려고 시도합니다. (pam_krb5와 Windows 모두 AD 로그온 중에 동일한 작업을 수행합니다.)

나는 host/hostname.fqdn@REALM과 ldap/hostname.fqdn@REALM을 만들었습니다. LDAP용 키탭을 만들었습니다. 사용자 1명의 패스를 "{SASL}name@REALM"으로 변환했습니다. 해당 사용자에 대해 testaslauthd를 사용하면 성공합니다. 해당 사용자에 대해 ldapsearch를 사용하면 자격 증명이 유효하지 않습니다. ldap이 saslauthd와 통신하지 않는 것 같아요? 여기 "Kerberos 인증" 아래에 구성을 추가했습니다: help.ubuntu.com/community/OpenLDAPServer 그러나 "ldapsearch -Y GSSAPI"를 수행하면 "GSSAPI 오류: 자격 증명이 제공되지 않았습니다...

-Y GSSAPI~이다직접Kerberos 인증 – saslauthd 및 비밀번호 통과와 완전히 별개입니다. 즉, slapd는 Kerberos 비밀번호조차 받지 않고 Kerberos 비밀번호만 받습니다.티켓서비스 키탭을 기준으로 내부적으로 유효성을 검사합니다.

  1. SASL GSSAPI의 경우 saslauthd가 아닌 slapd 서비스 자체에는 ldap/<fqdn>. (기본적으로 모든 서비스는 /etc/krb5.keytab 시스템에서 키를 찾지만, 보안을 위해 항목을 별도로 유지하고 slapd의 KRB5_KTNAME을 다른 경로로 설정하는 것이 더 나을 수 있습니다. 이렇게 하면 읽도록 할 필요가 없습니다. 시스템 키탭에 액세스합니다.)

  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

OS에 libsasl2를 설치하고 krb5.keytab에 대한 소유권을 openldap 사용자에게 부여해야 합니다.

데비안에서:

sudo apt 설치 libsasl2-2 libsasl2-modules-gssapi-mit

그런 다음

sudo chown openldap:openldap /etc/krb5.keytab 또는 기타 keytab

편집: 하지만 동일한 머신/컨테이너(여러 서버 포함)에 있는 여러 키탭에 주의하세요.

관련 정보