openldap-technical June 2008

openldap-technical@openldap.org

73 participants
83 discussions

Re: Openldap fine grained / advanced ACLs
by Raphaël Ouazana-Sustowski 17 Jun '08

17 Jun '08

Hi, Le Mar 17 juin 2008 16:30, Faraz R. Khan a écrit : > Is it possible to have fine grained ACLs in OpenLDAP? My problem is that > the 'write' access is too broad. I wish to be able to control ADD, > modify and delete separately. I tried looking at aacls.sourceforge.net > but it involves the setup of a separate server and looks abandoned. Just a note: this project has not been abandoned. In fact the "set" functionality of OpenLDAP now supersedes AACLs: http://www.openldap.org/faq/data/cache/1133.html Regards, Raphaël Ouazana.

1 0

Openldap fine grained / advanced ACLs
by Faraz R. Khan 17 Jun '08

17 Jun '08

Is it possible to have fine grained ACLs in OpenLDAP? My problem is that the 'write' access is too broad. I wish to be able to control ADD, modify and delete separately. I tried looking at aacls.sourceforge.net but it involves the setup of a separate server and looks abandoned. Any pointers would be appreciated- maybe the denyop module? I was trying to find some docs but all I could find was a FAQ entry. Any pointers would be welcome. Thank you. -- Faraz R Khan Chief Architect Emergen Consulting Pvt Ltd +92.21.529.0381 x200 www.emergen.biz

2 1

Re: Fwd: openldap
by Aravind Arjunan 17 Jun '08

17 Jun '08

Ya i had tried through schema, in internet. It was mentioned tat we can create our own schema for eg: test.schema and we can add the list off attributes that are required for us. I have tried that also but it was not working. I will tell the objective of mine. we have mailserver in RHEL 5 and ldap server is separate. we have all the user information in ldap server including mail id mail box location and other things related to mail and organization. so when a user sends mail the information must want to fetched from ldap server and work accordingly. somehow please help with this issue.Since i need some help from you guys. And thanks in advance. On 17/06/2008, Buchan Milne <bgmilne(a)staff.telkomsa.net> wrote: > > On Tuesday 17 June 2008 14:55:34 Aravind Arjunan wrote: > > Its working when i do it intially. > > can you please tell wat objectclass i have to add when i add the below > > attributes. > > > > 1)Nickname: > > 2)E-mail address: > > 3)First name: > > 4)Last name: > > 5)Additional info: > > These aren't attributes. You haven't specified the client, so it is > difficult > to guess what attributes the client is going to map to these address book > fields. > > However, if I were to guess, they would be: > > 1)displayName (from officeperson.schema) > 2)mail > 3)gn > 4)sn > 5)N/A > > 2-4 are all supported with inetOrgPerson. > > However, this is the kind of information you can determine for yourself. > Please consult the schema definitions ... > > Regards, > Buchan >

2 1

Fwd: Fwd: openldap
by Aravind Arjunan 17 Jun '08

17 Jun '08

---------- Forwarded message ---------- From: Aravind Arjunan <aravind.arjunan(a)gmail.com> Date: 17 Jun 2008 18:25 Subject: Re: Fwd: openldap To: Buchan Milne <bgmilne(a)staff.telkomsa.net> Its working when i do it intially. can you please tell wat objectclass i have to add when i add the below attributes. 1)Nickname: 2)E-mail address: 3)First name: 4)Last name: 5)Additional info: On 17/06/2008, Buchan Milne <bgmilne(a)staff.telkomsa.net> wrote: > > On Tuesday 17 June 2008 14:22:59 Aravind Arjunan wrote: > > ---------- Forwarded message ---------- > > From: Aravind Arjunan <aravind.arjunan(a)gmail.com> > > Date: 17 Jun 2008 17:52 > > Subject: Re: openldap > > To: Michael Ströder <michael(a)stroeder.com> > > > > This is my ldif file, here i have used objectclass as person > > Objectclass person does not include the mail attribute. The objectclass > inetOrgPerson, which you have commented out, does. > > > and i have > > included attribute mail and i got the error. > > > > I had tested by adding objectClass as inetOrgPerson and i got the below > > error. > > > > ldap_modify: Cannot modify object class (69) > > additional info: structural object class modification from > 'person' > > to ' > > inetOrgPerson' not allowed > > Create the entry with the objectclass inetOrgPerson initially ... > > > # Oracle Team > > > > dn: cn=saju,ou=solution,dc=test,dc=com > > objectClass: person > > #objectClass: inetOrgPerson > > cn: saju > > sn: kuttan > > description: Oracle team > > telephoneNumber: 9891950975 > > mail: csaju(a)hcl.in > > > Regards, > Buchan >

