ldap proxy, attribute rwm

[Krisztián Gáhor]

I created an LDAP proxy using an LDAP backend to connect to our Active
Directory server. Unfortunately, our AD server has incorrect usernames in
the sAMAccountName attribute, so I would like to override this with the
prefix of the value found in the userPrincipalName attribute (the part
before @domain).

Is this possible at all? Unfortunately, I haven't succeeded in doing this
so far.

Re: back-ldap proxy doesn't forward response from upstream server

[Jean-Luc Bourguignon]

Hello Sven,

Did you set ACL that allow reply to be send to client on the proxy ldap 
instance ? I had same issue with META proxy ldap type before I set these ACL. 

Brgds,
Jean-Luc. 

> On 7 Jun 2023, at 16:23, Sven Feyerabend 
>  wrote:
> 
> Hello everyone,
> 
> I have set up two slapd instances in mirror mode.
> As described in the documentation I used another slapd instance with ldap 
> backend to proxy the requests and provide failover capabilities in case one 
> of the upstream servers becomes unavailable.
> 
> Now I have the curious situation, that the proxy correctly forwards the 
> search request from a client to the upstream server but doesn't return the 
> result.
> I can see in the log that the upstream server responds with one entry:
> 
> SEARCH RESULT tag=101 err=0 qtime=0.34 etime=0.001134 nentries=1
> 
> The proxy however does not forward this result to the client:
> 
> SEARCH RESULT tag=101 err=0 qtime=0.34 etime=0.001730 nentries=0
> 
> The client (ldapsearch for test purposes) then gives me the following result:
> 
> # search result
> search: 2
> result: 0 Success
> 
> I don't understand what I did wrong. I imported the correct schema into the 
> proxy instance, my config of the ldap backend on the proxy is as follows:
> 
> # {2}ldap, config
> dn: olcDatabase={2}ldap,cn=config
> objectClass: olcDatabaseConfig
> objectClass: olcLdapConfig
> olcDatabase: {2}ldap
> olcSuffix: ROOT_SUFFIX_OF_UPSTREAM_DIRECTORY
> olcDbURI: 
> ldap://openldap-test-0.ldap-test:1389,ldap://openldap-test-1.ldap-test:1389
> 
> Does anyone know how to solve this?
> 
> Some help would be appreciated greatly.
> 
> Thanks in advance and kind regards
> 
> Sven

back-ldap proxy doesn't forward response from upstream server

[Sven Feyerabend]

Hello everyone,

I have set up two slapd instances in mirror mode.
As described in the documentation I used another slapd instance with 
ldap backend to proxy the requests and provide failover capabilities in 
case one of the upstream servers becomes unavailable.


Now I have the curious situation, that the proxy correctly forwards the 
search request from a client to the upstream server but doesn't return 
the result.

I can see in the log that the upstream server responds with one entry:

SEARCH RESULT tag=101 err=0 qtime=0.34 etime=0.001134 nentries=1

The proxy however does not forward this result to the client:

SEARCH RESULT tag=101 err=0 qtime=0.34 etime=0.001730 nentries=0

The client (ldapsearch for test purposes) then gives me the following 
result:


# search result
search: 2
result: 0 Success

I don't understand what I did wrong. I imported the correct schema into 
the proxy instance, my config of the ldap backend on the proxy is as 
follows:


# {2}ldap, config
dn: olcDatabase={2}ldap,cn=config
objectClass: olcDatabaseConfig
objectClass: olcLdapConfig
olcDatabase: {2}ldap
olcSuffix: ROOT_SUFFIX_OF_UPSTREAM_DIRECTORY
olcDbURI: 
ldap://openldap-test-0.ldap-test:1389,ldap://openldap-test-1.ldap-test:1389


Does anyone know how to solve this?

Some help would be appreciated greatly.

Thanks in advance and kind regards

Sven

LDAP Proxy (meta type)

[bourguijl]

Dears,

I tried to configure a proxy ldap type (meta) but without success as I get 
following error message when I try to start it :

63d13d3c.03f49ea0 0x7f2e4ff3b1c0 backend_startup_one: starting "o=mobistar.be"
63d13d3c.03f4ab38 0x7f2e4ff3b1c0 meta_back_db_open: no targets defined
63d13d3c.03f53e41 0x7f2e4ff3b1c0 backend_startup_one (type=meta, 
suffix="o=mobistar.be"): bi_db_open failed! (1)

Here is my configuration :

dn: olcDatabase={2}meta
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {2}meta
olcSuffix: o=mobistar.be
olcDbURI: 
"ldap://acccorpldapproxym1.nonprod.priv.orange.be:389/ou=staff,o=mobistar.be;
olcLastMod: FALSE
olcReadOnly: TRUE
olcRootDN: cn=directory manager,o=mobistar.be
olcRootPW:: e1NTSEF9aFVwQ2t0RHdOeHJDZHJ3UHA2bkc2dEVHdFJRQzFwWk8=
structuralObjectClass: olcMdbConfig

To be sure it's not a Firewall issue, I started the target on the same server 
but no luck, it doesn't start.

What can be my misconfiguration ?

Thx for help,
Jean-Luc.

Bind failures via open ldap proxy for few users -

[shekhar . shrinivasan]

Hi,

We have setup a open ldap proxy with AD backend and we are seeing the following 
bind error for some users. The only difference in successful bind users versus 
the failed ones is the addition of square brackets "[]" in the user profile. As 
seen below for the failed users "X" is inside square brackets. Can you please 
provide some pointers on this issues. Thanks for your help as always.

For example -  
cn=Terry\2C Troy  [X],ou=X Accounts,ou=Users,ou=Users & 
Groups,dc=or,dc=myorg,dc=org --> BIND FAILED
cn=CN=Meza\, Rosalinda X,ou=X Accounts,ou=Users,ou=Users & 
Groups,dc=or,dc=myorg,dc=org --> BIND SUCCESS   

slapd[15544]: conn=3206402 op=6 BIND dn="cn=Terry\2C Troy  [X],ou=X 
Accounts,ou=Users,ou=Users & Groups,dc=or,dc=myorg,dc=org" method=128
slapd[15544]: conn=3206402 op=6 meta_back_search[3] match="OU=X 
Accounts,OU=Users,OU=Users & Groups,dc=or,dc=myorg,dc=org" err=32 (No such 
object) text="208D: NameErr: DSID-03100241, problem 2001 (NO_OBJECT), data 
0, best match of:#012#011'OU=X Accounts,OU=Users,OU=Users & 
Groups,DC=or,dc=myorg,DC=org'#012".
slapd[15544]: conn=3206402 op=6 meta_back_bind: no target for dn "cn=Terry\2C 
Troy  [X],ou=X Accounts,ou=Users,ou=Users & Groups,dc=or,dc=myorg,dc=org" (32).
slapd[15544]: conn=3206402 op=6 RESULT tag=97 err=49 text=

Re: LDAP-proxy with meta-backend

[Stefan Kania]

Am 23.02.21 um 16:50 schrieb Tilman Kranz:
> Hi Stefan,
> 
> On Sun, 2021-02-14 at 18:46 +0100, Stefan Kania wrote:
>> I would like to set up a OpenLDAP proxy with meta-backend. I have a test
>> environment with two windows 2019 ADs and one OpenLDAP-server configured
>> as proxy. [...]
>> [...]
>>
>> But now I would like to connect a client to the proxy to get the
>> entries. The ldap.conf file is the same as on the proxy. But what ever I
>> try I got now result.
>> --
>> root@proxy-client:~# ldapsearch -x -D cn=admin,dc=example,dc=de -W  -LLL
>> No such object (32)
>>
>> root@proxy-client:~# ldapsearch -x -LLL
>> No such object (32)
>> --
>>
>> What am I missing?
> 
> Did you try with the meta-DB's suffix as search base?
> 
>  ldapsearch -LLL -x -D cn=admin,dc=example,dc=de -W -b dc=example,dc=de
> 
> Kind regards,
> Tilman
Hi Tilman,
thank's for your answer but i solved the problem. I got the wrong suffix
from the customer so if the suffix of the ADs is correct the answer can
only be "no such object". I finally got it running

Stefan
> 




smime.p7s
Description: S/MIME Cryptographic Signature

Re: LDAP-proxy with meta-backend

[Tilman Kranz]

Hi Stefan,

On Sun, 2021-02-14 at 18:46 +0100, Stefan Kania wrote:
> I would like to set up a OpenLDAP proxy with meta-backend. I have a test
> environment with two windows 2019 ADs and one OpenLDAP-server configured
> as proxy. [...]
> [...]
> 
> But now I would like to connect a client to the proxy to get the
> entries. The ldap.conf file is the same as on the proxy. But what ever I
> try I got now result.
> --
> root@proxy-client:~# ldapsearch -x -D cn=admin,dc=example,dc=de -W  -LLL
> No such object (32)
> 
> root@proxy-client:~# ldapsearch -x -LLL
> No such object (32)
> --
> 
> What am I missing?

Did you try with the meta-DB's suffix as search base?

 ldapsearch -LLL -x -D cn=admin,dc=example,dc=de -W -b dc=example,dc=de

Kind regards,
Tilman

LDAP-proxy with meta-backend

[Stefan Kania]

Hi,

I would like to set up a OpenLDAP proxy with meta-backend. I have a test
environment with two windows 2019 ADs and one OpenLDAP-server configured
as proxy. At the beginning all the authentication are med with
admin-accounts, it's the first step just testing. Here is my slapd.conf:

---
Include /etc/ldap/schema/core.schema
Include /etc/ldap/schema/corba.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/duaconf.schema
include /etc/ldap/schema/dyngroup.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/java.schema
include /etc/ldap/schema/misc.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/openldap.schema
include /etc/ldap/schema/collective.schema
include /etc/ldap/schema/pmi.schema
include /etc/ldap/schema/ppolicy.schema


pidfile /var/run/slapd/slapd.pid
argsfile    /var/run/slapd/slapd.args

# Load dynamic backend modules:
modulepath  /usr/lib/ldap
moduleload  rwm.la
moduleload  back_meta.la
moduleload  back_ldap.la

loglevel 4095

###
# MDB database definitions
###

database meta
suffix "dc=example,dc=de"
rootdn "cn=admin,dc=example,dc=de"
rootpw secret

uri "ldap://192.168.56.201/ou=firma-01,dc=example,dc=de;
readonly yes
lastmod off
suffixmassage "ou=firma-01,dc=example,dc=de"
"ou=firma-01,dc=dom01,dc=example,dc=net"
map attribute uid sAMAccountName
idassert-bind bindmethod=simple
    binddn="cn=administrator,cn=Users,dc=dom01,dc=example,dc=net"
    credentials="Passw0rd"
idassert-authzFrom "*"

uri "ldap://192.168.56.202/ou=firma-02,dc=example,dc=de;
readonly yes
lastmod  off
suffixmassage "ou=firma-02,dc=example,dc=de"
"ou=firma-02,dc=dom02,dc=example,dc=com"
map attribute uid sAMAccountName
idassert-bind bindmethod=simple
  binddn="CN=Administrator,CN=Users,DC=dom02,dc=example,DC=com"
  credentials="Passw0rd"
idassert-authzFrom "*"
---

on my proxy I can do a "ldapsearch -x " and I can see all the wanted
entries from both ADs. This is my ldap.conf on the proxy:
---
BASE dc=example,dc=de
URI ldap://192.168.56.210
---
192.168.56.210 is my proxy.

But now I would like to connect a client to the proxy to get the
entries. The ldap.conf file is the same as on the proxy. But what ever I
try I got now result.
--
root@proxy-client:~# ldapsearch -x -D cn=admin,dc=example,dc=de -W  -LLL
No such object (32)

root@proxy-client:~# ldapsearch -x -LLL
No such object (32)
--

What am I missing?

Thank's for any help

Stefan





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Antw: [EXT] LDAP proxy backend does not drop idle connections

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 01.12.2020 um 21:15 in
Nachricht <8A3F8DDDE068E83FD6E7561D@[192.168.1.156]>:

> 
> ‑‑On Tuesday, December 1, 2020 8:20 AM + Tero Saarni 
>  wrote:
> 
>> I tested only with recent releases and git master, not with very old
>> versions since they are bit harder to compile with modern distros.  But I
>> have compared the code from a random historical release.  It seems to be
>> the same as today.
>>
>> Quanah also replied "back‑ldap likely needs a task to check for idle
>> connections" so I'm bit puzzled if this has worked previously.  Maybe
>> ldap_back_getconn() can be called in some other scenario also without
>> having traffic from client towards the proxy?
> 
> Howard specifically said the following while I was discussing with him:
> 
> ‑‑‑
> The current idletimeout code in there is pretty useless. It checks the 
> timestamp the next time a conn is referenced, so if it's never referenced, 
> the idle timeout never has any effect.  If the conn *is* referenced ‑ you 
> should just use the conn, instead of killing it.
> ‑‑‑
> 
> So generally, if a load balancer or other traffic shaper is in use that 
> closes connections silently, set a keepalive.  Overall the idle timeout has

> little purpose for back‑ldap connections.

Hi!

Having written an app myself that had the same problem, I just added a timeout
thread that watches the time of last activity for each registered connection
(which is a thread in my app). If the last activity is too old, the connection
is terminated.
In OpenLDAP the monitor database shows there is a
monitorConnectionActivityTime, so I can imagine this could be fixed ;-)

Regards,
Ulrich

> 
> 
> Regards,
> Quanah
> 
> 
> 
> ‑‑
> 
> Quanah Gibson‑Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> 

Re: Antw: [EXT] LDAP proxy backend does not drop idle connections

[Tero Saarni]

Howard Chu wrote:
>> So generally, if a load balancer or other traffic shaper is in use that 
>> closes connections silently, set a keepalive.  Overall the idle timeout has 
>> little
>> purpose for back-ldap connections.
>
> Thinking about it some more, there is a valid use case - if you know that
> a firewall will silently close connections after some time, you can set
> the idletimeout to a shorter time to prevent it from trying to use a
> connection that would have died.

>From what I can see, proxy will still try to use the connection that has died. 
> ldap_back_getconn() just marks the connection for deletion.  From the comment 
>in bind.c:

/* let it be used, but taint/delete it so that no-one else can look it up any 
further */

Since the TCP connection does not exist, the remote server will just respond 
TCP RST and thanks to retry fix #9400 a new connection will be created 
immediately and the operation will succeed.

I wonder if anyone is already looking at adding a task to check for idle 
connections?  If not, I could try, though I'm unsure if that would result in 
anything and I would certainly need some hand-holding :)

--
Tero

Re: Antw: [EXT] LDAP proxy backend does not drop idle connections

[Howard Chu]

Quanah Gibson-Mount wrote:
> 
> 
> --On Tuesday, December 1, 2020 8:20 AM + Tero Saarni 
>  wrote:
> 
>> I tested only with recent releases and git master, not with very old
>> versions since they are bit harder to compile with modern distros.  But I
>> have compared the code from a random historical release.  It seems to be
>> the same as today.
>>
>> Quanah also replied "back-ldap likely needs a task to check for idle
>> connections" so I'm bit puzzled if this has worked previously.  Maybe
>> ldap_back_getconn() can be called in some other scenario also without
>> having traffic from client towards the proxy?
> 
> Howard specifically said the following while I was discussing with him:
> 
> ---
> The current idletimeout code in there is pretty useless. It checks the 
> timestamp the next time a conn is referenced, so if it's never referenced, 
> the idle
> timeout never has any effect.  If the conn *is* referenced - you should just 
> use the conn, instead of killing it.
> ---
> 
> So generally, if a load balancer or other traffic shaper is in use that 
> closes connections silently, set a keepalive.  Overall the idle timeout has 
> little
> purpose for back-ldap connections.

Thinking about it some more, there is a valid use case - if you know that
a firewall will silently close connections after some time, you can set
the idletimeout to a shorter time to prevent it from trying to use a
connection that would have died.

-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: Antw: [EXT] LDAP proxy backend does not drop idle connections

[Quanah Gibson-Mount]

--On Tuesday, December 1, 2020 8:20 AM + Tero Saarni 
 wrote:



I tested only with recent releases and git master, not with very old
versions since they are bit harder to compile with modern distros.  But I
have compared the code from a random historical release.  It seems to be
the same as today.

Quanah also replied "back-ldap likely needs a task to check for idle
connections" so I'm bit puzzled if this has worked previously.  Maybe
ldap_back_getconn() can be called in some other scenario also without
having traffic from client towards the proxy?


Howard specifically said the following while I was discussing with him:

---
The current idletimeout code in there is pretty useless. It checks the 
timestamp the next time a conn is referenced, so if it's never referenced, 
the idle timeout never has any effect.  If the conn *is* referenced - you 
should just use the conn, instead of killing it.

---

So generally, if a load balancer or other traffic shaper is in use that 
closes connections silently, set a keepalive.  Overall the idle timeout has 
little purpose for back-ldap connections.



Regards,
Quanah



--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: Antw: [EXT] LDAP proxy backend does not drop idle connections

[Tero Saarni]

Ulrich Windl wrote:
> OK, I don't know about the allowable range of the timeout and the scale of
> problem you are having, but we had idle connections that were inactive for 
> days
> or weeks, so we set the timeout to one day. That worked.
>
> Considering that a closed connection may stay around for several seconds, a
> timeout of 5 seconds seems extremely short to me, however.

Sure, it is short and it was just for my test case, not for production.  The 
original problem was found with 5 minute idle timeout, which we wanted to use 
for production.

However, I do not see any evidence in the code that it would treat these 
differently, and what led me to ask here is that I did not manage to spot any 
code that would set timers that even could expire in idle conditions.  I wonder 
if something else have happening within the one-day mark which then triggers 
disconnect?

--
Tero

From: Ulrich Windl 
Sent: Tuesday, December 1, 2020 11:08
To: Tero Saarni ; openldap-technical@openldap.org 

Subject: Re: Antw: [EXT] LDAP proxy backend does not drop idle connections

>>> Tero Saarni  schrieb am 01.12.2020 um 09:20 in
Nachricht
:

> Ulrich Windl wrote:
>> It may depend on the version, but for us it worked. How did you check that

> it doesn't work?
>
> I have tested by setting up "idassert‑bind" configuration which results in
> cached connection.  I set idle‑timeout to 5 (seconds).  I did packet capture

> with Wireshark to see that the connection is still up.

OK, I don't know about the allowable range of the timeout and the scale of
problem you are having, but we had idle connections that were inactive for days
or weeks, so we set the timeout to one day. That worked.

Considering that a closed connection may stay around for several seconds, a
timeout of 5 seconds seems extremely short to me, however.

Regards,
Ulrich

>
> To test I have executed:
>
> 1. execute search from client
> 2. wait for the duration of idle‑timeout to expire
> 3. observe from LDAP protocol capture that the connection is still up
>
>
> Secondly I tested:
>
> 1. execute search from client
> 2. wait for the duration of idle‑timeout to expire
> 3. execute search from client again
> 4. observe that unbind and TCP connection tear down happened immediately
> after step 3
>
>
> I also tested that search before idle timeout extends the timeout:
>
> 1. execute search from client
> 2. execute search from client again before idle‑timeout
> 3. observe that nothing happens
> 4. execute search after idle‑timeout has passed when measuring the time from

> step 2.
> 5. observe that unbind and TCP connection tear down happened immediately
> after step 4
>
>
> I also tried to find the function within back‑ldap code that compares the
> idle timeout value.  This is the only place in the code I found idle timeout

> being compared
>
https://git.openldap.org/openldap/openldap/‑/blob/master/servers/slapd/back‑l

> dap/bind.c#L1133 and it is in function ldap_back_getconn().  I attached gdb

> to slapd and breakpoint to the function.  Debugger shows that it does not
> seem to get called unless there is activity from client to proxy i.e. not
> during connection from proxy to remote LDAP remains idle.
>
> I tested only with recent releases and git master, not with very old
> versions since they are bit harder to compile with modern distros.  But I
> have compared the code from a random historical release.  It seems to be the

> same as today.
>
> Quanah also replied "back‑ldap likely needs a task to check for idle
> connections" so I'm bit puzzled if this has worked previously.  Maybe
> ldap_back_getconn() can be called in some other scenario also without having

> traffic from client towards the proxy?
>
> ‑‑
> Tero

Re: Antw: [EXT] LDAP proxy backend does not drop idle connections

[Ulrich Windl]

>>> Tero Saarni  schrieb am 01.12.2020 um 09:20 in
Nachricht
:

> Ulrich Windl wrote:
>> It may depend on the version, but for us it worked. How did you check that

> it doesn't work?
> 
> I have tested by setting up "idassert‑bind" configuration which results in 
> cached connection.  I set idle‑timeout to 5 (seconds).  I did packet capture

> with Wireshark to see that the connection is still up.

OK, I don't know about the allowable range of the timeout and the scale of
problem you are having, but we had idle connections that were inactive for days
or weeks, so we set the timeout to one day. That worked.

Considering that a closed connection may stay around for several seconds, a
timeout of 5 seconds seems extremely short to me, however.

Regards,
Ulrich

> 
> To test I have executed:
> 
> 1. execute search from client
> 2. wait for the duration of idle‑timeout to expire
> 3. observe from LDAP protocol capture that the connection is still up 
> 
> 
> Secondly I tested:
> 
> 1. execute search from client
> 2. wait for the duration of idle‑timeout to expire
> 3. execute search from client again
> 4. observe that unbind and TCP connection tear down happened immediately 
> after step 3
> 
> 
> I also tested that search before idle timeout extends the timeout:
> 
> 1. execute search from client
> 2. execute search from client again before idle‑timeout
> 3. observe that nothing happens
> 4. execute search after idle‑timeout has passed when measuring the time from

> step 2.
> 5. observe that unbind and TCP connection tear down happened immediately 
> after step 4
> 
> 
> I also tried to find the function within back‑ldap code that compares the 
> idle timeout value.  This is the only place in the code I found idle timeout

> being compared 
>
https://git.openldap.org/openldap/openldap/‑/blob/master/servers/slapd/back‑l

> dap/bind.c#L1133 and it is in function ldap_back_getconn().  I attached gdb

> to slapd and breakpoint to the function.  Debugger shows that it does not 
> seem to get called unless there is activity from client to proxy i.e. not 
> during connection from proxy to remote LDAP remains idle. 
> 
> I tested only with recent releases and git master, not with very old 
> versions since they are bit harder to compile with modern distros.  But I 
> have compared the code from a random historical release.  It seems to be the

> same as today.
> 
> Quanah also replied "back‑ldap likely needs a task to check for idle 
> connections" so I'm bit puzzled if this has worked previously.  Maybe 
> ldap_back_getconn() can be called in some other scenario also without having

> traffic from client towards the proxy?
> 
> ‑‑ 
> Tero

Re: Antw: [EXT] LDAP proxy backend does not drop idle connections

[Tero Saarni]

Ulrich Windl wrote:
> It may depend on the version, but for us it worked. How did you check that it 
> doesn't work?

I have tested by setting up "idassert-bind" configuration which results in 
cached connection.  I set idle-timeout to 5 (seconds).  I did packet capture 
with Wireshark to see that the connection is still up.

To test I have executed:

1. execute search from client
2. wait for the duration of idle-timeout to expire
3. observe from LDAP protocol capture that the connection is still up 


Secondly I tested:

1. execute search from client
2. wait for the duration of idle-timeout to expire
3. execute search from client again
4. observe that unbind and TCP connection tear down happened immediately after 
step 3


I also tested that search before idle timeout extends the timeout:

1. execute search from client
2. execute search from client again before idle-timeout
3. observe that nothing happens
4. execute search after idle-timeout has passed when measuring the time from 
step 2.
5. observe that unbind and TCP connection tear down happened immediately after 
step 4


I also tried to find the function within back-ldap code that compares the idle 
timeout value.  This is the only place in the code I found idle timeout being 
compared 
https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/back-ldap/bind.c#L1133
 and it is in function ldap_back_getconn().  I attached gdb to slapd and 
breakpoint to the function.  Debugger shows that it does not seem to get called 
unless there is activity from client to proxy i.e. not during connection from 
proxy to remote LDAP remains idle. 

I tested only with recent releases and git master, not with very old versions 
since they are bit harder to compile with modern distros.  But I have compared 
the code from a random historical release.  It seems to be the same as today.

Quanah also replied "back-ldap likely needs a task to check for idle 
connections" so I'm bit puzzled if this has worked previously.  Maybe 
ldap_back_getconn() can be called in some other scenario also without having 
traffic from client towards the proxy?

-- 
Tero

Antw: [EXT] LDAP proxy backend does not drop idle connections

[Ulrich Windl]

