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