Noriko, I did not notice any special characters, but I have not been checking specifically for non-printable characters - the next time I run into this problem I will check for that. I am monitoring for this problem by periodically outputting a search for objectclass=* as directory manager to a file, and then using grep to identify DNs that are not in the expected OU. We first discovered the problem when a user reported not being able to login to some applications. It turned out that the user's DN had "shifted" up one level out of ou=People so applications that are configured to look only in ou=People for users would not find them. Our base dn is dc=acs,dc=albany,dc=edu. Here are some of sample DNs, with the uid substituted: user examples: dn: uid=ab123456,dc=acs,dc=albany,dc=edu dn: uid=da123456,ou=People,ou=Netgroup,dc=acs,dc=albany,dc=edu group examples: dn: cn=wwwcarey,=albany,,dc=acs,dc=albany,dc=edu dn: cn=mongrp,dc=acs,dc=albany,dc=edu Here is an example of what one of our typical user entries looks like, with attributes: dn: uid=et123456,ou=People,dc=acs,dc=albany,dc=edu sambaPwdLastSet: 1286193602 albanyEduPersonAffiliation: CEMP albanyEduPersonAffiliation: EMPA eduPersonPrimaryAffiliation: staff eduPersonScopedAffiliation: staff@xxxxxxxxxx eduPersonAffiliation: staff employeeNumber: 999999999 primaryDeptUADContact: Doe,John secondDeptCSSContact: Doe,John primaryDeptCSSContact: Smith, Bob campusAddress: Some Building Rm 5 albanyEduPersonPrimarySubdivision: Systems Management & Operation albanyEduPersonPrimaryDivision: Information Technology Srvcs telephoneNumber: +1 518 4373665 mail: eric@xxxxxxxxxx albanyEduPersonPrimaryDept: 99999 eduPersonPrincipalName: et123456@xxxxxxxxxx preferredDisplayName: Eric Torgersen eduPersonNickName: Eric albanyEduPersonMiddleInitial: A givenName: Eric sn: Torgersen cn: Eric Torgersen displayName: Eric Torgersen ITSLIHomeDirectory: /home/et123456 loginShell: /bin/csh artmac-homeDirectory: /Users/LDAP/et123456 apple-generateduid: 008A0AAE-3C41-197D-CAA7-A5C0475D749D authAuthority: ;basic; sambaSID: S-1-5-21-1234567890-3016994024-4563145123-1234 albanyEduPersonNopwrset: gidNumber: 1001 RITHomeDirectory: /network/rit/home/et123456 albanyEduPersonMboxStatus: active albanyEduPersonNetworkAccess: uid: et123456 objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount objectClass: inetorgperson objectClass: person objectClass: organizationalPerson objectClass: albanyeduperson objectClass: albanyedulinuxaccount objectClass: eduperson objectClass: sunyperson objectClass: sambaSamAccount objectClass: apple-user objectClass: artmac-user objectClass: splunkUser uidNumber: 1002 homeDirectory: /home2/c/e/et123456 gecos: Eric Torgersen,,, We have a number of web applications that use LDAP for authentication, by searching for the user and then binding. We also use our directory as a naming service for Solaris, Linux and Mac hosts. In addition, we have FreeRADIUS servers using our directory to authenticate users on our wireless network. As far as changes to the directory information, we rename entries very rarely, and have not done any since the migration to 389. Most of the modify operations we see are password changes. We have the Samba PAM module on our main Solaris login host, which tends to be quite chatty, deleting and then adding back the sambaPwdLastSet attribute for users each time they login there, even if there is no corresponding change to the sambaNTPassword attribute. When I have come across the incorrect DNs, I have checked the audit log and not found any correlation between the affected DNs and recent modify operations. We have a single master and two read-only replicas. I have seen some of the incorrect DNs replicate over while performing a consumer initialization, but otherwise have not seen this problem on the replicas. Thanks in advance for any help you can provide. Eric Eric Torgersen Assistant Director ITS Systems Management & Operations 518-437-3665 On Thu, 14 Oct 2010, Noriko Hosoi wrote: > Hello, Eric. > > Is it possible to share any sample DNs with us? (No need to be as it > is, you could replace a real uid with something else. But if there are > any special characters in the string, we'd like to learn it.) > > And if you could tell us your use cases, it'd be a big help. For > instance, do you modify the entries or rename them or just search them? > > Thank you for your help, > --noriko > > On 10/14/2010 11:48 AM, Eric Torgersen wrote: > > Hello, > > > > We recently started using the 389 Directory Server and are seeing an odd > > problem where searches start returning the wrong DN for a small number of > > entries in our directory. For example, our users are in > > ou=People,dc=acs,dc=albany,dc=edu but for a few user entries the server > > starts returning the DN as "uid=(username),dc=acs,dc=albany,dc=edu," > > "uid=(username),ou=Group,dc=acs,dc=albany,dc=edu," or sometimes even > > something like "uid=(username),=albany,,dc=acs,dc=albany,dc=edu." The > > problem seems to be in memory, as restarting the directory server fixes > > the problem temporarily but then it will start happening again with a > > different set of entries. A db2ldif extract made while the server is in > > this state does not contain any of the bad DNs. > > > > I tried upgrading to 1.2.6.1-2. Since the upgrade, this has not happened > > for any user entries, but has happened for group entries. > > > > Has anyone else run into this problem? We are running 389 Directory > > Server on Oracle Linux 5.5 and using the x86_64 389 DS packages from EPEL. > > We have about 125,000 entries in our directory, most of which are in > > ou=People. We recently migrated from the Sun Directory Server 5.2. > > > > Thanks, > > Eric > > > > Eric Torgersen > > Assistant Director > > ITS Systems Management& Operations > > 518-437-3665 > > > > -- > > 389 users mailing list > > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
