openldap-technical September 2010

openldap-technical@openldap.org

111 participants
113 discussions

I can't login in my system using OpenLDAP
by Eric KOM 14 Sep '10

14 Sep '10

Hi Dear! Since 3 days I try to setting a LDAP Server with OpenLDAP on Debian Lenny. I'm using Mandriva Management Console (mmc) like web based admin. I already create some users with mmc, but I can't login? Please, everybody can help me or provide me a good tuto? -- Yours truly, Eric KOM 110 LAWN STREET ROSETTENVILLE 2190 JOHANNESBURG SOUTH AFRICA Phone: +27 (0) 788 791 334 Fax: +27 (0) 865 563 009 E-mail: erickom(a)namekom.co.za Websites: www.erickom.co.za | www.namekom.co.za/erickom | www.namekom.co.za

5 9

troubles with back-ldap based replication
by DT Piotr Wadas 14 Sep '10

14 Sep '10

Hello. I have some troubles setting syncrepl + back-ldap push based replication, as described on http://www.openldap.org/doc/admin24/replication.html#LDAP Sync Replication I'm using current stable openldap - the problem is, when I set up daemons (using the same slapcat output file) and modify e.g. "description" attribute on master side, back-ldap pushes out system attributes like entryCSN, creatorsName, etc, which causes modify operation to fail on final consumer side. conn=1000 op=33 MOD attr=creatorsName createTimestamp description entryCSN conn=1000 op=33 RESULT tag=103 err=19 text=creatorsName: no user modification allowed Is it some ACL-related matter, should I create some ACL, which denies to read of system attributes on master-side, to avoid replicating it with syncrepl to local back-ldap ? In such push-based scenario ( in opposite to classic provider-consumer syncrepl), final consumer does not know actually that it is a replica, it's just receiving modify operation, how do I prevent read-only system attributes from being pushed from back-ldap to final replica? Regards, DT

2 2

Re: invalid syntax on pwdPolicy object add
by Julien Vehent 14 Sep '10

14 Sep '10

On Tue, 14 Sep 2010 10:51:01 +0200, Emmanuel Lecharny <elecharny(a)gmail.com> wrote: > On 9/14/10 8:40 AM, mailing lists wrote: >> Hello, >> >> I think that the pwdAttribute needs an OID value (specified by the syntax) >> so you would must use the OID of the userPassword attribute which is >> 2.5.4.35 >> >> >> >> >> > I thought that would be a possibility for the failure Kiran and Julien are facing, (please guys, can you give it a try ?), but IMO, there is no reason why we would not be allowed to use 'userPassword' in this context. > > Using the OID instead of the alias name does not carry any extra information, as soon as the alias is valid accordingly to the schema (whatever it represents, be it an AT, OC, MR, or any of the other kind of schema objects). The syntax should just check that the alias is syntaxically correct. It's up to the ppolicy overlay to check that the value is a valid AT. > > Plus the error message is really misleading if this is the cause for the error. I tried with the OID... same thing. How can I check that the module is properly loaded and functional ? Julien

2 1

objectClass index from slapd.conf is not working
by tim stone 14 Sep '10

14 Sep '10