1 0

Fwd: openldap
by Aravind Arjunan 17 Jun '08

17 Jun '08

---------- Forwarded message ---------- From: Aravind Arjunan <aravind.arjunan(a)gmail.com> Date: 17 Jun 2008 17:52 Subject: Re: openldap To: Michael Ströder <michael(a)stroeder.com> This is my ldif file, here i have used objectclass as person and i have included attribute mail and i got the error. I had tested by adding objectClass as inetOrgPerson and i got the below error. ldap_modify: Cannot modify object class (69) additional info: structural object class modification from 'person' to ' inetOrgPerson' not allowed # Oracle Team dn: cn=saju,ou=solution,dc=test,dc=com objectClass: person #objectClass: inetOrgPerson cn: saju sn: kuttan description: Oracle team telephoneNumber: 9891950975 mail: csaju(a)hcl.in dn: cn=aravind,ou=solution,dc=test,dc=com objectClass: person #objectClass: inetOrgPerson cn: aravind sn: arjunan description: Oracle team mail: aaravind(a)hcl.in #mobilenumber: 9899798985 # Microsoft Team dn: cn=Kannan,ou=solution,dc=test,dc=com objectClass: person #objectClass: inetOrgPerson cn: Kannan sn: Kann description: Microsoft Team mail: kannans(a)hcl.in #mobilenumber: 9891200471 dn: cn=Manish,ou=solution,dc=test,dc=com objectClass: person cn: Manish sn: Gupta description: Microsoft Team telephoneNumber: 9818206547 dn: cn=sachin,ou=solution,dc=test,dc=com objectClass: person cn: sachin sn: saghal description: Microsoft Team telephoneNumber: 9873574433 On 17/06/2008, Michael Ströder <michael(a)stroeder.com> wrote: > > Aravind Arjunan wrote: > >> ldap_add: Object class violation (65) >> additional info: attribute 'mail' not allowed >> What i need to do for adding this attribute. tell me the correct >> objectclass for this attribute. >> > > Most people use object class 'inetOrgPerson' for adding attribute 'mail' to > user/person entries. Since you don't provide an example entry nobody can > tell what's right for your data. > > Ciao, Michael. >

2 1

openldap
by Aravind Arjunan 17 Jun '08

17 Jun '08

Hi, I had configured openldap 2.3.27-5 in RHEL 5 operating systems. my ldap is acting as a master slave. I have no problem with that, the changes what i make in master is getting replicated to slave. What i need to know is, I had to certain attributes to my openldap server. for eg: when i add an attribute called ' mail ' for specifying mail address and in the ldif file and if i add that ldif file using 'ldapadd' command am getting, ldap_add: Object class violation (65) additional info: attribute 'mail' not allowed What i need to do for adding this attribute. tell me the correct objectclass for this attribute.

1 0

syncrepl in OpenLDAP 2.3.x and updating on a replica
by Filipe Brandenburger 17 Jun '08

17 Jun '08

