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.
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.
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.
--
/ Alexander Bokovoy
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
