Re: [389-users] Some bind DNs sporadically can't search users
Hi,
so you say that a search with a specific bind user sometimes succeeds
and sometimes doesn't ?
If so, could you run this withe aci logging enabled ?
Are groups involved in the acis and do these groups during these runs ?
Could you post your acis ?
Ludwig
On 03/03/2014 04:56 PM, Morgan Jones wrote:
We're pulling our hair out over this issue and wondering if it
rings a bell for anyone or perhaps there's a bug fix in a later version of 389 that
might resolve it. I've looked and not found anything but it's also not the
easiest issue to search for. We are on CentOS DS now but can move to 389 of course but
hesitate to put forth the effort if we aren't reasonably sure it will resolve our
issue.
Certain bind DNs (so far only service accounts) are unable to search for users. For
instance:
[20/Feb/2014:10:18:05 -0500] conn=15600927 op=1 BIND
dn="uid=copier,ou=employees,dc=domain,dc=org" method=128 version=3
[20/Feb/2014:10:18:05 -0500] conn=15600927 op=1 RESULT err=0 tag=97 nentries=0 etime=0
dn="uid=copier,ou=employees,dc=domain,dc=org"
[20/Feb/2014:10:18:05 -0500] conn=15600927 op=2 SRCH
base="ou=employees,dc=domain,dc=org" scope=2 filter="(uid=user1)"
attrs="cn mail uid"
[20/Feb/2014:10:18:05 -0500] conn=15600927 op=2 RESULT err=0 tag=101 nentries=0 etime=0
I did a search of the directory at the same time on the same replica as myself and other
users with the same access level and was able to search uid=user1.
It sometimes only lasts a few minutes though in a few instances it was much longer. In
one case we resolved it by adding a service account with a different name but the same
access level and moved the application to that account. In another case where hundreds of
copiers are configured with the binddn and thus changing the binddn wasn't practical
we were able to resolve it by restoring the masters from a db2ldif and re-initializing the
consumers. It's not isolated to once consumer--we've seen it on at least 2: one
partial, one full.
Our environment is CentOS DS on CentOS 5. We have ~35,000 entries in the directory, most
of them users. We only have 9 acis, most of which provide access via groups. We have 2
multi-masters, 2 full consumers and until recently 2 partial replicas. We converted the
partial replicas to full replicas recently as we know there are/were issues with partial
replication and wanted to rule that out. We're at the latest version of CentOS DS:
[morgan@ldap01 ~]$ rpm -qa|grep centos-ds
centos-ds-admin-8.2.1-1.el5.centos
centos-ds-console-8.2.0-4.el5.centos
centos-ds-base-8.2.8-2.el5.centos
centos-ds-8.2.0-2.el5.centos
[morgan@ldap01 ~]$
This issue is killing us as it effectively denies access to a service for all users that
use it. This could be the VPN for instance which many users depend on all day for their
work.
We are considering many options, primarily just moving to 389 on CentOS 6. That's a
fairly big task for a site of our size so we'd like some confidence that we won't
see a repeat of this issue. There's talk of considering other products which no one
wants to do but we're all edgy as this has caused a fair amount of downtime and about
all I can do at the moment is monitor for it and re-initialize when it happens which
doesn't inspire confidence.
thank you,
-morgan
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users