openldap-software

openldap-software@openldap.org

2719 discussions

Problem with back-sql after update from 2.2 to 2.3
by Andreas 'ads' Scherbaum 09 Aug '07

09 Aug '07

Hello all, i tried to update an openldap server from 2.2.13 to 2.3.27 but ran into problems. The slapd is using back-sql to get data from an existing PostgreSQL groupware database. This worked fine with the 2.2 version, but after the update the client (Thunderbird in my case) no longer gets data. According to wireshark, no data is sent back to the client. Testing with a local ldapsearch brings results, but with the following differences: ----- 2.2.13 ----- objectClass: orgPerson objectClass: inetOrgPerson objectClass: officePerson objectClass: evolutionPerson objectClass: top objectClass: opengroupwareentity objectClass: person ----- 2.2.13 ----- ----- 2.3.27 ----- objectClass: person objectClass: evolutionPerson objectClass: inetOrgPerson objectClass: opengroupwareentity objectClass: top ----- 2.3.27 ----- The 'ldap_objectclass_list' table contains the following entries: ----- cut ----- OGo=# select * from ldap_objectclass_list; oc_map_id | objectclass -----------+--------------------- 1 | orgPerson 1 | inetOrgPerson 1 | officePerson 1 | evolutionPerson 1 | top 1 | opengroupwareentity 3 | top 3 | opengroupwareentity 4 | top 4 | domainRelatedObject (10 rows) ----- cut ----- Has anybody an idea why the ldapsearch returns fewer entries for the objectClass? That should be the reason, why no data is sent back to the client. Kind regards -- Andreas 'ads' Scherbaum Failure is not an option. It comes bundled with your Microsoft product. (Ferenc Mantfeld)

2 3

olcPasswordHash scheme not available
by Mustafa A. Hashmi 09 Aug '07

09 Aug '07

OS: Debian Etch Openldap version: 2.3.30 Hi all: Moving towards housing configuration data within openldap, I have the directory working correctly and reading cn=config without any issues. However, if the password-hash {K5KEY} is specified, slapd refuses to start and immediately reports: olcPasswordHash: value #0: <olcPasswordHash> scheme not available ({K5KEY}) olcPasswordHash: value #0: <olcPasswordHash> no valid hashes found config error processing cn=config: <olcPasswordHash> no valid hashes found I am guessing this has to do with the order modules and configuration are loaded -- however, I am not at all sure. The smbk5pwd module is loaded and the hash directive works correctly via slapd.conf. Any help would be much appreciated. thank you, -- Mustafa A. Hashmi mahashmi(a)gmail.com

3 6

Re: Problems changing passwords
by Pierangelo Masarati 09 Aug '07

09 Aug '07

Please keep replies on the list. Rick Tautin wrote: > Here is the output from ldapwhoami > > ldapwhoami -x -h ldap1.example.com -D > "uid=user1,ou=users,employees,ou=users,dc=example,dc=com" -w tt#12345 > ldap_bind: Invalid DN syntax (34) > additional info: invalid DN The above DN is blatantly invalid, as the error message says. > > > But if I do an ldapsearch using the manager account all info show up on > this user. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Overlay "Constraint" in OpenLDAP 2.3?
by Christian Marg 08 Aug '07

08 Aug '07

Hello, according to http://www.openldap.org/its/index.cgi/Documentation?id=4844;#followup4 the "constraint" Overlay was added to CVS April 29 2006. I was wondering why it isn't in current 2.3.x releases (after said date, of course), since I really could use the functionality provided by that plugin. It isn't listed in http://www.openldap.org/software/release/changes.html either. bye Christian -- Christian Marg mail : mailto:marg@rz.tu-clausthal.de Dezernat 2 TU Clausthal web : http://www.tu-clausthal.de D-38678 Clausthal-Zellerfeld fon : 05323/72-2107 Germany jabber: ifcma(a)jabber.tu-clausthal.de

2 1

SASL/EXTERNAL
by Turbo Fredriksson 08 Aug '07

08 Aug '07

Is there a picture or 'flow chart' on SASL/EXTERNAL and how it's working?

1 0

problems with slapd-ldap and overlays in using OpenLDAP as an LDAP proxy
by DePriest, Jason R. 07 Aug '07

