openldap-technical

openldap-technical@openldap.org

18 participants
9786 discussions

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

LDAP ACL/ ADRESSBOOK Problems and more
by Sebastian Reinhardt 15 Jun '08

15 Jun '08

Hi, I have some huge (for me, but I hope not for the experts in this list) problems: First the server config: - openSuSE 10.3 (x86_64) - openldap openldap2-2.3.37-7.4 User administration, NFS and also Apache (for company intern information websites, not for "real" web) is running without problems and 5 clients (openSuSE 10.3 (x86_64 and i586), too), replication is not setup yet, but this is not the major problem. 1. Problem: I added an central adressbook into the ldap- directory. It can be edited by KAdressBook and also used by Thunderbird from every Client, but for editing the ldap-root- Login is required (no good idea, I know and I like to change) and everyone can read the hole ldap- directory (have to be changed, too). I tried to give only users of group "adressbook_write" permission to edit entries in "ou=people"- part (adressbook) of ldap and users of "adressbook_read"- group the "read"- rights. Any other should not be allowed to read or write in "ou=people" or other parts of the ldap directory. This is the section of slap.conf: ---------------------------------- access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to attrs=userPassword,userPKCS12 by self write by * auth access to attrs=shadowLastChange by self write by * read access to dn.base="ou=people,dc=LMV,dc=LMV" by group="cn=adressbook_read,dc=LMV,dc=LMV" read by group="cn=adressbook_write,dc=LMV,dc=LMV" write access to * by * read ----------------------------------------- I tried it also without "dn.base=" in front of first line (access to..), but then user- auth. was disabled. What is wrong? Can I delete "access to * by * read", without disabling Login- capability ? 2. Problem: KAddressBook can access (r/w, only by using root- access, simple auth.) the ldap- address book (ou=people). Reading is no problem, but by saving an new entry, KAddressBook shows the busy- symbol (mouse symbol) an the new entry is not shown in KAddressBook, but the entry is saved in ldap (it can be read/ edited by other applications; ldapbrowser or other). Whats the problem? KAddressBook, user read/write permissions? Or is it LDAP? To show the new entry in KAddressBook, the program has to be restarted. But KAddressBook is not crashed or frozen, the user can add new address or show/ edit old entries. 3. Problem: Is any schema available, which can handle more (3 or more) email- addresses for every entry? I can not figure out, if the mozilla- schema ( german HowTo and schema taken from: http://www.pro-linux.de/t_office/openldap-adressbuch.html ) can handle more than one email- entry per person. Is this possible or is Thunderbird unable to read more than one email address from ldap? And if so, how can store all addresses from KAdressBook in LDAP (to share it with other KAddressBook- Clients)? 4. Auto- LogIn Some Clients where used only by one person/ login. With local user management, openSuSE provides the option to login an standard user at boot. Is an automatic user login with ldap-users and ldap- user management possible? 5. file/ dir- modes Is it possible to change the default file- mode (644) and dir- mode (755) in ldap user accounts for new generated files into file: 660 and dir: 770 ? So the group- members can edit files/ dirs generated by other users of same ldap managed group ? Thanks -- Mit freundlichen Grüßen Sebastian Reinhardt

1 0

help with ldapsearch on uid
by joshua＠itsecureadmin.com 13 Jun '08

13 Jun '08

Hello, I am using OpenLDAP 2.4.9 on CentOS 5.1 (32 bit) with a custom schema and I have added ~7500 objects and I am not able to search successfully for these objects by uid. What must I do to be able to search for these objects by uid? Sample object: # 496user, People, example.com dn: uid=496user,ou=People,dc=example,dc=com objectClass: mailAccount maildrop: 496user(a)nest.tld mailid: 496user(a)nest.tld maildir: 496user/ userPassword:: secret mailquota: 35969216S If I search for this user by uid, I will get no results back: # ldapsearch -xZZ -b "ou=people,dc=example,dc=com" uid=496user # extended LDIF # # LDAPv3 # base <ou=people,dc=example,dc=com> with scope subtree # filter: uid=496user # requesting: ALL # # search result search: 3 result: 0 Success # numResponses: 1 Searching by mailid does work: # ldapsearch -xZZ -b "ou=people,dc=example,dc=com" mailid=496user(a)nest.tld ...<snip>... dn: uid=496user,ou=People,dc=example,dc=com objectClass: mailAccount maildrop: 496user(a)nest.tld mailid: 496user(a)nest.tld maildir: 496user/ userPassword:: secret mailquota: 35969216S # search result search: 3 result: 0 Success # numResponses: 2 # numEntries: 1 The schema is as follows (downloaded from riseuplabs.org): objectIdentifier OID 1.1 objectIdentifier ldapOID OID:2 objectIdentifier attributetypeOID ldapOID:1 objectIdentifier objectclassOID ldapOID:2 attributeType ( attributetypeOID:1 NAME 'mailAddress' DESC 'email address(es)' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) attributeType ( attributetypeOID:2 NAME 'maildrop' DESC 'Mail addresses where mail is delivered -- ie forwards' SUP mailAddress ) attributeType ( attributetypeOID:3 NAME 'mailid' DESC 'Mail addresses accepted by this account -- ie aliases' SUP mailAddress ) attributeType ( attributetypeOID:4 NAME 'mailquota' DESC 'Bytes of mail quota' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} SINGLE-VALUE ) attributetype ( attributetypeOID:5 NAME 'maildir' DESC 'where mail is stored' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} SINGLE-VALUE ) objectclass ( objectclassOID:1 NAME 'mailAccount' DESC 'users who receive mail' AUXILIARY MAY (maildrop $ mailid $ mailquota $ maildir) ) TIA, Josh Miller, RHCE

4 11

Shell script to monitor LDAP server
by Alexandre Vieira 13 Jun '08

13 Jun '08

Hello all, I have a Solaris 10 system that queries a clients openldap server to deliver a certain service and the client is complaining that my system sometimes denies services to clients. Well my system only denies service to clients if the openldap system from the customer fails to answer. In this sense I tried to write a script to monitor the openldap server and its responsiveness but ldapsearch client in Solaris 10 doesn't work as I expected :( For example, all ok: bash# ldapsearch -v -b '' -s base -h 192.168.1.102:7323 'objectclass=top' namingContexts ldapsearch: started Fri Jun 13 01:51:53 2008 ldap_init( 192.168.1.102:7323, 389 ) filter pattern: objectclass=top returning: namingContexts filter is: (objectclass=top) version: 1 dn: namingContexts: nodeName=XXXXX 1 matches Now imagine that the ldap server goes down: bash# ldapsearch -v -b '' -s base -h 192.168.1.102:7323 'objectclass=top' namingContexts ldapsearch: started Fri Jun 13 02:11:04 2008 ldap_init( 192.168.1.102:7323, 389 ) filter pattern: objectclass=top returning: namingContexts filter is: (objectclass=top) ldap_search: Can't connect to the LDAP server - Connection refused Now imagine that the machine hosting LDAP goes down or a problem somewhere in the network occurs or a firewall blocks traffic (timeout): bash# ldapsearch -v -b '' -s base -h 192.168.1.102:7323 'objectclass=top' namingContexts ldapsearch: started Fri Jun 13 02:11:04 2008 ldap_init( 192.168.1.102:7323, 389 ) filter pattern: objectclass=top returning: namingContexts filter is: (objectclass=top) And it just stays here forever. The -l flag only works after the search is initiated server side. There isn't a switch for a connection timeout limit. With this behaviour I can't test this as I imagined. Maybe some of you already have a monitoring script? Thanks in advance for any tip! PS: The script I wrote initially: ############################################################## #!/bin/bash LDAP_HOST=127.0.0.1:10000 POOLING_INTERVAL=5 LOGFILE=/var/log/ldap_watchdog.log # echo "Watchdog started at `date`" >> $LOGFILE while `/bin/true`; do ldapsearch -v -b '' -s base -h $LDAP_HOST 'objectclass=top' namingContexts if [ $? -ne 0 ]; then echo "`date`: Could not establish connection to LDAP server" >> $LOGFILE fi sleep $POOLING_INTERVAL done ############################################################## Alexandre Vieira - nullpt(a)gmail.com

3 4

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical