openldap-software October 2008

openldap-software@openldap.org

55 participants
54 discussions

openLDAP paged response problem
by Navaneetha Subramanian 24 Oct '08

24 Oct '08

Hi, I'm using OpenLDAP backend with .NET 2.0 System.DirectoryServices.Protocols API in my application. I'm trying to issue PagedResult control as part of my request to get results in multiple pages that code can navigate. This would use rfc2696 which is already supported in OpenLDAP. But when I run my code it comes back with exception that ''critical control unavailable in context'. I've attached the capture from OpenLDAP server ## T 10.218.5.27:33236 -> 10.217.94.154:389 [AP] 0........c....s.!dc=openldap,dc=dev,dc=net6,dc=com...................... .objectClass..person0.... ..distinguishedName..sn..manager...../0....)..1.2.840.1 13556.1.4.319.....0........... # T 10.217.94.154:389 -> 10.218.5.27:33236 [AP] 03...e...5...'critical control unavailable in context # But OpenLDAP does support the control 1.2.840.113556.1.4.319 as listed in my query response against rootDSE below DB2-95-02:~ # ldapsearch -x -h 10.217.94.154 -b "" -s base '(objectclass=*)' + # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: + # # dn: structuralObjectClass: OpenLDAProotDSE configContext: cn=config namingContexts: dc=openldap,dc=dev,dc=net6,dc=com supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.334810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedFeatures: 1.3.6.1.1.14 supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 supportedLDAPVersion: 3 entryDN: subschemaSubentry: cn=Subschema Any idea why the server responds with ''critical control unavailable in context' message? I'm using OpenLDAP v 2.3.19 [root@labvmware ~]# slapd -V @(#) $OpenLDAP: slapd 2.3.19 (Feb 13 2006 11:19:24) $ root@ls20-bc1-14.build.redhat.com:/usr/src/build/708086-i386/BUILD/openl dap-2.3.19/openldap-2.3.19/build-servers/servers/slapd Thanks, Navaneetha

6 9

Problem using ldapsearch with TLS (-ZZ)
by Eric Johanson 24 Oct '08

24 Oct '08

