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

Re: using kpasswd with ldap db (0.7.2)



On Wed, May 31, 2006 at 09:19:21AM -0500, Eric Ortego wrote:
> On 5/24/06, Love Hörnquist Åstrand <lha@kth.se> wrote:
> >I think its a bug somewhere where the krb5EncryptionType is set, but I
> >can't figure out what it is. If you have time to debug the code its in
> >lib/hdb/hdb-ldap.c:LDAP_entry2mods() where the krb5EncryptionType is set.
> 
> I am not very proficient in C but my curiosity leads me to take a stab at 
> it.
> 
> >if you can't find the error, you can just comment out the while "if
> >(ent->etypes) { " section in that file.
> 
> My guess is that in this section(i.e. ent->etypes) the LDAP_MOD_ADD
> should be LDAP_MOD_REPLACE.
> Seems logical that if the ldap entry is in fact a heimdal entry that
> it would already have the "krb5EncryptionType" set in the entry thus
> leading to my error when trying to add instead of replace. Ill also
> guess that the for loops twice and is why I get the error twice.
> 
>        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;
>            }
>        }

The problem could be in LDAP_message2entry() which constructs the hdb entry from
LDAP. When it finds a samba password attribute, it decodes it as a kerberos key
(right) and then *always* adds ETYPE_ARCFOUR_HMAC_MD5 to ent->etypes->val, even if
the user entry already has krb5EncryptionType set to ETYPE_ARCFOUR_HMAC_MD5. So
we end up with two krb5EncryptionType attributes with the same value.

I applied the attached patch hdb-ldap:LDAP_message2entry() to check, seems to
work. This is just to show the issue (no re-identation to make the patch
clearer), I'm not familiar with the code to tell if this is the correct fix.


--- heimdal-0.7.2/lib/hdb/hdb-ldap.c.attrreplace	2005-04-18 05:03:54.000000000 -0300
+++ heimdal-0.7.2/lib/hdb/hdb-ldap.c	2006-06-14 15:58:49.000000000 -0300
@@ -969,10 +969,11 @@
     /* manually construct the NT (type 23) key */
     ret = LDAP_get_string_value(db, msg, "sambaNTPassword", &ntPasswordIN);
     if (ret == 0) {
 	int *etypes;
 	Key *keys;
+	int i;
 
 	keys = realloc(ent->keys.val,
 		       (ent->keys.len + 1) * sizeof(ent->keys.val[0]));
 	if (keys == NULL) {
 	    free(ntPasswordIN);
@@ -1003,20 +1004,25 @@
 	    }
 	    ent->etypes->val = NULL;
 	    ent->etypes->len = 0;
 	}
 
+	for (i = 0; i < ent->etypes->len && 
+		ent->etypes->val[i] != ETYPE_ARCFOUR_HMAC_MD5; i++);
+	
+	if (i == ent->etypes->len) {
 	etypes = realloc(ent->etypes->val, 
 			 (ent->etypes->len + 1) * sizeof(ent->etypes->val[0]));
 	if (etypes == NULL) {
 	    krb5_set_error_string(context, "malloc: out of memory");
 	    ret = ENOMEM;
 	    goto out;			    
 	}
 	ent->etypes->val = etypes;
 	ent->etypes->val[ent->etypes->len] = ETYPE_ARCFOUR_HMAC_MD5;
 	ent->etypes->len++;
+	}
     }
 
     ret = LDAP_get_generalized_time_value(db, msg, "createTimestamp",
 					  &ent->created_by.time);
     if (ret)