Hi, I have a setup with two CentOS 5 machines running OpenLDAP 2.3.x, right now the primary uses slurpd to send the updates to the second server, and the second server is using "updatedn" to allow updates (from what I understand! I'm no OpenLDAP guru here.) Clients are using pam_ldap and nss_ldap to get the users and authenticate them in LDAP. Right now hosts query only the primary LDAP server, that is the address set on the "host" variable of /etc/ldap.conf. Changing password with "passwd" works fine, and the password is correctly replicated to the secondary server. Now, first thing, I wanted to load balance between the two servers. The way I did it was to register a Round-Robin DNS record, with one A entry for each server IP, and I used that entry in the "host" variable of /etc/ldap.conf. Everything worked. Queries going each time to a different server. I was expecting to have problems changing passwords, but amazingly it worked. Apparently when a password change request goes to the second server, that server will do a query on the first server to do the password change, and then (through slurpd) the change gets replicated on the second one. Everything great. (Is there a better configuration for pam_ldap and nss_ldap on /etc/ldap.conf for load balancing other than round-robin DNS?) Now, I was reading that syncrepl is superior to slurpd, and that syncrepl is the preferred method of replication. I actually saw that it's true when I saw that it actually replicated the master without having to stop it and copy the dbs (which is necessary with slurpd.) I even saw that in OpenLDAP 2.4.x slurpd is deprecated/discontinued and only syncrepl is supported. So I'm trying to migrate from slurpd to syncrepl. And so far everything is working fine in my test environments. This is what I have configured on the master: overlay syncprov syncprov-checkpoint 1 10 syncprov-sessionlog 100 And on the slave: syncrepl rid=1 provider=ldap://ldap1.mydomain.com type=refreshAndPersist searchbase="dc=mydomain,dc=com" schemachecking=off bindmethod=simple binddn="cn=Manager,dc=mydomain,dc=com" credentials=xxxxxxxxxxx updateref ldap://ldap1.mydomain.com/ It works with queries, and when I do an update on the master, it replicates fine to the slave. But when I try to do some change on the slave, that's what I get: $ ldapdelete -H ldap://ldap2.mydomain.com/ -D cn=Manager,dc=mydomain,dc=com \ -w XXXXXXX -x uid=usertodelete,ou=Users,dc=mydomain,dc=com ldap_delete: Referral (10) referrals: ldap://ldap1.mydomain.com/uid=usertodelete,ou=Users,dc=mydomain,dc=com I would like to have something closer to what happens when using slurpd, which seems to be more transparent to clients. I tried to set "updatedn" but slapd complained that it is supported when using slurpd. I also tried to start configuring overlay on the slave and syncrepl on the master, but when I do that I can't run updates on either side, both of them end up being read-only. I read that on OpenLDAP 2.4.x Administration Guide, on the section about multi-master replication, but I then saw that multi-master replication is supposed to work only on 2.4.x, and not on 2.3.x, so that's apparently not an option. So I ask: is there a way to configure OpenLDAP so that the slave (running syncrepl) can send updates to the master when receives from a client? Or (not as good but still an option): If I use "updateref" to send Referral, how can I make sure the tools (ldapdelete, ldapmodify, ldapadd, ...) actually *follow* the referral (I looked for that in man pages and didn't find any obvious options for that)? And more important, will pam_ldap and nss_ldap follow those referrals when changing the password? Do I have to set something on /etc/ldap.conf for that? Upgrade to 2.4.x is something I would like to avoid, since I would rather stick with what is supported by CentOS 5. Sorry for the long e-mail! Any help and advices will be appreciated. Thanks a lot! Filipe

4 7

Re: [Samba] ldap filter removed? - Solution
by Jarbas Peixoto Júnior 16 Jun '08

16 Jun '08

Can anybody help me about that? []s Jarbas Remy Zandwijk escreveu: > Hi Jarbas, > > Nice solution, but how do you handle ldap searches from different Samba domains? I mean, all searches will use the same filter, which will be converted to another filter. Is OpenLDAP capable of 'rewrite when search from IP number x.x.x.x' ? > > Remy > > > >> In reference at http://lists.samba.org/archive/samba/2005-August/108999.html and http://threebit.net/mail-archive/samba/msg00118.html >> >> Hi Remy, >> Hi Norbert, >> >> >> I have the similar problem e I resolved with the "overlay rwm in openldap". >> >> If in smb.conf I haved: ldap filter = (&(iufmLogin=%u)(gecos=#*)) >> >> When the new samba search by any user, the following filter in openldap is used: (&(uid=user)(objectClass=sambaSamAccount)). Then the overlay replace by filter by (&(iufmLogin=$1)(gecos=#*)) only in openldap server. >> >> My slapd.conf (only the part with overlay rwm) is: >> ... >> moduleload rwm >> overlay rwm >> rwm-rewriteEngine on >> rwm-rewriteContext searchFilter >> rwm-rewriteRule "\$&\\(uid=([a-z0-9_]+)\$\$objectClass=sambaSamAccount\$\\)" "(&(iufmLogin=$1)(objectClass=sambaSamAccount))" ":@I" >> ... >> >> This work fine to me. >> >> >

1 0

Thunderbird & OpenLDAP
by Erik Lotspeich 15 Jun '08

15 Jun '08

Hi, Is there anyone who is using Thunderbird and OpenLDAP with SSL enabled? I cannot get this combination to work -- I can only use Thunderbird with non-SSL OpenLDAP. If no one can say, definitively, that this works, I guess there must be a bug in one or both software packages. Any help would be greatly appreciated. Thanks, Erik.

2 1

slapd-passwd backend problems
by Lawrence Stewart 15 Jun '08

15 Jun '08

Hi all, I'm attempting to set up a very simple passwd database backed slapd instance and can't seem to make it work reliably. A number of hours on google and experimenting with options has not been fruitful so far. I'm running openldap 2.4.10 on FreeBSD 7.0 My slapd.conf looks like this: ############################################## include /usr/local/etc/openldap/schema/core.schema loglevel conns filter stats pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args modulepath /usr/local/libexec/openldap moduleload back_passwd moduleload back_monitor access to * by anonymous read database passwd readonly yes suffix "dc=example,dc=com" rootdn "cn=root,dc=example,dc=com" rootpw <passwod> database monitor ############################################## I am able to successfully start slapd and I can successfully query for a user by running the following command on the server itself: ldapsearch -x -H ldap://127.0.0.1 -b 'dc=example,dc=com' 'uid=test' which correctly returns the following details about the test user already in the system's passwd database: ############################################## # extended LDIF # # LDAPv3 # base <dc=example,dc=com> with scope subtree # filter: uid=test # requesting: ALL # # test, example.com dn: uid=test,dc=example,dc=com objectClass: person objectClass: uidObject uid: test cn: test cn: Testy McTest sn: test sn: McTest description: Testy McTest # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ############################################## However, attempting an identical, additional query after the first one results in an empty search being returned: ############################################## # extended LDIF # # LDAPv3 # base <dc=example,dc=com> with scope subtree # filter: uid=test # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 ############################################## I have experimented with many different options in slapd.conf and have not found anything that is able to mitigate this behaviour. The only way I have found to make an additional query work successfully is to restart slapd. After a restart, I can successfully make a single query again and then it stops returning a query result. The debugging output from slapd when a query is successful looks like this: ############################################## Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: waked Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: listen=7, new connection on 8 Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: added 8r (active) listener=0x0 Jun 16 13:19:29 newtcp8 slapd[11410]: conn=0 fd=8 ACCEPT from IP=127.0.0.1:59836 (IP=0.0.0.0:389) Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: waked Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: activity on: Jun 16 13:19:29 newtcp8 slapd[11410]: 8r Jun 16 13:19:29 newtcp8 slapd[11410]: Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: read activity on 8 Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: waked Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: conn=0 op=0 BIND dn="" method=128 Jun 16 13:19:29 newtcp8 slapd[11410]: conn=0 op=0 RESULT tag=97 err=0 text= Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: activity on: Jun 16 13:19:29 newtcp8 slapd[11410]: 8r Jun 16 13:19:29 newtcp8 slapd[11410]: Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: read activity on 8 Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: waked Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: begin get_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: end get_filter 0 Jun 16 13:19:29 newtcp8 slapd[11410]: conn=0 op=1 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(uid=test)" Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:19:29 newtcp8 slapd[11410]: => test_filter Jun 16 13:19:29 newtcp8 slapd[11410]: EQUALITY Jun 16 13:19:29 newtcp8 slapd[11410]: <= test_filter 6 Jun 16 13:19:29 newtcp8 slapd[11410]: conn=0 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: activity on: Jun 16 13:19:29 newtcp8 slapd[11410]: 8r Jun 16 13:19:29 newtcp8 slapd[11410]: Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: read activity on 8 Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: connection_read(8): input error=-2 id=0, closing. Jun 16 13:19:29 newtcp8 slapd[11410]: conn=0 op=2 UNBIND Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: removing 8 Jun 16 13:19:29 newtcp8 slapd[11410]: conn=0 fd=8 closed Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: waked Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:19:29 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL ############################################## and for an unsuccessful query looks like this: ############################################## Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=7 busy Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: listen=7, new connection on 8 Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: added 8r (active) listener=0x0 Jun 16 13:22:21 newtcp8 slapd[11410]: conn=1 fd=8 ACCEPT from IP=127.0.0.1:64362 (IP=0.0.0.0:389) Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: waked Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: activity on: Jun 16 13:22:21 newtcp8 slapd[11410]: 8r Jun 16 13:22:21 newtcp8 slapd[11410]: Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: read activity on 8 Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL Jun 16 13:22:21 newtcp8 slapd[11410]: conn=1 op=0 BIND dn="" method=128 Jun 16 13:22:21 newtcp8 slapd[11410]: conn=1 op=0 RESULT tag=97 err=0 text= Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: waked Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: activity on: Jun 16 13:22:21 newtcp8 slapd[11410]: 8r Jun 16 13:22:21 newtcp8 slapd[11410]: Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: read activity on 8 Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL Jun 16 13:22:21 newtcp8 slapd[11410]: begin get_filter Jun 16 13:22:21 newtcp8 slapd[11410]: EQUALITY Jun 16 13:22:21 newtcp8 slapd[11410]: end get_filter 0 Jun 16 13:22:21 newtcp8 slapd[11410]: conn=1 op=1 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(uid=test)" Jun 16 13:22:21 newtcp8 slapd[11410]: => test_filter Jun 16 13:22:21 newtcp8 slapd[11410]: EQUALITY Jun 16 13:22:21 newtcp8 slapd[11410]: <= test_filter 5 Jun 16 13:22:21 newtcp8 slapd[11410]: conn=1 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: waked Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: activity on: Jun 16 13:22:21 newtcp8 slapd[11410]: 8r Jun 16 13:22:21 newtcp8 slapd[11410]: Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: read activity on 8 Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL Jun 16 13:22:21 newtcp8 slapd[11410]: connection_read(8): input error=-2 id=1, closing. Jun 16 13:22:21 newtcp8 slapd[11410]: conn=1 op=2 UNBIND Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: removing 8 Jun 16 13:22:21 newtcp8 slapd[11410]: conn=1 fd=8 closed Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: activity on 1 descriptor Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: waked Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=6 active_threads=0 tvp=NULL Jun 16 13:22:21 newtcp8 slapd[11410]: daemon: select: listen=7 active_threads=0 tvp=NULL ############################################## I have analysed both sets of debug output and there are no material differences except that the successful query applies a number of equality test operations (indicating it is successfully walking through the entries in the passwd file) where as the failed query only applies 1 equality test. It's like the subsequent queries are not causing a full re-walk of the passwd database to find a match, but that's pure speculation at this point. Any insights into why the passwd backend might be behaving like this would be greatly appreciated. Please let me know if additional information or more detailed debugging output would help to diagnose the issue. Thanks in advance. Cheers, Lawrence

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical June 2008