since the changes of #481 it is not possible any more to regenerate memberuids from uniquemember list by create a memberuid task.
Steps to reproduce -- test:
check it is synced to DS and memberuid value is added in corresponding group on DS
delete memberuid value on DS
start fix_memberuid task
nothing happend --> wrong! the memberuid should be regenerated
The idea of my implemetation was, that memberuid only maintained on DS and NOT in AD. So that AD admins only have to assign group memberships and never touch the memberuid list in AD.
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1090176
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1090178
Hello, cgrzemba;
Could you help me understand the problem?
Here are the steps I took to reproduce the problem...
Replying to [ticket:47770 cgrzemba]:
since the changes of #481 it is not possible any more to regenerate memberuids from uniquemember list by create a memberuid task. Steps to reproduce -- test: - assign a user on AD Posix values
Steps to reproduce -- test: - assign a user on AD Posix values
{{{ ldapmodify -h <windows> ... -D "cn=administrator,.." -w <pw> dn: CN=user0,CN=Users,DC=example,DC=com changetype: modify add: uidNumber uidNumber: 28 - add: gidNumber gidNumber: 28 - add: unixHomeDirectory unixHomeDirectory: /home/user0 }}}
check this is synced
Yes, they are synced to DS: {{{ dn: uid=user0,ou=People,dc=example,dc=com objectClass: posixAccount homeDirectory: /home/user0 gidNumber: 28 uidNumber: 28 }}}
assign user a group membership in AD
{{{ dapmodify -h <windows> ... -D "cn=administrator,.." -w <pw> dn: CN=ad group0,CN=Users,DC=example,DC=com changetype: modify add: gidNumber gidNumber: 10 - add: memberuid memberuid: CN=user0,CN=Users,DC=example,DC=com }}}
Or did it mean add "member: CN=user0,CN=Users,DC=example,DC=com" by "assign user a group membership in AD"? I also did it and it's synced to DS as "uniquemember".
They are synced to DS. Please note that the DN is the one on AD. (not converted to the one on DS, which would be "uid=user0,ou=People,dc=example,dc=com")
{{{ dn: cn=ad group0,ou=People,dc=example,dc=com memberuid: CN=user0,CN=Users,DC=example,DC=com gidnumber: 10 }}}
{{{ dn: cn=ad group0,ou=People,dc=example,dc=com changetype: modify delete: memberuid memberuid: CN=user0,CN=Users,DC=example,DC=com }}}
Then, the operation is synced to the AD and the "memberuid: CN=user0,CN=Users,DC=example,DC=com" is removed on AD, as well.
Indeed, nothing happened by this task.
{{{ ldapmodify -x -h <DS> .. -D 'cn=directory manager' -w <PW> -a dn: cn=memuidtask,cn=memberuid task,cn=tasks,cn=config cn: memuidtask objectClass: extensibleObject objectClass: top }}}
But I need more input what should happen...
I also thought this AD style value of memberuid "memberuid: CN=user0,CN=Users,DC=example,DC=com" is supposed to be converted to the DS style "uid=user0,ou=People,dc=example,dc=com" by the task (although the value is already deleted by "- delete memberuid value on DS")?
What was the problem in the above use case? Adding memberuid to AD and the value is synced to DS?
{{{ add: memberuid memberuid: CN=user0,CN=Users,DC=example,DC=com }}}
memberuid is supposed to be added to DS only and it's translated to member when synced to AD?
So, what would be the correct use case scenario?
Thanks!
Replying to [comment:5 nhosoi]:
Hello, cgrzemba; Could you help me understand the problem? Here are the steps I took to reproduce the problem... Replying to [ticket:47770 cgrzemba]: since the changes of #481 it is not possible any more to regenerate memberuids from uniquemember list by create a memberuid task. Steps to reproduce -- test: - assign a user on AD Posix values {{{ ldapmodify -h <windows> ... -D "cn=administrator,.." -w <pw> dn: CN=user0,CN=Users,DC=example,DC=com changetype: modify add: uidNumber uidNumber: 28 - add: gidNumber gidNumber: 28 - add: unixHomeDirectory unixHomeDirectory: /home/user0 }}} check this is synced Yes, they are synced to DS: {{{ dn: uid=user0,ou=People,dc=example,dc=com objectClass: posixAccount homeDirectory: /home/user0 gidNumber: 28 uidNumber: 28 }}} assign user a group membership in AD {{{ dapmodify -h <windows> ... -D "cn=administrator,.." -w <pw> dn: CN=ad group0,CN=Users,DC=example,DC=com changetype: modify add: gidNumber gidNumber: 10 - add: memberuid memberuid: CN=user0,CN=Users,DC=example,DC=com }}} Or did it mean add "member: CN=user0,CN=Users,DC=example,DC=com" by "assign user a group membership in AD"? I also did it and it's synced to DS as "uniquemember".
Yes, attribute memberuid should never contain a DN, only a Posix UID (login name) RFC2307!!!!
check it is synced to DS and memberuid value is added in corresponding group on DS They are synced to DS. Please note that the DN is the one on AD. (not converted to the one on DS, which would be "uid=user0,ou=People,dc=example,dc=com") {{{ dn: cn=ad group0,ou=People,dc=example,dc=com memberuid: CN=user0,CN=Users,DC=example,DC=com gidnumber: 10 }}} delete memberuid value on DS {{{ dn: cn=ad group0,ou=People,dc=example,dc=com changetype: modify delete: memberuid memberuid: CN=user0,CN=Users,DC=example,DC=com }}} Then, the operation is synced to the AD and the "memberuid: CN=user0,CN=Users,DC=example,DC=com" is removed on AD, as well.
Typically I never change the memberUid on AD. The idea is the the AD administrator only assign AD-users to AD-groups and this will synced to DS and also mapped in DS to memberUid's if the AD-group has posix attributes.
start fix_memberuid task Indeed, nothing happened by this task. {{{ ldapmodify -x -h <DS> .. -D 'cn=directory manager' -w <PW> -a dn: cn=memuidtask,cn=memberuid task,cn=tasks,cn=config cn: memuidtask objectClass: extensibleObject objectClass: top }}} But I need more input what should happen... nothing happend --> wrong! the memberuid should be regenerated I also thought this AD style value of memberuid "memberuid: CN=user0,CN=Users,DC=example,DC=com" is supposed to be converted to the DS style "uid=user0,ou=People,dc=example,dc=com" by the task (although the value is already deleted by "- delete memberuid value on DS")? The idea of my implemetation was, that memberuid only maintained on DS and NOT in AD. So that AD admins only have to assign group memberships and never touch the memberuid list in AD. What was the problem in the above use case? Adding memberuid to AD and the value is synced to DS? {{{ add: memberuid memberuid: CN=user0,CN=Users,DC=example,DC=com }}} memberuid is supposed to be added to DS only and it's translated to member when synced to AD? meberuid should get a value like: memberuid: user0
memberuid is supposed to be added to DS only and it's translated to member when synced to AD? meberuid should get a value like: memberuid: user0
A retranslation to member is not necessary because uniquemember and member is synced already.
So, what would be the correct use case scenario? Thanks!
git patch file (master) 0001-Ticket-47770-481-breaks-possibility-to-reassemble-me.patch
Description: Patch to implement #481 "expand nested posix groups" wiped out the code in posix_group_fix_memberuid_callback (posix- group-task.c) to add memberuid if the entry is a posix group. This patch adds the code back.
in posix_group_fix_memberuid_callback do you need to free uids?
Replying to [comment:11 rmeggins]:
Thank you, Rich! I forgot to "port" the line... Plus, running valgrind revealed more leaks... :( Replacing with a new patch.
git patch file (master; take 2) -- Fixed memory leaks. 0001-Ticket-47770-481-breaks-possibility-to-reassemble-me.2.patch
ack - Carsten, can you test this patch and see if it fixes your problem?
Reviewed by Rich (Thank you!!)
Pushed to master: fa31627..8d5410e master -> master commit 8d5410e
Pushed to 389-ds-base-1.3.2: c314999..945d113 389-ds-base-1.3.2 -> 389-ds-base-1.3.2 commit 945d113
Pushed to 389-ds-base-1.3.1: a5e636b..2574dff 389-ds-base-1.3.1 -> 389-ds-base-1.3.1 commit 2574dffa82490b2258226edf5b420abaf19a9c09
Pushed to 389-ds-base-1.2.11: bf4cbf1..bdb5e35 389-ds-base-1.2.11 -> 389-ds-base-1.2.11 commit bdb5e35
Replying to [comment:13 rmeggins]:
unfortunatly not, it visits only the first group entry and returns. If I provide a filter on fixup-memberuid.pl like:
fixup-memberuid.pl -D cn=directory" "manager -j /tmp/.dmpw -b dc=example,dc=com -v -f "(&(objectclass=posixGroup)(uniquemember=*))"
it process all group but do not fix them.
Replying to [comment:15 cgrzemba]:
Replying to [comment:13 rmeggins]: ack - Carsten, can you test this patch and see if it fixes your problem? unfortunatly not, it visits only the first group entry and returns. If I provide a filter on fixup-memberuid.pl like: fixup-memberuid.pl -D cn=directory" "manager -j /tmp/.dmpw -b dc=example,dc=com -v -f "(&(objectclass=posixGroup)(uniquemember=*))" it process all group but do not fix them.
I have tested with 1.3.2.17 but there is the patch not applied I guess?
Replying to [comment:16 cgrzemba]:
Not yet. The fix is only in the git branches. Do you need a scratch build?
Replying to [comment:15 cgrzemba]: Replying to [comment:13 rmeggins]: ack - Carsten, can you test this patch and see if it fixes your problem? unfortunatly not, it visits only the first group entry and returns. If I provide a filter on fixup-memberuid.pl like: fixup-memberuid.pl -D cn=directory" "manager -j /tmp/.dmpw -b dc=example,dc=com -v -f "(&(objectclass=posixGroup)(uniquemember=*))" it process all group but do not fix them. I have tested with 1.3.2.17 but there is the patch not applied I guess? How I have tested with source from git master and it works for me. Thanks!
I have tested with 1.3.2.17 but there is the patch not applied I guess? How I have tested with source from git master and it works for me. Thanks!
Replying to [comment:18 cgrzemba]:
How I have tested with source from git master and it works for me. Thanks!
What a relief... Thank you so much for verifying the fix, Carsten!
Metadata Update from @nhosoi: - Issue assigned to nhosoi - Issue set to the milestone: 1.2.11.30
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/1102
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.