Description of problem: When adding a sub user entry under a user entry that is a member of another group and syncing to Windows, it causes a segmentation fault and crashes the Directory Server. Version-Release number of selected component (if applicable): 8.1 How reproducible: Steps to Reproduce: 1. Set up Windows Synchronization 2. In DS, under a user entry A, add another user B. Then add user entry A to a group 3. Initiate send and receive updates Actual results: [30/Jan/2009:07:20:59 -0800] - windows_search_entry: recieved 1 messages, 0 entries, 0 references [30/Jan/2009:07:20:59 -0800] NSMMReplicationPlugin - agmt="cn=ADS" (jennyv3:636): map_entry_dn_outbound: entry not found - rc 0 ./start-slapd: line 43: 11503 Segmentation fault ./ns-slapd -D /etc/dirsrv/slapd-ivanova -i $PIDFILE -w $STARTPIDFILE "$@" Expected results: successful syncronization of users and group members Additional info: In my test: 1st user was already synchronized and added both users to a group.
Results from gdb stack trace: (gdb) c Continuing. [Thread 1137219936 (LWP 30091) exited] [New Thread 1137219936 (LWP 5507)] [Thread 1137219936 (LWP 5507) exited] [New Thread 1137219936 (LWP 5526)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1137219936 (LWP 5526)] 0x0000002a955a275e in ?? () (gdb) Continuing. Program terminated with signal SIGSEGV, Segmentation fault. The program no longer exists. (gdb) bt No stack.
sorry - little more explaination: First seg fault - users being synced already existed in ADS, I realized that was not the setup - deleted all the users from ADS, redid agreement, and set up for sync again - this time seg fault crashed the server. But no stack trace.
I've tried to reproduce this - I could not. Steps: 1) Set up winsync agreement 2) Add user A to DS like this: uid=testuserA,ou=people,suffix The user was successfully created in AD 3) Add user B to DS like this: uid=testuserB,uid=testuserA,ou=people,suffix The user was _not_ created in AD - because the DN in AD is changed to something like this: cn=Test UserA,cn=Users,suffix So I'm not sure how to reproduce this part of the test - when the test adds users to DS, does it add them as cn=User NameA,ou=people,suffix? If so, then that could work, since it will use the same DN on DS as on AD 4) Added cn=testgroup,ou=people,suffix to DS with uniqueMember: uid=testuserA,ou=people,suffix and uid=testuserB,uid=testuserA,ou=people,suffix The group was added to AD with only testuserA as a member (since testuserB did not get synced over) So I could not reproduce the bug, but I'm not sure I followed the correct steps - where is the test plan/script for this bug?
I tried the cn=Test UserA naming style above - when I tried to add testuserB, I got the following error from AD: [03/Feb/2009:14:48:48 -0700] - Attempting to add entry cn=Test User7,cn=Test User6,cn=Users,dc=testdomain,dc=com to AD for local entry cn=Test User7,cn=Test User6,ou=people,dc=testdomain,dc=com [03/Feb/2009:14:48:48 -0700] NSMMReplicationPlugin - agmt="cn=meTowin2k3svr389" (win2k3svr:389): Received result code 64 (00002099: NameErr: DSID-03050EB2, problem 2005 (NAMING_VIOLATION), data 0, best match of: 'cn=Test User6,cn=Users,dc=testdomain,dc=com' ) for add operation [03/Feb/2009:14:48:48 -0700] NSMMReplicationPlugin - agmt="cn=meTowin2k3svr389" (win2k3svr:389): windows_replay_update: Cannot replay add operation. So it looks as though AD does not allow you to add a user under another user, or something like that. However, testuserA and the group were both added to AD correctly. So I'm still not sure if I'm following the correct steps, or if I just can't reproduce the bug.
Created attachment 330901 [details] diffs
Created attachment 330919 [details] cvs commit log Reviewed by: nkinder (Thanks!) Fix Description: The function that checks to see if the mod has already been made to the AD entry should just return 0 if the AD entry does not exist or could not be found - in this case, the regular windows replay code will handle it. Platforms tested: RHEL5 Flag Day: no Doc impact: no
fix verified RHEL 5 DS 8.1 - Windows 2003 Enterprise passsync 1.1.0
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-0455.html