openldap-technical

openldap-technical@openldap.org

23 participants
9804 discussions

HowTo to setup LDAP
by Luc MAIGNAN 16 May '12

16 May '12

Hi, I've found a lot of howto to setup openLDAP using the slapd.conf but none using the actual database feature. But I want to configure a freshly installed openLDAP without writing a slapd.conf and doing a migration on it. Is there somewhere a step-by-step howto to setup an openLDAP using the new feature (all parameters in the LDAP) ? Thanks for any help Best regards

4 6

"do_bind: invalid dn" while trying to monitor slapd using pacemaker `slapd' resource agent
by Igor Zinovik 16 May '12

16 May '12

Hello. I'm deploing mirrormode openldap cluster. I have two hosts running openSUSE 12.1 with openldap2-2.4.30-83.3.x86_64 I created special user for mirrormode and tuned limits, so replication works fine. But for transparent switch between two nodes in case of failure i need some additional software to monitor ldap daemons and manage IP addresses on which my consumers connect. So i went for pacemaker and used following document to set it up: http://www.daasi.de/ldapcon2011/downloads/Haferkamp-paper.pdf I decided to create a special uid for monitoring my tree which can read only root element: ldap2:~# grep -C 2 pcmk /etc/openldap/slapd.conf # access to dn.base="dc=test,dc=org" by dn="uid=slapd-pcmk,ou=Services,dc=test,dc=org" read And here is my problem: I can successfully execute search query by hands using ldapsearch(1): ldap2:~# ldapsearch -H "ldap:/// ldaps:/// ldapi:///" -b dc=test,dc=org -LLL -s base -x -D 'uid=slapd-pcmk,ou=Services,dc=test,dc=org -w 'P@ssw0rd,' Enter LDAP Password: dn: dc=test,dc=org dc: test objectClass: organization objectClass: dcObject o: Test org ldap2:~# echo $? 0 Pacemaker uses resource agents to monitor various daemons, so i downloaded resource agent for slapd. Resource agent is just a script file (e.g. resource agent for slapd) and it executes same query as i do by hand, but slapd complains about "invalid dn": Here is how slapd resource was defined: ldap2:~# crm configure primitive slapd_mirrormode ocf:heartbeat:slapd params \ slapd="/usr/lib/openldap/slapd" config="/etc/openldap/slapd.conf" \ user="ldap" group="ldap" services="ldap:/// ldaps:/// ldapi:///" \ watch_suffix="dc=test,dc=org" \ bind_dn="uid=slapd-pcmk,ou=Services,dc=test,dc=org" \ password="P@ssw0rd," parameters="-o slp=on" \ meta migration-threshold="3" op monitor interval="10s" I changed loglevel in slapd to `1' and see following in log: May 16 13:07:00 ldap2 slapd[7641]: slap_listener_activate(8): May 16 13:07:00 ldap2 slapd[7641]: >>> slap_listener(ldap:///) May 16 13:07:00 ldap2 slapd[7641]: connection_get(17): got connid=1013 May 16 13:07:00 ldap2 slapd[7641]: connection_read(17): checking for input on id=1013 May 16 13:07:00 ldap2 slapd[7641]: op tag 0x60, time 1337159220 May 16 13:07:00 ldap2 slapd[7641]: conn=1013 op=0 do_bind May 16 13:07:00 ldap2 slapd[7641]: >>> dnPrettyNormal: <'uid=slapd-pcmk,ou=Services,dc=test,dc=org'> May 16 13:07:00 ldap2 slapd[7641]: conn=1013 op=0 do_bind: invalid dn ('uid=slapd-pcmk,ou=Services,dc=test,dc=org') May 16 13:07:00 ldap2 slapd[7641]: send_ldap_result: conn=1013 op=0 p=3 May 16 13:07:00 ldap2 slapd[7641]: send_ldap_response: msgid=1 tag=97 err=34 May 16 13:07:00 ldap2 slapd[7641]: connection_get(17): got connid=1013 May 16 13:07:00 ldap2 slapd[7641]: connection_read(17): checking for input on id=1013 May 16 13:07:00 ldap2 slapd[7641]: op tag 0x42, time 1337159220 May 16 13:07:00 ldap2 slapd[7641]: conn=1013 op=1 do_unbind May 16 13:07:00 ldap2 slapd[7641]: connection_close: conn=1013 sd=17 May 16 13:07:01 ldap2 slapd[7641]: slap_listener_activate(8): May 16 13:07:01 ldap2 slapd[7641]: >>> slap_listener(ldap:///) May 16 13:07:01 ldap2 slapd[7641]: connection_get(17): got connid=1014 May 16 13:07:01 ldap2 slapd[7641]: connection_read(17): checking for input on id=1014 May 16 13:07:01 ldap2 slapd[7641]: op tag 0x60, time 1337159221 May 16 13:07:01 ldap2 slapd[7641]: conn=1014 op=0 do_bind May 16 13:07:01 ldap2 slapd[7641]: >>> dnPrettyNormal: <'uid=slapd-pcmk,ou=Services,dc=test,dc=org'> May 16 13:07:01 ldap2 slapd[7641]: conn=1014 op=0 do_bind: invalid dn ('uid=slapd-pcmk,ou=Services,dc=test,dc=org') May 16 13:07:01 ldap2 slapd[7641]: send_ldap_result: conn=1014 op=0 p=3 May 16 13:07:01 ldap2 slapd[7641]: send_ldap_response: msgid=1 tag=97 err=34 May 16 13:07:01 ldap2 slapd[7641]: connection_get(17): got connid=1014 May 16 13:07:01 ldap2 slapd[7641]: connection_read(17): checking for input on id=1014 May 16 13:07:01 ldap2 slapd[7641]: op tag 0x42, time 1337159221 May 16 13:07:01 ldap2 slapd[7641]: ber_get_next on fd 17 failed errno=0 (Success) May 16 13:07:01 ldap2 slapd[7641]: conn=1014 op=1 do_unbind May 16 13:07:01 ldap2 slapd[7641]: connection_close: conn=1014 sd=17 May 16 13:07:02 ldap2 slapd[7641]: slap_listener_activate(8): May 16 13:07:02 ldap2 slapd[7641]: >>> slap_listener(ldap:///) May 16 13:07:02 ldap2 slapd[7641]: connection_get(17): got connid=1015 May 16 13:07:02 ldap2 slapd[7641]: connection_read(17): checking for input on id=1015 May 16 13:07:02 ldap2 slapd[7641]: op tag 0x60, time 1337159222 May 16 13:07:02 ldap2 slapd[7641]: conn=1015 op=0 do_bind May 16 13:07:02 ldap2 slapd[7641]: >>> dnPrettyNormal: <'uid=slapd-pcmk,ou=Services,dc=test,dc=org'> May 16 13:07:02 ldap2 slapd[7641]: conn=1015 op=0 do_bind: invalid dn ('uid=slapd-pcmk,ou=Services,dc=test,dc=org') May 16 13:07:02 ldap2 slapd[7641]: send_ldap_result: conn=1015 op=0 p=3 May 16 13:07:02 ldap2 slapd[7641]: send_ldap_response: msgid=1 tag=97 err=34 May 16 13:07:02 ldap2 slapd[7641]: connection_get(17): got connid=1015 May 16 13:07:02 ldap2 slapd[7641]: connection_read(17): checking for input on id=1015 May 16 13:07:02 ldap2 slapd[7641]: op tag 0x42, time 1337159222 May 16 13:07:02 ldap2 slapd[7641]: conn=1015 op=1 do_unbind May 16 13:07:02 ldap2 slapd[7641]: connection_close: conn=1015 sd=17 May 16 13:07:04 ldap2 slapd[7641]: slap_listener_activate(8): May 16 13:07:04 ldap2 slapd[7641]: >>> slap_listener(ldap:///) May 16 13:07:04 ldap2 slapd[7641]: connection_get(17): got connid=1016 May 16 13:07:04 ldap2 slapd[7641]: connection_read(17): checking for input on id=1016 May 16 13:07:04 ldap2 slapd[7641]: op tag 0x60, time 1337159224 May 16 13:07:04 ldap2 slapd[7641]: conn=1016 op=0 do_bind May 16 13:07:04 ldap2 slapd[7641]: >>> dnPrettyNormal: <'uid=slapd-pcmk,ou=Services,dc=test,dc=org'> May 16 13:07:04 ldap2 slapd[7641]: conn=1016 op=0 do_bind: invalid dn ('uid=slapd-pcmk,ou=Services,dc=test,dc=org') May 16 13:07:04 ldap2 slapd[7641]: send_ldap_result: conn=1016 op=0 p=3 May 16 13:07:04 ldap2 slapd[7641]: send_ldap_response: msgid=1 tag=97 err=34 May 16 13:07:04 ldap2 slapd[7641]: connection_get(17): got connid=1016 May 16 13:07:04 ldap2 slapd[7641]: connection_read(17): checking for input on id=1016 May 16 13:07:04 ldap2 slapd[7641]: op tag 0x42, time 1337159224 May 16 13:07:04 ldap2 slapd[7641]: conn=1016 op=1 do_unbind May 16 13:07:04 ldap2 slapd[7641]: connection_close: conn=1016 sd=17 May 16 13:07:05 ldap2 slapd[7641]: slap_listener_activate(8): May 16 13:07:05 ldap2 slapd[7641]: >>> slap_listener(ldap:///) May 16 13:07:05 ldap2 slapd[7641]: connection_get(17): got connid=1017 May 16 13:07:05 ldap2 slapd[7641]: connection_read(17): checking for input on id=1017 May 16 13:07:05 ldap2 slapd[7641]: op tag 0x60, time 1337159225 May 16 13:07:05 ldap2 slapd[7641]: conn=1017 op=0 do_bind May 16 13:07:05 ldap2 slapd[7641]: >>> dnPrettyNormal: <'uid=slapd-pcmk,ou=Services,dc=test,dc=org'> May 16 13:07:05 ldap2 slapd[7641]: conn=1017 op=0 do_bind: invalid dn ('uid=slapd-pcmk,ou=Services,dc=test,dc=org') May 16 13:07:05 ldap2 slapd[7641]: send_ldap_result: conn=1017 op=0 p=3 May 16 13:07:05 ldap2 slapd[7641]: send_ldap_response: msgid=1 tag=97 err=34 May 16 13:07:05 ldap2 slapd[7641]: connection_get(17): got connid=1017 May 16 13:07:05 ldap2 slapd[7641]: connection_read(17): checking for input on id=1017 May 16 13:07:05 ldap2 slapd[7641]: op tag 0x42, time 1337159225 May 16 13:07:05 ldap2 slapd[7641]: conn=1017 op=1 do_unbind May 16 13:07:05 ldap2 slapd[7641]: connection_close: conn=1017 sd=17 May 16 13:07:06 ldap2 slapd[7641]: daemon: shutdown requested and initiated. May 16 13:07:06 ldap2 slapd[7641]: slapd shutdown: waiting for 1 operations/tasks to finish May 16 13:07:06 ldap2 slapd[7641]: slapd shutdown: initiated May 16 13:07:06 ldap2 slapd[7641]: ====> bdb_cache_release_all May 16 13:07:06 ldap2 slapd[7641]: slapd destroy: freeing system resources. May 16 13:07:06 ldap2 slapd[7641]: syncinfo_free: rid=001 May 16 13:07:06 ldap2 slapd[7641]: connection_get(14): got connid=0 May 16 13:07:06 ldap2 slapd[7641]: slapd stopped. I understand that there might be a problem in pacemakers `slapd' resource agent. Maybe it corrupts bind dn somehow... Agent executes `monitor' operation, here is a snippet from resource agent code: ldap2:~# less /usr/lib/ocf/resource.d/heartbeat/slapd ... slapd_monitor() { ... options="-LLL -s base -x" if [ -n "$bind_dn" ]; then options="$options -D '$bind_dn' -w '$password'" fi [ -z "$1" ] && err_option="" for suffix in $suffixes; do ocf_run -q $err_option "$ldapsearch" -H "$services" -b "$suffix" $options >/dev/null 2>&1; rc=$? case "$rc" in "0") ocf_log debug "slapd database with suffix '$suffix' reachable" ;; "49") ocf_log err "slapd database with suffix '$suffix' unreachable. Invalid credentials." return $OCF_ERR_CONFIGURED ;; *) if [ -z "$1" ] || [ -n "$1" -a $rc -ne 1 ]; then ocf_log err "slapd database with suffix '$suffix' unreachable. exit code ($rc)" fi ... Still scratching head...

2 1

OpenLDAP 2.4.23 multi-master replication of the cn=config tree error: could not put entry file in place
by Cyril Grosjean 16 May '12

16 May '12

I've a sandbox environment with 2 CentOS 6.2 servers running the genuine openldap-servers rpms, that is OpenLDAP 2.4.23 . I've setup a multi-master replication between the servers, so that both my data DIT (dc=....,dc=.... ) and the cn=config should be replicated. Actually, the replication of data works fine, as expected in either way, but the replication of the configuration tree fails: each time I update the configuration on the second node, I get this error in my LDAP client (Apache Directory Studio): could not put entry file in place I've tried to run the second master in debug (-d -1) mode, and it seems like there's a write access error when the slapd daemon (on the 2nd master) tries to update/modify/replace the /etc/openldap/slapd.d/cn=config.ldif file: <= acl_access_allowed: granted to database root ldif_write_entry: could not put entry file for "cn=config" in place: Permission denied send_ldap_result: conn=-1 op=0 p=3 send_ldap_result: err=80 matched="" text="internal error (could not put entry file in place)" send_ldap_result: conn=-1 op=0 p=3 send_ldap_result: err=80 matched="" text="internal error (could not put entry file in place)" null_callback : error code 0x50 slap_graduate_commit_csn: removing 0x7fd19412f090 20120510163105.003156Z#000000#001#000000 syncrepl_updateCookie: rid=001 be_modify failed (80) ldap_msgfree The OpenLDAP error log shows the following error: May 10 19:12:39 sashimi slapd[24866]: slapd starting May 10 19:12:40 sashimi slapd[24866]: ldif_write_entry: cannot create file for "olcDatabase={0}config,cn=config": Permission denied May 10 19:12:40 sashimi slapd[24866]: null_callback : error code 0x50 May 10 19:12:40 sashimi slapd[24866]: syncrepl_entry: rid=001 be_modify failed (80) May 10 19:12:40 sashimi slapd[24866]: do_syncrepl: rid=001 rc -1 quitting May 10 19:12:50 sashimi slapd[24866]: ldif_write_entry: could not put entry file for "cn=config" in place: Permission denied May 10 19:12:50 sashimi slapd[24866]: null_callback : error code 0x50 May 10 19:12:50 sashimi slapd[24866]: syncrepl_updateCookie: rid=001 be_modify failed (80) May 10 19:13:00 sashimi slapd[24866]: ldif_write_entry: could not put entry file for "cn=config" in place: Permission denied May 10 19:13:00 sashimi slapd[24866]: null_callback : error code 0x50 May 10 19:13:00 sashimi slapd[24866]: syncrepl_updateCookie: rid=001 be_modify failed (80) May 10 19:13:10 sashimi slapd[24866]: ldif_write_entry: could not put entry file for "cn=config" in place: Permission denied May 10 19:13:10 sashimi slapd[24866]: null_callback : error code 0x50 May 10 19:13:10 sashimi slapd[24866]: syncrepl_updateCookie: rid=001 be_modify failed (80) Of course, I don't have any right access problems at the file system level, I don't have any file system ACLs, I don't use SELinux and I've checked that I can update or create any file under /etc/openldap/slapd.d, when logged in as the ldap user (who's the account used to run slapd). So, this error looks like a bug to me. Already fixed ? To setup the replication of both data and configuration, I've copied the full /etc/openldap directory from one server to the other, with the same file system rights. I've just changed the server certificate files since I use TLS to replicate both the data and the configuration. So, I don't have any TLS problem since the data tree replication works fine. Here's my replication configuration for the cn=config database: dn: olcDatabase={0}config,cn=config ... .... olcSyncRepl: rid=001 provider=ldap://......:389 binddn="cn=config" bindmethod=simple credentials="......" searchbase="cn=config" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1 starttls=yes tls_cacert=/etc/openldap/conf/cacert.pem olcSyncRepl: rid=002 provider=ldap://.....:389 binddn="cn=config" bindmethod=simple credentials="....... " searchbase="cn=config" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1 starttls=yes tls_cacert=/etc/openldap/conf/cacert.pem olcMirrorMode: TRUE I actually use the same setup than for the data replication, excepted that I have rid=003 and rid=004 of course for data replication, and the BIND DN and passwords are different too. -- Cyril

4 4

SASL AD + SASL SCRAM
by Pieter Baele 16 May '12

16 May '12

Hi, My current LDAP setup uses SASL PTA to authenticate against Active Directory. For users only existing in OpenLDAP, I would use SASL SCRAM, so no passes over the wire except for these in AD ;-) But I believe only 1 method can be used by SASL External? Any guidelines on configuring something as this? Do I really need the meta backend or is there a better way? -- PieterB

2 1

AW: overlay nssov + pass-through authentication
by Uwe Werler 16 May '12

16 May '12

> Hello list, > > up to now we have pam_ldap/nss_ldap running from padl and all user accounts have > > pass-through authentication configured to authenticate against an > external ldap server.* > > Now I try the overlay nssov and except authentication all is running fine. > > If I use the userPassword directly the user can authenticate without problems. > > Isn't it possible to use pass-through authentication with overlay nssov? > > Thanks in advance! > > Regards Uwe > > *userPassword: {SASL}uid > > > Ok, I found overlay pbind - it does what I want 'cause we use saslauthd with ldap auth against an external ldap server for some user accounts. Drawback in this setup is that I have to split my database for this.

1 0

Re: options for meta when using configuration backend
by Scott Koranda 16 May '12

16 May '12

On Tue, May 15, 2012 at 10:52 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Tuesday, May 15, 2012 9:32 PM -0500 Scott Koranda <skoranda(a)gmail.com> > wrote: > >> Does slapd-meta built from 2.4.31 source support using >> slapd-config? > > > You never mentioned slapd-meta in your original post. The subject of the post was "options for meta when using configuration backend". I agree that the note could have been more clear. > olcDbURI is usually > associated with slapd-ldap. I don't believe slapd-meta has cn=config > support at this time. Thank you. I will proceed with slapd.conf. Scott > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

options for meta when using configuration backend
by Scott Koranda 16 May '12

16 May '12

Hi, I am using slapd 2.4.23 on Debian Squeeze. Is 'olcDbURI' the correct configuration option to use with the configuration backend? Put another way, is 'olcDbURI' the configuration backend analog of the 'uri' target specification option used in the slapd.conf file? If 'olcDbURI' is not the correct option I would be grateful to know the correct option to use. Thanks, Scott

2 3

extracting
by Alex Samad - Yieldbroker 16 May '12

16 May '12

Hi Wondering if anyone can help me, I need to extra schema info out of MS AD and then add it to openldap . try to get openldap - proxy to - MS AD working... I can do simple type of searches like on cn, but I can do search on attributes like samaccountype ... I am guess that's it's a scheme issues... A

3 6

Re: options for meta when using configuration backend
by André Ribas 16 May '12

16 May '12

2012/5/15 Quanah Gibson-Mount <quanah(a)zimbra.com>: > --On Tuesday, May 15, 2012 5:35 PM -0500 Scott Koranda <skoranda(a)gmail.com> > wrote: > >> Hi, >> >> I am using slapd 2.4.23 on Debian Squeeze. > > > Bad idea. Build your own package. > Can I ask you why is it a bad idea? > > [...] > > --Quanah > > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > André Ribas

1 0

2.4.31 slapd-meta
by Eugene Vilensky 15 May '12

15 May '12

Hello, I am trying to move a meta-directory from version 2.3.43 (included with RHEL 5) to version 2.4.31 (openldap-ltb packages on RHEL6). I've tried to follow the man pages and FAQ properly in using newer directives for the same functionality, but searches that previously worked on 2.3.43 no longer work. The meta database in the 2.3.43 is defined like so: ----- database meta suffix "dc=example,dc=edu" uri "ldap://central-ldap.example.edu/ou=people,dc=example,dc=edu" idassert-bind bindmethod=simple binddn "cn=account,ou=service,dc=example,dc=edu" bindpw secret uri "ldap://localhost/ou=groups,dc=local,dc=example,dc=edu" idassert-bind bindmethod=simple binddn "cn=Manager,dc=local,dc=example,dc=edu" bindpw supersecret ---------- This seems to work (People are retrieved from the upstream ldap and a local bdb [not shown] database serves groupofnames memberships specific to our org unit), with deprecation warnings: /etc/openldap/slapd.conf: line 118: "binddn" statement is deprecated; use "acl-authcDN" instead /etc/openldap/slapd.conf: line 119: "bindpw" statement is deprecated; use "acl-passwd" instead /etc/openldap/slapd.conf: line 123: "binddn" statement is deprecated; use "acl-authcDN" instead /etc/openldap/slapd.conf: line 124: "bindpw" statement is deprecated; use "acl-passwd" instead [1] I've assumed binddn and bindpw are used by slapd-meta to perform searches against the remote directory. Is this wrong? Moving these configuration options to 2.4.31, my <database meta> is defined like so (focusing on the remote LDAP entry): database meta suffix "dc=example,dc=edu" uri "ldap://central-ldap.example.edu/ou=people,dc=example,dc=edu" idassert-bind bindmethod=simple binddn="cn=account,ou=service,dc=example,dc=edu" credentials="secret" Searches don't work and debug output includes among other information: 4fb288b5 conn=1001 op=11 meta_search_dobind_init[0] mc=0x7ff4c0104b20: non-empty dn with empty cred; binding anonymously request done: ld 0x7ff4c4101f40 msgid 2 res_errno: 48, res_error: <binds with a dn require a password>, res_matched: <> Is there a reason why credentials aren't being used along with bind dn? Was I wrong about assumption [1]? Hmm..the search works if I use "rebind-as-user yes" as an option for the remote URI, but I've not figured out from slapd-ldap(5) why this is so...the client credentials are not valid upstream, its a dn specific to the local database. Any help greatly appreciated (as before!) -Eugene

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical