openldap-software September 2009

openldap-software@openldap.org

50 participants
51 discussions

Strong bind doesn't work in slapd-ldap when used by slapd-relay or slapo-translucent
by Martin Rubáš 17 Sep '09

17 Sep '09

Hello. This is a kind of follow-up on my previous message "Trouble with slapd-ldap in various scenarios (LdarErr: DSID-0C090627)" sent to OpenLDAP-Technical. I did more research on topic including a code debugging. I finally found the reason why it doesn't work and fixed the code. I have to use slapd-ldap in "strong bind" mode which means that user binds using its own credentials and no identity assertion is performed. If slapd-ldap is the only module that is processing request then everything works fine. If slapd-ldap is processing an request forwarded from slapd-relay (with slapo-rwm) or request to database with slapo-translucent then the authentication problem occurs. Let's suppose that we have remote LDAP server with disabled anonymous binding. It could be Active Directory or OpenLDAP with following configuration: # --- config for remote server (remote.host.net) --- # [cut-off] command schema, slapd files & logs definitions # Load of modules: modulepath /usr/lib/ldap moduleload back_hdb.la # VERY IMPORTANT: Disable anonymous binding disallow bind_anon # Configuration Database database config rootdn "cn=admin,cn=config" rootpw secret # realone.net - local Repository database hdb suffix "dc=realone,dc=net" rootdn "cn=admin,dc=realone,dc=net" rootpw secret directory /var/lib/slapd/realone.net index objectClass eq index cn eq index uid eq Let's say there is a common content in database: # --- Directory content (just an overview) --- dn: dc=realone,dc=net # top, domain dn: ou=people,dc=realone,dc=net # organizationalUnit dn: ou=groups,dc=realone,dc=net # organizationalUnit dn: cn=idassert,dc=realone,dc=net # simpleSecurityObject, organizationalRole dn: cn=admin,dc=realone,dc=net # same as above dn: uid=super.account,ou=people,dc=realone,dc=net # inetOrgPerson, posixAccount, shadowAccount dn: uid=power.account,ou=people,dc=realone,dc=net # same as above dn: uid=basic.account,ou=people,dc=realone,dc=net # same as above dn: cn=admins,ou=groups,dc=realone,dc=net # posixGroup dn: cn=users,ou=groups,dc=realone,dc=net # same as above I want to use another OpenLDAP server that is configured with slapo-translucent: # --- config for local server (trans.local.net) --- # [cut-off] command schema, slapd files & logs definitions # Configuration Database database config rootdn "cn=admin,cn=config" rootpw secret # realone.net - local database extending the remote one database bdb suffix "dc=realone,dc=net" directory ./database/realone.net index objectClass eq index cn eq index uid eq overlay translucent uri ldap://remote.host.net:389/ chase-referrals true rebind-as-user true ... or with slapd-relay (this is probably very very very rare use case but I used it for debugging): # --- config for local server (relay.local.net) --- # [cut-off] command schema, slapd files & logs definitions # Configuration Database database config rootdn "cn=admin,cn=config" rootpw secret # domain (forwarded to remote repository) database ldap suffix "dc=realone,dc=net" uri ldap://remote.host.net chase-referrals yes # domain alias database relay suffix "dc=virtual,dc=net" relay "dc=realone,dc=net" overlay rwm rwm-suffixmassage "dc=virtual,dc=net" "dc=realone,dc=net" Now, we can do usual search: ldapsearch -x -w secret -h <host> -D <bindDN> -b <baseDN> -s sub "(objectClass=inetOrgPerson)" dn displayName mail (in my environment I should receive 3 records below ou=people,dc=realone,dc=net). But the story is getting interesting here. The command works only in cases that slapd-ldap is used dirrectly: =================================================================================================== # | Host | BindDN | BaseDN | Result --+-----------------+----------------------------+-------------------+----------------------------- 1 | remote.host.net | cn=admin,dc=realone,dc=net | dc=realone,dc=net | Success (3 records) --+-----------------+----------------------------+-------------------+----------------------------- 2 | trans.local.net | cn=admin,dc=realone,dc=net | dc=realone,dc=net | Failure: Anon.bind.n.allwd. --+-----------------+----------------------------+-------------------+----------------------------- 3 | relay.local.net | cn=admin,dc=realone,dc=net | dc=realone,dc=net | Success (3 records) --+-----------------+----------------------------+-------------------+----------------------------- 4 | relay.local.net | cn=admin,dc=realone,dc=net | dc=virtual,dc=net | Success (3 records) !!!! --+-----------------+----------------------------+-------------------+----------------------------- 5 | relay.local.net | cn=admin,dc=virtual,dc=net | dc=virtual,dc=net | Failure: Anon.bind.n.allwd. =================================================================================================== The failures of case #2 and #5 are not expected because the connection to remote server is handled by slapd-ldap configured the same way like in case 3. The success in case #3 is correct (although I didn't expected it) and it was guide to solution. I noticed that each time the request fail the LDAP connection is correctly opened and bind request is successful. But the search request was processed using a new connection that was created for it and anonymous bind executed with failure. While debugging, I found that ldap_back_getconn() is called by ldap_back_bind() as well as ldap_back_search() request handlers. For operations other then op_bind it tests whether connection associated with Operation (op->o_hdr->oh_conn) was used for authentication in previous step. If slapd-ldap is NOT using identity assertion then it checks Operation using SLAP_IS_AUTHZ_BACKEND macro whether op->o_conn->c_authz_backend is not NULL and is equal to current backend. This test works fine is the slapd-ldap backend is the only which processes the LDAP request because op->o_conn->c_authz_backend is set in the binding handler of the frontend module - fe_op_bind(). In this, case the test succeeds and connection created during the binding is used also for searching. If the slapd-ldap module is used as nested module in slapo-translucent (case #2), then the fe_op_bind() sets variable op->o_conn->c_authz_backend to the backend extended by slapo-translucent. Macro SLAP_IS_AUTHZ_BACKEND returns false and a new LDAP connection is allocated causing failure due anonymouse binding. If the slapd-ldap module is target for slapd-relay then it behaves similar way. In case #5 the bind request is forwarded to slapd-ldap but slapd-relay is associated with connection as the backend who did the bind (op->o_conn->c_authz_backend) and subsequent search request fails the same way like above. The success in case #4 is a kind of singularity ;-) - bind request is forwarded directly from frontend to slapd-ldap and therefore op->o_conn->c_authz_backend is set correctly, the subsequent search request goes first to slapd-relay which forwards it to slapd-ldap but SLAP_IS_AUTHZ_BACKEND test succeeds. I attached unified diffs of changes I made to OpenLDAP (2.4.18) source code to make it working (fix for back-relay/op.c was much more easier in 2.4.15). It looks like everyone uses the identity assertion mechanism because it make the above mentioned use cases working in certain configurations. Unfortunately, it's not a solution for me to use identity assertion. Could someone confirm my findings? Martin Rubas --- openldap/servers/slapd/overlays/translucent.2_4_15.c Wed Sep 16 16:27:33 2009 +++ openldap/servers/slapd/overlays/translucent.custom.c Wed Sep 16 16:27:34 2009 @@ -1199,6 +1199,10 @@ op->o_bd = &ov->db; ov->db.be_acl = op->o_bd->be_acl; rc = ov->db.bd_info->bi_op_bind(op, rs); + if (0 == rc && 0 == rs->sr_err + && op->o_hdr->oh_conn && !op->o_hdr->oh_conn->c_authz_backend) { + op->o_hdr->oh_conn->c_authz_backend = op->o_bd; + } op->o_bd = db; if (ov->bind_local) { --- openldap/servers/slapd/back-relay/op.2_4_15.c Wed Sep 16 16:55:08 2009 +++ openldap/servers/slapd/back-relay/op.custom.c Wed Sep 16 16:55:09 2009 @@ -170,6 +170,7 @@ relay_back_op_bind( Operation *op, SlapReply *rs ) { BackendDB *bd; + int rc; /* allow rootdn as a means to auth without the need to actually * contact the proxied DSA */ @@ -187,8 +188,14 @@ return rs->sr_err; } - return relay_back_op( op, rs, bd, bd->be_bind, + rc = relay_back_op( op, rs, bd, bd->be_bind, ( LDAP_INVALID_CREDENTIALS | RB_ERR_SEND ) ); + + if (0 == rc && 0 == rs->sr_err + && op->o_hdr->oh_conn && !op->o_hdr->oh_conn->c_authz_backend) { + op->o_hdr->oh_conn->c_authz_backend = bd; + } + return rc; } int --- openldap/servers/slapd/back-relay/op.2_4_18.c Wed Sep 16 17:34:54 2009 +++ openldap/servers/slapd/back-relay/op.custom.c Wed Sep 09 14:36:14 2009 @@ -208,11 +208,6 @@ if ( op->o_callback == (slap_callback *) &rcb ) { op->o_callback = op->o_callback->sc_next; } - if (op_bind == which && 0 == rc && 0 == rs->sr_err - && op->o_hdr->oh_conn && !op->o_hdr->oh_conn->c_authz_backend) { - op->o_hdr->oh_conn->c_authz_backend = bd; - } - } else if ( fail_mode & RB_OPERR ) { rs->sr_err = rc;

