Re: [Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server
On 06/17/2014 09:42 PM, Simo Sorce wrote: On Tue, 2014-06-17 at 21:36 +0200, thierry bordaz wrote: On 06/17/2014 09:29 PM, Simo Sorce wrote: On Tue, 2014-06-17 at 15:23 -0400, Rob Crittenden wrote: Simo Sorce wrote: On Tue, 2014-06-17 at 17:59 +0200, thierry bordaz wrote: * ipa stageuser-add login --from-delete It moves a deleted entry to staging container where uidNumber: unchanged, so it is preserved from the prevous active account gidNumber: unchanged, so it is preserved from the prevous active account ipaUniqueID: autogenerate (reset to autogenerate) Why are you resetting the unique id ? Read back a few in the thread. I suggested, perhaps incorrectly, that given that there should be no more references to the user once they go into deleted or staged, it may be ok to reset this value. Well, let me reiterate, the deleted bucket is for those environments where they have a mandate (regulation, law, policy, etc..) to never delete users and reinstate users if they are deleted. So all uniquely identifying information should be preserved in case the object is revived. This means we need to do our best to preserve all these attributes if we can. This is what is done when an Active user is deleted. uidNumber/gidNumber/ipaUniqueID are preserved. When activating a user, currently UUID plugin prevents to set a value. Should it be relaxed.. I feel not. It is a sensitive info and provisioning system should not define it. Why is it sensitive ? A ipaUniqueID is not really sensitive, it just needs to be unique. Ok. I believed it was :-) I have a concern, if a provisioning system is free to define this value, I wonder if it can create problem for replication. For example a provisioning system creates two staging entries on different servers but with the same ipaUniqueID value. If the entries are activated at the same time, the ADDs operation (activation) will not be replicated because the attribute uniqueness plugin will reject it. This case existed before if two IPA uuid plugins generated identical value on different replica. But the probability was less than if the provisioning system is free to set it. When undelete a user (move Delete-Staging), ipaUniqueID can be preserved but as the purpose of Staging entry is to become active I thought it would be better to wipe the value also at this time. I understand that (and I noted before that I think deleted-staged is a bad idea IMO :-) ), but you are wiping it only as a workaround, because the plugin prevents you from adding it. Would have you wiped it if it were not the case ? And if so, why ? That is correct. I thought to wipe it because the plugin rejected values others than 'autogenerate'. To relax the control that rejects values other than 'autogenerate', I need to modify the plugin. Should it be done under an other ticket or can it be part of this RFE ? 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: enforce ipaUniqueID generation by the server
On Wed, 2014-06-18 at 11:39 +0200, thierry bordaz wrote: On 06/17/2014 09:42 PM, Simo Sorce wrote: On Tue, 2014-06-17 at 21:36 +0200, thierry bordaz wrote: On 06/17/2014 09:29 PM, Simo Sorce wrote: On Tue, 2014-06-17 at 15:23 -0400, Rob Crittenden wrote: Simo Sorce wrote: On Tue, 2014-06-17 at 17:59 +0200, thierry bordaz wrote: * ipa stageuser-add login --from-delete It moves a deleted entry to staging container where uidNumber: unchanged, so it is preserved from the prevous active account gidNumber: unchanged, so it is preserved from the prevous active account ipaUniqueID: autogenerate (reset to autogenerate) Why are you resetting the unique id ? Read back a few in the thread. I suggested, perhaps incorrectly, that given that there should be no more references to the user once they go into deleted or staged, it may be ok to reset this value. Well, let me reiterate, the deleted bucket is for those environments where they have a mandate (regulation, law, policy, etc..) to never delete users and reinstate users if they are deleted. So all uniquely identifying information should be preserved in case the object is revived. This means we need to do our best to preserve all these attributes if we can. This is what is done when an Active user is deleted. uidNumber/gidNumber/ipaUniqueID are preserved. When activating a user, currently UUID plugin prevents to set a value. Should it be relaxed.. I feel not. It is a sensitive info and provisioning system should not define it. Why is it sensitive ? A ipaUniqueID is not really sensitive, it just needs to be unique. Ok. I believed it was :-) I have a concern, if a provisioning system is free to define this value, I wonder if it can create problem for replication. For example a provisioning system creates two staging entries on different servers but with the same ipaUniqueID value. A provisioning system should never have to contact 2 different servers, what would be the point ? And then on top of that generate the same UUID ? Well don't do that, fix your provisioning tool. If the entries are activated at the same time, the ADDs operation (activation) will not be replicated because the attribute uniqueness plugin will reject it. Right, don't do that. This case existed before if two IPA uuid plugins generated identical value on different replica. But the probability was less than if the provisioning system is free to set it. Sure, but who cares ? I mean there are *many* ways to whose a system, the provisioning system can simply create 2 users accounts with the same name on 2 servers and get them activated at the same time and you get the same issue as uid is also unique. Just fix the malfunctioning provisioning system. When undelete a user (move Delete-Staging), ipaUniqueID can be preserved but as the purpose of Staging entry is to become active I thought it would be better to wipe the value also at this time. I understand that (and I noted before that I think deleted-staged is a bad idea IMO :-) ), but you are wiping it only as a workaround, because the plugin prevents you from adding it. Would have you wiped it if it were not the case ? And if so, why ? That is correct. I thought to wipe it because the plugin rejected values others than 'autogenerate'. To relax the control that rejects values other than 'autogenerate', I need to modify the plugin. Should it be done under an other ticket or can it be part of this RFE ? I think it can be part of this RFE, should we use the Relax Control for this ? I think it may still valuable to enforce the rule in non-staging cases. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server
On 06/16/2014 03:04 PM, Rob Crittenden wrote: thierry bordaz wrote: Hello, When a stage user is activate (ipa stageuse-activate), UUID plugin (DS) checks that the ipaUniqueID value of the new active user is 'autogenerate'. This is useful to prevent a provisioning systems to create Active user with invalid ipaUniqueID. Now one of the workflow step is to move a Delete user into the Stage container. In that case the Stage entry contains a ipaUniqueID and can not activate. A possibility is to 'reset' the ipaUniqueID value to 'autogenerate' during that step but I wonder it it is valid to reset it. Also, is it valid to reset it and keep others values like uidNumber/gidNumber ? I guess to walk through the logic, the unique id is there so we can uniquely address an entry without worrying about the value changing (like uid, name, etc). So if it is a brand new entry from the provisioning system, yeah, we want to always set it to autogenerate. If a user is deleted I think we agreed that all links to that user would be broken (memberships, hbac rules, etc) which means that it doesn't matter if the unique id is changed I suppose. IMHO uidnumber/gidnumber should always be maintained. rob Hello Rob, 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 * ipa stageuser-add login --from-delete It moves a deleted entry to staging container where uidNumber: unchanged, so it is preserved from the prevous active account gidNumber: unchanged, so it is preserved from the prevous active account ipaUniqueID: autogenerate (reset to autogenerate) description: __no_upg__ (to show there is no managed group) nsAccountLock: True * ipa stageuser-activate login It adds in the active container, a destination copy of a stage entry where uidNumber: unchanged, so a provisioning system can force a uidNumber gidNumber: unchanged, so a provisioning system can force a gidNumber ipaUniqueID: autogenerate (reset to autogenerate) description: value __no_upg__ is removed nsAccountLock: False DN syntax attributes are cleared (but kept for schema checking) except: manager, managedby and secretary (those values must be active DN entries) Then remove the source entry from the 'Staging' container. * ipa stageuser-find login * ipa stageuser-show login * ipa stageuser-mod login nsAccountLock: can not be modify DN syntax attributes: checks that the DN is an active user * ipa stageuser-del login 1. Active (container: cn=users,cn=accounts,SUFFIX) A new entry (user-add or stageuser-activate) is updated by DS plugins (UUID, memberof, managed entries and DNA plugins) * ipa user-add login nsAccountLock:False * ipa user-find login * ipa user-show login * ipa user-mod login nsAccountLock: can not be modify DN syntax attributes: checks that DN is an active user * ipa user-delete login moves (modrdn) the entry under 'Delete' container but first do the following upates nsAccountLock: true all memberships attributes updated by plugins (managed entries/memberof) description: __no_upg__ DN syntax attributes are cleared (but kept for schema checking) except: manager, managedby and secretary) * ipa user-undelete login moves (modrdn) the entry under 'Active' containers. DS plugins will update the membership attributes. Before the modrdn, the updates are done: nsAccountLock: False description: value __no_upg__ is removed DN syntax attributes are cleared (but kept for schema checking) except: manager, managedby and secretary (those values must be active DN entries) 1. Delete (container is cn=deleted users,cn=accounts,SUFFIX) This container has no specific plugin, only user and stageuser are implemented. I would have an additional question. 'stageuser-add' is used both to create a
Re: [Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server
thierry bordaz wrote: On 06/16/2014 03:04 PM, Rob Crittenden wrote: thierry bordaz wrote: Hello, When a stage user is activate (ipa stageuse-activate), UUID plugin (DS) checks that the ipaUniqueID value of the new active user is 'autogenerate'. This is useful to prevent a provisioning systems to create Active user with invalid ipaUniqueID. Now one of the workflow step is to move a Delete user into the Stage container. In that case the Stage entry contains a ipaUniqueID and can not activate. A possibility is to 'reset' the ipaUniqueID value to 'autogenerate' during that step but I wonder it it is valid to reset it. Also, is it valid to reset it and keep others values like uidNumber/gidNumber ? I guess to walk through the logic, the unique id is there so we can uniquely address an entry without worrying about the value changing (like uid, name, etc). So if it is a brand new entry from the provisioning system, yeah, we want to always set it to autogenerate. If a user is deleted I think we agreed that all links to that user would be broken (memberships, hbac rules, etc) which means that it doesn't matter if the unique id is changed I suppose. IMHO uidnumber/gidnumber should always be maintained. rob Hello Rob, 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 * ipa stageuser-add login --from-delete It moves a deleted entry to staging container where uidNumber: unchanged, so it is preserved from the prevous active account gidNumber: unchanged, so it is preserved from the prevous active account ipaUniqueID: autogenerate (reset to autogenerate) description: __no_upg__ (to show there is no managed group) nsAccountLock: True * ipa stageuser-activate login It adds in the active container, a destination copy of a stage entry where uidNumber: unchanged, so a provisioning system can force a uidNumber gidNumber: unchanged, so a provisioning system can force a gidNumber ipaUniqueID: autogenerate (reset to autogenerate) description: value __no_upg__ is removed nsAccountLock: False DN syntax attributes are cleared (but kept for schema checking) except: manager, managedby and secretary (those values must be active DN entries) Then remove the source entry from the 'Staging' container. * ipa stageuser-find login * ipa stageuser-show login * ipa stageuser-mod login nsAccountLock: can not be modify DN syntax attributes: checks that the DN is an active user So your plugin is going to manage restriction access to nsAccountLock or is this going to be via an ACI? * ipa stageuser-del login 1. Active (container: cn=users,cn=accounts,SUFFIX) A new entry (user-add or stageuser-activate) is updated by DS plugins (UUID, memberof, managed entries and DNA plugins) * ipa user-add login nsAccountLock:False * ipa user-find login * ipa user-show login * ipa user-mod login nsAccountLock: can not be modify DN syntax attributes: checks that DN is an active user Why can't nsAccountLock be modified, or was this a cut-n-paste error? * ipa user-delete login moves (modrdn) the entry under 'Delete' container but first do the following upates nsAccountLock: true all memberships attributes updated by plugins (managed entries/memberof) Just to be clear, your plugin is going to remove all of these? description: __no_upg__ DN syntax attributes are cleared (but kept for schema checking) except: manager, managedby and secretary) * ipa user-undelete login moves (modrdn) the entry under 'Active' containers. DS plugins will update the membership attributes. Before the modrdn, the updates are done: nsAccountLock: False description: value __no_upg__ is removed
Re: [Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server
On 06/17/2014 07:35 PM, Rob Crittenden wrote: thierry bordaz wrote: On 06/16/2014 03:04 PM, Rob Crittenden wrote: thierry bordaz wrote: Hello, When a stage user is activate (ipa stageuse-activate), UUID plugin (DS) checks that the ipaUniqueID value of the new active user is 'autogenerate'. This is useful to prevent a provisioning systems to create Active user with invalid ipaUniqueID. Now one of the workflow step is to move a Delete user into the Stage container. In that case the Stage entry contains a ipaUniqueID and can not activate. A possibility is to 'reset' the ipaUniqueID value to 'autogenerate' during that step but I wonder it it is valid to reset it. Also, is it valid to reset it and keep others values like uidNumber/gidNumber ? I guess to walk through the logic, the unique id is there so we can uniquely address an entry without worrying about the value changing (like uid, name, etc). So if it is a brand new entry from the provisioning system, yeah, we want to always set it to autogenerate. If a user is deleted I think we agreed that all links to that user would be broken (memberships, hbac rules, etc) which means that it doesn't matter if the unique id is changed I suppose. IMHO uidnumber/gidnumber should always be maintained. rob Hello Rob, 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 * ipa stageuser-add login --from-delete It moves a deleted entry to staging container where uidNumber: unchanged, so it is preserved from the prevous active account gidNumber: unchanged, so it is preserved from the prevous active account ipaUniqueID: autogenerate (reset to autogenerate) description: __no_upg__ (to show there is no managed group) nsAccountLock: True * ipa stageuser-activate login It adds in the active container, a destination copy of a stage entry where uidNumber: unchanged, so a provisioning system can force a uidNumber gidNumber: unchanged, so a provisioning system can force a gidNumber ipaUniqueID: autogenerate (reset to autogenerate) description: value __no_upg__ is removed nsAccountLock: False DN syntax attributes are cleared (but kept for schema checking) except: manager, managedby and secretary (those values must be active DN entries) Then remove the source entry from the 'Staging' container. * ipa stageuser-find login * ipa stageuser-show login * ipa stageuser-mod login nsAccountLock: can not be modify DN syntax attributes: checks that the DN is an active user So your plugin is going to manage restriction access to nsAccountLock or is this going to be via an ACI? Hi, my first intention was to do this in the plugin. It does not protect from a ldapmodify. ACI would be a better protection but it has overhead. * ipa stageuser-del login 1. Active (container: cn=users,cn=accounts,SUFFIX) A new entry (user-add or stageuser-activate) is updated by DS plugins (UUID, memberof, managed entries and DNA plugins) * ipa user-add login nsAccountLock:False * ipa user-find login * ipa user-show login * ipa user-mod login nsAccountLock: can not be modify DN syntax attributes: checks that DN is an active user Why can't nsAccountLock be modified, or was this a cut-n-paste error? Well, I was thinking to have 'nsAccountLock: False' only in Active container. And the value is set at the transition when the entry becomes active (stageuser-activate and user-undelete) * ipa user-delete login moves (modrdn) the entry under 'Delete' container but first do the following upates nsAccountLock: true all memberships attributes updated by plugins (managed entries/memberof) Just to be clear, your plugin is going to remove all of these? Here I mention membership managed by the scoping of managed entries plugin and memberof plugin. So the 'user plugin' will not wipe the memberships
Re: [Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server
On Tue, 2014-06-17 at 17:59 +0200, thierry bordaz wrote: * ipa stageuser-add login --from-delete It moves a deleted entry to staging container where uidNumber: unchanged, so it is preserved from the prevous active account gidNumber: unchanged, so it is preserved from the prevous active account ipaUniqueID: autogenerate (reset to autogenerate) Why are you resetting the unique id ? description: __no_upg__ (to show there is no managed group) nsAccountLock: True -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server
On 06/17/2014 08:39 PM, Simo Sorce wrote: On Tue, 2014-06-17 at 17:59 +0200, thierry bordaz wrote: * ipa stageuser-add login --from-delete It moves a deleted entry to staging container where uidNumber: unchanged, so it is preserved from the prevous active account gidNumber: unchanged, so it is preserved from the prevous active account ipaUniqueID: autogenerate (reset to autogenerate) Why are you resetting the unique id ? I can not activate a stage user that already has ipaUniqueID. The UUID IPA plugin rejects adding such entry. It is not strictly necessary to reset this value when moving the entry Delete to Staging. But later 'Staging' to 'Active' (stageuser-activate) it is required. description: __no_upg__ (to show there is no managed group) nsAccountLock: True ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server
Simo Sorce wrote: On Tue, 2014-06-17 at 17:59 +0200, thierry bordaz wrote: * ipa stageuser-add login --from-delete It moves a deleted entry to staging container where uidNumber: unchanged, so it is preserved from the prevous active account gidNumber: unchanged, so it is preserved from the prevous active account ipaUniqueID: autogenerate (reset to autogenerate) Why are you resetting the unique id ? Read back a few in the thread. I suggested, perhaps incorrectly, that given that there should be no more references to the user once they go into deleted or staged, it may be ok to reset this value. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server
On Tue, 2014-06-17 at 20:43 +0200, thierry bordaz wrote: On 06/17/2014 08:39 PM, Simo Sorce wrote: On Tue, 2014-06-17 at 17:59 +0200, thierry bordaz wrote: * ipa stageuser-add login --from-delete It moves a deleted entry to staging container where uidNumber: unchanged, so it is preserved from the prevous active account gidNumber: unchanged, so it is preserved from the prevous active account ipaUniqueID: autogenerate (reset to autogenerate) Why are you resetting the unique id ? I can not activate a stage user that already has ipaUniqueID. The UUID IPA plugin rejects adding such entry. It is not strictly necessary to reset this value when moving the entry Delete to Staging. But later 'Staging' to 'Active' (stageuser-activate) it is required. If someone keys something around the ipaUniqueID you cannot lose it. I wonder if we can allow setting a ipauniqueID instead of refusing, I forgot why we refuse to set values though. Maybe we can relax and just count on uniqueness plugin to reject if there is a conflict. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server
On Tue, 2014-06-17 at 15:23 -0400, Rob Crittenden wrote: Simo Sorce wrote: On Tue, 2014-06-17 at 17:59 +0200, thierry bordaz wrote: * ipa stageuser-add login --from-delete It moves a deleted entry to staging container where uidNumber: unchanged, so it is preserved from the prevous active account gidNumber: unchanged, so it is preserved from the prevous active account ipaUniqueID: autogenerate (reset to autogenerate) Why are you resetting the unique id ? Read back a few in the thread. I suggested, perhaps incorrectly, that given that there should be no more references to the user once they go into deleted or staged, it may be ok to reset this value. Well, let me reiterate, the deleted bucket is for those environments where they have a mandate (regulation, law, policy, etc..) to never delete users and reinstate users if they are deleted. So all uniquely identifying information should be preserved in case the object is revived. This means we need to do our best to preserve all these attributes if we can. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server
On 06/17/2014 09:29 PM, Simo Sorce wrote: On Tue, 2014-06-17 at 15:23 -0400, Rob Crittenden wrote: Simo Sorce wrote: On Tue, 2014-06-17 at 17:59 +0200, thierry bordaz wrote: * ipa stageuser-add login --from-delete It moves a deleted entry to staging container where uidNumber: unchanged, so it is preserved from the prevous active account gidNumber: unchanged, so it is preserved from the prevous active account ipaUniqueID: autogenerate (reset to autogenerate) Why are you resetting the unique id ? Read back a few in the thread. I suggested, perhaps incorrectly, that given that there should be no more references to the user once they go into deleted or staged, it may be ok to reset this value. Well, let me reiterate, the deleted bucket is for those environments where they have a mandate (regulation, law, policy, etc..) to never delete users and reinstate users if they are deleted. So all uniquely identifying information should be preserved in case the object is revived. This means we need to do our best to preserve all these attributes if we can. This is what is done when an Active user is deleted. uidNumber/gidNumber/ipaUniqueID are preserved. When activating a user, currently UUID plugin prevents to set a value. Should it be relaxed.. I feel not. It is a sensitive info and provisioning system should not define it. When undelete a user (move Delete-Staging), ipaUniqueID can be preserved but as the purpose of Staging entry is to become active I thought it would be better to wipe the value also at this time. thierry Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server
On Tue, 2014-06-17 at 21:36 +0200, thierry bordaz wrote: On 06/17/2014 09:29 PM, Simo Sorce wrote: On Tue, 2014-06-17 at 15:23 -0400, Rob Crittenden wrote: Simo Sorce wrote: On Tue, 2014-06-17 at 17:59 +0200, thierry bordaz wrote: * ipa stageuser-add login --from-delete It moves a deleted entry to staging container where uidNumber: unchanged, so it is preserved from the prevous active account gidNumber: unchanged, so it is preserved from the prevous active account ipaUniqueID: autogenerate (reset to autogenerate) Why are you resetting the unique id ? Read back a few in the thread. I suggested, perhaps incorrectly, that given that there should be no more references to the user once they go into deleted or staged, it may be ok to reset this value. Well, let me reiterate, the deleted bucket is for those environments where they have a mandate (regulation, law, policy, etc..) to never delete users and reinstate users if they are deleted. So all uniquely identifying information should be preserved in case the object is revived. This means we need to do our best to preserve all these attributes if we can. This is what is done when an Active user is deleted. uidNumber/gidNumber/ipaUniqueID are preserved. When activating a user, currently UUID plugin prevents to set a value. Should it be relaxed.. I feel not. It is a sensitive info and provisioning system should not define it. Why is it sensitive ? A ipaUniqueID is not really sensitive, it just needs to be unique. When undelete a user (move Delete-Staging), ipaUniqueID can be preserved but as the purpose of Staging entry is to become active I thought it would be better to wipe the value also at this time. I understand that (and I noted before that I think deleted-staged is a bad idea IMO :-) ), but you are wiping it only as a workaround, because the plugin prevents you from adding it. Would have you wiped it if it were not the case ? And if so, why ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server
Hello, When a stage user is activate (ipa stageuse-activate), UUID plugin (DS) checks that the ipaUniqueID value of the new active user is 'autogenerate'. This is useful to prevent a provisioning systems to create Active user with invalid ipaUniqueID. Now one of the workflow step is to move a Delete user into the Stage container. In that case the Stage entry contains a ipaUniqueID and can not activate. A possibility is to 'reset' the ipaUniqueID value to 'autogenerate' during that step but I wonder it it is valid to reset it. Also, is it valid to reset it and keep others values like uidNumber/gidNumber ? thanks thierry ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