>>> "Tero Saarni"  schrieb am 26.11.2020 um 09:48 in
Nachricht <20201126084819.798.54...@hypatia.openldap.org>:
> Hi,
> 
> I understood from slapd-ldap(5) description of "idle-timeout" that cached
> connections towards remote LDAP server would be automatically dropped after
>  seconds.  
> 
> Problem: cached connections that are idle do not get dropped.

It may depend on the version, but for us it worked. How did you check that it 
doesn't work?

> 
> Questions:
> 
> (1) Is this expected? 
> 
> (2) Are idle connections kept due to limitation in the implementation: 
> when connection is idle, back-ldap does not have a trigger that could be 
> used 
> to drop idle connections?
> 
> Background:
> 
> While experimenting with this, it seems that idle timeout is only checked 
> when
> there is new activity towards the cached connection i.e. connection needs to
> become active before idle timeout is checked.  If the connection just 
> remains
> idle, nothing will happen.
> 
> I'm trying to study the timeout handling in back-ldap code, and I believe I
> found relevant code at the end of ldap_back_getconn() in bind.c.  It will 
> eventually trigger unbind and disconnect, but only when new activity happens
> after the idle period is reached.  I did not find other paths that could
> trigger unbind of cached connection.
> 
> -- 
> Tero

Re: LDAP proxy backend does not drop idle connections

[Quanah Gibson-Mount]

--On Monday, November 30, 2020 10:19 AM -0800 Quanah Gibson-Mount 
 wrote:





--On Thursday, November 26, 2020 8:48 AM + Tero Saarni
 wrote:


Hi,

I understood from slapd-ldap(5) description of "idle-timeout" that cached
connections towards remote LDAP server would be automatically dropped
after  seconds.

Problem: cached connections that are idle do not get dropped.


General note: This was a bug that has been fixed and will be in the next
OpenLDAP release (ITS#9400).


Err, sorry, ITS#9400 was for retry.

This is ITS#9197, still needs fixing (back-ldap likely needs a task to 
check for idle connections).


--Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: LDAP proxy backend does not drop idle connections

[Quanah Gibson-Mount]

--On Thursday, November 26, 2020 8:48 AM + Tero Saarni 
 wrote:



Hi,

I understood from slapd-ldap(5) description of "idle-timeout" that cached
connections towards remote LDAP server would be automatically dropped
after  seconds.

Problem: cached connections that are idle do not get dropped.


General note: This was a bug that has been fixed and will be in the next 
OpenLDAP release (ITS#9400).


--Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

LDAP proxy backend does not drop idle connections

[Tero Saarni]

Hi,

I understood from slapd-ldap(5) description of "idle-timeout" that cached
connections towards remote LDAP server would be automatically dropped after
 seconds.  

Problem: cached connections that are idle do not get dropped.

Questions:

(1) Is this expected? 

(2) Are idle connections kept due to limitation in the implementation: 
when connection is idle, back-ldap does not have a trigger that could be used 
to drop idle connections?

Background:

While experimenting with this, it seems that idle timeout is only checked when
there is new activity towards the cached connection i.e. connection needs to
become active before idle timeout is checked.  If the connection just remains
idle, nothing will happen.

I'm trying to study the timeout handling in back-ldap code, and I believe I
found relevant code at the end of ldap_back_getconn() in bind.c.  It will 
eventually trigger unbind and disconnect, but only when new activity happens
after the idle period is reached.  I did not find other paths that could
trigger unbind of cached connection.

-- 
Tero

Help for setting-up an ldap-proxy

[li...@zxt10d.de]

Hello,

I'm pretty new to this list, and maybe/hopefully someone could help ...

I work at a chair at a german university, and we would like to use the 
central AD of theat university for our chair - by using a ldap-proxy 
system, so that there's only one connection to the central AD, and not 
~70 (all of our computers, etc.).

I can search the AD by using this (modified) command:
ldapsearch -LLL "(cn=FIRSTNAME LASTNAME)" -H ldaps://ldap.UNIVERSITY.de 
-b dc=university,dc=de -D cn=special,ou=group,dc=university,dc=de -W


For locally installed applications I can use this /etc/pam_ldap.conf:
uri ldaps://ldap.university.de
host ldap.university.de
base ou=group,ou=hosts,dc=university,dc=de
ldap_version 3
binddn cn=special,ou=group,dc=university,dc=de
bindpw password
pam_password crypt
ssl start_tls
ssl on

To set-up the local ldap-proxy, I tried to follow this description, but 
it won't work (and I guess its not realy correct, as the config-file is 
there twice):

https://doc.owncloud.com/server/admin_manual/configuration/ldap/ldap_proxy_cache_server_setup.html
When running "slaptest -f /etc/ldap/slapd.conf" I get these errors:
5ebd3ec5 /etc/ldap/slapd.conf: line 102: warning, source attributeType 
'dn' should be defined in schema

5ebd3ec5 PROXIED attributeDescription "DN" inserted.
5ebd3ec5 hdb_db_open: warning - no DB_CONFIG file found in directory 
/var/lib/ldap: (2).

Expect poor performance for suffix "ou=group,ou=hosts,dc=university,dc=de".
5ebd3ec5 hdb_db_open: database "ou=lsafp,ou=hosts,dc=university,dc=de": 
db_open(/var/lib/ldap/id2entry.bdb) failed: No such file or directory (2).
5ebd3ec5 backend_startup_one (type=hdb, 
suffix="ou=group,ou=hosts,dc=university,dc=de"): bi_db_open failed! (2)
5ebd3ec5 backend_startup_one (type=ldap, 
suffix="ou=group,ou=hosts,dc=university,dc=de"): bi_db_open failed! (2)

slap_startup failed (test would succeed using the -u switch)

Now my questions:
- where and how to put the data to do a query versus the central AD? 
(binddn & bindpw part)
- where to define the local ldap-database? (I guess that has to be 
created an will be filled automatically...?)


The system I'm using is a Debian 10.4 one.
slapd -V:
@(#) $OpenLDAP: slapd  (Apr 20 2020 18:19:54) $
Debian OpenLDAP Maintainers 



Sorry, english is not my native language ...

Thanks a lot for reading! ;)

Cheers,
Torsten

Re: not getting ldap proxy to AD working... please help

[Drikus Brits]

thanks, i'll try that.

On Wed, Oct 2, 2019 at 5:40 PM Dieter Klünter  wrote:
>
> Am Tue, 1 Oct 2019 18:35:16 +1000
> schrieb Drikus Brits :
>
> > Heya experts.
> >
> > I need some guidance. I am having difficulty deploying my
> > requirements. I need to deploy a couple of U18 servers/containers.
> > These servers all needs to authenticate with LDAP accounts that is
> > active and in a certain group on AD, but the IT team doesn't want to
> > allow IPs and ports from servers across the network and so I have to
> > set up a ldap proxy that will speak to AD on behalf of all the other
> > machines eg jumphost. The windows AD cannot be modified to add extra
> > groups eg posixAccount, uidNumber, gidNumber, loginShell,
> > homeDirectory etc.
> >
> > I can successfully run a ldapsearch from the proxy machine to the AD
> > and query a user based on the sAMAccountName and am getting successful
> > results back from AD. However, when the jumphost (proxy set as ldap
> > authhost) tries to authenticate with the proxy, then I see the request
> > coming in from the jumphost to ldap proxy, and see the ldap proxy
> > sending the request to the windows AD, but it forwards the same
> > details as it sent to the local to the remote; eg
> > objectClass=posixAccount, uid=testuser. This doesn't exist on the AD
> > and so returns no result. I've tried to do rewrites and according to
> > the packet captures, saw that the rewrite was working somewhat. I was
> > able to rewrite uid to sAMAccountName, but not sure what to rewrite
> > the posixAccount to
> >
> > So ideally what I'd like to see happening is that :
> >
> >  1) user logs onto jumphost with username "testuser"
> > 2) user lookup & authentication goes to ldap_proxy
> > 3) ldap_proxy send request to AD to check if user exists and is active
> > and match against the password
> > 4) upon username=exists, is=active, password=ok return the result to
> > ldap_proxy 5) ldap_proxy returns the necessary to jumphost eg;
> > a) posixAccount
> > b) homeDirectory
> > c) loginShell
> >
> > I've tried following a couple of different options to make it work,
> > but right now I'm not sure which option is the correct one eg; (mdb
> > config + ldap backend) or (meta + ldap backend ) or ( ldap +  pcache )
> > and whether to rewrite or not to rewrite. From my understanding, I am
> > looking for something that sounds like a meta setup that combines the
> > local and remote data...is my understanding correct?
> >
> > I've seen this working at a previous employer but not sure whether
> > their AD was modified and that is why it was working there, or whether
> > the solution is workable without having to force the IT guys' hand and
> > add extra vars..
> >
> > I've scouted the openldap mailing list as well for answers but there
> > is a plethora of no replies and some replies that somewhat matches
> > what I'm trying to do...
> >
> > Any guidance would be super appreciated
> >
> Create a private schema based on AD attribute types and load this
> schema to ldap proxy.
>
> -Dieter
>
> --
> Dieter Klünter | Systemberatung
> http://sys4.de
> GPG Key ID: E9ED159B
> 53°37'09,95"N
> 10°08'02,42"E
>

Re: not getting ldap proxy to AD working... please help

[Dieter Klünter]

Am Tue, 1 Oct 2019 18:35:16 +1000
schrieb Drikus Brits :

> Heya experts.
> 
> I need some guidance. I am having difficulty deploying my
> requirements. I need to deploy a couple of U18 servers/containers.
> These servers all needs to authenticate with LDAP accounts that is
> active and in a certain group on AD, but the IT team doesn't want to
> allow IPs and ports from servers across the network and so I have to
> set up a ldap proxy that will speak to AD on behalf of all the other
> machines eg jumphost. The windows AD cannot be modified to add extra
> groups eg posixAccount, uidNumber, gidNumber, loginShell,
> homeDirectory etc.
> 
> I can successfully run a ldapsearch from the proxy machine to the AD
> and query a user based on the sAMAccountName and am getting successful
> results back from AD. However, when the jumphost (proxy set as ldap
> authhost) tries to authenticate with the proxy, then I see the request
> coming in from the jumphost to ldap proxy, and see the ldap proxy
> sending the request to the windows AD, but it forwards the same
> details as it sent to the local to the remote; eg
> objectClass=posixAccount, uid=testuser. This doesn't exist on the AD
> and so returns no result. I've tried to do rewrites and according to
> the packet captures, saw that the rewrite was working somewhat. I was
> able to rewrite uid to sAMAccountName, but not sure what to rewrite
> the posixAccount to
> 
> So ideally what I'd like to see happening is that :
> 
>  1) user logs onto jumphost with username "testuser"
> 2) user lookup & authentication goes to ldap_proxy
> 3) ldap_proxy send request to AD to check if user exists and is active
> and match against the password
> 4) upon username=exists, is=active, password=ok return the result to
> ldap_proxy 5) ldap_proxy returns the necessary to jumphost eg;
> a) posixAccount
> b) homeDirectory
> c) loginShell
> 
> I've tried following a couple of different options to make it work,
> but right now I'm not sure which option is the correct one eg; (mdb
> config + ldap backend) or (meta + ldap backend ) or ( ldap +  pcache )
> and whether to rewrite or not to rewrite. From my understanding, I am
> looking for something that sounds like a meta setup that combines the
> local and remote data...is my understanding correct?
> 
> I've seen this working at a previous employer but not sure whether
> their AD was modified and that is why it was working there, or whether
> the solution is workable without having to force the IT guys' hand and
> add extra vars..
> 
> I've scouted the openldap mailing list as well for answers but there
> is a plethora of no replies and some replies that somewhat matches
> what I'm trying to do...
> 
> Any guidance would be super appreciated
> 
Create a private schema based on AD attribute types and load this
schema to ldap proxy.

-Dieter

-- 
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E

Re: Add supportedExtensions to LDAP proxy

[Philip Brusten]

On 9/01/2019 15:28, Howard Chu wrote:

It's not that simple. Advertising a supportedExtension in the rootDSE implies 
that the
entire server supports them. slapd allows multiple backends to operate at once, 
and what
you're talking about would only be valid for a single specific back-ldap 
instance.

The standard format for extended ops doesn't include a DN, and slapd uses the 
DN to
determine which backend should process an incoming op. So there's no generic way
for slapd to correctly forward an incoming exop to the correct backend, or the 
proxy backend.
Every op must be handled explicitly and must be at least parsed in order for 
slapd to
be able to route it.


Okay, that makes sense. Thank you for the explanation

Philip

Re: Add supportedExtensions to LDAP proxy

[Philip Brusten]

On 7/01/2019 17:59, Howard Chu wrote:

Philip Brusten wrote:

On 3/01/2019 18:09, Howard Chu wrote:

Philip Brusten wrote:

Is there a way to allow these extensions on the proxy?

Write yourself a dynamic module to register those extension OIDs in back-ldap.

So there is no current way to support these extensions via configuration?

Extensions, by their very nature, require code to implement them. So no, you 
cannot
configure new functionality into existence without writing your own module.
In the context of a proxy this is a big overhead. IMHO this should be 
possible via configuration in case of an LDAP-proxy. It just needs to 
allow the extension to passthrough, not to implement the logic behind 
it, or is this too short-sighted?

Re: Add supportedExtensions to LDAP proxy

[Howard Chu]

Philip Brusten wrote:
> 
> On 7/01/2019 17:59, Howard Chu wrote:
>> Philip Brusten wrote:
>>> On 3/01/2019 18:09, Howard Chu wrote:
>>>> Philip Brusten wrote:
>>>>> Is there a way to allow these extensions on the proxy?
>>>> Write yourself a dynamic module to register those extension OIDs in 
>>>> back-ldap.
>>> So there is no current way to support these extensions via configuration?
>> Extensions, by their very nature, require code to implement them. So no, you 
>> cannot
>> configure new functionality into existence without writing your own module.
> In the context of a proxy this is a big overhead. IMHO this should be 
> possible via configuration in case of an LDAP-proxy. It just needs to allow 
> the extension
> to passthrough, not to implement the logic behind it, or is this too 
> short-sighted?

It's not that simple. Advertising a supportedExtension in the rootDSE implies 
that the
entire server supports them. slapd allows multiple backends to operate at once, 
and what
you're talking about would only be valid for a single specific back-ldap 
instance.

The standard format for extended ops doesn't include a DN, and slapd uses the 
DN to
determine which backend should process an incoming op. So there's no generic way
for slapd to correctly forward an incoming exop to the correct backend, or the 
proxy backend.
Every op must be handled explicitly and must be at least parsed in order for 
slapd to
be able to route it.

-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: Add supportedExtensions to LDAP proxy

[Philip Brusten]

On 3/01/2019 18:09, Howard Chu wrote:

Philip Brusten wrote:

Is there a way to allow these extensions on the proxy?

Write yourself a dynamic module to register those extension OIDs in back-ldap.


So there is no current way to support these extensions via configuration?

Re: Add supportedExtensions to LDAP proxy

[Howard Chu]

Philip Brusten wrote:
> 
> On 3/01/2019 18:09, Howard Chu wrote:
>> Philip Brusten wrote:
>>> Is there a way to allow these extensions on the proxy?
>> Write yourself a dynamic module to register those extension OIDs in 
>> back-ldap.
> 
> So there is no current way to support these extensions via configuration?

Extensions, by their very nature, require code to implement them. So no, you 
cannot
configure new functionality into existence without writing your own module.

-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: Add supportedExtensions to LDAP proxy

[Howard Chu]

Philip Brusten wrote:
> Hi
> 
> We have set up an LDAP proxy (slapd-ldap) in front of a NetIQ eDirectory.
> 
> The LDAP-client  which connects to the proxy uses an extended operation, but 
> the request fails because the proxy is not aware of this extension:
> 
> do_extended: unsupported operation "2.16.840.1.113719.1.39.42.100
> RESULT tag=120 err=2 text=unsupported extended operation
> 
> # ldapsearch -H ldaps://proxy:port -b '' -s base -D  -W -LLL 
> supportedExtension
> Enter LDAP Password:
> dn:
> supportedExtension: 1.3.6.1.4.1.1466.20037
> supportedExtension: 1.3.6.1.4.1.4203.1.11.1
> supportedExtension: 1.3.6.1.4.1.4203.1.11.3
> supportedExtension: 1.3.6.1.1.8
> 
> Whereas the NetIQ eDirectory back-end supports lots of custom NetIQ 
> extensions:
> 
> # ldapsearch -H ldaps://backend:port -b '' -s base -D  -W -LLL 
> supportedExtension
> Enter LDAP Password:
> dn:
> supportedExtension: 2.16.840.1.113719.1.39.42.100.1

> Is there a way to allow these extensions on the proxy?

Write yourself a dynamic module to register those extension OIDs in back-ldap.

-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: Add supportedExtensions to LDAP proxy

[Quanah Gibson-Mount]

--On Thursday, January 03, 2019 3:15 PM +0100 Philip Brusten 
 wrote:



Hi

We have set up an LDAP proxy (slapd-ldap) in front of a NetIQ eDirectory.

The LDAP-client  which connects to the proxy uses an extended operation,
but the request fails because the proxy is not aware of this extension:

Is there a way to allow these extensions on the proxy?


Hi Philip,

Is this perhaps ITS#8845?  It might be worth seeing if 
c29542c41885b56066c66046ca1f690251265c09 resolves the issue.


<https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=c29542c41885b56066c66046ca1f690251265c09;hp=8ccb3d4e1b455a0eef48a7abc8b10e546244ea9d>

Regards,
Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>

Add supportedExtensions to LDAP proxy

[Philip Brusten]

Hi

We have set up an LDAP proxy (slapd-ldap) in front of a NetIQ eDirectory.

The LDAP-client  which connects to the proxy uses an extended operation, 
but the request fails because the proxy is not aware of this extension:


do_extended: unsupported operation "2.16.840.1.113719.1.39.42.100
RESULT tag=120 err=2 text=unsupported extended operation

# ldapsearch -H ldaps://proxy:port -b '' -s base -D  -W -LLL 
supportedExtension

Enter LDAP Password:
dn:
supportedExtension: 1.3.6.1.4.1.1466.20037
supportedExtension: 1.3.6.1.4.1.4203.1.11.1
supportedExtension: 1.3.6.1.4.1.4203.1.11.3
supportedExtension: 1.3.6.1.1.8

Whereas the NetIQ eDirectory back-end supports lots of custom NetIQ 
extensions:


# ldapsearch -H ldaps://backend:port -b '' -s base -D  -W -LLL 
supportedExtension

Enter LDAP Password:
dn:
supportedExtension: 2.16.840.1.113719.1.39.42.100.1
supportedExtension: 2.16.840.1.113719.1.39.42.100.3
supportedExtension: 2.16.840.1.113719.1.39.42.100.5
supportedExtension: 2.16.840.1.113719.1.39.42.100.7
supportedExtension: 2.16.840.1.113719.1.39.42.100.9
supportedExtension: 2.16.840.1.113719.1.39.42.100.11
supportedExtension: 2.16.840.1.113719.1.39.42.100.13
supportedExtension: 2.16.840.1.113719.1.39.42.100.15
supportedExtension: 2.16.840.1.113719.1.39.42.100.17
supportedExtension: 2.16.840.1.113719.1.39.42.100.19
supportedExtension: 2.16.840.1.113719.1.39.42.100.21
supportedExtension: 2.16.840.1.113719.1.39.42.100.23
supportedExtension: 2.16.840.1.113719.1.39.42.100.25
supportedExtension: 2.16.840.1.113719.1.39.42.100.27
supportedExtension: 1.3.6.1.4.1.4203.1.11.1
supportedExtension: 2.16.840.1.113719.1.39.42.100.29
supportedExtension: 2.16.840.1.113719.1.14.100.1
supportedExtension: 2.16.840.1.113719.1.14.100.3
supportedExtension: 2.16.840.1.113719.1.14.100.5
supportedExtension: 2.16.840.1.113719.1.14.100.7
supportedExtension: 2.16.840.1.113719.1.14.100.9
supportedExtension: 2.16.840.1.113719.1.14.100.11
supportedExtension: 2.16.840.1.113719.1.14.100.13
supportedExtension: 2.16.840.1.113719.1.14.100.15
supportedExtension: 2.16.840.1.113719.1.14.100.17
supportedExtension: 2.16.840.1.113719.1.14.100.21
supportedExtension: 2.16.840.1.113719.1.14.100.23
supportedExtension: 2.16.840.1.113719.1.14.100.25
supportedExtension: 2.16.840.1.113719.1.14.100.27
supportedExtension: 2.16.840.1.113719.1.14.100.29
supportedExtension: 2.16.840.1.113719.1.14.100.31
supportedExtension: 2.16.840.1.113719.1.14.100.33
supportedExtension: 2.16.840.1.113719.1.14.100.35
supportedExtension: 2.16.840.1.113719.1.14.100.37
supportedExtension: 2.16.840.1.113719.1.14.100.39
supportedExtension: 2.16.840.1.113719.1.14.100.41
supportedExtension: 2.16.840.1.113719.1.14.100.43
supportedExtension: 2.16.840.1.113719.1.14.100.45
supportedExtension: 2.16.840.1.113719.1.14.100.47
supportedExtension: 2.16.840.1.113719.1.14.100.49
supportedExtension: 2.16.840.1.113719.1.14.100.51
supportedExtension: 2.16.840.1.113719.1.14.100.53
supportedExtension: 2.16.840.1.113719.1.14.100.55
supportedExtension: 2.16.840.1.113719.1.14.100.57
supportedExtension: 2.16.840.1.113719.1.14.100.59
supportedExtension: 2.16.840.1.113719.1.14.100.61
supportedExtension: 2.16.840.1.113719.1.14.100.63
supportedExtension: 2.16.840.1.113719.1.14.100.65
supportedExtension: 2.16.840.1.113719.1.14.100.67
supportedExtension: 2.16.840.1.113719.1.14.100.69
supportedExtension: 2.16.840.1.113719.1.14.100.71
supportedExtension: 2.16.840.1.113719.1.14.100.73
supportedExtension: 2.16.840.1.113719.1.14.100.75
supportedExtension: 2.16.840.1.113719.1.14.100.77
supportedExtension: 2.16.840.1.113719.1.14.100.79
supportedExtension: 2.16.840.1.113719.1.14.100.81
supportedExtension: 2.16.840.1.113719.1.14.100.19
supportedExtension: 2.16.840.1.113719.1.14.100.83
supportedExtension: 2.16.840.1.113719.1.14.100.85
supportedExtension: 2.16.840.1.113719.1.14.100.87
supportedExtension: 2.16.840.1.113719.1.14.100.89
supportedExtension: 2.16.840.1.113719.1.14.100.91
supportedExtension: 2.16.840.1.113719.1.14.100.93
supportedExtension: 2.16.840.1.113719.1.148.100.1
supportedExtension: 2.16.840.1.113719.1.148.100.3
supportedExtension: 2.16.840.1.113719.1.148.100.5
supportedExtension: 2.16.840.1.113719.1.148.100.7
supportedExtension: 2.16.840.1.113719.1.148.100.9
supportedExtension: 2.16.840.1.113719.1.148.100.11
supportedExtension: 2.16.840.1.113719.1.148.100.13
supportedExtension: 2.16.840.1.113719.1.148.100.15
supportedExtension: 2.16.840.1.113719.1.148.100.17
supportedExtension: 2.16.840.1.113719.1.27.100.1
supportedExtension: 2.16.840.1.113719.1.27.100.3
supportedExtension: 2.16.840.1.113719.1.27.100.5
supportedExtension: 2.16.840.1.113719.1.27.100.7
supportedExtension: 2.16.840.1.113719.1.27.100.11
supportedExtension: 2.16.840.1.113719.1.27.100.13
supportedExtension: 2.16.840.1.113719.1.27.100.15
supportedExtension: 2.16.840.1.113719.1.27.100.17
supportedExtension: 2.16.840.1.113719.1.27.100.19
supportedExtension: 2.16.840.1.113719.1.27.100.21
supportedExtension: 2.16.840.1.113719.1.27.1

LDAP proxy issue

[jason cafarelli]

note:  Apologize if this dupes; think i sent original out before i was
approved on mailing list.

A bit stuck; bear with me;  somewhat of a LDAP nubbie; sure i am missing
something simple,

Trying to get a local server to AUTH locally to its own openldap-server and
then proxy to corporate LDAP if user is not found locally.

1.  Local users work
2.  AUTH to local LDAP server works
3.  AUTH to corporate LDAP does NOT work
4.  LDAP search to corporate works when using local server (ack!?!)

user = corporate LDAP account
internal ldap = users - internal.com
corporate ldap = people - datacenter.corporate.com

note: anonymous bind is enabled on corporate.


oot@ sssd]# ldapsearch -h 127.0.0.1 -x -b
uid=user,ou=people,dc=datacenter,dc=corporate,dc=com
# extended LDIF
#
# LDAPv3
# base uid=user,ou=people,dc=datacenter,dc=corporate,dc=com with scope
subtree
# filter: (objectclass=*)
# requesting: ALL
#

