On Fri, Jul 29, 2016 at 12:27:24PM +0200, thierry bordaz wrote:
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).
I'm sorry, but I don't know what is COS (I only know it's a Swedish clothing
brand :-)), is there some link I can take a look at?