Re: [Freeipa-devel] User life-cycle: nsAccountLock
On 06/18/2014 06:09 PM, Simo Sorce wrote: 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: ... 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. IMO we should definitely allow provisioning system to set userPassword, looks like a valid use case to me. 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. When someone creates user with plain text userPassword, we normally hash it and also generate krbPrincipalKey, right? Should we then simply avoid both operations in the staging area, let the password be stored in plain text and let the Kerberos keys and attributes be generated during user activation? It will happen via recreating the entry anyway, so the right operations should be triggered. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] User life-cycle: nsAccountLock
On 06/19/2014 09:06 AM, Martin Kosek wrote: On 06/18/2014 06:09 PM, Simo Sorce wrote: 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: ... 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. IMO we should definitely allow provisioning system to set userPassword, looks like a valid use case to me. 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. When someone creates user with plain text userPassword, we normally hash it and also generate krbPrincipalKey, right? Should we then simply avoid both operations in the staging area, let the password be stored in plain text and let the Kerberos keys and attributes be generated during user activation? It will happen via recreating the entry anyway, so the right operations should be triggered. Setting a Staging password policy would keep userPassword in clear. This is needed because generation of krb keys is done by ipa-pwd on an unhashed password. For kerberos authentication, to limit ipa-pwd to generate the keys only in Active container, we need to provide a scope to that plugin. I did not find such scope and needs to be implemented. When deleting an Active user, krb keys are removed. That means that only Active entries have krb keys. For simple bind, we can do simple bind on Active entry. we can not bind with Delete user as userPassword has been removed. Stage users may contain userPassword (in clear), we can rely on a cos to lock the entry or reject a bind in pre-op plugin. thierry Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] User life-cycle: nsAccountLock
On Thu, 2014-06-19 at 09:06 +0200, Martin Kosek wrote: On 06/18/2014 06:09 PM, Simo Sorce wrote: 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: ... 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. IMO we should definitely allow provisioning system to set userPassword, looks like a valid use case to me. 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. When someone creates user with plain text userPassword, we normally hash it and also generate krbPrincipalKey, right? Should we then simply avoid both operations in the staging area, let the password be stored in plain text and let the Kerberos keys and attributes be generated during user activation? It will happen via recreating the entry anyway, so the right operations should be triggered. No, we do not store plain text passwords. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] User life-cycle: nsAccountLock
On 06/19/2014 02:33 PM, Simo Sorce wrote: On Thu, 2014-06-19 at 09:06 +0200, Martin Kosek wrote: On 06/18/2014 06:09 PM, Simo Sorce wrote: 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: ... 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. IMO we should definitely allow provisioning system to set userPassword, looks like a valid use case to me. 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. When someone creates user with plain text userPassword, we normally hash it and also generate krbPrincipalKey, right? Should we then simply avoid both operations in the staging area, let the password be stored in plain text and let the Kerberos keys and attributes be generated during user activation? It will happen via recreating the entry anyway, so the right operations should be triggered. No, we do not store plain text passwords. So the only way to have clear password is during the ADD or MOD (password). For user-add or user-mod, keys are generated and we can authenticate with the account. For stageuser-add or stageuser-mod , we can generate krb keys but do not want to authenticate with it. So it is a change in ipa-kdb to skip Staging. Then when activating an account, userpassword/krb keys are simply copied to the new Active account. thierry Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] User life-cycle: nsAccountLock
On 06/19/2014 02:33 PM, Simo Sorce wrote: On Thu, 2014-06-19 at 09:06 +0200, Martin Kosek wrote: On 06/18/2014 06:09 PM, Simo Sorce wrote: 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: ... 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. IMO we should definitely allow provisioning system to set userPassword, looks like a valid use case to me. 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. When someone creates user with plain text userPassword, we normally hash it and also generate krbPrincipalKey, right? Should we then simply avoid both operations in the staging area, let the password be stored in plain text and let the Kerberos keys and attributes be generated during user activation? It will happen via recreating the entry anyway, so the right operations should be triggered. No, we do not store plain text passwords. Simo. Ok, but then we need to allow generation krbPrincipalKey for staged users, when a new user is filed and userPassword is set. Otherwise you would not be able to generate the krpPrincipalKey during user activation. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] User life-cycle: nsAccountLock
On Thu, 2014-06-19 at 14:47 +0200, Martin Kosek wrote: On 06/19/2014 02:33 PM, Simo Sorce wrote: On Thu, 2014-06-19 at 09:06 +0200, Martin Kosek wrote: On 06/18/2014 06:09 PM, Simo Sorce wrote: 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: ... 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. IMO we should definitely allow provisioning system to set userPassword, looks like a valid use case to me. 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. When someone creates user with plain text userPassword, we normally hash it and also generate krbPrincipalKey, right? Should we then simply avoid both operations in the staging area, let the password be stored in plain text and let the Kerberos keys and attributes be generated during user activation? It will happen via recreating the entry anyway, so the right operations should be triggered. No, we do not store plain text passwords. Simo. Ok, but then we need to allow generation krbPrincipalKey for staged users, when a new user is filed and userPassword is set. Otherwise you would not be able to generate the krpPrincipalKey during user activation. This is ok, this is actually what happens today if you do it. The only thing we need to do is to change the code to not allow use of keys for staged/deleted entries, which we have to do anyway if we allow to write userPassword. One issue is what to do with expiration times. When you store a password we do create keys and hash it, but we also mark it as expired by default. I guess we want to maintain that ? Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] User life-cycle: nsAccountLock
On 06/18/2014 12:47 PM, 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? That is correct, provisioning system can create entries in Staging area without nsAccountLock or with nsAccountLock: False. With stageuser-add we have this ability but as you described below it can be done with different ways. We may create a new DS plugin to enforce added stage entries (or modifications) have the expected values. But I think the idea was to make Stage container free to receive any kind of entries. This was the activation job to make the control. activation (stageuser-activate) is setting 'nsAccountLock: False' so currently at least this method is manipulating nsAccountLock. 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? Sure this solution would also have the advantages to prevent authentication from Staging/Delete container and allow authentication only from 'Active' container. For LDAP BIND pre-bind which plugin are you thinking of ? a new one ? About Kerberos update, my understanding is that if we restrict (in sasl mapping) the baseDN template (nsSaslMapBaseDNTemplate) to cn=users,cn=accounts,SUFFIX it would restrict kerberos authentication only to Active user. Is that correct ? This would allow us to be sure that nobody can bind/authenticate to these users without having to manipulate nsAccountLock attribute. The only downside is that this would not be effective in older FreeIPA versions, but AFAIR, we specified that if User Life Cycle is enabled, all server should have at least 4.1 - otherwise for example deleted users would be put to the special container or old servers would not have the appropriate DS plugins updates. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] User life-cycle: nsAccountLock
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. 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. This would allow us to be sure that nobody can bind/authenticate to these users without having to manipulate nsAccountLock attribute. We should just make sure no credentials are set ? Is there any valid reson for the provisioning system to be allowed to set userPassword ? (It can't set KrbKerberosKey anyway) Alternatively/optionally just set a CoS that enforces nsAccountLock to be set on all staged entries without having to explicitly set it ? The only downside is that this would not be effective in older FreeIPA versions, but AFAIR, we specified that if User Life Cycle is enabled, all server should have at least 4.1 - otherwise for example deleted users would be put to the special container or old servers would not have the appropriate DS plugins updates. Yeah I do not see an issue with older servers, esp if we do not allow credentials on the entry anyway. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] User life-cycle: nsAccountLock
On Wed, 2014-06-18 at 15:22 +0200, thierry bordaz wrote: On 06/18/2014 12:47 PM, 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? That is correct, provisioning system can create entries in Staging area without nsAccountLock or with nsAccountLock: False. With stageuser-add we have this ability but as you described below it can be done with different ways. We may create a new DS plugin to enforce added stage entries (or modifications) have the expected values. But I think the idea was to make Stage container free to receive any kind of entries. This was the activation job to make the control. activation (stageuser-activate) is setting 'nsAccountLock: False' so currently at least this method is manipulating nsAccountLock. Shouldn't it just remove the attribute if present ? 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? Sure this solution would also have the advantages to prevent authentication from Staging/Delete container and allow authentication only from 'Active' container. For LDAP BIND pre-bind which plugin are you thinking of ? a new one ? About Kerberos update, my understanding is that if we restrict (in sasl mapping) the baseDN template (nsSaslMapBaseDNTemplate) to cn=users,cn=accounts,SUFFIX it would restrict kerberos authentication only to Active user. Is that correct ? No, we have many other principals that can bind to DS in cn=computers,cn=users cn=services,cn=users and cn=kerberos at least, you cannot exclude those. Besides there are also simple binds. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] User life-cycle: nsAccountLock
On 06/18/2014 03:40 PM, Simo Sorce wrote: On Wed, 2014-06-18 at 15:22 +0200, thierry bordaz wrote: On 06/18/2014 12:47 PM, 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? That is correct, provisioning system can create entries in Staging area without nsAccountLock or with nsAccountLock: False. With stageuser-add we have this ability but as you described below it can be done with different ways. We may create a new DS plugin to enforce added stage entries (or modifications) have the expected values. But I think the idea was to make Stage container free to receive any kind of entries. This was the activation job to make the control. activation (stageuser-activate) is setting 'nsAccountLock: False' so currently at least this method is manipulating nsAccountLock. Shouldn't it just remove the attribute if present ? Yes as we decide to not use this attribute to allow/disallow . I will remove it from CLIs 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? Sure this solution would also have the advantages to prevent authentication from Staging/Delete container and allow authentication only from 'Active' container. For LDAP BIND pre-bind which plugin are you thinking of ? a new one ? About Kerberos update, my understanding is that if we restrict (in sasl mapping) the baseDN template (nsSaslMapBaseDNTemplate) to cn=users,cn=accounts,SUFFIX it would restrict kerberos authentication only to Active user. Is that correct ? No, we have many other principals that can bind to DS in cn=computers,cn=users cn=services,cn=users and cn=kerberos at least, you cannot exclude those. Besides there are also simple binds. Ok. We want to exclude 'Stage' and 'Delete' containers. A possibility is to create a new multivalued attribute (like 'nsSaslMapExcludeSubtree') for nsSaslMapping entry. thanks thierry Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] User life-cycle: nsAccountLock
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. 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'. This would allow us to be sure that nobody can bind/authenticate to these users without having to manipulate nsAccountLock attribute. We should just make sure no credentials are set ? Is there any valid reson for the provisioning system to be allowed to set userPassword ? (It can't set KrbKerberosKey anyway) Does that mean stageuser-add/mod should not support options around password setting ? Alternatively/optionally just set a CoS that enforces nsAccountLock to be set on all staged entries without having to explicitly set it ? The only downside is that this would not be effective in older FreeIPA versions, but AFAIR, we specified that if User Life Cycle is enabled, all server should have at least 4.1 - otherwise for example deleted users would be put to the special container or old servers would not have the appropriate DS plugins updates. Yeah I do not see an issue with older servers, esp if we do not allow credentials on the entry anyway. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] User life-cycle: nsAccountLock
On Wed, 2014-06-18 at 15:55 +0200, thierry bordaz wrote: On 06/18/2014 03:40 PM, Simo Sorce wrote: On Wed, 2014-06-18 at 15:22 +0200, thierry bordaz wrote: On 06/18/2014 12:47 PM, 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? That is correct, provisioning system can create entries in Staging area without nsAccountLock or with nsAccountLock: False. With stageuser-add we have this ability but as you described below it can be done with different ways. We may create a new DS plugin to enforce added stage entries (or modifications) have the expected values. But I think the idea was to make Stage container free to receive any kind of entries. This was the activation job to make the control. activation (stageuser-activate) is setting 'nsAccountLock: False' so currently at least this method is manipulating nsAccountLock. Shouldn't it just remove the attribute if present ? Yes as we decide to not use this attribute to allow/disallow . I will remove it from CLIs 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? Sure this solution would also have the advantages to prevent authentication from Staging/Delete container and allow authentication only from 'Active' container. For LDAP BIND pre-bind which plugin are you thinking of ? a new one ? About Kerberos update, my understanding is that if we restrict (in sasl mapping) the baseDN template (nsSaslMapBaseDNTemplate) to cn=users,cn=accounts,SUFFIX it would restrict kerberos authentication only to Active user. Is that correct ? No, we have many other principals that can bind to DS in cn=computers,cn=users cn=services,cn=users and cn=kerberos at least, you cannot exclude those. Besides there are also simple binds. Ok. We want to exclude 'Stage' and 'Delete' containers. A possibility is to create a new multivalued attribute (like 'nsSaslMapExcludeSubtree') for nsSaslMapping entry. I fail to see the need for this. In order to be able to to GSSAPI authentication you need to be able to acquire a ticket for the principal, but the KrbKerberosKey should be removed when deleting a user and the provisioning system has no way to create it in the staged entries. So there should be no way for a principal to make an AS request to start with nor a TGS request, so it should never be able to have a ticket that would map to one of those entries. Also just changing the Sasl mapping will not preclude simple binds ? But can we simply delete userPassword from deleted and prevent it to be set in staging (or alternatively force accountlock) ? Third alternative is to change the ipa pre-bind plugin to preclude any binding for entries in deleted/staged Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] User life-cycle: nsAccountLock
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 ? If this is the case then we probably need to change the pre-bind plugin (and ipa-kdb ?) to explicitly exclude staging (and deleted ?). 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. This would allow us to be sure that nobody can bind/authenticate to these users without having to manipulate nsAccountLock attribute. We should just make sure no credentials are set ? Is there any valid reson for the provisioning system to be allowed to set userPassword ? (It can't set KrbKerberosKey anyway) Does that mean stageuser-add/mod should not support options around password setting ? Well the problem is that is you allow setting userPassword then you need it in the clear and have to also generate Kerberos Keys, and then we need to prevent them from being used (ipa-kdb change). Allowing to set a pre-hashed userPassword won't work because then the user cannot authenticate with Kerberos and the server need to be permanently set in migration mode or the user must be forced to go somewhere to change the password so setting a pre-shared password in the first place is basically useless. Otherwise we can simply forbid them being set by provisioning and the only thing we need to do is to remove userPassword/KrbPrincipalKey when the user is moved to the deleted tree. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] User life-cycle: nsAccountLock
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). 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 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. 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. Now if password and keys have been removed, he should reset his password before being authenticate. I think it is an acceptable limitation. This would allow us to be sure that nobody can bind/authenticate to these users without having to manipulate nsAccountLock attribute. We should just make sure no credentials are set ? Is there any valid reson for the provisioning system to be allowed to set userPassword ? (It can't set KrbKerberosKey anyway) Does that mean stageuser-add/mod should not support options around password setting ? Well the problem is that is you allow setting userPassword then you need it in the clear and have to also generate Kerberos Keys, and then we need to prevent them from being used (ipa-kdb change). Allowing to set a pre-hashed userPassword won't work because then the user cannot authenticate with Kerberos and the server need to be permanently set in migration mode or the user must be forced to go somewhere to change the password so setting a pre-shared password in the first place is basically useless. Otherwise we can simply forbid them being set by provisioning and the only thing we need to do is to remove userPassword/KrbPrincipalKey when the user is moved to the deleted tree. Simo. ___ Freeipa-devel mailing list
Re: [Freeipa-devel] User life-cycle: nsAccountLock
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. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
