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

[Simo Sorce]

On Wed, 2012-07-11 at 16:40 +0300, Alexander Bokovoy wrote:
> On Wed, 11 Jul 2012, Simo Sorce wrote:
> >On Wed, 2012-07-11 at 15:41 +0300, Alexander Bokovoy wrote:
> >> 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.
> >
> >Yes the point is that you may have users you do not want to give a
> >password to. No need to keep retrying to generate a hash.
> >
> >> >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.
> >
> >Not sure what you mean by 'turn off ipaNTHash from your pre-mod code'.
> Set ipaNTHash value to '0', for example. I.e. not 16 bytes and not
> missing.
> 
> 
> >> 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.
> >
> >True, but it is still required only once per user, in normal course of
> >action you should always get the ipaNTHash back. Even in the race
> >condition case the worst that can happen is that you fail auth once.
> >Given it is not that critical as it can happen only once per user I am
> >not sure it is worth optimizing for this case and create a whole new
> >extended operation for it.
> As per discussion with Simo on IRC, NACK for current approach with
> LDAP_MOD_REPLACE, NACK for extended operation as well.
> 
> Please replace LDAP_MOD_REPLACE with LDAP_MOD_ADD detection. smbldap
> code in smbd uses LDAP_MOD_DELETE/LDAP_MOD_ADD combination as
> replacement of LDAP_MOD_REPLACE to avoid some nasty bugs with Novell
> Directory so we have to live with this approach.

Attached patch that changes REPLACE -> ADD

> >It still doesn't give you much, there are 2 cases:
> >
> >1) For users that are supposed to have the ipaNTHash, you will go
> >through this operation *once* in the lifetime of a pre-existing user
> >(new users get ipaNTHash immediately).
> >
> >2) For users that will never get the ipaNTHash will simply never have
> >it, you only keep repeating this operation and then fail authentication
> >as you won't get back a valid hash, I do not think optimizing this
> >failure case is worth a full extop.
> My point was to get pre-mod code to set ipaNTHash to invalid (non-16
> byte) value to signify that they are 'disabled' for NTLM operations.
> This way I can get ipaNTHash on user fetch but can locally detect that
> the user is without password and therefore avoid the whole process.

Do you still want to do this ?
We could store the value 'DISABLED' instead of the hash, but then I'd
have to change the password plugin to respect it. If you want that I
think we need to open a new bug and treat it as a separate feature.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-simo-494-0003-2-Add-special-modify-op-to-regen-ipaNTHash.patch
Type: text/x-patch
Size: 7195 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20120711/b3130da6/attachment.bin>