2 2

Creating database, catch-22
by Peter Mogensen 16 Sep '09

16 Sep '09

Hi, I've been trying to script database creation via cn=config. Creating the HDB database works fine, but when I try to add the LDIF for the root node, I get: # ldapadd -YEXTERNAL -H ldapi:/// -f ./bootstrap.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "dc=app,dc=example,dc=com" ldap_add: Insufficient access (50) additional info: no write access to parent ... which is understandable. However, I would prefer not to set a temporary rootpw for the database. Is there any way around that? I considered Proxy authorization, but the root DN for the database I'm creating is in the LDIF I'm trying to add. /Peter PS: As you can probably see, all access goes through SASL EXTERNAL. UNIX root maps to cn=config via ldapi:/// , remote access uses x509 certificates.

4 7

Wired issue with slurpd
by Dawei Wang 16 Sep '09

16 Sep '09

Hi, I am using slurpd to do replication (openldap 2.3.33) and encountered a strange issue: The master have an entry which has a binary field, size of filed is about 10 meg. When never this field is updated ( and it's the only field get updated), slurpd is triggered to replicate the change to the slave. But slurpd seems gone wild on this binary filed, when i check the replication log, i saw this binary filed becomes huge, i mean really huge, gigabytes in size. Is there any problem with slurpd to read the binary filed? Regards Dawei

2 3

set.regex and substring substitution
by Ronie Gilberto Henrich 15 Sep '09

15 Sep '09

Hi, I am trying to grant users access to a ldap object when user/allowedDomain match the Mail object ou. To accomplish that I have to use set.regex and substring substitution, but I was not able to figure out what I am doing wrong. This is the current ACL: access to dn.regex="^(.+,)?ou=([^,]+),ou=Mail,o=example,c=BR$" by set="user/allowedDomain & this/ou" write result (tested using "slapacl -D"): ======= "ou=example.com,ou=Mail,o=example,c=BR" = write(=wrscxd) "mail=test(a)example.com,ou=example.com,ou=Mail,o=example,c=BR" = 0 This is the ACL that I am trying to build. It was expecting both results as = write(=wrscxd), but I am getting only = 0. access to dn.regex="^(.+,)?ou=([^,]+),ou=Mail,o=example,c=BR$" by set.regex="user/allowedDomain & $2" write result (tested using "slapacl -D"): ======= "ou=example.com,ou=Mail,o=example,c=BR" = 0 "mail=test(a)example.com,ou=example.com,ou=Mail,o=example,c=BR" = 0 Any ideas about what I should do for this to work? Thanks! Ronie

1 0

virtual list view, control value absent
by Dieter Kluenter 14 Sep '09

14 Sep '09

Hi, I am experimenting with server side sorting and virtual list view. While SSS does what it should do, vlv provides some headaches. Although sss control and vlv control are passed to the server, I get following error: ,----[ slapd debug output ] | => get_ctrls: oid="1.2.840.113556.1.4.473" (critical) | => get_ctrls: oid="2.16.840.1.113730.3.4.9" (critical) | <= get_ctrls: n=2 rc=2 err="vlv control value is absent" `---- What kind of vlv control value is missing? My vlv object, written in perl, is: ,----[ vlv object ] | $vlv = Net::LDAP::Control::VLV->new( | after => 1, | before => 0, | content => 0, | offset => 1, | critical => 'TRUE', | ); `---- my sss object looks like ,----[ sss object ] | $sort = Net::LDAP::Control::Sort->new( | order => 'sn:2.5.13.3', | critical => 'TRUE', | ); `---- my search object: ,----[ search object ] | my @args = ( | base => 'ou=benchmark,o=avci,c=de', | scope => 'one', | attrs => [ "$attrs[0]","$attrs[1]","$attrs[2]" ]); | filter => $filter, | control => [ $sort, $vlv ], | ); | $msg = $ldap->search( @args ); `---- -Dieter -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:8EF7B6C6 53°37'09,95"N 10°08'02,42"E

2 1

Is Openldap supported on Windows XP/Vista/Server editions?
by Rupak Kumar Sah 11 Sep '09

11 Sep '09

Hi All, Is Open Ldap supported on Windows Server Editions, XP/Vista? Is this supported on z/OS as well? Thanks in advance. Regards, Rupak

3 2

Re: Emulating replication from an LDAP client (not another slapd)
by Pierangelo Masarati 11 Sep '09

11 Sep '09

Pierangelo Masarati wrote: > Hallvard B Furuseth wrote: >> Brandon Hume writes: >>> So my question is this: Is it possible for me to write some code, using >>> perl or C or whatever is needed, that will connect as a syncrepl >>> consumer, and "refresh and persist"? Are there docs for how the >>> synchronization protocol works? Is it just an odd LDAP query? >> >> RFC 4533 describes the sync protocol. You might also have a look at the >> auditlog and accesslog overlays for alternate solutions to your probelm. > > Following on to Hallvard's comment, OpenLDAP's libldap provides > primitives to implement consumer-side syncrepl (as per RFC4533, no > support for OpenLDAP extensions like delta-syncrepl and so). If you > want to design your own consumer-side code based on RFC 4533, I'd > recommend to start there. Of course, other solutions based on e.g. > accesslog might be preferable if you prefer to limit the amount of > required coding. Forgot to point you to ldap_sync(3) p.

2 1

Emulating replication from an LDAP client (not another slapd)
by Brandon Hume 11 Sep '09

11 Sep '09

Most of my organization's data is kept in LDAP, along with groups and affiliations and titles and positions and everything else. We've got a simple single-master, multi-slave setup, built back in the OpenLDAP 2.0 days. We also have a provisioning service, which essentially monitors LDAP, and as new people arrive, change position, or what have you, it runs off and provisions accounts, mailboxes, services and permissions as needed for the person, all automatically. Currently, this monitoring - trying to keep it as "live" as possible - is done by essentially making the provisioning server an LDAP replicant, using slurpd. It works "well enough", though it has some problems. But slurpd is going away, and I'm trying to kill it off in our structure. The provisioning server is one of the last holdouts. So my question is this: Is it possible for me to write some code, using perl or C or whatever is needed, that will connect as a syncrepl consumer, and "refresh and persist"? Are there docs for how the synchronization protocol works? Is it just an odd LDAP query?

4 3

OpenLDAP and SASL
by Jittinan Suwanrueangsri 11 Sep '09

11 Sep '09

Hi I have seen configuration which sasl get password from sasldb .I must run saslpasswd2 to create user and password for authentication but Is it possible to configure openldap and sasl verify authentication by getting password from openldap self like it happen in simple binding(userPassword attribute).How can I do it? jittinan

4 8

TLS negotiation failure
by manu＠netbsd.org 10 Sep '09

10 Sep '09

Hello I experience a wierd problem with OpenLDAP and TLS connexions. slapd will randomly reject connexions, with "TLS negotiation failure" error message. That happens with various clients (MacOS, NetBSD, Linux), and it happens on multiples machines that run slapd, the current setup is below: OpenLDAP 2.4.16 OpenSSL 0.9.9-dev 09 May 2008 NetBSD 5.0.1 But the problem also existed before upgrades with NetBSD 4.0 and OpenLDAP 2.4.14. It seems to become worse over time. Here is a trace obtained with a breakpoint set on the error message in slapd. conn=0 fd=19 ACCEPT from IP=193.54.82.248:59782 (IP=193.54.82.23:636) TLS: can't accept: (null). Breakpoint 1, connection_read (s=19, cri=0xa63ff8ac) at connection.c:1326 1326 connection_closing( c, "TLS negotiation failure" ); (gdb) bt #0 connection_read (s=19, cri=0xa63ff8ac) at connection.c:1326 #1 0x08078bf9 in connection_read_thread (ctx=0xa63ff900, argv=0x13) at connection.c:1216 #2 0xbbbaad3a in ldap_int_thread_pool_wrapper (xpool=0xbb540080) at tpool.c:663 #3 0xbb85e9df in pthread_create () from /usr/lib/libpthread.so.0 #4 0xbb7aa640 in swapcontext () from /usr/lib/libc.so.12 (gdb) c Continuing. conn=1 fd=20 ACCEPT from IP=193.54.82.248:59783 (IP=193.54.82.23:636) conn=0 fd=19 closed (TLS negotiation failure) So connection_read() reports an error from ldap_pvt_tls_accept(), which is caused by tls_imp->ti_session_accept(). For OpenSSL, that is tlso_session_accept(), which just calls SSL_accept() Does that ring a bell to anyone? Any suggestion for a workaround? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

2 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software September 2009