On Wed, 2012-07-11 at 14:55 +0300, Alexander Bokovoy wrote: > On Sat, 07 Jul 2012, Simo Sorce wrote: > >When installing the adtrust code we need to be able to get the ipaNTHash > >populated as in some cases we may need it to authenticate connections > >over SMB w/o using kerberos during the trust setup phase. > > > >The NT hash is really just the same thing as the rc4-hmac key we already > >have by default in the Kerberos Keys. > > > >This patch-set implements a check in the password plugin for the pre-mod > >operation to catch the attempt to replace the attribute with the value > >'MagicRegen' in the ipaNThash attribute. > > > >If no previous ipaNTHash value is present, and the kerberos keys are > >available, then we attempt to find the rc4-hmac key and if we find it we > >store it in the ipaNTHash. > > > >This will allow us to give the admin user (and potentially any other > >user) the NT hash samba requires without forcing them to reset their > >password, assuming the rc4-hmac key is present (currently it is by > >default). > > > >I marked this patch-set as RFC as I want opinions on the method (LDAP > >modify with replace operation) I utilized to perform the extraction. > > > >If it bode well with everybody we can consider the patch-set for > >inclusion. > > > >I tested it and extracting the hash works fine and it works later on > >using smbclient to access a share. > > > >This patchset implements task #2867: > >https://fedorahosted.org/freeipa/ticket/2867 > I've read through the code and I think it is a sensible approach. However, > let's get through its possible use first. If I understood correctly, > ipasam is supposed to do following: > > 1. Upon user lookup ldapsam_getsampwnam() in ipa_sam.c will be called > 2. It will call init_sam_from_ldap() > 3. init_sam_from_ldap() will attempt to read ipaNTHash > 4. If (3) failed, we don't call pdb_set_nt_passwd() to set NT hash in > internal pdb structure that is later used by smbd to authenticate the > user. > > Now, with this RFC in action, we'll have: > 3a. read ipaNTHash > 3b. if failed, perform mod/replace ipaNTHash value with MagicRegen > 3c. read ipaNTHash > > Besides two reads, we may have possible race condition where attribute value > is not yet written back when (3c) occurs.
My idea ws that you run the MagicRegen operation out of band, and not in ipasam. The reason is that for users without an RC4-HMAC key you'd keep doing it over and over again. My idea was that when the ipa trust-add operation is run we execute a magicregen op for the user that run it. Then we can run a process that adds ipaNThash via magicregen for all users we want it to. This is something you really need to do only once as after you have added the appropriate objectclass any password change will keep things in sync. > Can we replace this sequence with a single extended operation? I prefer avoiding whole extended operations for trivial stuff that needs to be run once only. > 3. Perform extended operation, say, IPA_OBTAIN_NTHASH, get ipaNTHash > value back for a specified DN > > The operation internally would handle both cases when ipaNTHash is > available and when it is not. > > We also can simply use ipaNTHash attribute length as differentiating > factor for cases when ipaNTHash generation should be prevented. I.e. > absent or empty ipaNTHash would cause generating the hash from kerberos > keys if possible, ipaNTHash set to size less than 16 would prevent > generating the hash. We could do that but I think it would be a lot of work for very little gain. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
