On Wed, 11 Jul 2012, Simo Sorce wrote:
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

>> 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.
Yes, I think it could be good optimization. I've made following ticket:

/ Alexander Bokovoy

Freeipa-devel mailing list

Reply via email to