# user, People, datacenter.corporate.com
dn: uid=user,ou=People,dc=datacenter,dc=corporate,dc=com
uid: user
cn:
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
shadowMax:
shadowWarning:
loginShell: /bin/bash
uidNumber:
gidNumber:
homeDirectory: /home/users/user
gecos: user
shadowLastChange: 16461

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1



Setup slap.d;

###
# database definitions
###

database bdb
suffix dc=internal,dc=com
checkpoint 1024 15
rootdn cn=adm,dc=internal,dc=com
rootpw {SSHA}a
directory /var/lib/ldap

# Indices to maintain for this database
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub

# Replicas of this database
#replogfile /var/lib/ldap/openldap-master-replog
#replica host=ldap-1.example.com:389 starttls=critical
# bindmethod=sasl saslmech=GSSAPI
# authcId=host/ldap-master.example@example.com

#proxy ldap
database ldap
suffix ou=People,dc=datacenter,dc=corp,dc=com
uri ldap://1.1.1.1:389/;

idassert-bind bindmethod=none


ldap.conf
URI ldap://127.0.0.1
BASE dc=internal,dc=com

ldap proxy to AD with local ACLs

[Meike Stone]

Hello,

it is me again regarding the ldap-backend.

As told, I've installed a openldap as proxy in a DMZ for authentication
forwarding to an Active Directoy. The Proxy is used by a VPN gateway.

That all works very well. But now, I want to protect the AD from modifying.
Only password changes from the user by self should be allowed.

But as I see or understand, ACLs from a backend are used, AFTER the
result from remote LDAP (AD) are coming back?! See second sentence
from http://www.openldap.org/faq/data/cache/532.html:

It allows the common configuration directives as suffix, which is
used to select it when a request is received by the server, *ACLs,
which are applied to search results*, size and time limits, and so on.


So is it (and how is it) possible, to switch the ldap-backend in
read only mode and only pass the the password change (modify:
DEL/ADD)?

Thanks Meike

Re: ldap proxy to AD with local ACLs

[Howard Chu]

Meike Stone wrote:

Hello,

it is me again regarding the ldap-backend.

As told, I've installed a openldap as proxy in a DMZ for authentication
forwarding to an Active Directoy. The Proxy is used by a VPN gateway.

That all works very well. But now, I want to protect the AD from modifying.
Only password changes from the user by self should be allowed.

But as I see or understand, ACLs from a backend are used, AFTER the
result from remote LDAP (AD) are coming back?! See second sentence
from http://www.openldap.org/faq/data/cache/532.html:

It allows the common configuration directives as suffix, which is
used to select it when a request is received by the server, *ACLs,
which are applied to search results*, size and time limits, and so on.



Correct. back-ldap only performs ACL checks on search responses.


So is it (and how is it) possible, to switch the ldap-backend in
read only mode and only pass the the password change (modify:
DEL/ADD)?


You could use the denyop overlay to deny all write operations. I don't know of 
any way currently to allow only passwordModify exops, it would actually allow 
all extended operations.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: ldap proxy to AD with local ACLs

[Meike Stone]

Hello,
thanks for answering ...

2015-08-06 16:24 GMT+02:00 Howard Chu h...@symas.com:
 Meike Stone wrote:

 Hello,

 it is me again regarding the ldap-backend.

 As told, I've installed a openldap as proxy in a DMZ for authentication
 forwarding to an Active Directoy. The Proxy is used by a VPN gateway.

 That all works very well. But now, I want to protect the AD from
 modifying.
 Only password changes from the user by self should be allowed.

 But as I see or understand, ACLs from a backend are used, AFTER the
 result from remote LDAP (AD) are coming back?! See second sentence
 from http://www.openldap.org/faq/data/cache/532.html:

 It allows the common configuration directives as suffix, which is
 used to select it when a request is received by the server, *ACLs,
 which are applied to search results*, size and time limits, and so on.
 


 Correct. back-ldap only performs ACL checks on search responses.

 So is it (and how is it) possible, to switch the ldap-backend in
 read only mode and only pass the the password change (modify:
 DEL/ADD)?


 You could use the denyop overlay to deny all write operations.
I found following comment to denyop:
http://www.openldap.org/faq/data/cache/1202.html
So it is possible to do this, without rebuild openldap? (my binary is
compiled without --enable-denyop=yes)


 I don't know of any way currently to allow only passwordModify exops, it 
 would actually
 allow all extended operations.

Maybe it will not work, because

Re: ldap proxy to AD with local ACLs

[Meike Stone]

sorry, wrong button ...

 I don't know of any way currently to allow only passwordModify exops, it 
 would actually
 allow all extended operations.

 Maybe it will not work, because UnicodePwd is only changeable be del+add ..


Meike

Re: ldap proxy to AD - UnicodePwd: attribute type undefined

[Meike Stone]

 Hello


 I've installed a openldap as proxy in a DMZ for authentication
 forwarding to an Active Directoy.
 The Proxy is used by a VPN gateway.

 That all works very well, but password change from client fails with
 following error:

 slapd[30661]: conn=1001 op=5 do_modify
 slapd[30661]: conn=1001 op=5 do_modify: dn
 (cn=XPTEST5,ou=Users,dc=myorg,dc=net) slapd[30661]: 
 dnPrettyNormal: cn=TEST5,ou=Users,dc=myorg,dc=net slapd[30661]: 
 dnPrettyNormal: cn=TEST5,ou=Users,dc=myorg,dc=net,
 cn=xptest5,ou=users,dc=myorg,dc=net slapd[30661]: conn=1001 op=5
 modifications: slapd[30661]:   delete: UnicodePwd
 slapd[30661]:   one value, length 26
 slapd[30661]:   add: UnicodePwd
 slapd[30661]:   one value, length 26
 slapd[30661]: conn=1001 op=5 MOD
 dn=cn=TEST5,ou=Users,dc=myorg,dc=net slapd[30661]: conn=1001 op=5
 MOD attr=UnicodePwd UnicodePwd slapd[30661]: send_ldap_result:
 conn=1001 op=5 p=3 slapd[30661]: send_ldap_result: err=17 matched=
 text=UnicodePwd: attribute type undefined
 slapd[30661]: send_ldap_response: msgid=6 tag=103 err=17
 slapd[30661]: conn=1001 op=5 RESULT tag=103 err=17 text=UnicodePwd:
 attribute type undefined
 slapd[30661]: daemon: activity on 1 descriptor
 slapd[30661]: daemon: activity on:
 slapd[30661]:
 slapd[30661]: daemon: epoll: listen=7 active_threads=0 tvp=zero
 slapd[30661]: daemon: activity on 1 descriptor
 slapd[30661]: daemon: activity on:

 As I understand, UnicodePwd is a proprietary standard MS attribute
 in AD to store the password but the RFC attribute is the userPassword.


 Is it possible, to get the proxy working to process this MOD request,
 may be that openldap proxy pass through the MOD operation with the
 attribute UnicodePwd from the VPN-gateway?
 [...]

 create a private schema with all relevant attribute types and object
 classes

Thanks, that worked!!!

Meike

Re: ldap proxy to AD - UnicodePwd: attribute type undefined

[Dieter Klünter]

Am Thu, 30 Jul 2015 14:00:06 +0200
schrieb Meike Stone meike.st...@googlemail.com:

 Hello
 
 
 I've installed a openldap as proxy in a DMZ for authentication
 forwarding to an Active Directoy.
 The Proxy is used by a VPN gateway.
 
 That all works very well, but password change from client fails with
 following error:
 
 slapd[30661]: conn=1001 op=5 do_modify
 slapd[30661]: conn=1001 op=5 do_modify: dn
 (cn=XPTEST5,ou=Users,dc=myorg,dc=net) slapd[30661]: 
 dnPrettyNormal: cn=TEST5,ou=Users,dc=myorg,dc=net slapd[30661]: 
 dnPrettyNormal: cn=TEST5,ou=Users,dc=myorg,dc=net,
 cn=xptest5,ou=users,dc=myorg,dc=net slapd[30661]: conn=1001 op=5
 modifications: slapd[30661]:   delete: UnicodePwd
 slapd[30661]:   one value, length 26
 slapd[30661]:   add: UnicodePwd
 slapd[30661]:   one value, length 26
 slapd[30661]: conn=1001 op=5 MOD
 dn=cn=TEST5,ou=Users,dc=myorg,dc=net slapd[30661]: conn=1001 op=5
 MOD attr=UnicodePwd UnicodePwd slapd[30661]: send_ldap_result:
 conn=1001 op=5 p=3 slapd[30661]: send_ldap_result: err=17 matched=
 text=UnicodePwd: attribute type undefined
 slapd[30661]: send_ldap_response: msgid=6 tag=103 err=17
 slapd[30661]: conn=1001 op=5 RESULT tag=103 err=17 text=UnicodePwd:
 attribute type undefined
 slapd[30661]: daemon: activity on 1 descriptor
 slapd[30661]: daemon: activity on:
 slapd[30661]:
 slapd[30661]: daemon: epoll: listen=7 active_threads=0 tvp=zero
 slapd[30661]: daemon: activity on 1 descriptor
 slapd[30661]: daemon: activity on:
 
 As I understand, UnicodePwd is a proprietary standard MS attribute
 in AD to store the password but the RFC attribute is the userPassword.
 
 
 Is it possible, to get the proxy working to process this MOD request,
 may be that openldap proxy pass through the MOD operation with the
 attribute UnicodePwd from the VPN-gateway?
[...]

create a private schema with all relevant attribute types and object
classes.Or get the AD schema and add it to your directories
configuration.

-Dieter

-- 
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95N
10°08'02,42E

ldap proxy to AD - UnicodePwd: attribute type undefined

[Meike Stone]

Hello


I've installed a openldap as proxy in a DMZ for authentication
forwarding to an Active Directoy.
The Proxy is used by a VPN gateway.

That all works very well, but password change from client fails with
following error:

slapd[30661]: conn=1001 op=5 do_modify
slapd[30661]: conn=1001 op=5 do_modify: dn (cn=XPTEST5,ou=Users,dc=myorg,dc=net)
slapd[30661]:  dnPrettyNormal: cn=TEST5,ou=Users,dc=myorg,dc=net
slapd[30661]:  dnPrettyNormal: cn=TEST5,ou=Users,dc=myorg,dc=net,
cn=xptest5,ou=users,dc=myorg,dc=net
slapd[30661]: conn=1001 op=5 modifications:
slapd[30661]:   delete: UnicodePwd
slapd[30661]:   one value, length 26
slapd[30661]:   add: UnicodePwd
slapd[30661]:   one value, length 26
slapd[30661]: conn=1001 op=5 MOD dn=cn=TEST5,ou=Users,dc=myorg,dc=net
slapd[30661]: conn=1001 op=5 MOD attr=UnicodePwd UnicodePwd
slapd[30661]: send_ldap_result: conn=1001 op=5 p=3
slapd[30661]: send_ldap_result: err=17 matched= text=UnicodePwd:
attribute type undefined
slapd[30661]: send_ldap_response: msgid=6 tag=103 err=17
slapd[30661]: conn=1001 op=5 RESULT tag=103 err=17 text=UnicodePwd:
attribute type undefined
slapd[30661]: daemon: activity on 1 descriptor
slapd[30661]: daemon: activity on:
slapd[30661]:
slapd[30661]: daemon: epoll: listen=7 active_threads=0 tvp=zero
slapd[30661]: daemon: activity on 1 descriptor
slapd[30661]: daemon: activity on:

As I understand, UnicodePwd is a proprietary standard MS attribute
in AD to store the password but the RFC attribute is the userPassword.


Is it possible, to get the proxy working to process this MOD request,
may be that openldap proxy pass through the MOD operation with the
attribute UnicodePwd from the VPN-gateway?

I use openldap 2.4.40, here is my configuration:

==
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/rfc2307bis.schema

pidfile /var/run/slapd/slapd.pid
argsfile/var/run/slapd/slapd.args
modulepath  /usr/lib/openldap/modules
moduleload  back_ldap

disallowbind_anon
require authc

TLSCACertificateFile/etc/openldap/certs/myorg.net.root.pem
TLSCertificateFile  /etc/openldap/certs/proxy1.myorg.net.pem
TLSCertificateKeyFile   /etc/openldap/certs/proxy1.myorg.net.pem.key
TLSVerifyClient never
TLSCipherSuite  ALL:!DH:!EDH

databaseldap
securitytls=256
rebind-as-user  yes
suffix  dc=myorg,dc=net
uri ldap://dc1.myorg.net ldap://dc2.myorg.net;
tls start
tls_cacert=/etc/openldap/certs/adroot.pem
chase-referrals no
protocol-version3

loglevel-1
==

Thanks for help!!

Meike

Re: LDAP Proxy Timeout Values

[Liam Gretton]

On 04/06/2014 14:10, Jack Kielsmeier wrote:
 So you basically have some sort of script that checks responsiveness. If 
 none, it reconfigures slapd.conf and restarts the process? Seems like quite a 
 bandaid, but it'd work.

Exactly. It's not elegant, but it works.

I'm still using slapd.conf instead of cn=config so a restart is
necessary, but as I'm using back-meta I don't think cn=config is
possible anyway.

-- 
Liam Grettonliam.gret...@le.ac.uk
Systems Specialist   http://www.le.ac.uk/its/
IT Services   Tel: +44 (0)116 2522254
University Of Leicester, University Road
Leicestershire LE1 7RH, United Kingdom

Re: LDAP Proxy Timeout Values

[Howard Chu]

Liam Gretton wrote:

I'm still using slapd.conf instead of cn=config so a restart is
necessary, but as I'm using back-meta I don't think cn=config is
possible anyway.


cn=config support for back-meta was released in 2.4.33.

--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: LDAP Proxy Timeout Values

[Liam Gretton]

On 05/06/2014 14:12, Howard Chu wrote:
 Liam Gretton wrote:
 I'm still using slapd.conf instead of cn=config so a restart is
 necessary, but as I'm using back-meta I don't think cn=config is
 possible anyway.

 cn=config support for back-meta was released in 2.4.33.

That's excellent news, thanks.

Regards,

Liam

-- 
Liam Grettonliam.gret...@le.ac.uk
HPC Architecthttp://www.le.ac.uk/its/
IT Services   Tel: +44 (0)116 2522254
University Of Leicester, University Road
Leicestershire LE1 7RH, United Kingdom

Re: LDAP Proxy Timeout Values

[Howard Chu]

Liam Gretton wrote:

On 05/06/2014 14:12, Howard Chu wrote:

Liam Gretton wrote:

I'm still using slapd.conf instead of cn=config so a restart is
necessary, but as I'm using back-meta I don't think cn=config is
possible anyway.


cn=config support for back-meta was released in 2.4.33.


That's excellent news, thanks.


Not exactly news, 2.4.33 was released in 2012...

--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: LDAP Proxy Timeout Values

[Howard Chu]

Howard Chu wrote:

Liam Gretton wrote:

On 05/06/2014 14:12, Howard Chu wrote:

Liam Gretton wrote:

I'm still using slapd.conf instead of cn=config so a restart is
necessary, but as I'm using back-meta I don't think cn=config is
possible anyway.


cn=config support for back-meta was released in 2.4.33.


That's excellent news, thanks.


Not exactly news, 2.4.33 was released in 2012...


2012-10-10. Fun fact: coincidentally, Double-Ten day, the 100th since the 
founding of the Republic of China.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

RE: LDAP Proxy Timeout Values

[Jack Kielsmeier]

Interesting.

So you basically have some sort of script that checks responsiveness. If none, 
it reconfigures slapd.conf and restarts the process? Seems like quite a 
bandaid, but it'd work.

-Original Message-
From: openldap-technical-boun...@openldap.org 
[mailto:openldap-technical-boun...@openldap.org] On Behalf Of Liam Gretton
Sent: Tuesday, June 03, 2014 2:12 PM
To: openldap-technical@openldap.org
Subject: Re: LDAP Proxy Timeout Values

On 03/06/2014 16:34, Jack Kielsmeier wrote:
 We are running OpenLDAP 2.4.23. Part of our implementation proxies to an 
 Active Directory server. Whenever connectivity to the AD server is 
 interrupted, queries to the non-proxied portion of our implementation take a 
 very long time and cause many issues with querying services.

I reported a similar issue a couple of years ago:

http://www.openldap.org/its/index.cgi/Incoming?id=7372;selectid=7372

That was with 2.4.32. I don't think it's been fixed since, but I've worked 
around it with a slightly unpleasant out-of-band check on our domain 
controllers which reconfigures OpenLDAP when it detects a DC going out of 
service.

-- 
Liam Grettonliam.gret...@le.ac.uk
HPC Architecthttp://www.le.ac.uk/its/
IT Services   Tel: +44 (0)116 2522254
University Of Leicester, University Road Leicestershire LE1 7RH, United Kingdom

Re: LDAP Proxy Timeout Values

[Howard Chu]

Jack Kielsmeier wrote:

Interesting.

So you basically have some sort of script that checks responsiveness. If none, 
it reconfigures slapd.conf and restarts the process? Seems like quite a 
bandaid, but it'd work.

-Original Message-
From: openldap-technical-boun...@openldap.org 
[mailto:openldap-technical-boun...@openldap.org] On Behalf Of Liam Gretton
Sent: Tuesday, June 03, 2014 2:12 PM
To: openldap-technical@openldap.org
Subject: Re: LDAP Proxy Timeout Values

On 03/06/2014 16:34, Jack Kielsmeier wrote:

We are running OpenLDAP 2.4.23. Part of our implementation proxies to an

Active Directory server. Whenever connectivity to the AD server is
interrupted, queries to the non-proxied portion of our implementation take a
very long time and cause many issues with querying services.

Based on the config info you provided, I don't see how that's possible. You 
have 3 database sections of note, and they are all independent. Queries to any 
of the first two databases cannot be affected by anything in the back-ldap 
database, unless you've deleted something crucial from the censored config you 
sent.


The doc sections you quote are not relevant, I suggest you re-read the 
slapd-ldap(5) manpage more carefully.



I reported a similar issue a couple of years ago:


Your issue was reported against back-meta, this post is about back-ldap. The 
configurations are not similar at all.


http://www.openldap.org/its/index.cgi/Incoming?id=7372;selectid=7372

That was with 2.4.32. I don't think it's been fixed since, but I've worked

around it with a slightly unpleasant out-of-band check on our domain
controllers which reconfigures OpenLDAP when it detects a DC going out of 
service.

From what I see in the mailing list archives, there was nothing to fix. The 
timeouts all worked as designed when tested locally.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

RE: LDAP Proxy Timeout Values

[Jack Kielsmeier]

Would it matter that our suffixes are nested?

Example:

DB 1:
suffix ou=sample4,dc=sample3,dc=sample2,dc=sample1

DB 2:
suffix dc=sample3,dc=sample2,dc=sample1

AD Server:
suffix dc=sample2,dc=sample1

So, if the server doing 'suffix dc=sample2,dc=sample1' goes down, would the 
other 2 be affected?

Thanks

- Jack

-Original Message-
From: Howard Chu [mailto:h...@symas.com] 
Sent: Wednesday, June 04, 2014 8:51 AM
To: Jack Kielsmeier; openldap-technical@openldap.org
Subject: Re: LDAP Proxy Timeout Values

Jack Kielsmeier wrote:
 Interesting.

 So you basically have some sort of script that checks responsiveness. If 
 none, it reconfigures slapd.conf and restarts the process? Seems like quite a 
 bandaid, but it'd work.

 -Original Message-
 From: openldap-technical-boun...@openldap.org 
 [mailto:openldap-technical-boun...@openldap.org] On Behalf Of Liam 
 Gretton
 Sent: Tuesday, June 03, 2014 2:12 PM
 To: openldap-technical@openldap.org
 Subject: Re: LDAP Proxy Timeout Values

 On 03/06/2014 16:34, Jack Kielsmeier wrote:
 We are running OpenLDAP 2.4.23. Part of our implementation proxies to 
 an
Active Directory server. Whenever connectivity to the AD server is interrupted, 
queries to the non-proxied portion of our implementation take a very long time 
and cause many issues with querying services.

Based on the config info you provided, I don't see how that's possible. You 
have 3 database sections of note, and they are all independent. Queries to any 
of the first two databases cannot be affected by anything in the back-ldap 
database, unless you've deleted something crucial from the censored config you 
sent.

The doc sections you quote are not relevant, I suggest you re-read the
slapd-ldap(5) manpage more carefully.

 I reported a similar issue a couple of years ago:

Your issue was reported against back-meta, this post is about back-ldap. The 
configurations are not similar at all.

 http://www.openldap.org/its/index.cgi/Incoming?id=7372;selectid=7372

 That was with 2.4.32. I don't think it's been fixed since, but I've 
 worked
around it with a slightly unpleasant out-of-band check on our domain 
controllers which reconfigures OpenLDAP when it detects a DC going out of 
service.

 From what I see in the mailing list archives, there was nothing to fix. The 
timeouts all worked as designed when tested locally.

-- 
   -- Howard Chu
   CTO, Symas Corp.   http://www.symas.com
   Director, Highland Sun http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: LDAP Proxy Timeout Values

[Liam Gretton]

On 04/06/2014 14:51, Howard Chu wrote:
 I reported a similar issue a couple of years ago:
 
 Your issue was reported against back-meta, this post is about back-ldap. The 
 configurations are not similar at all.

Agreed. I couldn't get the timeout directives to work as expected either
though. I don't know if the backends share code as far as connection
timeouts are concerned.

 http://www.openldap.org/its/index.cgi/Incoming?id=7372;selectid=7372

  From what I see in the mailing list archives, there was nothing to fix. The 
 timeouts all worked as designed when tested locally.

It was you who suggested I file the ITS about it, with a hint to
Pierangelo as to where the problem might be:

http://www.openldap.org/lists/openldap-technical/201208/msg00247.html

That was more to do with back-meta not falling through to alternative
targets, but the timeouts didn't seem to behave as expected either.

-- 
Liam Grettonliam.gret...@le.ac.uk
HPC Architecthttp://www.le.ac.uk/its/
IT Services   Tel: +44 (0)116 2522254
University Of Leicester, University Road
Leicestershire LE1 7RH, United Kingdom

LDAP Proxy Timeout Values

[Jack Kielsmeier]

Hello,

We are running OpenLDAP 2.4.23. Part of our implementation proxies to an Active 
Directory server. Whenever connectivity to the AD server is interrupted, 
queries to the non-proxied portion of our implementation take a very long time 
and cause many issues with querying services.

I have been looking at timeout options for both slapd.conf and ldap.conf and I 
have found the following:

ldap.conf:

   NETWORK_TIMEOUT integer
  Specifies the timeout (in seconds) after which the 
poll(2)/select(2) following a connect(2) returns in case of no activity.

   TIMEOUT integer
  Specifies a timeout (in seconds) after which calls to synchronous 
LDAP APIs will abort if no response is received.  Also used  for
  any ldap_result(3) calls where a NULL timeout parameter is 
supplied.

slapd.conf:

   idletimeout integer
  Specify the number of seconds to wait before forcibly closing an 
idle client connection.  A idletimeout of 0 disables this feature.   The
  default is 0. You may also want to set the writetimeout option.

   writetimeout integer
  Specify  the  number of seconds to wait before forcibly closing a 
connection with an outstanding write. This allows recovery from various
  network hang conditions.  A writetimeout of 0 disables this 
feature.  The default is 0.

I am wondering which timeout values would be best to set in order to speed up 
queries when proxy connectivity is interrupted.  Perhaps there is something 
else wrong with our config that is causing this issue.

Our ldap.conf file is basically empty (so, using all default)

Our slapd.conf looks something like this (heavily edited to remove specific 
info):

##BEGIN SLAPD.CONF##

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/samba3.schema
include /etc/openldap/schema/lockfile.schema
include /etc/openldap/schema/yast.schema
include /etc/openldap/schema/ldap2dns.schema
include /etc/openldap/schema/radius.schema
include /etc/openldap/schema/mail.schema

loglevel 256

allow bind_v2

sasl-host [REMOVED]
sasl-realm [REMOVED]

pidfile /var/run/openldap/slapd.pid
argsfile/var/run/openldap/slapd.args

modulepath  /usr/lib64/openldap
moduleload  rwm

tool-threads 2

#TLSCipherSuite HIGH:MEDIUM:+SSLv2
#TLSCACertificatePath /etc/ssl/certs/
#TLSCertificateFile [REMOVED]
#TLSCertificateKeyFile [REMOVED]
#TLSVerifyClient demand

access to attrs=[REMOVED]
by anonymous [REMOVED]
by * [REMOVED]

