#47770 #481 breaks possibility to reassemble memberuid list
Closed: Fixed None Opened 6 years ago by 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
  • check this is synced
  • assign user a group membership in AD
  • 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.


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".

  • 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.

  • 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?

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

A retranslation to member is not necessary because uniquemember and member is synced already.

So, what would be the correct use case scenario?

Thanks!

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]:

in posix_group_fix_memberuid_callback do you need to free uids?

Thank you, Rich! I forgot to "port" the line... Plus, running valgrind revealed more leaks... :( Replacing with a new 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]:

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.

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]:

I have tested with 1.3.2.17 but there is the patch not applied I guess?

Not yet. The fix is only in the git branches. Do you need a scratch build?

Replying to [comment:16 cgrzemba]:

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!

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

3 years ago

Login to comment on this ticket.

Metadata