07 Aug '07

I am a complete newbie with OpenLDAP. I have worked with Windows NT Domains and Active Directory for a long time. I've also worked with Microsoft ADAM and CA's eTrust Admin Directory. However, I am having trouble getting OpenLDAP to perform what I think are basic functions. I have a Debian GNU/Linux Etch system with a 2.6.18 kernel. slapd reports a version of 2.3.30. I have slapd running and I am able to authenticate with the local admin account. What I want is for it to take requests for domain.com, ask the real domain.com LDAP server (Active Directory) to handle it, then provide the answer to the client. I want to have an OpenLDAP server in my DMZ proxy connections to my internal network without actually storing any account information locally (except for the local admin). I think this is the relevant configuration information (comments removed): include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel 0 modulepath /usr/lib/ldap moduleload back_bdb moduleload back_ldap sizelimit 500 tool-threads 1 backend bdb checkpoint 512 30 database ldap lastmod off uri "ldap://server.domain.com" map attribute uid sAMAccountName map attribute cn name map attribute mail userPrincipalName map objectclass account user map attribute * idassert-bind bindmethod=simple binddn="cn=<USER>,ou=<CONTAINER>,dc=domain,dc=com" credentials="<password>" method=self chase-referrals yes database bdb suffix "dc=domain,dc=com" rootdn "cn=<USER>,ou=<CONTAINER>,dc=domain,dc=com" directory "/var/lib/ldap" dbconfig set_cachesize 0 2097152 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 index objectClass eq lastmod on access to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=ftbco,dc=ftn,dc=com" write by anonymous auth by self write by * none access to dn.base="" by * read access to * by dn="cn=admin,dc=ftbco,dc=ftn,dc=com" write by * read Running this with: slapd -g openldap -u openldap -d 16383 Give a few errors such as: line 44 (checkpoint 512 30) /etc/ldap/slapd.conf: line 44: unknown directive <checkpoint> inside backend database definition (ignored). and /etc/ldap/slapd.conf: line 51: rewrite/remap capabilities have been moved to the "rwm" overlay; see slapo-rwm(5) for details (hint: add "overlay rwm" and prefix all directives with "rwm-"). Adding the requested overlay line and changing the map to rwm-map doesn't help. I may be adding it in the wrong place. I always get: line 31 (overlay rwm) overlay "rwm" not found /etc/ldap/slapd.conf: line 31: <overlay> handler exited with 1! with the line number obviously different for the different places I've tried it. Yet, the rwm files are right where they should be: root@ebizsrvb:/etc/ldap# ls -l /usr/lib/ldap/rwm* lrwxrwxrwx 1 root root 17 2007-04-16 12:18 /usr/lib/ldap/rwm-2.3.so.0 -> rwm-2.3.so.0.2.18 -rw-r--r-- 1 root root 33020 2007-03-08 23:45 /usr/lib/ldap/rwm-2.3.so.0.2.18 -rw-r--r-- 1 root root 891 2007-03-08 23:45 /usr/lib/ldap/rwm.la lrwxrwxrwx 1 root root 17 2007-04-16 12:18 /usr/lib/ldap/rwm.so -> rwm-2.3.so.0.2.18 Please tell me what simple step I am messing up? Thank you! -Jason -- NOTICE: This email is being sent in clear-text across the public Internet. Therefore, any attempts to include unenforceable legalese restrictions are ridiculous and pointless. If you can read this, consider yourself authorized (whether I like it or not).

4 7

schema
by Jan Pokorný 07 Aug '07

07 Aug '07

Hello, I would like to ask you for help ... We have migrated RH with openLDAP and now core.schema has changed (1.7.2.19 --> 1.68.2.5). I cannot find a definition of attributetype 'userPassword' which was present in the previous version: attributetype ( 2.5.4.35 NAME 'userPassword' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} ) Could anyone advise me where can I find userPassword definition? In which file? I need to change something in the defintion. Thank you very much for any help! Best regards, Jan

4 6

Using cached entries when ldap backend server fails?
by Heiko 07 Aug '07

07 Aug '07