access to attrs=[REMOVED]
by * [REMOVED]

access to [REMOVED]
by * [REMOVED]

access to [REMOVED]
by * [REMOVED]


database [REMOVED]
suffix [REMOVED]
checkpoint  20480 5
cachesize   10
directory   [REMOVED]

dbconfig set_cachesize 0 268435456 1
dbconfig set_lg_max 268435456
dbconfig set_lg_bsize 16777216
dbconfig set_lk_max_objects 5000
dbconfig set_lk_max_locks 5000
dbconfig set_lk_max_lockers 5
dbconfig set_flags DB_LOG_AUTOREMOVE

index [REMOVED]
index [REMOVED]
index [REMOVED]



rootdn  [REMOVED]
rootpw  [REMOVED]
syncrepl rid=[REMOVED]
provider=[REMOVED]
type=refreshAndPersist
retry=300 +
searchbase=[REMOVED]
filter=(objectClass=*)
sizelimit=unlimited
timelimit=unlimited
scope=sub
schemachecking=off
bindmethod=simple
binddn=[REMOVED]
credentials=[REMOVED]


database [REMOVED]
suffix [REMOVED]
checkpoint  20480 5
cachesize   10
directory   [REMOVED]

dbconfig set_cachesize 0 268435456 1
dbconfig set_lg_max 268435456
dbconfig set_lg_bsize 16777216
dbconfig set_lk_max_objects 5000
dbconfig set_lk_max_locks 5000
dbconfig set_lk_max_lockers 5
dbconfig set_flags DB_LOG_AUTOREMOVE

index [REMOVED]
index [REMOVED]
index [REMOVED]



rootdn  [REMOVED]
rootpw  [REMOVED]
syncrepl [REMOVED]
provider=[REMOVED]
type=refreshAndPersist
retry=300 +
searchbase=[REMOVED]
filter=(objectClass=*)
sizelimit=unlimited
timelimit=unlimited
scope=sub
schemachecking=off
bindmethod=simple
binddn=[REMOVED]
credentials=[REMOVED]


database ldap

suffix [REMOVED]
uri ldap:// [REMOVED]
uri ldap:// [REMOVED]

rebind-as-user
lastmod   off
chase-referrals yes

acl-bind
bindmethod=simple
binddn=[REMOVED]
credentials=[REMOVED]
idassert-bind
bindmethod=simple
binddn=[REMOVED]
credentials=[REMOVED]
mode=none
flags=prescriptive
idassert-authzFrom   dn.regex:.*

overlay rwm
rwm-map attribute   [REMOVED]
rwm-map attribute   [REMOVED]
rwm-map 

Re: LDAP Proxy Timeout Values

[Liam Gretton]

On 03/06/2014 16:34, Jack Kielsmeier wrote:
 We are running OpenLDAP 2.4.23. Part of our implementation proxies to an 
 Active Directory server. Whenever connectivity to the AD server is 
 interrupted, queries to the non-proxied portion of our implementation take a 
 very long time and cause many issues with querying services.

I reported a similar issue a couple of years ago:

http://www.openldap.org/its/index.cgi/Incoming?id=7372;selectid=7372

That was with 2.4.32. I don't think it's been fixed since, but I've
worked around it with a slightly unpleasant out-of-band check on our
domain controllers which reconfigures OpenLDAP when it detects a DC
going out of service.

-- 
Liam Grettonliam.gret...@le.ac.uk
HPC Architecthttp://www.le.ac.uk/its/
IT Services   Tel: +44 (0)116 2522254
University Of Leicester, University Road
Leicestershire LE1 7RH, United Kingdom

Re: LDAP proxy and memberOf overlay

[Dan Pritts]

In case it's not obvious 
to you when reading the slapo-translucent man page, you 
set up a local bdb or mdb or hdb or xyzdb database, and add the 
translucent overlay atop that.

In your case to test this, I'd suggest you replace your back_ldap with a
 second local db + translucent.
For long term use you might just want to change the whole thing to a 
single db with translucent.


   	   
   	Michael Proto  
  February 12, 2014
 at 2:03 PM
  I haven't done 
this myself, but I suspect you'd want to use the translucent proxy 
backend instead of the normal back_ldap one. Check the man page for 
slapo-translucent.


  
   	   
   	Ingo Mailinglists  
  February 12, 2014
 at 9:24 AM
  Hi List,I am 
currently stuck with setting up OpenLDAP servers to fully addressmy 
use case. I hope someone here can point me in the right direction. Ithink
 it comes down to the point at where I do not know how to use thememberOf
 overlay with an LDAP proxy (back_ldap).First the use case:*
 I have a corporate OpenLDAP server that holds entries for our employees*
 There are also multiple http-based services which are allowed to beused
 after successful user authentication and given that groupmembership
 requirements are met.* The http-based services need to be accessed 
by both internal employees(those for which entries are stored in the
 corporate OpenLDAP server)and external people (for which there are 
no user entries yet).The task is to come up with an approach 
that supports the following:* allow the http-based services to 
authenticate both internal andexternal users against an OpenLDAP 
server* allow authorization based on group memberships* entries 
that represent external people are not allowed to be stored inthe 
existing corporate OpenLDAP server* entries that represent group 
memberships are not allowed to be storedin the existing corporate 
OpenLDAP server* in general, no changes to the corporate OpenLDAP 
server are allowed at allHere is my approach so far:* I have
 set up a new OpenLDAP server with two databases.* The first is a 
local hdb database. The suffix is set to a subordinateof the 
corporate OpenLDAP server.* The second is a ldap database, which 
points to and has the same suffixas the corporate OpenLDAP server.The
 purpose of the local hdb database is twofold* it should store 
entries for external people* it should store the group memberships 
for both external people andemployees from my own companyI 
did some tests with Apache 2.2.22, mod_ldap and mod_authnz_ldap. I canauthenticate
 both types of users (external from hdb and internal fromldap). I 
can even authorize them based on their group membership (usinggroupOfNames
 stored in the local hdb database). The group membershipcheck also 
works for user entries that are proxied via the ldap databasebackend.However,
 the approach fails for services that need the memberOf overlayfor 
making authorization decisions based on group membership (ownCloudis
 such an example). I have enabled the memberOf overlay for the localhdb
 database. So external users are not the problem. However, I cannotenable
 it for the ldap database, as I am not allowed to make any changesto
 the user entries of the corporate OpenLDAP server. That is, I am notallowed
 to add the memberOf attribute to the respective entries - evenif 
ACLs would allow me to do so.Now this is the point where I am 
stuck. Basically, I am looking for away to add the memberOf 
attribute to proxied user entries locally on mynew OpenLDAP server, 
without affecting the entries in the corporateOpenLDAP server.Any
 help that might point me in the right direction is highly appreciated.Thanks,Ingo


-- Dan PrittsICPSR Computing 
 Network ServicesUniversity of Michigan+1 (734)615-7362

LDAP proxy and memberOf overlay

[Ingo Mailinglists]

Hi List,

I am currently stuck with setting up OpenLDAP servers to fully address
my use case. I hope someone here can point me in the right direction. I
think it comes down to the point at where I do not know how to use the
memberOf overlay with an LDAP proxy (back_ldap).

First the use case:
* I have a corporate OpenLDAP server that holds entries for our employees
* There are also multiple http-based services which are allowed to be
used after successful user authentication and given that group
membership requirements are met.
* The http-based services need to be accessed by both internal employees
(those for which entries are stored in the corporate OpenLDAP server)
and external people (for which there are no user entries yet).

The task is to come up with an approach that supports the following:
* allow the http-based services to authenticate both internal and
external users against an OpenLDAP server
* allow authorization based on group memberships
* entries that represent external people are not allowed to be stored in
the existing corporate OpenLDAP server
* entries that represent group memberships are not allowed to be stored
in the existing corporate OpenLDAP server
* in general, no changes to the corporate OpenLDAP server are allowed at all

Here is my approach so far:
* I have set up a new OpenLDAP server with two databases.
* The first is a local hdb database. The suffix is set to a subordinate
of the corporate OpenLDAP server.
* The second is a ldap database, which points to and has the same suffix
as the corporate OpenLDAP server.

The purpose of the local hdb database is twofold
* it should store entries for external people
* it should store the group memberships for both external people and
employees from my own company

I did some tests with Apache 2.2.22, mod_ldap and mod_authnz_ldap. I can
authenticate both types of users (external from hdb and internal from
ldap). I can even authorize them based on their group membership (using
groupOfNames stored in the local hdb database). The group membership
check also works for user entries that are proxied via the ldap database
backend.

However, the approach fails for services that need the memberOf overlay
for making authorization decisions based on group membership (ownCloud
is such an example). I have enabled the memberOf overlay for the local
hdb database. So external users are not the problem. However, I cannot
enable it for the ldap database, as I am not allowed to make any changes
to the user entries of the corporate OpenLDAP server. That is, I am not
allowed to add the memberOf attribute to the respective entries - even
if ACLs would allow me to do so.

Now this is the point where I am stuck. Basically, I am looking for a
way to add the memberOf attribute to proxied user entries locally on my
new OpenLDAP server, without affecting the entries in the corporate
OpenLDAP server.

Any help that might point me in the right direction is highly appreciated.

Thanks,
Ingo

Re: LDAP proxy and memberOf overlay

[Michael Proto]

I haven't done this myself, but I suspect you'd want to use the translucent
proxy backend instead of the normal back_ldap one. Check the man page for
slapo-translucent.


On Wed, Feb 12, 2014 at 9:24 AM, Ingo Mailinglists 
ingo.mailingli...@gmail.com wrote:

 Hi List,

 I am currently stuck with setting up OpenLDAP servers to fully address
 my use case. I hope someone here can point me in the right direction. I
 think it comes down to the point at where I do not know how to use the
 memberOf overlay with an LDAP proxy (back_ldap).

 First the use case:
 * I have a corporate OpenLDAP server that holds entries for our employees
 * There are also multiple http-based services which are allowed to be
 used after successful user authentication and given that group
 membership requirements are met.
 * The http-based services need to be accessed by both internal employees
 (those for which entries are stored in the corporate OpenLDAP server)
 and external people (for which there are no user entries yet).

 The task is to come up with an approach that supports the following:
 * allow the http-based services to authenticate both internal and
 external users against an OpenLDAP server
 * allow authorization based on group memberships
 * entries that represent external people are not allowed to be stored in
 the existing corporate OpenLDAP server
 * entries that represent group memberships are not allowed to be stored
 in the existing corporate OpenLDAP server
 * in general, no changes to the corporate OpenLDAP server are allowed at
 all

 Here is my approach so far:
 * I have set up a new OpenLDAP server with two databases.
 * The first is a local hdb database. The suffix is set to a subordinate
 of the corporate OpenLDAP server.
 * The second is a ldap database, which points to and has the same suffix
 as the corporate OpenLDAP server.

 The purpose of the local hdb database is twofold
 * it should store entries for external people
 * it should store the group memberships for both external people and
 employees from my own company

 I did some tests with Apache 2.2.22, mod_ldap and mod_authnz_ldap. I can
 authenticate both types of users (external from hdb and internal from
 ldap). I can even authorize them based on their group membership (using
 groupOfNames stored in the local hdb database). The group membership
 check also works for user entries that are proxied via the ldap database
 backend.

 However, the approach fails for services that need the memberOf overlay
 for making authorization decisions based on group membership (ownCloud
 is such an example). I have enabled the memberOf overlay for the local
 hdb database. So external users are not the problem. However, I cannot
 enable it for the ldap database, as I am not allowed to make any changes
 to the user entries of the corporate OpenLDAP server. That is, I am not
 allowed to add the memberOf attribute to the respective entries - even
 if ACLs would allow me to do so.

 Now this is the point where I am stuck. Basically, I am looking for a
 way to add the memberOf attribute to proxied user entries locally on my
 new OpenLDAP server, without affecting the entries in the corporate
 OpenLDAP server.

 Any help that might point me in the right direction is highly appreciated.

 Thanks,
 Ingo

LDAP Proxy

[Keith Hamburg]

I'm trying to configure a third party product to obtain the list of valid
users based on a group membership in a corporate active directory server.
The third party product is not capable of querying for users based on group
membership. It can only use an OU or objectClass. The corporate AD server
has a very broad All Users OU and we can't add an OU or objectClass to AD
.

I would like to configure an OpenLDAP proxy using that can dynamically
create an OU by querying the members of a group. Is this possible using
overlays? Another possibility is that try to synchronize OpenLDAP with AD
based on a filter that includes membership in only one group. Would either
of these methods work or is there another solution I haven't mentioned?

Thanks,
Keith

LDAP proxy

[Šerých Jakub]

Dear group,
I manage the school network in which we have two separate MS-AD servers (one 
for teachers and the other for students). We also have mySQL database of our 
alumni. 
I would like to connect this three information bases to one virtual LDAP 
server (for authentication purposes on various LAMP web servers etc.).

Is it possible to configure such virtual or proxy server using OpenLDAP? And if 
yes, could anybody be so kind and redirect me to some how-to resources? 

I was trying to search this using Google, but as I'm OpenLDAP newbie, I don't 
know the terminology exactly and my search results are not good.

Thanks in advance for any help

Jakub

   

Re: LDAP proxy

[Andrew Findlay]

On Fri, Apr 19, 2013 at 09:49:36AM +, Šerých Jakub wrote:

 I manage the school network in which we have two separate MS-AD servers (one 
 for teachers and the other for students). We also have mySQL database of our 
 alumni. 
 I would like to connect this three information bases to one virtual LDAP 
 server (for authentication purposes on various LAMP web servers etc.).
 
 Is it possible to configure such virtual or proxy server using OpenLDAP? And 
 if yes, could anybody be so kind and redirect me to some how-to resources? 

That should be possible. You need to decide how you want the three
data sources to show up in the LDAP tree presented to the client
systems, and you need to consider what happens if the same username
(uid in LDAP terms) appears in more than one data-source.

I would start by building a simple LDAP proxy in front of one AD and
getting that working first (use the LDAP backend or the META backend).
Then try putting an rwm overlay on it and changing the name mapping.

Once those are working, try a simple SQL backend in isolation.

Finally, join all three together in the same server using the relay
overlay.

Documentation is here:

http://www.openldap.org/doc/admin24/

Look in the Backends and Overlays sections in particular. You will
also need to search Google and the Faq-O-Matic for examples as some of
the documentation is a bit thin.

http://www.openldap.org/faq/data/cache/1.html

Some things are better explained in the manpages than in the Admin
Guide.

Andrew
-- 
---
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/+44 1628 782565 |
---

Re: Controlled LDAP Proxy/Relay

[Aaron Richton]

On Fri, 22 Jun 2012, w.sieb...@t-systems.com wrote:


Hello,
thanks for your answer.
But I don?t have any local users. All users are in two targets: domain01.com 
and domain99.net (AD). Where I should place userPassword attribute?


So you have dc=microsoft1 running on ad1.example.com and dc=microsoft2 
running on ad2.example.net, with no need for additional data?


Have you considered:

database meta
subordinate
suffix dc=microsoft1
uri ldap://ad1.example.com/dc=microsoft1

database meta
subordinate
suffix dc=microsoft2
uri ldap://ad2.example.net/dc=microsoft2

database null
suffix  

and then have your single baseDN only client configured to the 
back-null? Only place this gets slightly weird is if you have conflicting 
namespace across the two back-meta's (i.e. if cn=example,dc=microsoft1 
and cn=example,dc=microsoft2 both exist -- check your application 
behavior carefully in such a case).



My problem:
We have a VoIP realized by Cisco Unified Call Manager (CUCM). There are several 
thousand users in the customers directory (domain01.com) using CUCM for Voice 
and
ca 100 adminusers in the supplier directory (domain99.net). No trusting, 
different companies.
Because CUCM can use only one directory to authenticate users I've implemented 
a OpenLDAP Metadirectory that proxying this 2 Microsft AD targets.
But meta backend tries to authenticate by the first target, if the user was not 
found, by the second.
Result: Intrusion detection register a lot of unsuccessfully login attempts.
 
Therefore my question:
Is it possible to implement the controlled proxy with OpenLDAP ?
E.g., like Radiusproxy based on realm: when username is _xxx@domain01.com_ go 
to the target1, and when username is _xxx@domain99.net_  go to the target2.
Can you help me please
Kind regards
Waldemar
 
 

 
On 08/02/2012 09:58, w.sieb...@t-systems.com wrote:
 
 Is it possible to implement the controlled proxy with OpenLDAP ?
 E.g., like Radiusproxy based on realm: when username is
 _xxx@domain01.com_ mailto:x...@domain01.com  go to the target1, and
 when username is _xxx@domain99.net_mailto:x...@domain99.net  go to the 
target2.
 
Yes, a combination of meta database config in slapd.conf and appropriate SASL 
config.
 
In your schema, use the following in userPassword:
 
userPassword: {SASL}xxx@DOMAIN
 
where DOMAIN is whichever domain the user needs to be authenticated against.
 
In slapd.conf:
 
database meta
suffix   dc=local
rootdn   cn=administrator,dc=local
rootpw   secret
 
# domain01
uri   ldaps://domain01.com:3269/ou=domain01.com,dc=local
lastmod off
suffixmassage  ou=domain01.com=local dc=domain01,dc=com
 
idassert-bind   bindmethod=simple
 binddn=cn=binder,dc=domain01,dc=com
 credentials=password
 flags=non-prescriptive
 
idassert-authzFrom  dn.exact:cn=administrator,dc=local
 
# domain02
uri   ldaps://domain02.com:3269/ou=domain02.com,dc=local
lastmod off
suffixmassage  ou=domain02.com=local dc=domain02,dc=com
 
idassert-bind   bindmethod=simple
 binddn=cn=binder,dc=domain02,dc=com
 credentials=password
 flags=non-prescriptive
 
idassert-authzFrom  dn.exact:cn=administrator,dc=local
 
In saslauthd.conf you need to create the appropriate search base for 
authentication based on the domain in the userPassword field:
 
ldap_servers: ldapi://%2Fvar%2Frun%2Fslapd%2Fldapi-meta
ldap_search_base: ou=%d,dc=local
ldap_filter: (sAMAccountName=%U)
ldap_auth_method: bind
 
ldap_bind_dn: cn=administrator,dc=local
ldap_password: secret
 
ldap_deref: never
ldap_use_sasl: no
 
Hopefully this is enough info to get you going.
 
--
Liam Gretton    liam.gret...@le.ac.uk
HPC Architect http://www.le.ac.uk/its
IT Services   Tel: +44 (0)116 2522254
University of Leicester, University Road Leicestershire LE1 7RH, United Kingdom
 
 
 

AW: Controlled LDAP Proxy/Relay

[W.Siebert]

Hello, thank you,

but my application CUCM can use only one directory to authenticate users. I can 
configure only one dc

Regards
Waldemar

-Ursprüngliche Nachricht-
Von: Aaron Richton [mailto:rich...@nbcs.rutgers.edu] 
Gesendet: Montag, 25. Juni 2012 16:28
An: Siebert, Waldemar
Cc: openldap-technical@openldap.org
Betreff: Re: Controlled LDAP Proxy/Relay

On Fri, 22 Jun 2012, w.sieb...@t-systems.com wrote:

 Hello,
 thanks for your answer.
 But I don?t have any local users. All users are in two targets: domain01.com 
 and domain99.net (AD). Where I should place userPassword attribute?

So you have dc=microsoft1 running on ad1.example.com and dc=microsoft2 
running on ad2.example.net, with no need for additional data?

Have you considered:

database meta
subordinate
suffix dc=microsoft1
uri ldap://ad1.example.com/dc=microsoft1

database meta
subordinate
suffix dc=microsoft2
uri ldap://ad2.example.net/dc=microsoft2

database null
suffix  

and then have your single baseDN only client configured to the 
back-null? Only place this gets slightly weird is if you have conflicting 
namespace across the two back-meta's (i.e. if cn=example,dc=microsoft1 
and cn=example,dc=microsoft2 both exist -- check your application 
behavior carefully in such a case).

 My problem:
 We have a VoIP realized by Cisco Unified Call Manager (CUCM). There are 
 several thousand users in the customers directory (domain01.com) using CUCM 
 for Voice and
 ca 100 adminusers in the supplier directory (domain99.net). No trusting, 
 different companies.
 Because CUCM can use only one directory to authenticate users I've 
 implemented a OpenLDAP Metadirectory that proxying this 2 Microsft AD targets.
 But meta backend tries to authenticate by the first target, if the user was 
 not found, by the second.
 Result: Intrusion detection register a lot of unsuccessfully login attempts.
  
 Therefore my question:
 Is it possible to implement the controlled proxy with OpenLDAP ?
 E.g., like Radiusproxy based on realm: when username is _xxx@domain01.com_ go 
 to the target1, and when username is _xxx@domain99.net_  go to the target2.
 Can you help me please
 Kind regards
 Waldemar
  
  
 
  
 On 08/02/2012 09:58, w.sieb...@t-systems.com wrote:
  
  Is it possible to implement the controlled proxy with OpenLDAP ?
  E.g., like Radiusproxy based on realm: when username is
  _xxx@domain01.com_ mailto:x...@domain01.com  go to the target1, and
  when username is _xxx@domain99.net_mailto:x...@domain99.net  go to the 
  target2.
  
 Yes, a combination of meta database config in slapd.conf and appropriate SASL 
 config.
  
 In your schema, use the following in userPassword:
  
 userPassword: {SASL}xxx@DOMAIN
  
 where DOMAIN is whichever domain the user needs to be authenticated against.
  
 In slapd.conf:
  
 database meta
 suffix   dc=local
 rootdn   cn=administrator,dc=local
 rootpw   secret
  
 # domain01
 uri   ldaps://domain01.com:3269/ou=domain01.com,dc=local
 lastmod off
 suffixmassage  ou=domain01.com=local dc=domain01,dc=com
  
 idassert-bind   bindmethod=simple
  binddn=cn=binder,dc=domain01,dc=com
  credentials=password
  flags=non-prescriptive
  
 idassert-authzFrom  dn.exact:cn=administrator,dc=local
  
 # domain02
 uri   ldaps://domain02.com:3269/ou=domain02.com,dc=local
 lastmod off
 suffixmassage  ou=domain02.com=local dc=domain02,dc=com
  
 idassert-bind   bindmethod=simple
  binddn=cn=binder,dc=domain02,dc=com
  credentials=password
  flags=non-prescriptive
  
 idassert-authzFrom  dn.exact:cn=administrator,dc=local
  
 In saslauthd.conf you need to create the appropriate search base for 
 authentication based on the domain in the userPassword field:
  
 ldap_servers: ldapi://%2Fvar%2Frun%2Fslapd%2Fldapi-meta
 ldap_search_base: ou=%d,dc=local
 ldap_filter: (sAMAccountName=%U)
 ldap_auth_method: bind
  
 ldap_bind_dn: cn=administrator,dc=local
 ldap_password: secret
  
 ldap_deref: never
 ldap_use_sasl: no
  
 Hopefully this is enough info to get you going.
  
 --
 Liam Gretton    liam.gret...@le.ac.uk
 HPC Architect http://www.le.ac.uk/its
 IT Services   Tel: +44 (0)116 2522254
 University of Leicester, University Road Leicestershire LE1 7RH, United 
 Kingdom
  
  
  
 

Re: AW: Controlled LDAP Proxy/Relay

[Aaron Richton]

On Mon, 25 Jun 2012, w.sieb...@t-systems.com wrote:


Hello, thank you,

but my application CUCM can use only one directory to authenticate users. I can 
configure only one dc


Exactly; this was written with a client that only accepts a single baseDN 
in mind. Configure to ldap://newopenldap.example.com/ with baseDN  if 
you use the config example I wrote. (Play around with OpenLDAP clients 
such as ldapsearch(1) to get the feel of things first, or if posting to 
the list.)



Regards
Waldemar

-Urspr?ngliche Nachricht-
Von: Aaron Richton [mailto:rich...@nbcs.rutgers.edu]
Gesendet: Montag, 25. Juni 2012 16:28
An: Siebert, Waldemar
Cc: openldap-technical@openldap.org
Betreff: Re: Controlled LDAP Proxy/Relay

On Fri, 22 Jun 2012, w.sieb...@t-systems.com wrote:


Hello,
thanks for your answer.
But I don?t have any local users. All users are in two targets: domain01.com 
and domain99.net (AD). Where I should place userPassword attribute?


So you have dc=microsoft1 running on ad1.example.com and dc=microsoft2
running on ad2.example.net, with no need for additional data?

Have you considered:

database meta
subordinate
suffix dc=microsoft1
uri ldap://ad1.example.com/dc=microsoft1

database meta
subordinate
suffix dc=microsoft2
uri ldap://ad2.example.net/dc=microsoft2

database null
suffix  