Hello, I've a strange behavior while using index objectClass for searching. In my slapd.conf I have defined the index in the database section: index objectClass eq Other indexes follows in the config. All of them working fine. If I search via ldapsearch like: ldapsearch -x -h localhost -w password -D"cn=admin,ou=root" -b"ou=root" "(objectclass=Guest)" I can find following Message in the syslog (loglevel -1): Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_equality_candidates (objectClass) Sep 1 14:02:52 LDAP01 slapd[17856]: => key_read Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_index_read: failed (-30989) Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_equality_candidates: id=0, first=0, last=0 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=0 first=0 last=0 Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_filter_candidates Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_equality_candidates (objectClass) Sep 1 14:02:52 LDAP01 slapd[17856]: => key_read Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_index_read 355545 candidates Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_equality_candidates: id=-1, first=228, last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=-1 first=228 last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_list_candidates: id=-1 first=228 last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=-1 first=228 last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_list_candidates: id=-1 first=112277 last=355755 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=-1 first=112277 last=355755 Sep 1 14:02:52 LDAP01 slapd[17856]: bdb_search_candidates: id=-1 first=112277 last=355755 Sep 1 14:02:52 LDAP01 slapd[17856]: => test_filter Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856]: <= test_filter 5 Sep 1 14:02:52 LDAP01 slapd[17856]: bdb_search: 112277 does not match filter Sep 1 14:02:52 LDAP01 slapd[17856]: entry_decode: "cn=Aaa,cn=Bbb,... Sep 1 14:02:52 LDAP01 slapd[17856]: <= entry_decode(cn=Aaa,cn=Bbb,... Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_dn2id("cn=aaa,cn=bbb,... Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_dn2id: got id=0x1b696 Sep 1 14:02:52 LDAP01 slapd[17856]: => test_filter Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856] ... all other entires following... As result, the entires are found, but not in the index and the search takes a very long time. After this, I have rebuild the complete database via slapcat/slapadd, rebuild the index via slapindex for objetClass, but nothing helped. In tried the test above on: * OpenSuSE 11.1 and openLDAP 2.4.21 and 2.4.23 (linked against libdb-4.5) * OpenSuSE 11.0 and openLDAP 2.4.9 (linked against libdb-4.5) * Debian Lenny and openLDAP 2.4.11 (linked against libdb-4.2) with different databases and a search against a objectClass. If I try another index (not objectClass) from the slapd.conf the index works, example: ldapsearch -x -h localhost -w password -D"cn=admin,ou=root" -b"ou=root" "(mypk=1234-234)" Sep 1 14:03:44 LDAP01 slapd[17856]: => bdb_equality_candidates (mypk) Sep 1 14:03:44 LDAP01 slapd[17856]: => key_read Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_index_read 1 candidates Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_equality_candidates: id=1, first=112838, last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_list_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_list_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: bdb_search_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: => test_filter Sep 1 14:03:44 LDAP01 slapd[17856]: EQUALITY Sep 1 14:03:44 LDAP01 slapd[17856]: <= test_filter 6 Sep 1 14:03:44 LDAP01 slapd[17856]: => send_search_entry: conn 1002 dn="cn=Fff,cn=Eee,... Sep 1 14:03:44 LDAP01 slapd[17856]: <= send_search_entry: conn 1002 exit. Sep 1 14:03:44 LDAP01 slapd[17856]: send_ldap_result: conn=1002 op=1 p=3 Sep 1 14:03:44 LDAP01 slapd[17856]: send_ldap_response: msgid=2 tag=101 err=0 Sep 1 14:03:44 LDAP01 slapd[17856]: connection_get(12): got connid=1002 Sep 1 14:03:44 LDAP01 slapd[17856]: connection_read(12): checking for input on id=1002 Sep 1 14:03:44 LDAP01 slapd[17856]: op tag 0x42, time 1283342624 Sep 1 14:03:44 LDAP01 slapd[17856]: conn=1002 op=2 do_unbind Sep 1 14:03:44 LDAP01 slapd[17856]: connection_close: conn=1002 sd=12 Why does only the objectClass index not work? The only difference I can see, is that all other indexes are based on "normal" attributes. I don't know, if it is necessary, but for objectClass I can't find a attribute definition in the schema. In the core.schema is the attribute definition for objectClass deactivated (aka #)... Here is the Config from the LDAP-Server: # Schema and objectClass definitions include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/yast.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/my_ldap_attribute.schema include /etc/openldap/schema/my_ldap.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args modulepath /usr/lib/ldap moduleload back_bdb sizelimit -1 timelimit 300 disallow bind_anon gentlehup on tool-threads 1 ####################################################################### # bdb database definitions ####################################################################### database bdb suffix "ou=root" rootdn "cn=root,ou=root" checkpoint 4096 15 rootpw password directory /var/lib/ldap dbnosync # Indices to maintain index objectClass,entryUUID,entryCSN eq index mypk,myusername pres,eq index myproperty,mylanguage eq index cn eq,sub Kindly regards Tim Stone

3 7

Re: invalid syntax on pwdPolicy object add
by mailing lists 14 Sep '10

14 Sep '10

Hello, I think that the pwdAttribute needs an OID value (specified by the syntax) so you would must use the OID of the userPassword attribute which is 2.5.4.35

3 2

Keep alive functionality when the remote closes the conenction due idle
by alin vasile 13 Sep '10

13 Sep '10

Hi guys, I have a question related to the open ldap client keep alive functionality. Our OS is SLES 11. In our client code we are reusing the ldap connections between requests uning a connection pool. For each conenction we are setting the keep-alive options (LDAP_OPT_X_KEEPALIVE_IDLE, LDAP_OPT_X_KEEPALIVE_PROBES and LDAP_OPT_X_KEEPALIVE_INTERVAL) and this works fine. My question is how the openl ldap library (libldap and libldap_r) handles the situation when the number of kee-alive probes for a connection is exceeded and the connection is closed at the server side. Did you dealt with this situation? Thanks, Alin

4 5

syncrepl incomplete database problem
by Islam Amer 13 Sep '10

13 Sep '10

Hello everyone, I have a problem with a simple master/slave syncrepl replication setup. Everytime I restart the slave it goes back to an empty state and then syncs about only 200 entries from thousands in the master. >From then on it gets the update events from the master fine. I have tried some of the things suggested in this mailing list but none have worked so far. For example I tried initializing the slave with a full slapcat of the master after deleting all files from /var/lib/ldap/ , but when I start the slave it deletes ALL entries and starts over. The master is debian etch with 2.3.30-5+etch2 ( critical, not easy to update ) The slave is 2.3.43 RHEL The slave config is : syncrepl rid=100 provider=ldaps://xxxxxxxxxxxxxx:636 type=refreshOnly tls_cert=/var/lib/ldap/ssl/clientcert.pem tls_key=/var/lib/ldap/ssl/clientkey.pem tls_cacert=/var/lib/ldap/ssl/cacert.pem interval=00:00:01:00 retry="5 60" searchbase="dc=xxxx" filter="(objectClass=*)" scope=sub schemachecking=off bindmethod=simple binddn="cn=xxxxx,dc=xxxx" credentials=xxxxxx slapd is started with options "-c rid=100,csn=0" ( the real values are obscured for security, sorry ) I switched to refreshOnly because the connection passes through a strict firewall, and I read that the persistent connection of refreshAndPersist has problems with that. Any help is appreciated. Thanks.

1 0

Re: invalid syntax on pwdPolicy object add
by Julien Vehent 13 Sep '10

13 Sep '10

On Mon, 13 Sep 2010 19:29:12 +0530, Kiran Ayyagari <kayyagari(a)apache.org> wrote: > On Mon, Sep 13, 2010 at 5:07 PM, Julien Vehent <julien(a)linuxwall.info> wrote: >> >> >> >> # slapd -V >> @(#) $OpenLDAP: slapd 2.4.23 (Aug 26 2010 18:33:04) $ >> root@monster:/tmp/buildd/openldap-2.4.23/debian/build/servers/slapd >> >> >> It's not a space/tab problem, and I've tried to put the request in an ldif file and insert it, with the same result. >> It's definitely a constraint that's not satisfied... but which one ?? > > think it is reproducible cause I have got the same error when I > followed the above steps > 'error code 21 - pwdAttribute: value #0 invalid per syntax' > > I have built OpenLDAP version 2.4.23 on Ubuntu 9.04 with berkeley db > version 4.7.25 > > Kiran Ayyagari > Alright, so it's either my steps that are wrong, or a problem with slapd. I'll be humble and suppose that my configuration is wrong first. Any hint on what I could have missed ? described here: http://wiki.linuxwall.info/doku.php/en:ressources:dossiers:openldap:openlda… Julien

2 1

Logging practices of OpenLDAP
by Mark John Rank 13 Sep '10

13 Sep '10

List: UW-Milwaukee is in the process of reviewing IAM infrastructure and looking to harmonize logging, audit and data retention configuration for many of our IAM related services. Our OpenLDAP service is in scope for this review. To help frame the review, I am looking for guidance or best practices for configuring logging for OpenLDAP, especially for the HigherEd community. Of particular interest is the decision process around balancing log level, performance overhead and data retention. A search of the archives didn't result in much so I though I would just ask the question of the list. If individuals are interested in sharing, they can reply to the list or they can contact me directly at the address below. Regards, Mark ------------------------------------------ Mark Rank, Middleware Architect University Information Technology Services UW-Milwaukee Email: rankm(a)uwm.edu Phn: 414-229-3706 ------------------------------------------

1 0

Confused about password authentication formats
by 1.41421＠gmail.com 12 Sep '10

12 Sep '10

I have an OpenLDAP 2.4.23 server up and running in a Linux box L against which I can carry out password authentication on behalf of users logging into an embedded system E. To accomplish this, in LI have an LDIF file with entries along the following lines: dn: uid=xxx,ou=yyy,dc=zzz,dc=com uid: xxx cn: xxx objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount userPassword: ThisIsthePassword shadowLastChange: 14014 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 1003 gidNumber: 1003 homeDirectory: /home/xxx gecos: ,,, I would like to change this so that, when sending password information from my LDAP client in E to the LDAP server in L, the password itself is never sent in the clear. So I thought to change the value of the userPassword attribute to read {SHA}3DRF4FXpG8r+Ki8i8azuZh7KwO8= instead, where the string above was obtained by means of slappasswd -v -s ThisIsthePassword -h "{SHA}" in L. After restarting the LDAP server in L, when user xxx logs into E with password "ThisIsthePassword" I can verify in the traces of the LDAP server (I am running it as slapd -d 255) that the client in E is sending the "3DRF4FXpG8r+Ki8i8azuZh7KwO8=" string, exactly as specified in the value of the userPassword attribute. However, the authentication is failing. What is it exactly that the LDAP client in L is supposed to be sending to the LDAP server in this case? I noticed that if the client sends the actual "ThisIsthePassword" string instead the authentication also fails. I am obviously missing something here but, what is it?

2 2

← Newer
1
...
5
6
7
8
9
10
11
12
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical September 2010