Hello, Having some basic experience with OpenLDAP, things like overlays and non-db backends are new to me. I'm trying to configure slapd in such a way that: - it proxies filtered user-accounts (objectClass=posixAccount) from Novell eDirectory (NDS). - stores some search and bind results locally like the pcache overlay. - But, unlike pcache, it only uses the locally stored ("cached") when The backend (Novell) server is down/unreachable. I've been through the slapo-* and slapd-* man pages trying to find or contruct a solution. It is possible to do re-writes in the frontend, in order to direct bind requests to another backend-server than search-requests. But is it possible to stack overlays in such a way that a ldap-request goes to another server (or backend) on error or on timeout? I am running Hope it is clear what I am trying to achieve (and I hope there is some way). Thanks in advance for any help. Below this mail is the slapd.conf I have so far, but it does nothing more than proxying a subtree from the Novell eDirectory server, while mapping some selected attributes. (it configures for simple binds and clear text passwords, but this is only for testing) Regards, Heiko Noordhof ~~~~~~~ slap.conf ~~~~~~~ # slapd.conf - Minimal # Global Options # include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema loglevel 256 pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args modulepath /usr/lib/ldap moduleload back_hdb moduleload back_ldap moduleload rwm access to dn="" by * read access to attrs=userPassword by self write by * auth access to * by * read # LDAP proxy database # database ldap protocol-version 3 uri "ldap://ldap.example.nl/" suffix "o=example,c=nl" # Rewrite overlay # overlay rwm rwm-map objectClass ndsLoginProperties rwm-map attribute cn * rwm-map attribute sn * rwm-map attribute givenName * rwm-map attribute initials * rwm-map attribute mail * rwm-map attribute title * rwm-map attribute telephoneNumber * rwm-map attribute l * rwm-map attribute postalCode * rwm-map attribute postalAddress * rwm-map attribute ou * rwm-map attribute homeDirectory * rwm-map attribute uidNumber * rwm-map attribute gidNumber * rwm-map attribute uid * rwm-map attribute * ~~~~~~~~~~~~~EOF~~~~~~~~~~~~

1 0

sasl proxy authentication failure
by Pierre-Francois LAURAND 07 Aug '07

07 Aug '07

Hi, I'm trying to setup sasl proxy authentication on a test database, but something not obvious for me is leading my test to SASL(-13): authentication failure: client response doesn't match what we generated - test setup : OpenLDAP 2.3.37 ( built with sasl2 ) + Cyrus SASL 2.1.22 ( with plain, digest-md5 and ldapdb auxprop support ). - relevant part of slapd.conf used : ... authz-policy to authz-regexp uid=([^,]+),cn=external,cn=auth ldap:///o=test??sub?(cn=$1) authz-regexp uid=([^,]+),cn=digest-md5,cn=auth ldap:///o=test??sub?(cn=$1) authz-regexp uid=([^,]+),cn=plain,cn=auth ldap:///o=test??sub?(cn=$1) password-hash {CLEARTEXT} database bdb suffix "o=test" access to dn.subtree="o=test" attrs=userPassword by group.base="cn=admins,o=test" =wrscx by self =wrcx by * =x access to dn.subtree="o=test" attrs=authzFrom,authzTo by group.base="cn=admins,o=test" =wrscx by * =x access to dn.subtree="o=test" by group.base="cn=admins,o=test" =wrscx by * =rscx ... - some entries : dn: cn=proxy,o=test objectClass: top objectClass: organizationalPerson objectClass: simpleSecurityObject cn: proxy sn: proxy userPassword: proxy authzTo: dn.regex: cn=[^,]+,ou=peoples,o=test dn: cn=testman,ou=peoples,o=test objectClass: top objectClass: inetOrgPerson objectClass: person cn: testman sn: testman userPassword: testman Sasl authentication seems to work using digest-md5 mech : shell$ ldapwhoami -U proxy -Y DIGEST-MD5 SASL/DIGEST-MD5 authentication started Please enter your password: [proxy] SASL username: proxy SASL SSF: 128 SASL installing layers dn:cn=proxy,o=test Result: Success (0) shell$ ldapwhoami -U testman -Y DIGEST-MD5 SASL/DIGEST-MD5 authentication started Please enter your password: [testman] SASL username: testman SASL SSF: 128 SASL installing layers dn:cn=testman,ou=peoples,o=test Result: Success (0) but when trying to test proxying, I get : shell$ ldapwhoami -U proxy -Y DIGEST-MD5 -X u:testman SASL/DIGEST-MD5 authentication started Please enter your password: [testman] ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): authentication failure: client response doesn't match what we generated I get the same result using plain mech : shell$ ldapwhoami -U proxy -Y PLAIN -X u:testman SASL/PLAIN authentication started Please enter your password: [testman] ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): authentication failure: Password verification failed What can cause these authentication failures ? -- Pierre-Francois Laurand

