[Freeipa-devel] User life-cycle: nsAccountLock

[Simo Sorce]

On Wed, 2014-06-18 at 17:49 +0200, thierry bordaz wrote:
> On 06/18/2014 04:45 PM, Simo Sorce wrote:
> > On Wed, 2014-06-18 at 16:20 +0200, thierry bordaz wrote:
> >> On 06/18/2014 03:31 PM, Simo Sorce wrote:
> >>> On Wed, 2014-06-18 at 12:47 +0200, Martin Kosek wrote:
> >>>> On 06/17/2014 05:59 PM, thierry bordaz wrote:
> >>>>> On 06/16/2014 03:04 PM, Rob Crittenden wrote:
> >>>> ...
> >>>>>      Thanks for your precise feedback and sorry for my late answer.
> >>>>>      So if I try to consolidate my understandings, the workflow would be:
> >>>>>
> >>>>>       1. Staging (container: cn=staged
> >>>>>          users,cn=accounts,cn=provisioning,SUFFIX)
> >>>>>            * ipa stageuser-add <login>
> >>>>>              It creates a stage entry with
> >>>>>
> >>>>>                  uidNumber: -1
> >>>>>                  gidNumber: -1
> >>>>>                  ipaUniqueID: autogenerate
> >>>>>                  description: __no_upg__
> >>>>>                  manager: checks that the DN is an active user
> >>>>>                  nsAccountLock: True
> >>>> I was thinking about the nsAccountLock part again. Should we really force
> >>>> provisioning systems to set it to True for staged users? Should we even
> >>>> manipulate it in stageduser plugin?
> >>> No, thinking hard about it I think nsAccountLock should be completely
> >>> ignored in the staged area. It is an operational attribute that is
> >>> responsibility of IPA admins, provisioning systems have nothing to do
> >>> with it. If they do not want a user to be available they simply do not
> >>> provision it. If they do then it is on the admin to decide if/when to
> >>> unstage the user and make it available.
> >> A Stage user is waiting for an approval before being Active. And an
> >> approver may have a look at its properties to decide.
> >> During the time it remains in Staging, admin do not want someone to bind
> >> with that entry even if the provisioning system set the password.
> >> pre-bind plugin or cos are possibilites to prevent binding with that entry.
> > Right, if we allow setting userPassword this would happen, but then if
> > we allow setting userPassword do we also generate Kerberos Keys ?

> Currently setting of the userPassword (add entry or mod entry) triggers 
> generation of krb keys (I guess in ipa-kdb).

No it happen in ipa-pwd-extop

> > If this is the case then we probably need to change the pre-bind plugin
> > (and ipa-kdb ?) to explicitly exclude staging (and deleted ?).

> Do you mean to prevent ipa-kdb to generate krb keys when the this is 
> Delete/Staging

No I mean to prevent the ipa-kdb driver (it's the KDC driver) from
returning any key even if present for entries in those suffixes.

> > I was actually planning to use staging to allow kadmin to create
> > entries, so we need to be careful how ipa-kdb limits access to staging,
> > I would guess it should pretend KrbKerberosKey is not present for those
> > entries.
> >
> >>>> The original reason why I proposed it in
> >>>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management
> >>>> is to prevent LDAP BINDs on such user or Kerberos authentication on such user.
> >>>> Wouldn't it be better to simply just update KDC backend plugin and LDAP BIND
> >>>> pre-bind callback to prevent authentication to users in cn=provisioning,SUFFIX?
> >>> The staged user should have it's userPassword anmd KrbKerberosKey
> >>> removed, so no binding should be possible.
> >> That means a Delete user being staged (ipa stageuser-add <login>
> >> --from-delete) will loose its password/keys.
> >> I believe it is an acceptable limitation else the admin would prefere to
> >> do 'ipa user-undelete <login>'.
> > What I meant here is the ipa-del would drop the passwords and keys, so
> > there is no undelete that will restore them. But if we think we should
> > preserve them then the above option (change in ipa-kdb plugin) is the
> > best way to go to mask out these entries.

> I do not know what are the consequences of dropping password and keys.

It means the entry cannot be used as an authentication source :)

> A use case would be someone that returns back to an organization and get 
> his account undelete. This person will likely remember his previous 
> password and would expect to be authenticate with kerberos using that 
> password.

TBH I think the likelihood of remembering an unused years old password
is very low, and they would probably be expired anyway ...

> Now if password and keys have been removed, he should reset his password 
> before being authenticate. I think it is an acceptable limitation.

I think it may be a desirable feature rather than a limitation :-)

Simo.