[Freeipa-devel] [PATCHES][RFC] Implement special operation to revoer NT hash for a user

[Alexander Bokovoy]

On Wed, 11 Jul 2012, Simo Sorce wrote:
>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.
If users don't have RC4-HMAC key and don't have ipaNTHash set, they
can't log in into smbd anyway until they change their password.

>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.
So we get to the same issue of a task run against potentially unbound
number of users, including replication interaction.

Instead, a scheme with ipasam-based generator would mean we:
1. Fetch the user attributes from LDAP
2. Notice ipaNTHash is missing and not disabled
3. Issue ipaNTHash update request if (2) is true.

Maybe we can turn off ipaNTHash from your pre-mod code if there is no
RC4-HMAC key and ipaNTHash wasn't set? Password change op will get that
overriden, of course. Then we can rely on it in (2) above.

>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.
If we decide to use it in ipasam, extended operation will be simpliest
thing -- contrary to other approaches which would require two LDAP
requests. It also allows to return the key in the same go.

>> 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.
See above. Being able to differentiate cases 
- RC4-HMAC is missing, no automatic ipaNTHash generation
- RC4-HMAC is available, generate ipaNTHash
- ipaNTHash is generated via password change

is worth it because it allows to avoid additional roundtrips from
ipasam and still be able to avoid generator tasks.

-- 
/ Alexander Bokovoy