1 0

Active Directory Password Cache
by Sebastian Hetze 07 Aug '07

07 Aug '07

Hi *, in the contrib section of the OpenLDAP tracking system I've uploaded a piece of software that you might find useful. I've also uploaded an additional patch. ftp://ftp.openldap.org/incoming/Sebastian-Hetze-pgk-070712.tgz ftp://ftp.openldap.org/incoming/Sebastian-Hetze-070630.patch It is registered in the issue tracking as ITS#5042. To enter the contrib section of OpenLDAP, the overlay module requires some testing from the community. I have developed the overlay for Debian GNU/Linux and it works pretty well for me. However, I did not test it in other environments. I would very much like to know how good it works and what improvements you suggest. To give you an overview what the module does, here is what the README says: Active Directory Password Cache =============================== Active Directory does not provide any means to read user credentials on any public API. It is possible, to install additional libraries as password sniffer to catch and forward cleartext passwords on changes. In case you cannot or simply dont want to install such libraries, the Active Directory Password Cache overlay is your option. The Active Directory Password Cache overlay allows to mirror user account credentials without any modification on the AD server. It only takes one occasional simple bind authentication against the OpenLDAP server. If the credential has not been mirrored yet, the overlay uses the krbPrincipalName and the password provided by the user to perform a Kerberos init against the Active Directory. A successful Kerberos init guarantees a correct password for this principal, and therefor the bind finally succeeds. Within this overlay operation, the password gets encrypted with the default OpenLDAP hash alorithm and stored as userPassword attribute. There is an option to update the sambaNTPassword also (using code borrowed from Howard Chu's smbk5pwd overlay). All following simple bind authentications will first try these cached credentials, making the OpenLDAP server independent from AD. In case the user changes its password on the Active Directory server, the old password stays valid in OpenLDAP until the user first presents the new password for an simple bind. Within this bind operation, the overlay performs another Kerberos init and updates the cached credentials in OpenLDAP. Installation ============ The adpwc overlay is developed for openldap-2.30. If you unpack the sources in contrib/slapd-modules/adpwc it should compile with a simple make. You need to copy and link the module adpwc.so-2.3.so.0.2.18 to your modulepath dir, /usr/lib/ldap for example. Additionally, you need some Kerberos schema. We use the Novell schema for MIT kerberos, Heimdal works as well. # cp adpwc.so-2.3.so.0.2.18 /usr/lib/ldap # ln -s /usr/lib/ldap/adpwc.so-2.3.so.0.2.18 /usr/lib/ldap/adpwc.so In /etc/ldap/slapd.conf the following lines must be inserted: # includes: include /etc/ldap/schema/kerberos.schema # before backend definition: modulepath /usr/lib/ldap moduleload adpwc.so # in backend section: overlay adpwc adpw-cache-mode user That's it. Given that your Kerberos client configuration is correct, simple bind operations for all users that have valid krbPrincipanName attributes will be forwarded to Kerberos/Active Directory if the local backend bind fails for whatever reason. Correct Kerberos client configuration is: you have your default_realm set to the Active Directory realm and provide a [realm] section pointing to the kdc in /etc/krb5.conf. You should be able to perform a kinit from your Linux/Unix command line prompt, using the krbPrincipalName. Security/Riscs ============== Simple bind authentication is risky in general. You should use SSL encryption to protect cleartext password on the wire. (This is totally independent from adpwc overlay.) The current implementation of adpwc does not use server authentication. The overlay uses krbPrincipalName to perform the Kerberos init. It is neccesary to protect this attribute from unauthorized modification. In case this attribute does not belong to the appropriate AD account, simple bind authentication might be directed to another existing AD account.

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software