[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Kerberos attributes with ldap/samba for a heimdal backend



On Wed, 16 Mar 2005 06:56:53 -0500
Adam Tauno Williams <adam@morrison-ind.com> wrote:

> > If I add the following attributes to the LDAP entry:
> >     objectClass: krb5Principal
> >     objectClass: krb5KDCEntry
> >     krb5PrincipalName: jfh@CISE.UFL.EDU
> >     krb5KeyVersionNumber: 0
> >     krb5KDCFlags: 382
> > I can then set krb-specific attributes, but when I change the password 
> > using kadmin, I do change the Samba password, but I end up adding krb5Key
> > attributes on doing so, which effectively separates the samba password 
> > from the heimdal password (a change via smbpasswd gives me two different
> > passwords).
> 
> I think the correct solution is to load the smbk5pwd module into the DSA, change
> the Samba LDAP passwd sync option to "only", and to change passwords via the
> extended operation (using normal passwd and properly configured pam ldap.conf).
> 

So, my LDAP entries should also have objectClasses of krb5Principal & 
krb5KDCEntry then along with posixAccount and sambaSamAccount?

So, are smbpasswd and kpasswd *not* supposed to work, then?

Using the smbk5pwd overlay setup, I can set the password using kadmin once, 
but upon the second try, I get

	krb5EncryptionType: value #0 provided more than once

I imagine this is due to this code in LDAP_entry2mods:

        for (i = 0; i < ent->etypes->len; i++) {
            if (is_samba_account &&
                ent->keys.val[i].key.keytype == ETYPE_ARCFOUR_HMAC_MD5)
            {
                ;
            } else if (is_heimdal_entry) {
                ret = LDAP_addmod_integer(context, &mods, LDAP_MOD_ADD,
                                          "krb5EncryptionType",
                                          ent->etypes->val[i]);
                if (ret)
                    goto out;
            }
        }

Here is the value for ent->etypes:

	(gdb) p *ent->etypes
	$3 = {len = 2, val = 0x8057fa0}
	(gdb) p *ent->etypes->val
	$4 = 23

Given the value of ent->etypes->len (2), the krb5EncryptionType is definitely
added twice.

And for ent->keys:

	(gdb) p ent->keys->val[0]
	$7 = {mkvno = 0x0, key = {keytype = 3, keyvalue = {length = 8, 
	data = 0x8057ff0}}, salt = 0x8058000}

	(gdb) p ent->keys->val[1]
	$8 = {mkvno = 0x0, key = {keytype = 2, keyvalue = {length = 8, 
	data = 0x8058330}}, salt = 0x8057f80}

	(gdb) p ent->keys->val[2]
	$9 = {mkvno = 0x0, key = {keytype = 1, keyvalue = {length = 8, 
	data = 0x8058340}}, salt = 0x8057f90}

	(gdb) p ent->keys->val[3]
	$10 = {mkvno = 0x0, key = {keytype = 18, keyvalue = {length = 32, 
	data = 0x8057e90}}, salt = 0x80579f0}

	(gdb) p ent->keys->val[4]
	$11 = {mkvno = 0x0, key = {keytype = 16, keyvalue = {length = 24, 
	data = 0x8057eb8}}, salt = 0x8057a18}

	(gdb) p ent->keys->val[5]
	$12 = {mkvno = 0x0, key = {keytype = 23, keyvalue = {length = 16, 
	data = 0x8058288}}, salt = 0x8058308}

So the two don't seem to match up anyway, unless I'm missing something.
Is this code correct, then?

What's interesting is that for pure samba entries or pure heimdal entries,
this attribute doesn't seem to exist, nor is added to the LDAP entry
through password changes. Only when the LDAP entry is of both objectClasses
does the krb5EncryptionType attribute get added via a password change
(using heimdal, not smbpasswd). Is it necessary?

On a hunch, #ifdefed the code above out, recompiled, and tried again. This 
time, using the smbk5pwd overlay, password changes via samba or heimdal
are reflected in the other, with no errors in changing or authenticating
in either after a password change using either.

Have I stumbled onto a useful fix, or will this cause problems in other
areas?

----------------------------------------------------------------------
| Jim Hranicky, Senior SysAdmin                   UF/CISE Department |
| E314D CSE Building                            Phone (352) 392-1499 |
| jfh@cise.ufl.edu                      http://www.cise.ufl.edu/~jfh |
----------------------------------------------------------------------