and then have your single baseDN only client configured to the
back-null? Only place this gets slightly weird is if you have conflicting
namespace across the two back-meta's (i.e. if cn=example,dc=microsoft1
and cn=example,dc=microsoft2 both exist -- check your application
behavior carefully in such a case).


My problem:
We have a VoIP realized by Cisco Unified Call Manager (CUCM). There are several 
thousand users in the customers directory (domain01.com) using CUCM for Voice 
and
ca 100 adminusers in the supplier directory (domain99.net). No trusting, 
different companies.
Because CUCM can use only one directory to authenticate users I've implemented 
a OpenLDAP Metadirectory that proxying this 2 Microsft AD targets.
But meta backend tries to authenticate by the first target, if the user was not 
found, by the second.
Result: Intrusion detection register a lot of unsuccessfully login attempts.
 
Therefore my question:
Is it possible to implement the controlled proxy with OpenLDAP ?
E.g., like Radiusproxy based on realm: when username is _xxx@domain01.com_ go 
to the target1, and when username is _xxx@domain99.net_  go to the target2.
Can you help me please
Kind regards
Waldemar
 
 

 
On 08/02/2012 09:58, w.sieb...@t-systems.com wrote:
 

Is it possible to implement the controlled proxy with OpenLDAP ?
E.g., like Radiusproxy based on realm: when username is
_xxx@domain01.com_ mailto:x...@domain01.com  go to the target1, and
when username is _xxx@domain99.net_mailto:x...@domain99.net  go to the 
target2.

 
Yes, a combination of meta database config in slapd.conf and appropriate SASL 
config.
 
In your schema, use the following in userPassword:
 
userPassword: {SASL}xxx@DOMAIN
 
where DOMAIN is whichever domain the user needs to be authenticated against.
 
In slapd.conf:
 
database meta
suffix   dc=local
rootdn   cn=administrator,dc=local
rootpw   secret
 
# domain01
uri   ldaps://domain01.com:3269/ou=domain01.com,dc=local
lastmod off
suffixmassage  ou=domain01.com=local dc=domain01,dc=com
 
idassert-bind   bindmethod=simple
 binddn=cn=binder,dc=domain01,dc=com
 credentials=password
 flags=non-prescriptive
 
idassert-authzFrom  dn.exact:cn=administrator,dc=local
 
# domain02
uri   ldaps://domain02.com:3269/ou=domain02.com,dc=local
lastmod off
suffixmassage  ou=domain02.com=local dc=domain02,dc=com
 
idassert-bind   bindmethod=simple
 binddn=cn=binder,dc=domain02,dc=com
 credentials=password
 flags=non-prescriptive
 
idassert-authzFrom  dn.exact:cn=administrator,dc=local
 
In saslauthd.conf you need to create the appropriate search base for 
authentication based on the domain in the userPassword field:
 
ldap_servers: ldapi://%2Fvar%2Frun%2Fslapd%2Fldapi-meta
ldap_search_base: ou=%d,dc=local
ldap_filter: (sAMAccountName=%U)
ldap_auth_method: bind
 
ldap_bind_dn: cn=administrator,dc=local
ldap_password: secret
 
ldap_deref: never
ldap_use_sasl: no
 
Hopefully this is enough info to get you going.
 
--
Liam Gretton    liam.gret...@le.ac.uk
HPC Architect http://www.le.ac.uk/its
IT Services   Tel: +44 (0)116 2522254
University of Leicester, University Road Leicestershire LE1 7RH, United Kingdom

Controlled LDAP Proxy/Relay

[W.Siebert]

Hello,
thanks for your answer.
But I don't have any local users. All users are in two targets: domain01.com 
and domain99.net (AD). Where I should place userPassword attribute?
My problem:
We have a VoIP realized by Cisco Unified Call Manager (CUCM). There are several 
thousand users in the customers directory (domain01.com) using CUCM for Voice 
and ca 100 adminusers in the supplier directory (domain99.net). No trusting, 
different companies.
Because CUCM can use only one directory to authenticate users I've implemented 
a OpenLDAP Metadirectory that proxying this 2 Microsft AD targets.
But meta backend tries to authenticate by the first target, if the user was not 
found, by the second.
Result: Intrusion detection register a lot of unsuccessfully login attempts.

Therefore my question:
Is it possible to implement the controlled proxy with OpenLDAP ?
E.g., like Radiusproxy based on realm: when username is 
_xxx@domain01.com_mailto:_xxx@domain01.com_ go to the target1, and when 
username is _xxx@domain99.net_mailto:_xxx@domain99.net_  go to the target2.

Can you help me please
Kind regards
Waldemar




On 08/02/2012 09:58, w.sieb...@t-systems.commailto:w.sieb...@t-systems.com 
wrote:

 Is it possible to implement the controlled proxy with OpenLDAP ?
 E.g., like Radiusproxy based on realm: when username is
 _xxx@domain01.com_mailto:_xxx@domain01.com_ mailto:x...@domain01.com  go 
 to the target1, and
 when username is 
 _xxx@domain99.net_mailto:x...@domain99.netmailto:_xxx@domain99.net_mailto:x...@domain99.net
   go to the target2.

Yes, a combination of meta database config in slapd.conf and appropriate SASL 
config.

In your schema, use the following in userPassword:

userPassword: {SASL}xxx@DOMAIN

where DOMAIN is whichever domain the user needs to be authenticated against.

In slapd.conf:

database meta
suffix   dc=local
rootdn   cn=administrator,dc=local
rootpw   secret

# domain01
uri   ldaps://domain01.com:3269/ou=domain01.com,dc=local
lastmod off
suffixmassage  ou=domain01.com=local dc=domain01,dc=com

idassert-bind   bindmethod=simple
 binddn=cn=binder,dc=domain01,dc=com
 credentials=password
 flags=non-prescriptive

idassert-authzFrom  dn.exact:cn=administrator,dc=local

# domain02
uri   ldaps://domain02.com:3269/ou=domain02.com,dc=local
lastmod off
suffixmassage  ou=domain02.com=local dc=domain02,dc=com

idassert-bind   bindmethod=simple
 binddn=cn=binder,dc=domain02,dc=com
 credentials=password
 flags=non-prescriptive

idassert-authzFrom  dn.exact:cn=administrator,dc=local

In saslauthd.conf you need to create the appropriate search base for 
authentication based on the domain in the userPassword field:

ldap_servers: ldapi://%2Fvar%2Frun%2Fslapd%2Fldapi-meta
ldap_search_base: ou=%d,dc=local
ldap_filter: (sAMAccountName=%U)
ldap_auth_method: bind

ldap_bind_dn: cn=administrator,dc=local
ldap_password: secret

ldap_deref: never
ldap_use_sasl: no

Hopefully this is enough info to get you going.

--
Liam Gretton
liam.gret...@le.ac.ukmailto:liam.gret...@le.ac.uk
HPC Architect http://www.le.ac.uk/its
IT Services   Tel: +44 (0)116 2522254
University of Leicester, University Road Leicestershire LE1 7RH, United Kingdom

slapd-ldap proxy database

[Ismael Gil]

Hello all,

 I'm trying to configure a ldap proxy to conect to a windows active directory 
to get data.
 My /etc/openldap/slapd.conf, looks like that (the databases definition only):

 # Our slapd-ldap back end to connect to AD

 database ldap
 suffix cn=users,dc=XXX,dc=XXX
 #rootdn cn=Administrador,dc=XXX,dc=XXX
 subordinate
 lastmod off
 rebind-as-user
 uri ldap://serverip/;
 chase-referrals yes

 database bdb
 suffix dc=XXX,dc=XXX
 rootdn cn=Administrador,dc=XXX,dc=XXX
 #rootdn dc=XXX,dc=XXX
 rootpw {SSHA}Yyyy

 Whit this config, I only can query the users directory, on the Active 
Directory server, but I need to be able to query all OUs inside the Active 
Directory.

 Why I only can get data from users ou, instead the whole Active Directory?
 How could I get to proxy all my querys to the Active directory server?
 If I have an ou called Bussines, in the Active Directory server, ¿how could 
I make a database definition or other configuration to get that working?

 Thanks in advance,

 Ismaeleitor

Re: Controlled LDAP Proxy/Relay

[Liam Gretton]

On 08/02/2012 09:58, w.sieb...@t-systems.com wrote:


Is it possible to implement the controlled proxy with OpenLDAP ?
E.g., like Radiusproxy based on realm: when username is _xxx@domain01.com_
mailto:x...@domain01.com  go to the target1, and when username is
_xxx@domain99.net_mailto:x...@domain99.net  go to the target2.


Yes, a combination of meta database config in slapd.conf and appropriate 
SASL config.


In your schema, use the following in userPassword:

userPassword: {SASL}xxx@DOMAIN

where DOMAIN is whichever domain the user needs to be authenticated against.

In slapd.conf:

database meta
suffix   dc=local
rootdn   cn=administrator,dc=local
rootpw   secret

# domain01
uri   ldaps://domain01.com:3269/ou=domain01.com,dc=local
lastmod off
suffixmassage  ou=domain01.com=local dc=domain01,dc=com

idassert-bind   bindmethod=simple
binddn=cn=binder,dc=domain01,dc=com
credentials=password
flags=non-prescriptive

idassert-authzFrom  dn.exact:cn=administrator,dc=local

# domain02
uri   ldaps://domain02.com:3269/ou=domain02.com,dc=local
lastmod off
suffixmassage  ou=domain02.com=local dc=domain02,dc=com

idassert-bind   bindmethod=simple
binddn=cn=binder,dc=domain02,dc=com
credentials=password
flags=non-prescriptive

idassert-authzFrom  dn.exact:cn=administrator,dc=local

In saslauthd.conf you need to create the appropriate search base for 
authentication based on the domain in the userPassword field:


ldap_servers: ldapi://%2Fvar%2Frun%2Fslapd%2Fldapi-meta
ldap_search_base: ou=%d,dc=local
ldap_filter: (sAMAccountName=%U)
ldap_auth_method: bind

ldap_bind_dn: cn=administrator,dc=local
ldap_password: secret

ldap_deref: never
ldap_use_sasl: no

Hopefully this is enough info to get you going.

--
Liam Grettonliam.gret...@le.ac.uk
HPC Architect http://www.le.ac.uk/its
IT Services   Tel: +44 (0)116 2522254
University of Leicester, University Road
Leicestershire LE1 7RH, United Kingdom

Controlled LDAP Proxy/Relay

[W.Siebert]

Hello,

I'v implemented a OpenLDAP Metadirectory that proxying 2 Microsft AD targets.

One target is customers AD, the second our AD for management purposes.

Problem: slapd-meta tries to authenticate the user first by one target and if 
this user there not exist will be the second target connected.
Means: in both directories Intrusion Detection register a lot of unsuccessfully 
authentication.

Is it possible to implement the controlled proxy with OpenLDAP ?

E.g., like Radiusproxy based on realm: when username is 
x...@domain01.commailto:x...@domain01.com go to the target1, and when 
username is x...@domain99.netmailto:x...@domain99.net go to the target2.



Kind regards
Waldemar

[Re: ldap proxy acl filter problem]

[Ron Peterson]

Had to turn away from this problem to deal w/ other stuff, but it's
still an issue for me.

Does anyone have a working example of a working proxy configuration they
would be willing to share that:
* includes a filter expression restricting the result set
* allows you to query for the value of an individual attribute

I would be very grateful.

Right now I'm thinking I may try a different tack: put the filter
expression on the master directory in an acl specific to the proxy base
dn I'm dealing with.

-Ron-

- Forwarded message from Ron Peterson rpete...@mtholyoke.edu -

Date: Fri, 16 Sep 2011 09:25:41 -0400
From: Ron Peterson rpete...@mtholyoke.edu
To: Howard Chu h...@symas.com
Subject: Re: ldap proxy acl filter problem
Organization: Mount Holyoke College
X-Spam-Score: -0.504 () RP_MATCHES_RCVD
Cc: openldap-technical@openldap.org

2011-09-15_08:22:54-0400 Ron Peterson rpete...@mtholyoke.edu:
 2011-09-14_16:54:56-0400 Howard Chu h...@symas.com:
  I've turned my logging way up, and the hiccup seems to be that the DN
  I've authenticated as
  (uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu) needs read
  access to the attributes in the filter expression.  But how do I give
  that account read access to those attributes, without then exposing the
  objects that I'm trying to hide with the filter expression?
  
  Give it auth access, not read access.

My previous example had too much going on for any sane person to wade
through, so I've distilled this configuration down to illustrate the
essence of the problem.  No fancy rewrite rules, etc.  The problem
remains: adding a filter expression makes it impossible to query the
value of particular attributes, although I can retrieve the entire
object.

It must be possible to filter the result set in a back-ldap proxy setup
when querying for particular attributes, but how?


ldaprc like:

BASE ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu
BINDDN uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu
URI ldap://dirt.mtholyoke.edu
SIZELIMIT   4
TLS_CACERT /local/etc/cert/ca/cacert.pem


proxy config like:

databaseldap
suffix  ou=accounts,ou=prod,dc=mtholyoke,dc=edu
uri ldapi://%2Fvar%2Frun%2Fslapd%2Fmastertest%2Fldapi

access to dn.sub=ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu 
attrs=entry
   by dn=uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu read
   by * none

# log file (see below) seems to indicate proxy wants search permission on this 
attribute,
# but this doesn't help
access to dn.sub=ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu 
attrs=yApplicationPermission
   by dn=uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu search
   by * none

access to dn.sub=ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu 
filter=(yApplicationPermission=email)
   by dn=uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu read
   by * none


(1) This query works (returns all attributes):
ldapsearch -LLL -Z -x -y ../../private/pwemail '(yUsername=rpeterso)'

(2) This query does not (only returns DN, but not yPrimaryEmail):
ldapsearch -LLL -Z -x -y ../../private/pwemail '(yUsername=rpeterso)' 
yPrimaryEmail


Log for both master and proxy database (loglevel 256 128 64 32), for
query (2) above:

pid 32160 = proxy server
pid 24268 = master directory server

Sep 16 09:17:41 mid slapd[32160]: conn=1001 fd=13 ACCEPT from 
IP=138.110.86.129:51010 (IP=138.110.86.129:389)
Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=0 STARTTLS
Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=0 RESULT oid= err=0 text=
Sep 16 09:17:41 mid slapd[32160]: conn=1001 fd=13 TLS established tls_ssf=256 
ssf=256
Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=1 BIND 
dn=uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu method=128
Sep 16 09:17:41 mid slapd[24268]: conn=1025 fd=13 ACCEPT from 
PATH=/var/run/slapd/mastertest/ldapi (PATH=/var/run/slapd/mastertest/ldapi)
Sep 16 09:17:41 mid slapd[24268]: conn=1025 op=0 BIND 
dn=uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu method=128
Sep 16 09:17:41 mid slapd[24268]: = access_allowed: result not in cache 
(userPassword)
Sep 16 09:17:41 mid slapd[24268]: = access_allowed: auth access to 
uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu userPassword 
requested
Sep 16 09:17:41 mid slapd[24268]: = acl_get: [1] attr userPassword
Sep 16 09:17:41 mid slapd[24268]: = acl_mask: access to entry 
uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu, attr 
userPassword requested
Sep 16 09:17:41 mid slapd[24268]: = acl_mask: to value by , (=0) 
Sep 16 09

Re: ldap proxy acl filter problem

[Ron Peterson]

2011-09-15_08:22:54-0400 Ron Peterson rpete...@mtholyoke.edu:
 2011-09-14_16:54:56-0400 Howard Chu h...@symas.com:
  I've turned my logging way up, and the hiccup seems to be that the DN
  I've authenticated as
  (uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu) needs read
  access to the attributes in the filter expression.  But how do I give
  that account read access to those attributes, without then exposing the
  objects that I'm trying to hide with the filter expression?
  
  Give it auth access, not read access.

My previous example had too much going on for any sane person to wade
through, so I've distilled this configuration down to illustrate the
essence of the problem.  No fancy rewrite rules, etc.  The problem
remains: adding a filter expression makes it impossible to query the
value of particular attributes, although I can retrieve the entire
object.

It must be possible to filter the result set in a back-ldap proxy setup
when querying for particular attributes, but how?


ldaprc like:

BASE ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu
BINDDN uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu
URI ldap://dirt.mtholyoke.edu
SIZELIMIT   4
TLS_CACERT /local/etc/cert/ca/cacert.pem


proxy config like:

databaseldap
suffix  ou=accounts,ou=prod,dc=mtholyoke,dc=edu
uri ldapi://%2Fvar%2Frun%2Fslapd%2Fmastertest%2Fldapi

access to dn.sub=ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu 
attrs=entry
   by dn=uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu read
   by * none

# log file (see below) seems to indicate proxy wants search permission on this 
attribute,
# but this doesn't help
access to dn.sub=ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu 
attrs=yApplicationPermission
   by dn=uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu search
   by * none

access to dn.sub=ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu 
filter=(yApplicationPermission=email)
   by dn=uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu read
   by * none


(1) This query works (returns all attributes):
ldapsearch -LLL -Z -x -y ../../private/pwemail '(yUsername=rpeterso)'

(2) This query does not (only returns DN, but not yPrimaryEmail):
ldapsearch -LLL -Z -x -y ../../private/pwemail '(yUsername=rpeterso)' 
yPrimaryEmail


Log for both master and proxy database (loglevel 256 128 64 32), for
query (2) above:

pid 32160 = proxy server
pid 24268 = master directory server

Sep 16 09:17:41 mid slapd[32160]: conn=1001 fd=13 ACCEPT from 
IP=138.110.86.129:51010 (IP=138.110.86.129:389)
Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=0 STARTTLS
Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=0 RESULT oid= err=0 text=
Sep 16 09:17:41 mid slapd[32160]: conn=1001 fd=13 TLS established tls_ssf=256 
ssf=256
Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=1 BIND 
dn=uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu method=128
Sep 16 09:17:41 mid slapd[24268]: conn=1025 fd=13 ACCEPT from 
PATH=/var/run/slapd/mastertest/ldapi (PATH=/var/run/slapd/mastertest/ldapi)
Sep 16 09:17:41 mid slapd[24268]: conn=1025 op=0 BIND 
dn=uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu method=128
Sep 16 09:17:41 mid slapd[24268]: = access_allowed: result not in cache 
(userPassword)
Sep 16 09:17:41 mid slapd[24268]: = access_allowed: auth access to 
uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu userPassword 
requested
Sep 16 09:17:41 mid slapd[24268]: = acl_get: [1] attr userPassword
Sep 16 09:17:41 mid slapd[24268]: = acl_mask: access to entry 
uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu, attr 
userPassword requested
Sep 16 09:17:41 mid slapd[24268]: = acl_mask: to value by , (=0) 
Sep 16 09:17:41 mid slapd[24268]: = check a_dn_pat: self
Sep 16 09:17:41 mid slapd[24268]: = check a_dn_pat: anonymous
Sep 16 09:17:41 mid slapd[24268]: = acl_mask: [2] applying auth(=xd) (stop)
Sep 16 09:17:41 mid slapd[24268]: = acl_mask: [2] mask: auth(=xd)
Sep 16 09:17:41 mid slapd[24268]: = slap_access_allowed: auth access granted 
by auth(=xd)
Sep 16 09:17:41 mid slapd[24268]: = access_allowed: auth access granted by 
auth(=xd)
Sep 16 09:17:41 mid slapd[24268]: conn=1025 op=0 BIND 
dn=uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu mech=SIMPLE 
ssf=0
Sep 16 09:17:41 mid slapd[24268]: conn=1025 op=0 RESULT tag=97 err=0 text=
Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=1 BIND 
dn=uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu mech=SIMPLE 
ssf=0
Sep 16 09:17:41 mid slapd[32160]: conn=1001 op=1 RESULT tag=97 err=0 text

Re: ldap proxy acl filter problem

[Ron Peterson]

2011-09-14_16:54:56-0400 Howard Chu h...@symas.com:
 I've turned my logging way up, and the hiccup seems to be that the DN
 I've authenticated as
 (uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu) needs read
 access to the attributes in the filter expression.  But how do I give
 that account read access to those attributes, without then exposing the
 objects that I'm trying to hide with the filter expression?
 
 Give it auth access, not read access.

Did that, but it seems to want read access.  ?

Sep 15 08:13:15 mid slapd[5050]: = acl_mask: access to entry 
yDirectoryID=c44883ba-ac62-d28c-556f-99ccbf532da7,ou=email, attr 
yGlobalPermission requested
Sep 15 08:13:15 mid slapd[5050]: = acl_mask: to value by 
uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu, (=0) 
Sep 15 08:13:15 mid slapd[5050]: = check a_dn_pat: 
uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu
Sep 15 08:13:15 mid slapd[5050]: = acl_mask: [1] applying auth(=xd) (stop)
Sep 15 08:13:15 mid slapd[5050]: = acl_mask: [1] mask: auth(=xd)
Sep 15 08:13:15 mid slapd[5050]: = slap_access_allowed: read access denied by 
auth(=xd)

Carefully watching logs for both master directory and proxy server, the
master directory is passing the information required.  It's the ACL's on
the proxy that are tripping me up.

search like:

ldapsearch -LLL -Z -x -y ../../private/pwemail '(uid=rpeterso)'

ldaprc like:

BASE ou=email
BINDDN uid=email,ou=admin
URI ldap://proxy.mtholyoke.edu
SIZELIMIT   4
TLS_CACERT /local/etc/cert/ca/cacert.pem

Full config:

databaseldap
suffix  ou=email
uri ldapi://%2Fvar%2Frun%2Fslapd%2Fmastertest%2Fldapi

idassert-bind bindmethod=simple 
binddn=uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu 
credentials=sanitized mode=self

chase-referrals yes
overlay rwm
rwm-rewriteEngine   on

rwm-rewriteMap ldap uid2emailDN 
ldaps://dirt-master.mtholyoke.edu/ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu?dn?sub
 binddn=uid=proxy,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu 
credentials=sanitized

rwm-rewriteMap ldap yid2emailDN 
ldaps://dirt-master.mtholyoke.edu/ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu?dn?sub
 binddn=uid=proxy,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu 
credentials=sanitized

# yUsername is rewritten to uid, so that's what we bind with
rwm-rewriteContext  bindDN
rwm-rewriteRule ^(yDirectoryID=.+),ou=email
${yid2emailDN($1)}
:@I
rwm-rewriteRule ^uid=([a-z0-9_]{3,24}),ou=email
${uid2emailDN(yUsername=$1)}
:@I

rwm-suffixmassage   ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu
rwm-map objectClass   inetOrgPerson yDummyA
rwm-map objectClass   yAccount *
rwm-map objectClass   *
rwm-map attribute givenName yNameFirstLegal
rwm-map attribute sn yNameLastLegal
rwm-map attribute uid yUsername
rwm-map attribute mail yPrimaryEmail
# keep these attribute names the same
rwm-map attribute yDirectoryID *
rwm-map attribute yInstitution *
rwm-map attribute yGlobalPermission *
rwm-map attribute yDefaultApplicationPermission *
rwm-map attribute yApplicationPermission *
rwm-map attribute ySHA1Password *
rwm-map attribute *

access to dn.sub=ou=email
   by dn=uid=proxy,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu read
   by * break

access to dn.sub=ou=email attrs=entry
   by dn=uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu read
   by * break

access to dn.sub=ou=email
   by dn=uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu auth
   by * break

