LDAP Stunt / Password Encryption in Kerberos Backend misunderstood?

Tom_Krauss thomas.krauss at itserv.de
Thu Jan 31 06:23:36 EST 2013


Hi all, 

I know the following is a bit of a stunt, but....

I have user identities in LDAP (uid containers) that I want to use to serve
for different REALMs in Kerberos.
To be more precise: The uid=user1,ou=... container should contain
krbprincipalname=user1 at REALM1 and krbprincipalname=user1 at REALM2 

In order to meet that requirement I tried the following:

-KDC Solaris 10, Kerberos 1.4
-LDAP branch with UIDs to hold Principals referenced by subtree statement in
REALM1
-copied krbconfig container of REALM1 ( the six initial principals ) to
REALM2 (exchanging REALM1 with REALM2 whereever necessary) using ldapadd
-copied stashfile .k5.REALM1 to .k5.REALM2
-created principal user1 at REALM1 with kadmin.local -x dn="uid=user1,....."
-added krbprincipalname=user1 at REALM2 to dn="uid=user1,...

Now, with kadmin.local -r REALM1 I am able to see a principal user1 at REALM1,
and with kadmin.local -r REALM2 I see user1 at REALM2 respectively.

kinit from REALM1 works, from REALM2 it does not.

My understanding of PW-encryption in KDC backend is as follows: use
supported_enctypes:salts with master_key to encrypt the password string and
write it into the backend.

Because of the setup described above I was hoping to be clean regarding the
master_key. 
Additionally I thought that using 

"cpw -pw <pw> -e aes128-cts:norealm user1" 

from each of kadmin.locals` instances would do the rest.

It does not. Funny thing is - no matter if I change the PW from KDC in
REALM1 or REALM2 it keeps working in REALM1 and it does not in REALM2.

Is it because the master_key is salted, too? 

Any comments welcome.

Cheers

Tom






--
View this message in context: http://kerberos.996246.n3.nabble.com/LDAP-Stunt-Password-Encryption-in-Kerberos-Backend-misunderstood-tp36273.html
Sent from the Kerberos - General mailing list archive at Nabble.com.


More information about the Kerberos mailing list