Bug 387681

Summary:

"windows_process_dirsync_entry: failed to map tombstone dn." with , in DisplayName

Product:

[Retired] 389

Reporter:

Brian Junker <bjunker>

Component:

Replication - General

Assignee:

Nathan Kinder <nkinder>

Status:

CLOSED ERRATA

QA Contact:

Chandrasekar Kannan <ckannan>

Severity:

low

Docs Contact:

Priority:

high

Version:

1.0.4

CC:

benl, jgalipea, rmeggins, sputhenp, tao

Target Milestone:

---

Target Release:

---

Hardware:

i386

OS:

Linux

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2010-01-21 22:40:28 UTC

Type:

---

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Bug Depends On:

Bug Blocks:

434914, 533025

Attachments:

Description	Flags
Proposed Patch	none

Description Brian Junker 2007-11-16 21:37:27 UTC

If you have a sync between Fedora and Active Directory, if you have a user that 
is synced between them, and you delete that user from Active Directory, if the 
user has a comma in the display name, you get the following error:

windows_process_dirsync_entry: failed to map tombstone dn.

I looked at the code in the replication plugin, and it assumes the a tombstone 
dn looks like this:

CN=WDel Userdb1\\\nDEL:551706bc-ecf2-4b38-9284-9a8554171d69,CN=Deleted 
Objects,DC=magpie,DC=com