access to dn.sub=ou=email 
filter=((yInstitution=mtholyoke.edu)(yGlobalPermission=allow)(|(yApplicationPermission=email)((yDefaultApplicationPermission=allow)(!(yApplicationPermission=email)
   by anonymous auth
   by dn=uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu read
   by * break

access to dn.regex=(yDirectoryID=.*),ou=email 
filter=((yInstitution=mtholyoke.edu)(yGlobalPermission=allow)(|(yApplicationPermission=email)((yDefaultApplicationPermission=allow)(!(yApplicationPermission=email)
   by dn=uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu read
   by dn.regex=$1,ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu read
   by * none   


-- 
Ron Peterson
Network  Systems Administrator
Mount Holyoke College
http://www.mtholyoke.edu/~rpeterso

ldap proxy acl filter problem

[Ron Peterson]

Hi,

(OpenLDAP version 2.4.23)

I have a filter expression in an ACL that is somehow affecting my
ability to retrieve specific attributes.  What's strange (to me) is that
with or without the filter expression in place, I can retrieve all
attributes, i.e. the full object.

4986# ldapsearch -LLL -Z -x -y ../../private/pwemail '(uid=rpeterso)'
dn: yDirectoryID=c44883ba-ac62-d28c-556f-99ccbf532da7,ou=email
yDirectoryID: c44883ba-ac62-d28c-556f-99ccbf532da7
objectClass: yAccount
objectClass: inetOrgPerson
uid: rpeterso
mail: rpete...@mtholyoke.edu
etc...

But if I specify a particular attribute, then having the filter
expression in place somehow inhibits my ability to retrieve the specific
attribute(s).

Without filter expression:

4987# ldapsearch -LLL -Z -x -y ../../private/pwemail '(uid=rpeterso)' mail
dn: yDirectoryID=c44883ba-ac62-d28c-556f-99ccbf532da7,ou=email
mail: rpete...@mtholyoke.edu

With filter expression in place:

4990# ldapsearch -LLL -Z -x -y ../../private/pwemail '(uid=rpeterso)' mail
dn: yDirectoryID=c44883ba-ac62-d28c-556f-99ccbf532da7,ou=email

The ACL in question looks like:

access to dn.regex=(yDirectoryID=.*),ou=email 
filter=((yInstitution=mtholyoke.edu)(yGlobalPermission=allow)(|(yApplicationPermission=email)((yDefaultApplicationPermission=allow)(!(yApplicationPermission=email)
   by dn.regex=$1,ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu read
   by dn=uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu read
   by * none

I've turned my logging way up, and the hiccup seems to be that the DN
I've authenticated as
(uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu) needs read
access to the attributes in the filter expression.  But how do I give
that account read access to those attributes, without then exposing the
objects that I'm trying to hide with the filter expression?

-- 
Ron Peterson
Network  Systems Administrator
Mount Holyoke College
http://www.mtholyoke.edu/~rpeterso

Re: ldap proxy acl filter problem

[Howard Chu]

Ron Peterson wrote:

Hi,

(OpenLDAP version 2.4.23)

I have a filter expression in an ACL that is somehow affecting my
ability to retrieve specific attributes.  What's strange (to me) is that
with or without the filter expression in place, I can retrieve all
attributes, i.e. the full object.

4986# ldapsearch -LLL -Z -x -y ../../private/pwemail '(uid=rpeterso)'
dn: yDirectoryID=c44883ba-ac62-d28c-556f-99ccbf532da7,ou=email
yDirectoryID: c44883ba-ac62-d28c-556f-99ccbf532da7
objectClass: yAccount
objectClass: inetOrgPerson
uid: rpeterso
mail: rpete...@mtholyoke.edu
etc...

But if I specify a particular attribute, then having the filter
expression in place somehow inhibits my ability to retrieve the specific
attribute(s).

Without filter expression:

4987# ldapsearch -LLL -Z -x -y ../../private/pwemail '(uid=rpeterso)' mail
dn: yDirectoryID=c44883ba-ac62-d28c-556f-99ccbf532da7,ou=email
mail: rpete...@mtholyoke.edu

With filter expression in place:

4990# ldapsearch -LLL -Z -x -y ../../private/pwemail '(uid=rpeterso)' mail
dn: yDirectoryID=c44883ba-ac62-d28c-556f-99ccbf532da7,ou=email

The ACL in question looks like:

access to dn.regex=(yDirectoryID=.*),ou=email 
filter=((yInstitution=mtholyoke.edu)(yGlobalPermission=allow)(|(yApplicationPermission=email)((yDefaultApplicationPermission=allow)(!(yApplicationPermission=email)
by dn.regex=$1,ou=people,ou=accounts,ou=prod,dc=mtholyoke,dc=edu read
by dn=uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu read
by * none

I've turned my logging way up, and the hiccup seems to be that the DN
I've authenticated as
(uid=email,ou=admin,ou=accounts,ou=prod,dc=mtholyoke,dc=edu) needs read
access to the attributes in the filter expression.  But how do I give
that account read access to those attributes, without then exposing the
objects that I'm trying to hide with the filter expression?


Give it auth access, not read access.

--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: LDAP proxy with back_ldap: (?=undefined)

[Quanah Gibson-Mount]

--On Monday, September 12, 2011 6:37 PM + Torsten Schlabach (Tascel 
eG) tschlab...@tascel.net wrote:

Any idea?


Your schemas have to match.  ?=undefined means that you are sending in 
attributes that the server knows nothing about.


--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

Re: LDAP proxy with back_ldap: (?=undefined)

[Howard Chu]

Torsten Schlabach (Tascel eG) wrote:

Hi all!

I am trying to setup the simplest possible LDAP proxy with OpenLDAP.
Actually, I do have a machine with one interface on a public IP address and
the other one on the private network. So all I want is a pass-through of
any LDAP query 1:1 from the proxy which sits on the public IP to an LDAP
server which can be reached only through a private IP on our internal
network.

Here is my config:

database ldap
suffix  o=top
uri  ldap://192.168.12.34/;

My problem is: The query sent to the backend server always contains a
(?=undefined) condition, which leads to no objects found.

In other words, the query I send to the proxy is for example:

((?objectClass=mailalias)(dc=.yy))

The back_ldap will send to the backend server:

(((?objectClass=mailalias)(dc=.yy))(?=undefined))

Any idea?


Turn up debug on slapd and see what filter it actually received. Also, what 
version of OpenLDAP is this?


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: LDAP proxy with back_ldap: (?=undefined)

[Howard Chu]

Quanah Gibson-Mount wrote:

--On Monday, September 12, 2011 6:37 PM + Torsten Schlabach (Tascel
eG)tschlab...@tascel.net  wrote:

Any idea?


Your schemas have to match.  ?=undefined means that you are sending in
attributes that the server knows nothing about.


On recent versions of OpenLDAP it's more specific than that, this only shows 
up for unknown filter operators (which usually means a broken client). Which 
is why I asked what version he's running.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: LDAP proxy with back_ldap: (?=undefined)

[Torsten Schlabach (Tascel eG)]

Hi!

 Which is why I asked what version he's running.

It's 2.4.23; both on the proxy as well as on the backend.

Regards,
Torsten


On Mon, 12 Sep 2011 12:19:38 -0700, Howard Chu h...@symas.com wrote:
 Quanah Gibson-Mount wrote:
 --On Monday, September 12, 2011 6:37 PM + Torsten Schlabach
(Tascel
 eG)tschlab...@tascel.net  wrote:
 Any idea?

 Your schemas have to match.  ?=undefined means that you are sending in
 attributes that the server knows nothing about.
 
 On recent versions of OpenLDAP it's more specific than that, this only
 shows 
 up for unknown filter operators (which usually means a broken client).
 Which 
 is why I asked what version he's running.
 
 -- 
-- Howard Chu
CTO, Symas Corp.   http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP  http://www.openldap.org/project/

Infos needed to setup a ldap proxy

[Frank Bonnet]

Hello

Anyone could send me some pointers on documentation
howto setup a proxy OpenLDAP server ?

Basically I need it to have a unique LDAP server
to configure all our LAN clients and have the possibility
to modify the proxy server on demand to access several
directory servers ( locals and distants )

Thanks

Re: Infos needed to setup a ldap proxy

[Aaron Richton]

On Thu, 31 Mar 2011, Frank Bonnet wrote:


Hello

Anyone could send me some pointers on documentation
howto setup a proxy OpenLDAP server ?


Perhaps start by running/observing the man pages (slapo-pcache etc.), 
Admin Guide (there are sections on Proxy Cache), and the (simple case) 
configuration of test020-proxycache and going from there?



Basically I need it to have a unique LDAP server
to configure all our LAN clients and have the possibility
to modify the proxy server on demand to access several
directory servers ( locals and distants )


If this means modify the server configuration you should be able to do 
that with cn=config in all cases. If this means modify the data on the 
proxy server and have those modifications propagate then you'd probably 
be served by multimaster and/or syncrepl with chains. (Which you also can 
find examples of in the man pages, Admin Guide, and the shipped tests/ 
directory.)




Thanks

Re: Infos needed to setup a ldap proxy

[Dieter Kluenter]

Am Thu, 31 Mar 2011 14:28:19 +0200
schrieb Frank Bonnet f.bon...@esiee.fr:

 
 Hello
 
 Anyone could send me some pointers on documentation
 howto setup a proxy OpenLDAP server ?
 
 Basically I need it to have a unique LDAP server
 to configure all our LAN clients and have the possibility
 to modify the proxy server on demand to access several
 directory servers ( locals and distants )

manual pages: slapd-ldap(5), slapd-meta(5),
http://www.openldap.org/faq/data/cache/532.html
http://www.openldap.org/doc/admin24/backends.html#LDAP
http://www.openldap.org/doc/admin24/backends.html#Metadirectory

-Dieter

-- 
Dieter Klünter | Systemberatung
sip: 7770...@sipgate.de 
http://www.dpunkt.de/buecher/2104.html
GPG Key ID:8EF7B6C6

Re: slapd.d syntax help for ldap proxy server

[Anton Chu]

Does anyone have a working ldap proxy configuration script?  Some attributes
such as olcURI are not welcomed with slapd on ubuntu 10.10.  My goals is to
make a standalone proxy.

TIA,
Anton

On Fri, Feb 4, 2011 at 12:46 PM, Dieter Kluenter die...@dkluenter.dewrote:

 Am Fri, 4 Feb 2011 11:45:36 -0800
 schrieb Anton Chu anton@telecommand.com:

  I'm trying to setup a ldap proxy server for push based replication.
  I'm in need of help with providing the correct syntax on installing a
  ldap proxy using slapd.d instead of slapd.conf.The items in bold
  are the questionable syntax that can crossover to slapd.d.  Here's my
  slapd.d configuration:
 
 
  Standalone LDAP Proxy:
  
   # load the schemas
   ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/cosine.ldif
  
   ldapadd -Y EXTERNAL -H ldapi:///
   -f /etc/ldap/schema/inetorgperson.ldif
  
   ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/nis.ldif
  
   ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/misc.ldif
  
   ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/ldapns.ldif
  
   ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/openldap.ldif
  
  
# Load dynamic backend modules
  
   dn: cn=module,cn=config
  
   objectClass: olcModuleList
  
   cn: module
  
   olcModulepath: /usr/lib/ldap
  
   olcModuleload: back_hdb
  
   olcModuleload: syncprov
  
  
# Database settings
  
   dn: olcDatabase=hdb,cn=config
  
   objectClass: olcDatabaseConfig
  
   objectClass: olcHdbConfig
  
   olcDatabase: {1}hdb

 This should be a ldap database, not a hdb database
  
   databaseldap
   # ignore conflicts with other databases, as we need to push
   out to same suffix hidden  on
   suffix  dc=suretecsystems,dc=com
   rootdn  cn=slapd-ldap
   uri ldap://localhost:9012/
  
   lastmod on
  
   # We don't need any access to this DSA
   restrictall
  
   acl-bindbindmethod=simple
   binddn=cn=replicator,dc=suretecsystems,dc=com
   credentials=testing
  
   syncreplrid=001
   provider=ldap://localhost:9011/
   binddn=cn=replicator,dc=suretecsystems,dc=com
   bindmethod=simple
   credentials=testing
   searchbase=dc=suretecsystems,dc=com
   type=refreshAndPersist
   retry=5 5 300 5
  
   overlay syncprov

 -Dieter

 --
 Dieter Klünter | Systemberatung
 http://dkluenter.de
 GPG Key ID:DA147B05
 53°37'09,95N
 10°08'02,42E

Re: slapd.d syntax help for ldap proxy server

[Howard Chu]

Anton Chu wrote:

Does anyone have a working ldap proxy configuration script?  Some attributes
such as olcURI are not welcomed with slapd on ubuntu 10.10.  My goals is to
make a standalone proxy.


Make sure you're actually using a valid schema.

ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=schema,cn=config -s base

Read the definition of the olcLDAPConfig objectclass.

If you still can't figure that out, then just write a regular slapd.conf and 
convert it to cn=config format using slaptest.



TIA,
Anton

On Fri, Feb 4, 2011 at 12:46 PM, Dieter Kluenter die...@dkluenter.de
mailto:die...@dkluenter.de wrote:

Am Fri, 4 Feb 2011 11:45:36 -0800
schrieb Anton Chu anton@telecommand.com
mailto:anton@telecommand.com:

  I'm trying to setup a ldap proxy server for push based replication.
  I'm in need of help with providing the correct syntax on installing a
  ldap proxy using slapd.d instead of slapd.conf.The items in bold
  are the questionable syntax that can crossover to slapd.d.  Here's my
  slapd.d configuration:
 
 
  Standalone LDAP Proxy:
  
   # load the schemas
   ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/cosine.ldif
  
   ldapadd -Y EXTERNAL -H ldapi:///
   -f /etc/ldap/schema/inetorgperson.ldif
  
   ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/nis.ldif
  
   ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/misc.ldif
  
   ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/ldapns.ldif
  
   ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/openldap.ldif
  
  
# Load dynamic backend modules
  
   dn: cn=module,cn=config
  
   objectClass: olcModuleList
  
   cn: module
  
   olcModulepath: /usr/lib/ldap
  
   olcModuleload: back_hdb
  
   olcModuleload: syncprov
  
  
# Database settings
  
   dn: olcDatabase=hdb,cn=config
  
   objectClass: olcDatabaseConfig
  
   objectClass: olcHdbConfig
  
   olcDatabase: {1}hdb

This should be a ldap database, not a hdb database
  
   databaseldap
   # ignore conflicts with other databases, as we need to push
   out to same suffix hidden  on
   suffix dc=suretecsystems,dc=com
   rootdn cn=slapd-ldap
   uri ldap://localhost:9012/
  
   lastmod on
  
   # We don't need any access to this DSA
   restrictall
  
   acl-bindbindmethod=simple
   binddn=cn=replicator,dc=suretecsystems,dc=com
   credentials=testing
  
   syncreplrid=001
   provider=ldap://localhost:9011/
   binddn=cn=replicator,dc=suretecsystems,dc=com
   bindmethod=simple
   credentials=testing
   searchbase=dc=suretecsystems,dc=com
   type=refreshAndPersist
   retry=5 5 300 5
  
   overlay syncprov

-Dieter

--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:DA147B05
53°37'09,95N
10°08'02,42E





--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: slapd.d syntax help for ldap proxy server

[masarati]

 Does anyone have a working ldap proxy configuration script?  Some
 attributes
 such as olcURI are not welcomed with slapd on ubuntu 10.10.  My goals is
 to
 make a standalone proxy.

s/olcURI/olcDbURI/

AFAIK, there's no specific documentation of slapd-ldap config schema; you
can configure it using slapd.conf, then slapcat the resulting cn=config
entry.

p.




 TIA,
 Anton

 On Fri, Feb 4, 2011 at 12:46 PM, Dieter Kluenter
 die...@dkluenter.dewrote:

 Am Fri, 4 Feb 2011 11:45:36 -0800
 schrieb Anton Chu anton@telecommand.com:

  I'm trying to setup a ldap proxy server for push based replication.
  I'm in need of help with providing the correct syntax on installing a
  ldap proxy using slapd.d instead of slapd.conf.The items in bold
  are the questionable syntax that can crossover to slapd.d.  Here's my
  slapd.d configuration:
 
 
  Standalone LDAP Proxy:
  
   # load the schemas
   ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/cosine.ldif
  
   ldapadd -Y EXTERNAL -H ldapi:///
   -f /etc/ldap/schema/inetorgperson.ldif
  
   ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/nis.ldif
  
   ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/misc.ldif
  
   ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/ldapns.ldif
  
   ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/openldap.ldif
  
  
# Load dynamic backend modules
  
   dn: cn=module,cn=config
  
   objectClass: olcModuleList
  
   cn: module
  
   olcModulepath: /usr/lib/ldap
  
   olcModuleload: back_hdb
  
   olcModuleload: syncprov
  
  
# Database settings
  
   dn: olcDatabase=hdb,cn=config
  
   objectClass: olcDatabaseConfig
  
   objectClass: olcHdbConfig
  
   olcDatabase: {1}hdb

 This should be a ldap database, not a hdb database
  
   databaseldap
   # ignore conflicts with other databases, as we need to push
   out to same suffix hidden  on
   suffix  dc=suretecsystems,dc=com
   rootdn  cn=slapd-ldap
   uri ldap://localhost:9012/
  
   lastmod on
  
   # We don't need any access to this DSA
   restrictall
  
   acl-bindbindmethod=simple
   binddn=cn=replicator,dc=suretecsystems,dc=com
   credentials=testing
  
   syncreplrid=001
   provider=ldap://localhost:9011/
   binddn=cn=replicator,dc=suretecsystems,dc=com
   bindmethod=simple
   credentials=testing
   searchbase=dc=suretecsystems,dc=com
   type=refreshAndPersist
   retry=5 5 300 5
  
   overlay syncprov

 -Dieter

 --
 Dieter Klünter | Systemberatung
 http://dkluenter.de
 GPG Key ID:DA147B05
 53°37'09,95N
 10°08'02,42E

slapd.d syntax help for ldap proxy server

[Anton Chu]

I'm trying to setup a ldap proxy server for push based replication.  I'm in
need of help with providing the correct syntax on installing a ldap proxy
using slapd.d instead of slapd.conf.The items in bold are the
questionable syntax that can crossover to slapd.d.  Here's my slapd.d
configuration:


Standalone LDAP Proxy:

 # load the schemas
 ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/cosine.ldif

 ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/inetorgperson.ldif

 ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/nis.ldif

 ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/misc.ldif

 ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/ldapns.ldif

 ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/openldap.ldif


  # Load dynamic backend modules

 dn: cn=module,cn=config

 objectClass: olcModuleList

 cn: module

 olcModulepath: /usr/lib/ldap

 olcModuleload: back_hdb

 olcModuleload: syncprov


  # Database settings

 dn: olcDatabase=hdb,cn=config

 objectClass: olcDatabaseConfig

 objectClass: olcHdbConfig

 olcDatabase: {1}hdb

 *olcHidden: TRUE*

 olcSuffix: dc=suretecsystems,dc=com

 olcDbDirectory: /var/lib/ldap

 olcRootDN: cn=admin,dc=suretecsystems,dc=com

 olcRootPW: secret

 *olcUri: ldap://localhost:9012/*



  # We don't need any access to this DSA

 *olcRestrict:  ALL

 olcAcl-bind: bindmethod=simple
  binddn=cn=replicator,dc=suretecsystems,dc=com
  credentials=testing*

 olcSyncrepl: rid=001
  provider=ldap://localhost:9011/
  binddn=cn=replicator,dc=suretecsystems,dc=com
  bindmethod=simple
  credentials=testing
  searchbase=dc=suretecsystems,dc=com
  type=refreshAndPersist
  retry=5 5 300 5




Here's the slapd.conf provided at the site that I'm trying to convert:
http://www.openldap.org/doc/admin24/replication.html

The following configuration is an example of a standalone LDAP Proxy:

 include /usr/local/etc/openldap/schema/core.schema
 include /usr/local/etc/openldap/schema/cosine.schema
 include /usr/local/etc/openldap/schema/nis.schema
 include /usr/local/etc/openldap/schema/inetorgperson.schema

 include /usr/local/etc/openldap/slapd.acl

 modulepath  /usr/local/libexec/openldap
 moduleload  syncprov.la
 moduleload  back_ldap.la

 
 ##
 # Consumer Proxy that pulls in data via Syncrepl and pushes out via 
 slapd-ldap
 
 ##

 databaseldap
 # ignore conflicts with other databases, as we need to push out to 
 same suffix
 hidden  on
 suffix  dc=suretecsystems,dc=com
 rootdn  cn=slapd-ldap
 uri ldap://localhost:9012/

 lastmod on

 # We don't need any access to this DSA
 restrictall

 acl-bindbindmethod=simple
 binddn=cn=replicator,dc=suretecsystems,dc=com
 credentials=testing

 syncreplrid=001
 provider=ldap://localhost:9011/
 binddn=cn=replicator,dc=suretecsystems,dc=com
 bindmethod=simple
 credentials=testing
 searchbase=dc=suretecsystems,dc=com
 type=refreshAndPersist
 retry=5 5 300 5

 overlay syncprov

Re: slapd.d syntax help for ldap proxy server

[Dieter Kluenter]

Am Fri, 4 Feb 2011 11:45:36 -0800
schrieb Anton Chu anton@telecommand.com:

 I'm trying to setup a ldap proxy server for push based replication.
 I'm in need of help with providing the correct syntax on installing a
 ldap proxy using slapd.d instead of slapd.conf.The items in bold
 are the questionable syntax that can crossover to slapd.d.  Here's my
 slapd.d configuration:
 
 
 Standalone LDAP Proxy:
 
  # load the schemas
  ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/cosine.ldif
 
  ldapadd -Y EXTERNAL -H ldapi:///
  -f /etc/ldap/schema/inetorgperson.ldif
 
  ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/nis.ldif
 
  ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/misc.ldif
 
  ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/ldapns.ldif
 
  ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/openldap.ldif
 
 
   # Load dynamic backend modules
 
  dn: cn=module,cn=config
 
  objectClass: olcModuleList
 
  cn: module
 
  olcModulepath: /usr/lib/ldap
 
  olcModuleload: back_hdb
 
  olcModuleload: syncprov
 
 
   # Database settings
 
  dn: olcDatabase=hdb,cn=config
 
  objectClass: olcDatabaseConfig
 
  objectClass: olcHdbConfig
 
  olcDatabase: {1}hdb

This should be a ldap database, not a hdb database
 
  databaseldap
  # ignore conflicts with other databases, as we need to push
  out to same suffix hidden  on
  suffix  dc=suretecsystems,dc=com
  rootdn  cn=slapd-ldap
  uri ldap://localhost:9012/
 
  lastmod on
 
  # We don't need any access to this DSA
  restrictall
 
  acl-bindbindmethod=simple
  binddn=cn=replicator,dc=suretecsystems,dc=com
  credentials=testing
 
  syncreplrid=001
  provider=ldap://localhost:9011/
  binddn=cn=replicator,dc=suretecsystems,dc=com
  bindmethod=simple
  credentials=testing
  searchbase=dc=suretecsystems,dc=com
  type=refreshAndPersist
  retry=5 5 300 5
 
  overlay syncprov

-Dieter

-- 
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:DA147B05
53°37'09,95N
10°08'02,42E

Re: Certificate authentication and back-ldap proxy

[Dieter Kluenter]

Am Tue, 28 Dec 2010 14:31:46 +
schrieb Ubay Dorta Guerra udo...@iac.es:

 Hi,
 
 El 28/12/10 12:00, openldap-technical-requ...@openldap.org escribió:
  Hi,
  Am Mon, 27 Dec 2010 15:15:21 +
  schrieb Ubay Dorta Guerra udo...@iac.es:
 

   The simple bind under TLS worked but when i try to use
  cert-based SASL EXTERNAL authentication i get no success.
 
 In the proxy server configuration i add the following directive
 
  idassert-bind   bindmethod=sasl
  saslmech=EXTERNAL
  binddn=CN=proxy-server1.example.com,O=Internet
  
  the binddn should be empty or just don't configure a binddn.
 

 
 Thank you very much.
 
 I have deleted the binddn in proxy configuration:
 
 idassert-bind   bindmethod=sasl
 saslmech=EXTERNAL
 tls_cert=/etc/ssl/certs/proxy-server1.example.com.pem
 tls_key=/etc/ssl/private/proxy-server1.example.com.key
 tls_cacertdir=/etc/ssl/cacerts/
 tls_reqcert=demand
 mode=self
 
 Now when i make a password change:
 
 ldapmodify -x -H ldaps://proxy-server1.example.com -f pass2_user.ldif
 -D 'uid=user_w_pass,ou=people,dc=example,dc=com' -W
 Enter LDAP Password:
 modifying entry uid=user_w_pass,ou=people,dc=example,dc=com

For password modification you should probably call the extended
operation modifiy password  (RFC-3206), which is supported by
ldappasswd(5).

-Dieter

-- 
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:DA147B05
53°37'09,95N
10°08'02,42E

Re: Certificate authentication and back-ldap proxy

[Ubay Dorta Guerra]

Hi,

El 23/04/10 17:17, masar...@aero.polimi.it escribió:

 The problem is that you probably do not realize that the proxy cannot do a
 cert-based authentication on behalf of the client because it doesn't have
 the client's private key (which is correct).  You need the proxy perform
 an identity assertion: bind to the remote server with its own identity,
 and then assert the client's identity using proxy authorization.

 To do this, you need to:

 a) define some means for the proxy to bind to the remote server, e.g.
 using cert-based SASL EXTERNAL, or simple bind under TLS, or whatever;

 b) configure the remote server so that the proxy's identity defined in (a)
 is allowed to proxy authz as whatever client's identity you want to
 accept; this requires to use the directive authz-policy; you may need to
 use the authz-regexp if you intend to map the client's identity; and
 you'll need to populate the authzTo operational attribute of the entry
 corresponding to the proxy's identity.

 c) add to the proxy configuration the directive

 idassert-bind bindmethod=what you chose for (a)
 bind parameters for (a)
 mode=self

   

 The simple bind under TLS worked but when i try to use cert-based
SASL EXTERNAL authentication i get no success.

   In the proxy server configuration i add the following directive

idassert-bind   bindmethod=sasl
saslmech=EXTERNAL
binddn=CN=proxy-server1.example.com,O=Internet Widgits
Pty Ltd,ST=Some-State,C=AU
tls_cert=/etc/ssl/certs/proxy-server1.example.com.pem
tls_key=/etc/ssl/private/proxy-server1.example.com.key
tls_cacertdir=/etc/ssl/cacerts/
tls_reqcert=demand
mode=self


In the master (remote) server i set:

#
# Authz
#
authz-policy to
authz-regexp CN=proxy-server1.example.com,O=Internet Widgits Pty
Ltd,ST=Some-State,C=AU cn=proxy_id,dc=example,dc=com

The cn=proxy_id,dc=example,dc=com has the following content:

ldapsearch -LLL -b 'cn=proxy_id,dc=example,dc=com' -H
ldaps://proxy-server1.example.com -x -D 'cn=Manager,dc=example,dc=com'
-w secret authzTo
dn: cn=proxy_id,dc=example,dc=com
authzTo: ldap:///ou=people,dc=example,dc=com??sub?(objectClass=person)


  But when i try to modify a password through the proxy i get the
following error:
ldapmodify -x -H ldaps://proxy-server1.example.com -f pass2_user.ldif -D
'uid=user_w_pass,ou=people,dc=example,dc=com' -W
Enter LDAP Password:
modifying entry uid=user_w_pass,ou=people,dc=example,dc=com
ldap_modify: Insufficient access (50)

 With simple bind i got the following message in syslog:
ldap-master[11314]: conn=1002 op=1 PROXYAUTHZ
dn=uid=user_w_pass,ou=people,dc=example,dc=com
But not in the cert-based SASL EXTERNAL case.

Is there something wrong in the configuration?

Thanks in advance.

 This way, the proxy will:

 - authc the client locally

 - authc as itself with respect to the remote host

 - proxy operations adding the proxyAuthz control with the identity of the
 client

 See slapd-ldap(5) for details on the syntax of the idassert-* directives.

 p.

   

-
ADVERTENCIA: Sobre la privacidad y cumplimiento de la Ley de Protección de 
Datos, acceda a http://www.iac.es/disclaimer.php
WARNING: For more information on privacy and fulfilment of the Law concerning 
the Protection of Data, consult http://www.iac.es/disclaimer.php?lang=en
attachment: udorta.vcf

Re: Certificate authentication and back-ldap proxy

[Dieter Kluenter]

Hi,

Am Mon, 27 Dec 2010 15:15:21 +
schrieb Ubay Dorta Guerra udo...@iac.es:

 Hi,
 
 El 23/04/10 17:17, masar...@aero.polimi.it escribió:
 
  The problem is that you probably do not realize that the proxy
  cannot do a cert-based authentication on behalf of the client
  because it doesn't have the client's private key (which is
  correct).  You need the proxy perform an identity assertion: bind
  to the remote server with its own identity, and then assert the
  client's identity using proxy authorization.
 
  To do this, you need to:
 
  a) define some means for the proxy to bind to the remote server,
  e.g. using cert-based SASL EXTERNAL, or simple bind under TLS, or
  whatever;
 
  b) configure the remote server so that the proxy's identity defined
  in (a) is allowed to proxy authz as whatever client's identity you
  want to accept; this requires to use the directive authz-policy;
  you may need to use the authz-regexp if you intend to map the
  client's identity; and you'll need to populate the authzTo
  operational attribute of the entry corresponding to the proxy's
  identity.
 
  c) add to the proxy configuration the directive
 
  idassert-bind bindmethod=what you chose for (a)
  bind parameters for (a)
  mode=self
 

 
  The simple bind under TLS worked but when i try to use cert-based
 SASL EXTERNAL authentication i get no success.
 
In the proxy server configuration i add the following directive
 
 idassert-bind   bindmethod=sasl
 saslmech=EXTERNAL
 binddn=CN=proxy-server1.example.com,O=Internet

the binddn should be empty or just don't configure a binddn.

 Widgits Pty Ltd,ST=Some-State,C=AU
 tls_cert=/etc/ssl/certs/proxy-server1.example.com.pem
 tls_key=/etc/ssl/private/proxy-server1.example.com.key
 tls_cacertdir=/etc/ssl/cacerts/
 tls_reqcert=demand
 mode=self
 
 
 In the master (remote) server i set:

Did you ever test the certificate chain?
Create a file ~/.ldaprc with
TLS_CERT /etc/ssl/certs/proxy-server1.example.com.pem
TLS_KEY  /etc/ssl/certs/proxy-server1.example.com.key
TLS_CACERTDIR /etc/ssl/cacerts

and run ldapwoami -Y EXTERNAL -ZZ ldap://your.host


-Dieter

-- 
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:DA147B05
53°37'09,95N
10°08'02,42E

LDAP proxy with local database

[Tunguskin Petr]

Hello.

I have one program which can authenticate with LDAP server and Active Directory 
with read access.
I need to authenticate extra users, but I can't add them to Active Directory 
for security reasons. Program can work with only one LDAP source.

I have tryed to use openldap chain overlay to join local and remote LDAP 
databases with refferals. Search works fine, but bind operation doesn't work, 
openldap writes error:
= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989)

Is it possible to bind to remote LDAP records with chain overlay?

--
databasebdb
suffix  dc=local
rootdn  cn=ldapadmin,dc=local
rootpw  12345678

directory   /var/lib/ldap

overlay   chain
chain-uri ldap://10.1.1.1/;
chain-rebind-as-userTRUE
chain-cache-uri true
chain-chaining  resolve=chainingRequired continuation=chainingRequired
chain-idassert-bind bindmethod=simple
  binddn=cn=ldapuser,cn=Users,dc=test,dc=local
  credentials=123
  mode=none


Could you recommend another solution?

Thank you
-- 

Re: LDAP proxy with local database

[Jonathan Clarke]

On 30/06/2010 12:14, Tunguskin Petr wrote:

Hello.

I have one program which can authenticate with LDAP server and Active Directory 
with read access.
I need to authenticate extra users, but I can't add them to Active Directory 
for security reasons. Program can work with only one LDAP source.

I have tryed to use openldap chain overlay to join local and remote LDAP 
databases with refferals. Search works fine, but bind operation doesn't work, 
openldap writes error:
= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989)

Is it possible to bind to remote LDAP records with chain overlay?

--
databasebdb
suffix  dc=local
rootdn  cn=ldapadmin,dc=local
rootpw  12345678

directory   /var/lib/ldap

overlay   chain
chain-uri ldap://10.1.1.1/;
chain-rebind-as-userTRUE
chain-cache-uri true
chain-chaining  resolve=chainingRequired continuation=chainingRequired
chain-idassert-bind bindmethod=simple
   binddn=cn=ldapuser,cn=Users,dc=test,dc=local
   credentials=123
   mode=none


Could you recommend another solution?


Yes, using a proxy with multiple backends. See slapd-meta(5), and this 
recent question on this list:


http://www.openldap.org/lists/openldap-technical/201006/msg00225.html

Regards,
Jonathan
--
--
Jonathan Clarke - jonat...@phillipoux.net
--
Ldap Synchronization Connector (LSC) - http://lsc-project.org
--

Write through an LDAP Proxy?

[Christoph Berkemeier]

Greetings,

i would like to use multiple OpenLDAP Server with Samba. As Samba uses
only one database server, i considered it would be suitable to use a
ldap proxy in front of my master and my slaves servers. I tried it with
the proxycache overlay, but after some testing and combing the internet
for information it seems this does not work for write-request.

Is this information correct? And if it is, are there some alternatives?

Best Regards,
Christoph Berkemeier

Re: Write through an LDAP Proxy?

[Aaron Richton]

On Fri, 4 Jun 2010, Christoph Berkemeier wrote:


i would like to use multiple OpenLDAP Server with Samba. As Samba uses
only one database server, i considered it would be suitable to use a
ldap proxy in front of my master and my slaves servers. I tried it with
the proxycache overlay, but after some testing and combing the internet
for information it seems this does not work for write-request.


It sounds like you're getting write referrals from your replicas. 
slapo-chain can chase those referrals server-side. You can run test032 to 
see a chain configuration in action; also read through slapd-ldap(5) and 
slapo-chain(5) man pages for background.

Re: Write through an LDAP Proxy?

[Jonathan Clarke]

On 04/06/2010 12:55, Christoph Berkemeier wrote:

Greetings,

i would like to use multiple OpenLDAP Server with Samba. As Samba uses
only one database server, i considered it would be suitable to use a
ldap proxy in front of my master and my slaves servers. I tried it with
the proxycache overlay, but after some testing and combing the internet
for information it seems this does not work for write-request.

Is this information correct? And if it is, are there some alternatives?


The proxycache overlay is designed to keep a local cache of requests 
(searches and binds if I recall correctly) to a distant LDAP server.


If you just want an LDAP proxy with multiple backends, take a look at 
the meta and ldap backends:


http://www.openldap.org/software/man.cgi?query=slapd-meta

Hope this helps,
Jonathan
--
--
Jonathan Clarke - jonat...@phillipoux.net
--
Ldap Synchronization Connector (LSC) - http://lsc-project.org
--

Re: Write through an LDAP Proxy?

[Buchan Milne]

On Friday, 4 June 2010 11:55:16 Christoph Berkemeier wrote:
 Greetings,
 
 i would like to use multiple OpenLDAP Server with Samba. As Samba uses
 only one database server



 , i considered it would be suitable to use a
 ldap proxy in front of my master and my slaves servers.

For a single-master, multiple-slaves scenario, samba has supported this since 
about 2.2.5.

Or, can you provide more details on the exact scenario, configuration extracts 
(e.g. passdb backend, ldap replication sleep) from your smb.conf, and error 
messages when problems occur etc.

Regards,
Buchan

Re: Write through an LDAP Proxy?

[Buchan Milne]

On Friday, 4 June 2010 15:27:12 Christoph Berkemeier wrote:
 Buchan Milne schrieb:
  On Friday, 4 June 2010 11:55:16 Christoph Berkemeier wrote:
  Greetings,
 
  i would like to use multiple OpenLDAP Server with Samba. As Samba uses
  only one database server
 
  , i considered it would be suitable to use a
  ldap proxy in front of my master and my slaves servers.
 
  For a single-master, multiple-slaves scenario, samba has supported this
  since about 2.2.5.
 
 The support was removed in 3.0.23 as you can read in
 http://www.samba.org/samba/history/samba-3.0.23.html:
 
 ##
 Passdb Changes
 ==
 
 The passdb backend parameter no long accepts multiple backends
 in a chaining configuration.
 ##
 
 The feature was removed, because, as far as i can remember, it need a
 lot of maintance.

But, a single passdb backend can specify multiple LDAP servers, as shown in 
the examples in the smb.conf man page:


   Multiple servers may also be specified in double-quotes.
   Whether multiple servers are supported or not and the exact
   syntax depends on the LDAP library you use.

Examples of use are:

   passdb backend = tdbsam:/etc/samba/private/passdb.tdb

   or multi server LDAP URL with OpenLDAP library:

   passdb backend = ldapsam:ldap://ldap-1.example.com 
ldap://ldap-2.example.com;




Regards,
Buchan

Re: Write through an LDAP Proxy?

[Christoph Berkemeier]

Aaron Richton schrieb:
 On Fri, 4 Jun 2010, Christoph Berkemeier wrote:
 
 i would like to use multiple OpenLDAP Server with Samba. As Samba uses
 only one database server, i considered it would be suitable to use a
 ldap proxy in front of my master and my slaves servers. I tried it with
 the proxycache overlay, but after some testing and combing the internet
 for information it seems this does not work for write-request.
 
 It sounds like you're getting write referrals from your replicas.
 slapo-chain can chase those referrals server-side. You can run test032
 to see a chain configuration in action; also read through slapd-ldap(5)
 and slapo-chain(5) man pages for background.


slapo-chain is another good hint, i take a look at it. Thanks for your help.

Best Regards,
Christoph Berkemeier



signature.asc
Description: OpenPGP digital signature

Re: Write through an LDAP Proxy?

[Christoph Berkemeier]

Buchan Milne schrieb:
 On Friday, 4 June 2010 15:27:12 Christoph Berkemeier wrote:
 Buchan Milne schrieb:
 On Friday, 4 June 2010 11:55:16 Christoph Berkemeier wrote:
[...]
 
 But, a single passdb backend can specify multiple LDAP servers, as shown in 
 the examples in the smb.conf man page:
 
 
Multiple servers may also be specified in double-quotes.
Whether multiple servers are supported or not and the exact
syntax depends on the LDAP library you use.
 
 Examples of use are:
 
passdb backend = tdbsam:/etc/samba/private/passdb.tdb
 
or multi server LDAP URL with OpenLDAP library:
 
passdb backend = ldapsam:ldap://ldap-1.example.com 
 ldap://ldap-2.example.com;
 
 

I think i tried this already, but as i am not completly sure, i will try
it again on the next occasion. Thank you for your help.

Best Regards
Christoph Berkemeier



signature.asc
Description: OpenPGP digital signature

Certificate authentication and back-ldap proxy

[Ubay Dorta Guerra]

Hi,

   We have some problems with certificate authentication when the master
server is behind a back-ldap proxy.

   We have openldap 2.4.21 on Suse Linux Enterprise Server  10 SP3 and
these are the details of our scenario:

   The master server: server1.example.com has the following slapd.conf file:

access to dn.base=
by * read   

access to dn.base=cn=Subschema
by * read  

access to attrs=userPassword,userPKCS12
by self write 
by dn.exact=CN=admin_w_cert,O=Internet Widgits Pty
Ltd,ST=Some-State,C=AU read
by *
auth  

access to attrs=shadowLastChange
by self write  
by * read  

access to *
by * read

#
# Security SSL
#
TLSCipherSuite HIGH:MEDIUM:+SSLv3
TLSCertificateFile /etc/ssl/certs/server1.example.com.pem
TLSCertificateKeyFile /etc/ssl/private/server1.example.com.key
TLSCACertificatePath /etc/ssl/cacerts/
TLSVerifyClient demand

#
#Log level
#
loglevel 256

# Require authentication
require authc

###
# HDB database definitions
###

databasehdb
suffix  dc=example,dc=com
checkpoint  10245
cachesize   1
rootdn  cn=Manager,dc=example,dc=com

rootpw  secret

# Indices to maintain
index   objectClass eq

# Overlay ppolicy
overlay ppolicy

--

   Authentication is required, and we give access to the user passwords
for the dn of a certificate.

   When we search for passwords using the certificate we get the following:

root# ldapsearch -LLL -b 'uid=user_w_pass,ou=people,dc=example,dc=com'
-H ldaps://server1.example.com userPassword

SASL/EXTERNAL authentication started
SASL username: CN=admin_w_cert,O=Internet Widgits Pty Ltd,ST=Some-State,C=AU
SASL SSF: 0
dn: uid=user_w_pass,ou=people,dc=example,dc=com
userPassword:: e2NyeXB0fTcyMXpQbU4waWdKaU0=

---

  The root user (ldap client) has a ~/.ldaprc file with:
TLS_CACERTDIR /etc/ssl/cacerts/
TLS_CERT /etc/ssl/certs/admin_w_cert.pem
TLS_KEY /etc/ssl/private/admin_w_cert.key
TLS_REQCERT demand
SASL_MECH EXTERNAL

   In /var/log/messages we get:
ldap-master[22358]: conn=1000 fd=11 ACCEPT from
IP=server1.example.com:40899 (IP=server1.example.com:636)
ldap-master[22358]: conn=1000 fd=11 TLS established tls_ssf=256 ssf=256
ldap-master[22358]: conn=1000 op=0 BIND dn= method=163
ldap-master[22358]: conn=1000 op=0 BIND
authcid=cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au
authzid=cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au
ldap-master[22358]: conn=1000 op=0 BIND dn=cn=admin_w_cert,o=internet
widgits pty ltd,st=some-state,c=au mech=EXTERNAL sasl_ssf=0 ssf=256
ldap-master[22358]: conn=1000 op=0 RESULT tag=97 err=0 text=
ldap-master[22358]: conn=1000 op=1 SRCH
base=uid=user_w_pass,ou=people,dc=example,dc=com scope=2 deref=0
filter=(objectClass=*)
ldap-master[22358]: conn=1000 op=1 SRCH attr=userPassword
ldap-master[22358]: conn=1000 op=1 SEARCH RESULT tag=101 err=0
nentries=1 text=
ldap-master[22358]: conn=1000 op=2 UNBIND
ldap-master[22358]: conn=1000 fd=11 closed

   This is the correct behavior for us. The problem appears when we
introduce a back-ldap proxy between the client and the master.
   The proxy server (proxy-server1.example.com) is listening in port
1636 and its slapd.conf file is:

#
# Security SSL
#
TLSCipherSuite HIGH:MEDIUM:+SSLv3
TLSCACertificatePath /etc/ssl/cacerts/
TLSCertificateFile /etc/ssl/certs/proxy-server1.example.com.pem
TLSCertificateKeyFile /etc/ssl/private/proxy-server1.example.com.key
TLSVerifyClient demand

# Log level
loglevel 256

###
# Database definitions
###
databaseldap

rebind-as-user  true

suffix  dc=example,dc=com

uri ldaps://server1.example.com
tls ldaps
tls_cert=/etc/ssl/certs/proxy-server1.example.com.pem
tls_key=/etc/ssl/private/proxy-server1.example.com.key
tls_cacertdir=/etc/ssl/cacerts/

--

   If we search for passwords through the proxy we get:
root # ldapsearch -LLL -b 'uid=user_w_pass,ou=people,dc=example,dc=com'
-H ldaps://proxy-server1.example.com:1636 userPassword

SASL/EXTERNAL authentication started
SASL username: CN=admin_w_cert,O=Internet Widgits Pty Ltd,ST=Some-State,C=AU
SASL SSF: 0
Server is unwilling to perform (53)
Additional information: authentication required

In the /var/log/messages the following messages appear:
ldap-proxy[22802]: conn=1001 fd=8 ACCEPT from
IP=proxy-server1.example.com:60712 (IP=proxy-server1.example.com:1636)
ldap-proxy[22802

Re: Certificate authentication and back-ldap proxy

[masarati]

 Hi,

We have some problems with certificate authentication when the master
 server is behind a back-ldap proxy.

We have openldap 2.4.21 on Suse Linux Enterprise Server  10 SP3 and
 these are the details of our scenario:

The master server: server1.example.com has the following slapd.conf
 file:

 access to dn.base=
 by * read

 access to dn.base=cn=Subschema
 by * read

 access to attrs=userPassword,userPKCS12
 by self write
 by dn.exact=CN=admin_w_cert,O=Internet Widgits Pty
 Ltd,ST=Some-State,C=AU read
 by *
 auth

 access to attrs=shadowLastChange
 by self write
 by * read

 access to *
 by * read

 #
 # Security SSL
 #
 TLSCipherSuite HIGH:MEDIUM:+SSLv3
 TLSCertificateFile /etc/ssl/certs/server1.example.com.pem
 TLSCertificateKeyFile /etc/ssl/private/server1.example.com.key
 TLSCACertificatePath /etc/ssl/cacerts/
 TLSVerifyClient demand

 #
 #Log level
 #
 loglevel 256

 # Require authentication
 require authc

 ###
 # HDB database definitions
 ###

 databasehdb
 suffix  dc=example,dc=com
 checkpoint  10245
 cachesize   1
 rootdn  cn=Manager,dc=example,dc=com

 rootpw  secret

 # Indices to maintain
 index   objectClass eq

 # Overlay ppolicy
 overlay ppolicy

 --

Authentication is required, and we give access to the user passwords
 for the dn of a certificate.

When we search for passwords using the certificate we get the
 following:

 root# ldapsearch -LLL -b 'uid=user_w_pass,ou=people,dc=example,dc=com'
 -H ldaps://server1.example.com userPassword

 SASL/EXTERNAL authentication started
 SASL username: CN=admin_w_cert,O=Internet Widgits Pty
 Ltd,ST=Some-State,C=AU
 SASL SSF: 0
 dn: uid=user_w_pass,ou=people,dc=example,dc=com
 userPassword:: e2NyeXB0fTcyMXpQbU4waWdKaU0=

 ---

   The root user (ldap client) has a ~/.ldaprc file with:
 TLS_CACERTDIR /etc/ssl/cacerts/
 TLS_CERT /etc/ssl/certs/admin_w_cert.pem
 TLS_KEY /etc/ssl/private/admin_w_cert.key
 TLS_REQCERT demand
 SASL_MECH EXTERNAL

In /var/log/messages we get:
 ldap-master[22358]: conn=1000 fd=11 ACCEPT from
 IP=server1.example.com:40899 (IP=server1.example.com:636)
 ldap-master[22358]: conn=1000 fd=11 TLS established tls_ssf=256 ssf=256
 ldap-master[22358]: conn=1000 op=0 BIND dn= method=163
 ldap-master[22358]: conn=1000 op=0 BIND
 authcid=cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au
 authzid=cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au
 ldap-master[22358]: conn=1000 op=0 BIND dn=cn=admin_w_cert,o=internet
 widgits pty ltd,st=some-state,c=au mech=EXTERNAL sasl_ssf=0 ssf=256
 ldap-master[22358]: conn=1000 op=0 RESULT tag=97 err=0 text=
 ldap-master[22358]: conn=1000 op=1 SRCH
 base=uid=user_w_pass,ou=people,dc=example,dc=com scope=2 deref=0
 filter=(objectClass=*)
 ldap-master[22358]: conn=1000 op=1 SRCH attr=userPassword
 ldap-master[22358]: conn=1000 op=1 SEARCH RESULT tag=101 err=0
 nentries=1 text=
 ldap-master[22358]: conn=1000 op=2 UNBIND
 ldap-master[22358]: conn=1000 fd=11 closed

This is the correct behavior for us. The problem appears when we
 introduce a back-ldap proxy between the client and the master.
The proxy server (proxy-server1.example.com) is listening in port
 1636 and its slapd.conf file is:

 #
 # Security SSL
 #
 TLSCipherSuite HIGH:MEDIUM:+SSLv3
 TLSCACertificatePath /etc/ssl/cacerts/
 TLSCertificateFile /etc/ssl/certs/proxy-server1.example.com.pem
 TLSCertificateKeyFile /etc/ssl/private/proxy-server1.example.com.key
 TLSVerifyClient demand

 # Log level
 loglevel 256

 ###
 # Database definitions
 ###
 databaseldap

 rebind-as-user  true

 suffix  dc=example,dc=com

 uri ldaps://server1.example.com
 tls ldaps
 tls_cert=/etc/ssl/certs/proxy-server1.example.com.pem
 tls_key=/etc/ssl/private/proxy-server1.example.com.key
 tls_cacertdir=/etc/ssl/cacerts/

 --

If we search for passwords through the proxy we get:
 root # ldapsearch -LLL -b 'uid=user_w_pass,ou=people,dc=example,dc=com'
 -H ldaps://proxy-server1.example.com:1636 userPassword

 SASL/EXTERNAL authentication started
 SASL username: CN=admin_w_cert,O=Internet Widgits Pty
 Ltd,ST=Some-State,C=AU
 SASL SSF: 0
 Server is unwilling to perform (53)
 Additional information: authentication required

 In the /var/log/messages the following messages appear:
 ldap-proxy[22802]: conn=1001 fd=8 ACCEPT from
 IP=proxy-server1.example.com:60712 (IP=proxy-server1.example.com:1636)
 ldap-proxy[22802]: conn=1001 fd=8 TLS established tls_ssf=256 ssf=256
 ldap-proxy[22802]: conn

Re: Slapd-ldap proxy between replica and mirror

[Ubay Dorta]

Hi,

   Ok, i understand that the problem is authorization, but when i supress
the back-ldap proxy from my scenario it works.
I am going to give more details.

First Scenario:
-

A delta syncrepl server replicating from the first server of a mirror.

IPs: delta syncrepl (192.168.1.5), mirror server 1 (192.168.1.10), mirror
server 2 (192.168.1.20)

replica slapd.conf

#
#  Chaining configuration #
#
overlay chain
chain-uri   ldap://mirror1:389 http://192.168.1.10:389/
chain-idassert-bind bindmethod=simple
binddn=cn=replicator,dc=example,dc=com
credentials=secret
mode=self
chain-return-error  TRUE

##
#  Replica  #
##
database bdb
suffix dc=example,dc=com
rootdn cn=Administrator,dc=example,dc=com
rootpw secret
checkpoint 1024 5
cachesize 1
index objectClass,uidNumber,gidNumber eq
index member,mail eq,pres
index cn,displayname,uid,sn,givenname sub,eq,pres
overlay ppolicy
ppolicy_default cn=Default Password Policy,dc=example,dc=com
ppolicy_forward_updates
ppolicy_hash_cleartext
overlay memberof



##
# Syncrepl directives #
##
syncrepl  rid=001
  provider=ldap://mirror1:389 http://192.168.1.10:389/
  type=refreshAndPersist
  retry=60 +
  searchbase=dc=example,dc=com
  filter=(objectclass=*)
  scope=sub
  attrs=*
  schemachecking=on
  binddn=cn=replicator,dc=example,dc=com
  bindmethod=simple
  credentials=secret
  sizelimit=unlimited
  logbase=cn=accesslog
  logfilter=((objectClass=auditWriteObject)(reqResult=0))
  syncdata=accesslog

# Refer updates to the master
updateref   ldap://mirror1:389 http://192.168.1.10:389/

-
-


slapd.conf  of mirror server #1
---
# Global
section

serverID
1


moduleload memberof

access to dn.base=
by * read

access to dn.base=cn=Subschema
by * read

access to attrs=userPassword,userPKCS12
by self write
by dn.base=cn=replicator,dc=example,dc=com read
by * auth

access to attrs=shadowLastChange
by self write
by * read

# Give the replica DN unlimited read access.  This ACL needs to be
# merged with other ACL statements, and/or moved within the scope
# of a database.  The by * break portion causes evaluation of
# subsequent rules.  See slapd.access(5) for details.

access to *
by dn.base=cn=replicator,dc=example,dc=com read
by * break

access to *
by * read

# Load the accesslog overlay
moduleload accesslog.la

#Load the syncprov overlay
moduleload syncprov.la


# Accesslog database definitions
database bdb

monitoring off

suffix cn=accesslog
rootdn cn=accesslog
index default eq
index entryCSN,objectClass,reqEnd,reqResult,reqStart

overlay syncprov
syncprov-nopresent TRUE
syncprov-reloadhint TRUE

# Let the replica DN have limitless searches
limits dn.exact=cn=replicator,dc=example,dc=com time.soft=unlimited
time.hard=unlimited size.soft=unlimited size.hard=unlimited


###
# BDB database definitions
###

database bdb

monitoring off

suffix dc=example,dc=com
rootdn cn=Administrator,dc=example,dc=com
rootpw secret
checkpoint 1024 5
cachesize 1
index objectClass,uidNumber,gidNumber eq
index member,mail eq,pres
index cn,displayname,uid,sn,givenname sub,eq,pres
overlay ppolicy
ppolicy_default cn=Default Password Policy,dc=example,dc=com
ppolicy_hash_cleartext
overlay memberof

# Habilitar authz-policiy
authz-policy to

index entryCSN eq
index entryUUID eq

# syncrepl Provider for primary db
overlay syncprov
syncprov-checkpoint 1000 60

# accesslog overlay definitions for primary db
overlay accesslog
logdb cn=accesslog
logops writes
logsuccess TRUE
# scan the accesslog DB every day, and purge entries older than 7 days
logpurge 07+00:00 01+00:00

# Let the replica DN have limitless searches
limits dn.exact=cn=replicator,dc=example,dc=com time.soft=unlimited
time.hard=unlimited size.soft=unlimited size.hard=unlimited


# MirrorMode - Syncrepl directive
syncreplrid=001
provider=ldap://mirror2:389
bindmethod=simple
binddn=cn=Administrator,dc=example,dc=com
credentials=secret
searchbase=dc=example,dc=com
schemachecking=on
type=refreshAndPersist
retry=60 +
mirrormode on

---
---

In the mirror servers we have set the attribute authzTo for the replicator
dn:

ldapsearch -x -b 'cn=replicator,dc=example,dc=com' -H ldap://mirror1:389 -D
'cn

Re: Slapd-ldap proxy between replica and mirror

[masarati]

 Hi,

Ok, i understand that the problem is authorization, but when i supress
 the back-ldap proxy from my scenario it works.
 I am going to give more details.

 First Scenario:
 -

 A delta syncrepl server replicating from the first server of a mirror.

 IPs: delta syncrepl (192.168.1.5), mirror server 1 (192.168.1.10), mirror
 server 2 (192.168.1.20)

 replica slapd.conf

 #
 #  Chaining configuration #
 #
 overlay chain
 chain-uri   ldap://mirror1:389 http://192.168.1.10:389/
 chain-idassert-bind bindmethod=simple
 binddn=cn=replicator,dc=example,dc=com
 credentials=secret
 mode=self
 chain-return-error  TRUE

 ##
 #  Replica  #
 ##
 database bdb
 suffix dc=example,dc=com
 rootdn cn=Administrator,dc=example,dc=com
 rootpw secret
 checkpoint 1024 5
 cachesize 1
 index objectClass,uidNumber,gidNumber eq
 index member,mail eq,pres
 index cn,displayname,uid,sn,givenname sub,eq,pres
 overlay ppolicy
 ppolicy_default cn=Default Password Policy,dc=example,dc=com
 ppolicy_forward_updates
 ppolicy_hash_cleartext
 overlay memberof



 ##
 # Syncrepl directives #
 ##
 syncrepl  rid=001
   provider=ldap://mirror1:389 http://192.168.1.10:389/
   type=refreshAndPersist
   retry=60 +
   searchbase=dc=example,dc=com
   filter=(objectclass=*)
   scope=sub
   attrs=*
   schemachecking=on
   binddn=cn=replicator,dc=example,dc=com
   bindmethod=simple
   credentials=secret
   sizelimit=unlimited
   logbase=cn=accesslog
   logfilter=((objectClass=auditWriteObject)(reqResult=0))
   syncdata=accesslog

 # Refer updates to the master
 updateref   ldap://mirror1:389 http://192.168.1.10:389/

 -
 -


 slapd.conf  of mirror server #1
 ---
 # Global
 section

 serverID
 1


 moduleload memberof

 access to dn.base=
 by * read

 access to dn.base=cn=Subschema
 by * read

 access to attrs=userPassword,userPKCS12
 by self write
 by dn.base=cn=replicator,dc=example,dc=com read
 by * auth

 access to attrs=shadowLastChange
 by self write
 by * read

 # Give the replica DN unlimited read access.  This ACL needs to be
 # merged with other ACL statements, and/or moved within the scope
 # of a database.  The by * break portion causes evaluation of
 # subsequent rules.  See slapd.access(5) for details.

 access to *
 by dn.base=cn=replicator,dc=example,dc=com read
 by * break

 access to *
 by * read

 # Load the accesslog overlay
 moduleload accesslog.la

 #Load the syncprov overlay
 moduleload syncprov.la


 # Accesslog database definitions
 database bdb

 monitoring off

 suffix cn=accesslog
 rootdn cn=accesslog
 index default eq
 index entryCSN,objectClass,reqEnd,reqResult,reqStart

 overlay syncprov
 syncprov-nopresent TRUE
 syncprov-reloadhint TRUE

 # Let the replica DN have limitless searches
 limits dn.exact=cn=replicator,dc=example,dc=com time.soft=unlimited
 time.hard=unlimited size.soft=unlimited size.hard=unlimited


 ###
 # BDB database definitions
 ###

 database bdb

 monitoring off

 suffix dc=example,dc=com
 rootdn cn=Administrator,dc=example,dc=com
 rootpw secret
 checkpoint 1024 5
 cachesize 1
 index objectClass,uidNumber,gidNumber eq
 index member,mail eq,pres
 index cn,displayname,uid,sn,givenname sub,eq,pres
 overlay ppolicy
 ppolicy_default cn=Default Password Policy,dc=example,dc=com
 ppolicy_hash_cleartext
 overlay memberof

 # Habilitar authz-policiy
 authz-policy to

 index entryCSN eq
 index entryUUID eq

 # syncrepl Provider for primary db
 overlay syncprov
 syncprov-checkpoint 1000 60

 # accesslog overlay definitions for primary db
 overlay accesslog
 logdb cn=accesslog
 logops writes
 logsuccess TRUE
 # scan the accesslog DB every day, and purge entries older than 7 days
 logpurge 07+00:00 01+00:00

 # Let the replica DN have limitless searches
 limits dn.exact=cn=replicator,dc=example,dc=com time.soft=unlimited
 time.hard=unlimited size.soft=unlimited size.hard=unlimited
 

 # MirrorMode - Syncrepl directive
 syncreplrid=001
 provider=ldap://mirror2:389
 bindmethod=simple
 binddn=cn=Administrator,dc=example,dc=com
 credentials=secret
 searchbase=dc=example,dc=com
 schemachecking=on
 type=refreshAndPersist
 retry=60 +
 mirrormode on

 ---
 ---

 In the mirror

Slapd-ldap proxy between replica and mirror

[Ubay Dorta]

 Hi,

We have a similar scenario that the one explained in the post of Javier
Manteiga:
http://www.openldap.org/cgi-bin/wilma_hiliter/openldap-technical/200907/msg00180.html

We have deployed two servers: a master and a replica (delta-syncrepl). We
added the chaining configuration that appears in openldap 2.4
administrator's guide (12.3.2) to handle the modifications originated from
the replica.

Replica slapd.conf:

#
#  Chaining configuration #
#
overlay chain
chain-uri   ldap://192.168.1.10:389;
chain-idassert-bind bindmethod=simple
binddn=cn=replicator,dc=example,dc=com
credentials=secret
mode=self
chain-return-error  TRUE

##
#  Replica  #
##
database bdb
suffix dc=example,dc=com
rootdn cn=Administrator,dc=example,dc=com
rootpw secret

##
# Syncrepl directives #
##
syncrepl  rid=001
  provider=ldap://192.168.1.10:389
  type=refreshAndPersist
  retry=60 +
  searchbase=dc=example,dc=com
  filter=(objectclass=*)
  scope=sub
  attrs=*
  schemachecking=on
  binddn=cn=replicator,dc=example,dc=com
  bindmethod=simple
  credentials=secret
  sizelimit=unlimited
  logbase=cn=accesslog
  logfilter=((objectClass=auditWriteObject)(reqResult=0))
  syncdata=accesslog

# Refer updates to the master
updateref   ldap://192.168.1.10:389

The problem appears when we change the single master for a mirrormode
configuration (administrator guide 18.3.4.1). In addition, we set up a
back-ldap proxy between mirror and replica.

back-ldap proxy slapd.conf:


#  Proxy #

databaseldap
suffix  dc=example,dc=com
rootdn  cn=slapd-ldap

uri ldap://192.168.1.20:389 ldap://192.168.1.30:389;


The IP addresses are:
192.168.1.10 - Back-ldap proxy
192.168.1.20 - Mirror mode server 1
192.168.1.30 - Mirror mode server 2


When we try to modify the password through the replica, we get the following
messages in the server where is located the proxy:

ldap-proxy[13175]: daemon: activity on 1 descriptor
ldap-proxy[13175]: daemon: activity on:
ldap-proxy[13175]:  12r
ldap-proxy[13175]:
ldap-proxy[13175]: daemon: read active on 12
ldap-proxy[13175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
ldap-proxy[13175]: connection_get(12)
ldap-proxy[13175]: connection_get(12): got connid=1002
ldap-proxy[13175]: connection_read(12): checking for input on id=1002
ldap-proxy[13175]: op tag 0x66, time 1270632398
ldap-proxy[13175]: conn=1002 op=2 do_modify
ldap-proxy[13175]: conn=1002 op=2 do_modify: dn
(uid=user,ou=people,dc=example,dc=com)
ldap-proxy[13175]: = get_ctrls
ldap-proxy[13175]: = get_ctrls: oid=2.16.840.1.113730.3.4.18
(noncritical)
ldap-proxy[13175]: parseProxyAuthz: conn 1002
authzid=dn:uid=user,ou=people,dc=example,dc=com
ldap-proxy[13175]: slap_sasl_getdn: conn 1002
id=dn:uid=user,ou=people,dc=example,dc=com [len=38]
ldap-proxy[13175]:  dnNormalize: uid=user,ou=people,dc=example,dc=com
ldap-proxy[13175]:  dnNormalize: uid=user,ou=people,dc=example,dc=com
ldap-proxy[13175]: ==slap_sasl2dn: converting SASL name
uid=user,ou=people,dc=example,dc=com to a DN
ldap-proxy[13175]: ==slap_sasl2dn: Converted SASL name to nothing
ldap-proxy[13175]: parseProxyAuthz: conn=1002
uid=user,ou=people,dc=example,dc=com
ldap-proxy[13175]: ==slap_sasl_authorized: can
cn=replicator,dc=example,dc=com become uid=user,ou=people,dc=example,dc=com?
ldap-proxy[13175]: == slap_sasl_authorized: return 48
ldap-proxy[13175]: = get_ctrls: n=1 rc=123 err=not authorized to assume
identity
ldap-proxy[13175]: send_ldap_result: conn=1002 op=2 p=3
ldap-proxy[13175]: send_ldap_result: err=123 matched= text=not authorized
to assume identity
ldap-proxy[13175]: send_ldap_response: msgid=3 tag=103 err=123
ldap-proxy[13175]: conn=1002 op=2 RESULT tag=103 err=123 text=not authorized
to assume identity
ldap-proxy[13175]: conn=1002 op=2 do_modify: get_ctrls failed
ldap-proxy[13175]: daemon: activity on 1 descriptor
ldap-proxy[13175]: daemon: activity on:

The authorization is denied for cn=replicator,dc=example,dc=com.

Is it the same problem with the propagation of identity?

Is there any way to avoid the problem?

Thanks in advance.


 Javier Manteiga wrote:

   We are trying to set a system with the DIT split in several servers,
using the Meta backend to proxy the LDAP requests among them. In the
remote servers we would like to check the ACLs using the identity of the

client that sent the request, instead of the identity used to create the
proxy connections. For this we have configured the idassert parameters
in the meta targets as follows:

idassert-bind bindmethod=simple

  binddn=cn=manager,dc=operator,dc=com (root user of the
backend receiving the proxied query)
  credentials=manager

Re: Slapd-ldap proxy between replica and mirror

[masarati]

  Hi,

 We have a similar scenario that the one explained in the post of Javier
 Manteiga:
 http://www.openldap.org/cgi-bin/wilma_hiliter/openldap-technical/200907/msg00180.html

 We have deployed two servers: a master and a replica (delta-syncrepl). We
 added the chaining configuration that appears in openldap 2.4
 administrator's guide (12.3.2) to handle the modifications originated from
 the replica.

 Replica slapd.conf:

 #
 #  Chaining configuration #
 #
 overlay chain
 chain-uri   ldap://192.168.1.10:389;
 chain-idassert-bind bindmethod=simple
 binddn=cn=replicator,dc=example,dc=com
 credentials=secret
 mode=self
 chain-return-error  TRUE

 ##
 #  Replica  #
 ##
 database bdb
 suffix dc=example,dc=com
 rootdn cn=Administrator,dc=example,dc=com
 rootpw secret
 
 ##
 # Syncrepl directives #
 ##
 syncrepl  rid=001
   provider=ldap://192.168.1.10:389
   type=refreshAndPersist
   retry=60 +
   searchbase=dc=example,dc=com
   filter=(objectclass=*)
   scope=sub
   attrs=*
   schemachecking=on
   binddn=cn=replicator,dc=example,dc=com
   bindmethod=simple
   credentials=secret
   sizelimit=unlimited
   logbase=cn=accesslog
   logfilter=((objectClass=auditWriteObject)(reqResult=0))
   syncdata=accesslog

 # Refer updates to the master
 updateref   ldap://192.168.1.10:389

 The problem appears when we change the single master for a mirrormode
 configuration (administrator guide 18.3.4.1). In addition, we set up a
 back-ldap proxy between mirror and replica.

 back-ldap proxy slapd.conf:

 
 #  Proxy #
 
 databaseldap
 suffix  dc=example,dc=com
 rootdn  cn=slapd-ldap

 uri ldap://192.168.1.20:389 ldap://192.168.1.30:389;


 The IP addresses are:
 192.168.1.10 - Back-ldap proxy
 192.168.1.20 - Mirror mode server 1
 192.168.1.30 - Mirror mode server 2


 When we try to modify the password through the replica, we get the
 following
 messages in the server where is located the proxy:

 ldap-proxy[13175]: daemon: activity on 1 descriptor
 ldap-proxy[13175]: daemon: activity on:
 ldap-proxy[13175]:  12r
 ldap-proxy[13175]:
 ldap-proxy[13175]: daemon: read active on 12
 ldap-proxy[13175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
 ldap-proxy[13175]: connection_get(12)
 ldap-proxy[13175]: connection_get(12): got connid=1002
 ldap-proxy[13175]: connection_read(12): checking for input on id=1002
 ldap-proxy[13175]: op tag 0x66, time 1270632398
 ldap-proxy[13175]: conn=1002 op=2 do_modify
 ldap-proxy[13175]: conn=1002 op=2 do_modify: dn
 (uid=user,ou=people,dc=example,dc=com)
 ldap-proxy[13175]: = get_ctrls
 ldap-proxy[13175]: = get_ctrls: oid=2.16.840.1.113730.3.4.18
 (noncritical)
 ldap-proxy[13175]: parseProxyAuthz: conn 1002
 authzid=dn:uid=user,ou=people,dc=example,dc=com
 ldap-proxy[13175]: slap_sasl_getdn: conn 1002
 id=dn:uid=user,ou=people,dc=example,dc=com [len=38]
 ldap-proxy[13175]:  dnNormalize: uid=user,ou=people,dc=example,dc=com
 ldap-proxy[13175]:  dnNormalize: uid=user,ou=people,dc=example,dc=com
 ldap-proxy[13175]: ==slap_sasl2dn: converting SASL name
 uid=user,ou=people,dc=example,dc=com to a DN
 ldap-proxy[13175]: ==slap_sasl2dn: Converted SASL name to nothing
 ldap-proxy[13175]: parseProxyAuthz: conn=1002
 uid=user,ou=people,dc=example,dc=com
 ldap-proxy[13175]: ==slap_sasl_authorized: can
 cn=replicator,dc=example,dc=com become
 uid=user,ou=people,dc=example,dc=com?
 ldap-proxy[13175]: == slap_sasl_authorized: return 48
 ldap-proxy[13175]: = get_ctrls: n=1 rc=123 err=not authorized to assume
 identity
 ldap-proxy[13175]: send_ldap_result: conn=1002 op=2 p=3
 ldap-proxy[13175]: send_ldap_result: err=123 matched= text=not
 authorized
 to assume identity
 ldap-proxy[13175]: send_ldap_response: msgid=3 tag=103 err=123
 ldap-proxy[13175]: conn=1002 op=2 RESULT tag=103 err=123 text=not
 authorized
 to assume identity
 ldap-proxy[13175]: conn=1002 op=2 do_modify: get_ctrls failed
 ldap-proxy[13175]: daemon: activity on 1 descriptor
 ldap-proxy[13175]: daemon: activity on:

 The authorization is denied for cn=replicator,dc=example,dc=com.

The error looks self-explanatory: the identity
cn=replicator,dc=example,dc=com is not authorized to assume the identity
of the client that attempted the write.  The failure appears to happen in
slap_sasl2dn(), where the user's DN is converted to nothing (the
mapping fails).  It is not clear why it fails.  You probably do not show
enough of your master and replica slapd.conf.

p.

Re: Slapd-ldap proxy between replica and mirror

[masarati]

  Hi,

 We have a similar scenario that the one explained in the post of Javier
 Manteiga:
 http://www.openldap.org/cgi-bin/wilma_hiliter/openldap-technical/200907/msg00180.html

 We have deployed two servers: a master and a replica (delta-syncrepl).
 We
 added the chaining configuration that appears in openldap 2.4
 administrator's guide (12.3.2) to handle the modifications originated
 from
 the replica.

 Replica slapd.conf:

 #
 #  Chaining configuration #
 #
 overlay chain
 chain-uri   ldap://192.168.1.10:389;
 chain-idassert-bind bindmethod=simple
 binddn=cn=replicator,dc=example,dc=com
 credentials=secret
 mode=self
 chain-return-error  TRUE

 ##
 #  Replica  #
 ##
 database bdb
 suffix dc=example,dc=com
 rootdn cn=Administrator,dc=example,dc=com
 rootpw secret
 
 ##
 # Syncrepl directives #
 ##
 syncrepl  rid=001
   provider=ldap://192.168.1.10:389
   type=refreshAndPersist
   retry=60 +
   searchbase=dc=example,dc=com
   filter=(objectclass=*)
   scope=sub
   attrs=*
   schemachecking=on
   binddn=cn=replicator,dc=example,dc=com
   bindmethod=simple
   credentials=secret
   sizelimit=unlimited
   logbase=cn=accesslog
   logfilter=((objectClass=auditWriteObject)(reqResult=0))
   syncdata=accesslog

 # Refer updates to the master
 updateref   ldap://192.168.1.10:389

 The problem appears when we change the single master for a mirrormode
 configuration (administrator guide 18.3.4.1). In addition, we set up a
 back-ldap proxy between mirror and replica.

 back-ldap proxy slapd.conf:

 
 #  Proxy #
 
 databaseldap
 suffix  dc=example,dc=com
 rootdn  cn=slapd-ldap

 uri ldap://192.168.1.20:389 ldap://192.168.1.30:389;


 The IP addresses are:
 192.168.1.10 - Back-ldap proxy
 192.168.1.20 - Mirror mode server 1
 192.168.1.30 - Mirror mode server 2


 When we try to modify the password through the replica, we get the
 following
 messages in the server where is located the proxy:

 ldap-proxy[13175]: daemon: activity on 1 descriptor
 ldap-proxy[13175]: daemon: activity on:
 ldap-proxy[13175]:  12r
 ldap-proxy[13175]:
 ldap-proxy[13175]: daemon: read active on 12
 ldap-proxy[13175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL
 ldap-proxy[13175]: connection_get(12)
 ldap-proxy[13175]: connection_get(12): got connid=1002
 ldap-proxy[13175]: connection_read(12): checking for input on id=1002
 ldap-proxy[13175]: op tag 0x66, time 1270632398
 ldap-proxy[13175]: conn=1002 op=2 do_modify
 ldap-proxy[13175]: conn=1002 op=2 do_modify: dn
 (uid=user,ou=people,dc=example,dc=com)
 ldap-proxy[13175]: = get_ctrls
 ldap-proxy[13175]: = get_ctrls: oid=2.16.840.1.113730.3.4.18
 (noncritical)
 ldap-proxy[13175]: parseProxyAuthz: conn 1002
 authzid=dn:uid=user,ou=people,dc=example,dc=com
 ldap-proxy[13175]: slap_sasl_getdn: conn 1002
 id=dn:uid=user,ou=people,dc=example,dc=com [len=38]
 ldap-proxy[13175]:  dnNormalize:
 uid=user,ou=people,dc=example,dc=com
 ldap-proxy[13175]:  dnNormalize:
 uid=user,ou=people,dc=example,dc=com
 ldap-proxy[13175]: ==slap_sasl2dn: converting SASL name
 uid=user,ou=people,dc=example,dc=com to a DN
 ldap-proxy[13175]: ==slap_sasl2dn: Converted SASL name to nothing
 ldap-proxy[13175]: parseProxyAuthz: conn=1002
 uid=user,ou=people,dc=example,dc=com
 ldap-proxy[13175]: ==slap_sasl_authorized: can
 cn=replicator,dc=example,dc=com become
 uid=user,ou=people,dc=example,dc=com?
 ldap-proxy[13175]: == slap_sasl_authorized: return 48
 ldap-proxy[13175]: = get_ctrls: n=1 rc=123 err=not authorized to
 assume
 identity
 ldap-proxy[13175]: send_ldap_result: conn=1002 op=2 p=3
 ldap-proxy[13175]: send_ldap_result: err=123 matched= text=not
 authorized
 to assume identity
 ldap-proxy[13175]: send_ldap_response: msgid=3 tag=103 err=123
 ldap-proxy[13175]: conn=1002 op=2 RESULT tag=103 err=123 text=not
 authorized
 to assume identity
 ldap-proxy[13175]: conn=1002 op=2 do_modify: get_ctrls failed
 ldap-proxy[13175]: daemon: activity on 1 descriptor
 ldap-proxy[13175]: daemon: activity on:

 The authorization is denied for cn=replicator,dc=example,dc=com.

 The error looks self-explanatory: the identity
 cn=replicator,dc=example,dc=com is not authorized to assume the identity
 of the client that attempted the write.  The failure appears to happen in
 slap_sasl2dn(), where the user's DN is converted to nothing (the
 mapping fails).  It is not clear why it fails.

Sorry, I take the last sentence back: mapping a DN to nothing means there
was nothing to map.  The failure is just later, where (pretty
self-explanatory):

ldap-proxy[13175]: ==slap_sasl_authorized: can
cn=replicator,dc=example,dc=com become
uid=user,ou=people,dc=example,dc=com?
ldap-proxy