On 07/29/2016 12:21 PM, Jakub Hrozek wrote:
On Fri, Jul 29, 2016 at 11:57:54AM +0200, thierry bordaz wrote:
On 07/28/2016 04:49 PM, Lukas Slebodnik wrote:
On (28/07/16 16:37), thierry bordaz wrote:
...
That is correct and this is the expected behavior.
Using ns-inactivate.pl with a role, it inactivates all the entries in that
role adding nsaccountlock virtual attibute.
You are right, update (add of nsaccountlock) of regular user can be done
without update of its modifytimestamp.
Thank you very much for confirmation and for info that plugin
is not used on IPA. So we needn't special case nsaccountlock for IPA.
We had a discussion on sssd devel meeting. And we agreed that we will
do some performace measurements. And if there will be significant
difference then we will check modifytimestamp only with IPA and AD.
and it will be disabled by default with generic LDAP.
LS
Hi Lukas,
Just to be sure. Does SSSD currently use or intend to use
ns-inactivate/ns-activate to disable/enable ipa users ?
Judging by the code, we use the value of nsAccountLock as well in IPA..
(before running the HBAC rules, we check the if the user is expired by
looking at nsAccountLock -> see sdap_account_expired_rhds() and us
calling sdap_access_send() from ipa_pam_access_handler_send().
Hi Jakub,
Thanks for your answer.
You are right, freeipa is only accessing nsaccountlock and does not use
ns-inactivate/ns-activate.
My concern is that there can be conflict if nsaccountlock is updated as
a real attribute or by COS.
so IMHO sssd should not use cos approach (like ns-inactivate/ns-activate).
thanks
thierry
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
