[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: KDC {K5KEY} userPassword problem
Henry B. Hotz wrote:
> I've no experience with LDAP back-ends, but isn't that entry supposed
> to be used by the KDC, not by slapd? In other words isn't it an
> issue with the KDC reading it rather than slapd reading it?
>
> I wouldn't think that type of entry is supposed to be usable by
> slapd, only by the kdc.
The smbk5pwd overlay (which I wrote) in OpenLDAP knows how to parse the keys
stored in LDAP by the Heimdal KDC. Of course for it to work, the overlay has
to actually be configured on all of the relevant slapd instances...
> On Dec 4, 2007, at 1:01 PM, Kent Nasveschuk wrote:
>
>> Hello,
>>
>> I'm having a problem with OpenLDAP using Heimdal Kerberos via the
>> {K5KEY} entry in userPassword. The problem is with the second LDAP/
>> KDC,
>> it works fine on the master LDAP/KDC/KPASSWDD/KADMIND.
>>
>> Some info:
>> This is an OpenLDAP server with Heimdal storing Kerberos stuff in
>> LDAP.
>> Master (mbauth01) Slave (mblauth02)
>> OSs: CentOS5
>> OpenLDAP 2.3.39
>> Heimdal 1.0.1
>>
>> On both KDCs I can use kadmin -l and do klist -l Princ and get
>> results fine, so I know that the KDC can talk to the LDAP backend via
>> ldapi.
>>
>> I don't think it is acls because I removed all and get the same
>> result.
>>
>>> From a remote machine if I search the master:
>> ldapsearch -Z -x -h mblauth01.mbl.edu -b ou=users,dc=mbl,dc=edu -D
>> cn=<some user>,ou=users,dc=mbl,dc=edu -w <krb5 password> cn=<user> cn
>>
>> I get results
>>
>>> From a remote machine if I search the slave:
>> ldapsearch -Z -x -h mblauth02.mbl.edu -b ou=users,dc=mbl,dc=edu -D
>> cn=<some user>,ou=users,dc=mbl,dc=edu -w <krb5 password> cn=<user> cn
>>
>> I get:
>> ldap_bind: Invalid credentials (49)
>>
>> It doesn't look like the mechanism in LDAP that refers userPassword
>> with
>> {K5KEY} to KDC is working on the slave machine. A couple things might
>> cause this to fail.
>>
>> The {K5KEY} entry never made it from the Master to the slave via
>> syncrepl. I verified that the entries are there. I also changed a
>> password using kadmin cpw and verified that the change was
>> replicated to
>> the slave and they were.
>>
>>
>> Any suggestions on how to troubleshoot this or get it working.
>>
>> /etc/krb5.conf on slave (mblauth02)
>>
>> [realms]
>> MBL.EDU = {
>> kdc = mblauth02.mbl.edu:88
>> admin_server = mblauth01.mbl.edu:749
>> kpasswd_server = mblauth01.mbl.edu
>> default_domain = mbl.edu
>> }
>> [domain_realm]
>> .mbl.edu = MBL.EDU
>> mbl.edu = MBL.EDU
>> [kadmin]
>> password_lifetime = 180d
>> [kdc]
>> database = {
>> realm = MBL.EDU
>> dbname = ldap:dc=mbl,dc=edu
>> }
>>
>> [appdefaults]
>> ticket_lifetime = 1d
>> renew_lifetime = 1d
>> forward = true
>> forwardable = true
>> [libdefaults]
>> ticket_lifetime = 1d
>> renew_lifetime = 2d
>> forwardable = true
>> proxiable = true
>> warn_pwexpire = 7d
>> fcc-mit-ticketflags = true
>> default_realm = MBL.EDU
>> dns_lookup_realm = false
>> dns_lookup_kdc = false
>> [logging]
>> kdc = SYSLOG:debug:local1
>> admin-server = SYSLOG:debug:local2
>> default = SYSLOG:debug:auth
>>
>>
>> /etc/krb5.conf on master (mblauth01)
>>
>> [realms]
>> MBL.EDU = {
>> kdc = mblauth01.mbl.edu:88
>> admin_server = mblauth01.mbl.edu:749
>> kpasswd_server = mblauth01.mbl.edu
>> default_domain = mbl.edu
>> }
>> [domain_realm]
>> .mbl.edu = MBL.EDU
>> mbl.edu = MBL.EDU
>> [kadmin]
>> password_lifetime = 180d
>> [appdefaults]
>> ticket_lifetime = 1d
>> renew_lifetime = 1d
>> forward = true
>> forwardable = true
>> [libdefaults]
>> ticket_lifetime = 1d
>> renew_lifetime = 2d
>> forwardable = true
>> proxiable = true
>> warn_pwexpire = 7d
>> fcc-mit-ticketflags = true
>> default_realm = MBL.EDU
>> dns_lookup_realm = false
>> dns_lookup_kdc = false
>> [logging]
>> kdc = SYSLOG:info:local1
>> admin-server = SYSLOG:info:local2
>> default = SYSLOG:err:auth
>>
>> [kdc]
>> database = {
>> realm = MBL.EDU
>> dbname = ldap:dc=mbl,dc=edu
>> }
>>
>> Keytabs on each server:
>>
>> [root@mblauth01 heimdal-1.0.1]# klist -k -e -t
>> Keytab name: FILE:/etc/krb5.keytab
>> KVNO Timestamp Principal
>> ---- -----------------
>> --------------------------------------------------------
>> 2 10/19/07 14:29:20 host/mblauth01.mbl.edu@MBL.EDU (DES cbc mode
>> with
>> RSA-MD5)
>> 2 10/19/07 14:29:20 host/mblauth01.mbl.edu@MBL.EDU (DES cbc mode
>> with
>> RSA-MD4)
>> 2 10/19/07 14:29:20 host/mblauth01.mbl.edu@MBL.EDU (DES cbc mode
>> with
>> CRC-32)
>> 2 10/19/07 14:29:20 host/mblauth01.mbl.edu@MBL.EDU (AES-256 CTS
>> mode
>> with 96-bit SHA-1 HMAC)
>> 2 10/19/07 14:29:20 host/mblauth01.mbl.edu@MBL.EDU (Triple DES cbc
>> mode with HMAC/sha1)
>> 2 10/19/07 14:29:20 host/mblauth01.mbl.edu@MBL.EDU (ArcFour with
>> HMAC/md5)
>> [root@mblauth01 heimdal-1.0.1]#
>>
>> [root@mblauth02 openldap]# klist -k -e -t
>> Keytab name: FILE:/etc/krb5.keytab
>> KVNO Timestamp Principal
>> ---- -----------------
>> --------------------------------------------------------
>> 2 12/03/07 10:33:16 host/mblauth02.mbl.edu@MBL.EDU (DES cbc mode
>> with
>> RSA-MD5)
>> 2 12/03/07 10:33:16 host/mblauth02.mbl.edu@MBL.EDU (DES cbc mode
>> with
>> RSA-MD4)
>> 2 12/03/07 10:33:16 host/mblauth02.mbl.edu@MBL.EDU (DES cbc mode
>> with
>> CRC-32)
>> 2 12/03/07 10:33:16 host/mblauth02.mbl.edu@MBL.EDU (AES-256 CTS
>> mode
>> with 96-bit SHA-1 HMAC)
>> 2 12/03/07 10:33:16 host/mblauth02.mbl.edu@MBL.EDU (Triple DES cbc
>> mode with HMAC/sha1)
>> 2 12/03/07 10:33:16 host/mblauth02.mbl.edu@MBL.EDU (ArcFour with
>> HMAC/md5)
>> [root@mblauth02 openldap]#
>>
>>
>> I'm baffled. (|:<()
>
> ------------------------------------------------------------------------
> The opinions expressed in this message are mine,
> not those of Caltech, JPL, NASA, or the US Government.
> Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
>
>
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/