I am trying to get a basic TLS connection working on my Linux server using OpenLDAP and the ldapsearch command, but it does not connect with TLS. I've created an SSL certificate with the usual command: openssl req -new -x509 -nodes -out ldcert.pem -keyout ldkey.pem -days 3650 I've added the requisite lines to slapd.conf (TLSCertificateFile TLSCertificateKeyFile) and to ldap.conf (TLS_CACERT) (since my certificate is self-signed). I've started the OpenLDAP server with the command: slapd -d 10 If I issue the command: ldapsearch -x -b 'dc=com' -H 'ldap://localhost/' -D 'uid=root' -W -v And everything works and I see a list of all the directory entries in the server. However, if I issue the same command except with the -ZZ option to use TLS: ldapsearch -x -b 'dc=com' -H 'ldap://localhost/' -D 'uid=root' -W -v -ZZ Then I get an error that reads: ldap_start_tls: Connect error (-11) So I analyzed the debug log coming from the server (during the ldapsearch ... -ZZ command) and I get the debug log below (I've snipped out the actual buffer exchanges for brevity). As you can see, it goes through several handshakes successfully, but then suddenly the server is looking for more data but the client doesn't send it, so the server closes the connection. Can someone please help to analyze this problem so I can get this working. LDAP 2.4.12, OpenSSL 0.9.8i. Thank you in advance for any advice you can offer me. -Eric slap_listener_activate(8): >>> slap_listener(ldap:///) connection_get(12): got connid=0 connection_read(12): checking for input on id=0 ber_get_next ldap_read: want=8, got=8 0000: 30 1d 02 01 01 77 18 80 0....w.. ldap_read: want=23, got=23 0000: 16 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 31 34 36 .1.3.6.1.4.1.146 0010: 36 2e 32 30 30 33 37 6.20037 ber_get_next: tag 0x30 len 29 contents: ber_dump: buf=0x83881e8 ptr=0x83881e8 end=0x8388205 len=29 0000: 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 2e 34 ...w...1.3.6.1.4 0010: 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .1.1466.20037 ber_get_next ldap_read: want=8 error=Resource temporarily unavailable conn=0 op=0 do_extended ber_scanf fmt ({m) ber: ber_dump: buf=0x83881e8 ptr=0x83881eb end=0x8388205 len=26 0000: 77 18 80 16 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e w...1.3.6.1.4.1. 0010: 31 34 36 36 2e 32 30 30 33 37 1466.20037 send_ldap_extended: err=0 oid= len=0 send_ldap_response: msgid=1 tag=120 err=0 ber_flush2: 14 bytes to sd 12 0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00 0....x........ ldap_write: want=14, written=14 0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00 0....x........ connection_get(12): got connid=0 connection_read(12): checking for input on id=0 TLS trace: SSL_accept:before/accept initialization tls_read: want=11, got=11 0000: 80 7a 01 03 01 00 51 00 00 00 20 .z....Q... tls_read: want=113, got=113 <... snip ...> TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write server done A tls_write: want=1105, written=1105 <... snip ...> TLS trace: SSL_accept:SSLv3 flush data tls_read: want=5, got=5 0000: 16 03 01 01 06 ..... tls_read: want=262, got=262 <... snip ...> TLS trace: SSL_accept:SSLv3 read client key exchange A tls_read: want=5, got=5 0000: 14 03 01 00 01 ..... tls_read: want=1, got=1 0000: 01 . tls_read: want=5, got=5 0000: 16 03 01 00 30 ....0 tls_read: want=48, got=48 <... snip ...> TLS trace: SSL_accept:SSLv3 read finished A TLS trace: SSL_accept:SSLv3 write change cipher spec A TLS trace: SSL_accept:SSLv3 write finished A tls_write: want=59, written=59 <... snip ...> TLS trace: SSL_accept:SSLv3 flush data connection_read(12): unable to get TLS client DN, error=49 id=0 connection_get(12): got connid=0 connection_read(12): checking for input on id=0 ber_get_next tls_read: want=5, got=0 ldap_read: want=8, got=0 ber_get_next on fd 12 failed errno=0 (Success) connection_closing: readying conn=0 sd=12 for close connection_close: conn=0 sd=12 --- -Eric Johanson Principle Software Engineer Newpoint Technologies, Inc.

2 1

SASL pass-through autentication with a ldap-backend KDC
by Guillaume Rousse 23 Oct '08

23 Oct '08

Hello list. Reading http://www.openldap.org/doc/admin24/security.html#SASL password storage scheme, I understand autentication can be delegated to an external mechanisme. Such as, for instance, a kerberos server. In this case, it is advised to prevent changing passwords in the directory. What happens if the autentication provider is an heimdal server, using OpenLDAP as its backend, and smbkrb5 overlay to keep ldap, samba and kerberos password synced ? Does pass-through still work ? And it is recommended then to make the userPassword attribute read-ony, but still use Exop PasswordChange to change samba and kerberos attributes ? I didn't tested it yet, but it look very interesting if it works. Particulary because heimdal password change through kpassword doesn't use ExOp PasswordChange operation, but only update kerberos and samba passwords. I know smbkrb5 has a special {smbkrb5} password storage scheme for redirecting autentication against kerberos password internally, not relying on a external SASL process. But it's only usable if smbkrb5 overlay is available (some of our slaves servers are centos-based, and don't have this overlay, but still need to autenticate users). And the trick of setting password-hash directive in slapd.conf to {smbkrb5} to prevent overwriting of userPassword attribute on PasswordChange operation with a normal value has the drawback than even pure ldap administrative accounts (syncrepl, for instance) get redirected to kerberos password for autentication, whereas only our users have principals currently. -- Guillaume Rousse Moyens Informatiques - INRIA Futurs Tel: 01 69 35 69 62