However, in our environment, we have the following display modification applied 
to Active Directory for the display name: Firstname, Lastname 
(http://support.microsoft.com/kb/250455).

When the tombstone is processed you get the following error:

[16/Nov/2007:11:48:07 -0800] NSMMReplicationPlugin - received entry from 
dirsync: CN=User\, Test\0ADEL:9f15d421-a637-454d-8de7-d84f528feeb3,CN=Deleted 
Objects,DC=pelco,DC=test
[16/Nov/2007:11:48:07 -0800] NSMMReplicationPlugin - agmt="cn=ADSync" (10:389): 
windows_process_dirsync_entry: failed to map tombstone dn.

Comment 4 Nathan Kinder 2009-10-30 17:40:12 UTC

Created attachment 366833 [details]
Proposed Patch

Comment 5 Nathan Kinder 2009-11-06 16:49:33 UTC

Fix pushed to master.

Counting objects: 13, done.
Delta compression using 2 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 972 bytes, done.
Total 7 (delta 5), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
   faf6894..07b5f94  master -> master

Comment 9 Jenny Severance 2010-01-21 18:09:55 UTC

Verified:

Adding user with lastname, firstname CN:

[21/Jan/2010:11:54:41 -0500] NSMMReplicationPlugin - received entry from dirsync: CN=Duck\,Donald,CN=Users,DC=bos,DC=redhat,DC=com
[21/Jan/2010:11:54:41 -0500] NSMMReplicationPlugin - agmt="cn=Windows Sync" (jennyv3:636): map_entry_dn_inbound: looking for local entry match
ing AD entry [
CN=Duck\,Donald,CN=Users,DC=bos,DC=redhat,DC=com]
[21/Jan/2010:11:54:41 -0500] NSMMReplicationPlugin - agmt="cn=Windows Sync" (jennyv3:636): map_entry_dn_inbound: looking for local entry by gu
id [0d988facc4
6cbd4688f4329335b00d59]
[21/Jan/2010:11:54:41 -0500] NSMMReplicationPlugin - agmt="cn=Windows Sync" (jennyv3:636): map_entry_dn_inbound: problem looking for guid: -1
[21/Jan/2010:11:54:41 -0500] NSMMReplicationPlugin - agmt="cn=Windows Sync" (jennyv3:636): map_entry_dn_inbound: looking for local entry by ui
d [dduck]
[21/Jan/2010:11:54:41 -0500] NSMMReplicationPlugin - agmt="cn=Windows Sync" (jennyv3:636): map_entry_dn_inbound: problem looking for username:
 -1
[21/Jan/2010:11:54:41 -0500] - Windows sync entry: Adding new local entry dn: uid=dduck,ou=People, dc=example, dc=com
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetOrgPerson
objectClass: ntUser
ntUserDeleteAccount: true
uid: dduck
sn: Duck
givenName: Donald
cn: Duck,Donald
ntUserCodePage: 0
ntUserAcctExpires: 9223372036854775807
ntUserDomainId: dduck
ntUniqueId: 0d988facc46cbd4688f4329335b00d59

[21/Jan/2010:11:54:41 -0500] NSMMReplicationPlugin - ruv_add_csn_inprogress: successfully inserted csn 4b5886d1000100010000 into pending list
[21/Jan/2010:11:54:41 -0500] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object 7f4bda0 for database b01d
6802-05de11df-
905696ba-ca239c39_4b572b99000000010000.db4
[21/Jan/2010:11:54:41 -0500] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object 7f4bda0 for database b01d
6802-05de11df-
905696ba-ca239c39_4b572b99000000010000.db4
[21/Jan/2010:11:54:41 -0500] NSMMReplicationPlugin - ruv_update_ruv: successfully committed csn 4b5886d1000100010000
[21/Jan/2010:11:54:41 -0500] NSMMReplicationPlugin - agmt="cn=Windows Sync" (jennyv3:636): Beginning linger on the connection
[21/Jan/2010:11:54:41 -0500] NSMMReplicationPlugin - agmt="cn=Windows Sync" (jennyv3:636): State: sending_updates -> wait_for_changes
[21/Jan/2010:11:54:41 -0500] NSMMReplicationPlugin - agmt="cn=Windows Sync" (jennyv3:636): Linger timeout has expired on the connection
[21/Jan/2010:11:54:41 -0500] NSMMReplicationPlugin - agmt="cn=Windows Sync" (jennyv3:636): State: wait_for_changes -> ready_to_acquire_replica
[21/Jan/2010:11:54:41 -0500] NSMMReplicationPlugin - agmt="cn=Windows Sync" (jennyv3:636): Disconnected from the consumer


Deleting User:

21/Jan/2010:11:55:21 -0500] NSMMReplicationPlugin - received entry from dirsync: CN=Duck\,Donald\0ADEL:ac8f980d-6cc4-46bd-88f4-329335b00d59,CN=Deleted Obje
cts,DC=bos,DC=redhat,DC=com
[21/Jan/2010:11:55:21 -0500] NSMMReplicationPlugin - ruv_add_csn_inprogress: successfully inserted csn 4b5886f9000100010000 into pending list
[21/Jan/2010:11:55:21 -0500] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object 7f4bda0 for database b01d6802-05de11df-
905696ba-ca239c39_4b572b99000000010000.db4
[21/Jan/2010:11:55:21 -0500] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object 7f4bda0 for database b01d6802-05de11df-
905696ba-ca239c39_4b572b99000000010000.db4
[21/Jan/2010:11:55:21 -0500] NSMMReplicationPlugin - ruv_update_ruv: successfully committed csn 4b5886f9000100010000

User is deleted and no "windows_process_dirsync_entry: failed to map tombstone dn" errors logged.  

Verified RHEL 4 32bit, RHEL 5 64 bit and Solaris 9.

RPM version:

redhat-ds-base-8.1.1-1.el5dsrv

PKG version:

   PKGINST:  RHATredhat-dsx-base
      NAME:  Red Hat Directory Server
  CATEGORY:  application
      ARCH:  sparcv9
   VERSION:  8.1.1,REV=2010.01.12.17.58.11
   BASEDIR:  /
      DESC:  Red Hat Directory Server
    PSTAMP:  sun-t1k-02.idm.lab.bos.redhat.com20100112145812
  INSTDATE:  Jan 21 2010 09:20
    STATUS:  completely installed
     FILES:      235 installed pathnames
                  25 shared pathnames
                  35 directories
                  96 executables
               17284 blocks used (approx)

Comment 11 errata-xmlrpc 2010-01-21 22:40:28 UTC

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/RHBA-2010-0064.html