Re: [389-users] incorrect DNs sometimes returned on searches: 1.2.6 and 1.2.6.1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Fedora Directory Users]     [Fedora Directory Devel]     [Fedora Announce]     [Fedora Legacy Announce]     [Kernel]     [Fedora Legacy]     [Share Photos]     [Fedora Desktop]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Big List of Linux Books]     [Gimp]     [Yosemite News]

  Powered by Linux