2 5

Large database initial replication problem
by Łukasz Wąsikowski 22 Oct '08

22 Oct '08

Welcome! I've got large test database (>20000 entries), set up replication using syncrepl (refreshAndPersist). It work's fine when consumer is connected to provider while importing all database. But when I add new consumer to use existing database only first 500 records are replicated. I know about sizelimit, but I don't want to raise it (because I don't know how big my database will grow). The question is - why consumer won't get rest of the entries in another queries? What am I doing wrong? I can't import all database everytime I connect new consumer in a production enviroment. -- Best regards, Lukasz Wasikowski

5 6

adding syncprov module fails
by Dieter Kluenter 21 Oct '08

21 Oct '08

Hi, I am trying to set up a cascading replication from scratch, adding syncprov module fails with: ,----[ output of slapd -dsync ] | @(#) $OpenLDAP: slapd 2.4.12 (Oct 17 2008 16:01:17) $ | dieter@rubin.l4b.de:/work/openldap-2.4.12/servers/slapd | slap_queue_csn: queing 0xa583f0 20081021122834.783484Z#000000#001#000000 | slap_graduate_commit_csn: removing 0xa578b0 20081021122834.783484Z#000000#001#000000 | slapd starting | slap_queue_csn: queing 0x40a70480 20081021122922.151442Z#000000#001#000000 | Control 1.3.6.1.4.1.4203.1.9.1.1 already registered. | syncprov_init: Failed to register control -9 | slap_graduate_commit_csn: removing 0xa52ef0 20081021122922.151442Z#000000#001#000000 `---- this is my script to load the module $LDAPMODIFY -x -D $ROOTDN -w $CPW -H $HOST <<EOF dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov EOF My initial slapd.conf is just ,----[ slapd.conf ] | include /opt/openldap-2.4/etc/openldap/schema/core.schema | include /opt/openldap-2.4/etc/openldap/schema/cosine.schema | include /opt/openldap-2.4/etc/openldap/schema/inetorgperson.schema | include /opt/openldap-2.4/etc/openldap/schema/nis.schema | | pidfile /opt/openldap-2.4/var/run/slapd.pid | argsfile /opt/openldap-2.4/var/run/slapd.args | | modulepath /opt/openldap-2.4/libexec/openldap | moduleload syncprov.la | | database config | rootdn "cn=config" | rootpw "xxx" `---- How come that the control is already registered? -Dieter -- Dieter Klünter | Systemberatung http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6 53°08'09,95"N 10°08'02,42"E

2 2

two issues with dyngroups
by Guillaume Rousse 21 Oct '08

21 Oct '08

Hello list. I'm an happy users of dynlist overlay, in order to make my unix users members of their unix primary group: # admins, groups, msr-inria.inria.fr dn: cn=admins,ou=groups,dc=msr-inria,dc=inria,dc=fr objectClass: groupOfURLs objectClass: posixGroup gidNumber: 5000 memberURL: ldap:///ou=users,dc=msr-inria,dc=inria,dc=fr??sub?(gidNumber=5000) cn: admins With this configuration: # dynamic groups overlay dynlist dynlist-attrset groupOfURLs memberURL member However, I'm facing two issues here. The first is that dynlist overlay only accept a single configuration directive for the whole base, preventing to map differently the request URL depending on the context. In my previous example, I need to map the URL as DN, because I'm dynamically building a group from users. If I wanted to build a group from other group, my URL would have been something as: ldap:///ou=group,dc=msr-inria,dc=inria,dc=fr?member?sub?(cn=users) and the configuration directive would have been instead dynlist-attrset groupOfURLs memberURL It would be nice to handle the overlay differently there. The second directive is that ACLs seems to ignore this dynamic group: # admins access to dn.subtree="dc=msr-inria,dc=inria,dc=fr" by group="cn=admins,ou=groups,dc=msr-inria,dc=inria,dc=fr" write by * break This worked with a static group, it doesn't work anymore with a dynamic one as I just presented. I'm using OpenLDAP 2.4.11. Should I open ITS for those issues ? -- Guillaume Rousse Moyens Informatiques - INRIA Futurs Tel: 01 69 35 69 62

2 3

Newbie question ldap_sasl_interactive_bind_s: Invalid credentials (49)
by Uli Kleemann 19 Oct '08

19 Oct '08

Hello my fellow openldap friends, I've installed openldap 2.4 on debian lenny usinf the Debian packages slapd and ldap-utils. For Authentification I would like to use sasl simple-bind but if I try e.g: ldapsearch -D "cn=admin,dc=lug-saar,dc=spc" -W -d 255 respectively ldapsearch -D "cn=Manager,dc=lug-saar,dc=de" -W -d 255 I got: ldap_sasl_interactive_bind_s: Invalid credentials (49) As I couldn't find the Error using google yet, but getting as more confused as more HOWTOS I read here is my ldap.conf: --------------------------------------------------------------------------------------------------------------------------------- # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. BASE dc=lug-saar,dc=de #URI ldap://ldap.lug-saar.de URI ldap://192.168.199.159 ldap_version 3 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never ------------------------------------------------------------------------------------------------------------------------------------ my slapd.conf ------------------------------------------------------------------------------------------------------------------------------------- # This is the main slapd configuration file. See slapd.conf(5) for more # info on the configuration options. ####################################################################### # Global Directives: # Features to permit #allow bind_v2 # Schema and objectClass definitions include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema # Where the pid file is put. The init.d script # will not stop the server if you change this. pidfile /var/run/slapd/slapd.pid # List of arguments that were passed to the server argsfile /var/run/slapd/slapd.args # Read slapd.conf(5) for possible values loglevel none # Where the dynamically loaded modules are stored modulepath /usr/lib/ldap moduleload back_hdb # The maximum number of entries that is returned for a search operation sizelimit 500 # The tool-threads parameter sets the actual amount of cpu's that is used # for indexing. tool-threads 1 # Specific Backend Directives for hdb: # Backend specific directives apply to this backend until another # 'backend' directive occurs backend hdb ####################################################################### # Specific Backend Directives for 'other': # Backend specific directives apply to this backend until another # 'backend' directive occurs #backend <other> ####################################################################### # Specific Directives for database #1, of type hdb: # Database specific directives apply to this databasse until another # 'database' directive occurs database hdb # The base of your directory in database #1 suffix "dc=lug-saar,dc=de" # rootdn directive for specifying a superuser on the database. This is needed # for syncrepl. rootdn "cn=root,dc=lug-saar,dc=de" rootpw secret rootpw {SSHA}Jh+[3]GpYm86f7E0ierBIQJhnN/gKmx # Where the database file are physically stored for database #1 directory "/var/lib/ldap" # The dbconfig settings are used to generate a DB_CONFIG file the first # time slapd starts. They do NOT override existing an existing DB_CONFIG # file. You should therefore change these settings in DB_CONFIG directly # or remove DB_CONFIG and restart slapd for changes to take effect. # For the Debian package we use 2MB as default but be sure to update this # value if you have plenty of RAM dbconfig set_cachesize 0 2097152 0 # Sven Hartge reported that he had to set this value incredibly high # to get slapd running at all. See http://bugs.debian.org/303057 for more # information. # Number of objects that can be locked at the same time. dbconfig set_lk_max_objects 1500 # Number of locks (both requested and granted) dbconfig set_lk_max_locks 1500 # Number of lockers dbconfig set_lk_max_lockers 1500 # Indexing options for database #1 index objectClass eq # Save the time that the entry gets modified, for database #1 lastmod on # Checkpoint the BerkeleyDB database periodically in case of system # failure and to speed slapd shutdown. checkpoint 512 30 # Where to store the replica logs for database #1 # replogfile /var/lib/ldap/replog # The userPassword by default can be changed # by the entry owning it if they are authenticated. # Others should not be able to see it, except the # admin entry below # These access lines apply to database #1 only access to attrs=userPassword,shadowLastChange by dn="cn=root,dc=lug-saar,dc=de" write by anonymous auth by self write by * none # Ensure read access to the base for things like # supportedSASLMechanisms. Without this you may # have problems with SASL not knowing what # mechanisms are available and the like. # Note that this is covered by the 'access to *' # ACL below too but if you change that as people # are wont to do you'll still need this if you # want SASL (and possible other things) to work # happily. access to dn.base="" by * read # The admin dn has full write access, everyone else # can read everything. access to * by dn="cn=root,dc=lug-saar,dc=de" write by * read # For Netscape Roaming support, each user gets a roaming # profile for which they have write access to #access to dn=".*,ou=Roaming,o=morsnet" # by dn="cn=root,dc=lug-saar,dc=de" write # by dnattr=owner write ####################################################################### # Specific Directives for database #2, of type 'other' (can be hdb too): # Database specific directives apply to this databasse until another # 'database' directive occurs #database <other> # The base of your directory for database #2 #suffix "dc=debian,dc=org" --------------------------------------------------------------------------------------------------------------------------------- The schema and ldif files I put into /etc/ldap/schema What did I do wrong? Thanks in advance. -- Uli Kleemann <uli.kleemann(a)guug.de> Note: No Microsoft programs were used in the creation or distribution of this message. If you are using a Microsoft program to view this message, be forewarned that I am not responsible for any harm you may encounter as a result.

5 6

Recording the Last Successful Authorization
by Tim Gustafson 17 Oct '08

17 Oct '08

I was wondering if there is any way to configure OpenLDAP to record the last time an account was successfully authorized? We need to be able to prune accounts after a period of inactivity, but there's no way right now to know if they user has been active or not. We can't base it on the last time they connected to a shell because not everyone uses shells; some people just authenticate to POP their e-mail or log into a web page. If there was some way to maintain a time stamp of the last time that that a user successfully authenticated (by way of an LDAP bind to the LDAP server) that would solve this problem. Thanks! Tim Gustafson SOE Webmaster UC Santa Cruz tjg(a)soe.ucsc.edu 831-459-5354

2 1

userCertificate;binary in a 2.3.X ldif file
by Brett ＠Google 17 Oct '08

17 Oct '08

Can anyone shed any light on : slapadd: could not parse entry (line=234) str2entry: attributeType userCertificate #0: needs ';binary' transfer as per syntax 1.3.6.1.4.1.1466.115.121.1.8 This is ocurring when running 2.4.x slapadd on a certificate containing a binary attribute, which was a slapcat from a 2.3.X openldap server. The attribute in question is already a binary attribute, there is a double colon after the certificate name, so i gather it just wants userCertificate;binary:: as the attribute name in the LDIF dump when loading ? Cant simply search and replace, because that will increase the line length, which will stop it from parsing. Alternatively, anybody know of any tool which can re-justify line lengths in an ldif, if i search and replace the attribute name ? It might be nice to have some sort of non-default legacy flag, for loading a previous release's ldif (or at least be more forgiving than the present parser) Cheers Brett

2 2

mysterious segfault
by Jason Dusek 17 Oct '08

17 Oct '08

I've added two seemingly innocuous lines to my LDAP configuration: Index: conf-root/etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif =================================================================== --- etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif (revision 1444) +++ etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif (working copy) @@ -1,6 +1,9 @@ dn: olcDatabase={1}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig +objectClass: olcSyncProvConfig +olcSpCheckpoint: 100 5 +olcSpSessionlog: 100 olcDatabase: {1}bdb olcSuffix: dc=metascopic,dc=com olcAccess: {0}to attrs=userPassword However, they cause `slaptest` to segfault on Linux! I'm a little perplexed by this. :; slaptest -F etc/openldap/slapd.d/ Segmentation fault Removing the lines restores `slaptest` to a state of sanity. -- _jsn

3 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software October 2008