Dear list!
We are trying something we thought should be simple:
We have got
Server A: Holds an LDAP database Server B: Is supposed to act as a proxy to A
Both are OpenLDAP, A is 2.2; B is 2.4.
What we want to achieve is that server B will just proxy everything from server A except that some attribute names shall be rewritten, i.e. B is queried for a different attribute name as the actual name on A.
Here is what we did:
database ldap suffix "o=world" uri "ldap://ldap.our.tld/" overlay rwm rwm-map attribute authzTo saslAuthzTo
The problem with that setup is that it will crash server B.
In some example we found somthing like this:
database ldap suffix "o=world" uri "ldap://ldap.our.tld/" overlay rwm rwm-map attribute authzTo saslAuthzTo rwm-map attribute *
So as soon as we add that wildcard line, slapd (on server B) will no longer crash, but unfortunately, it is not going to find anything anymore.
Could anyone help out with an example?
Regards, Torsten
Torsten Schlabach (Tascel eG) wrote:
database ldap suffix "o=world" uri "ldap://ldap.our.tld/" overlay rwm rwm-map attribute authzTo saslAuthzTo
The problem with that setup is that it will crash server B.
Trying to work around a crash doesn't seem a safe and reliable option. I suggest you provide some more information about the crash (which I couldn't reproduce), counting on the fact that OpenLDAP 2.4 will be maintained for a while (as opposed to 2.2 which is no longer maintained and you should upgrade rather than hide behind a proxy). Please see http://www.openldap.org/faq/data/cache/56.html for indications about providing useful information for debugging.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo!
I will happily provide some detailed debugging output. I just wanted to make sure that I understood the concept of rwm-map properly. So looking at our config, there isn't anything obvious that we have missed?
Just to confirm:
We have
Server A <--- Server B <--- Client (bdb) (ldap)
I need the overlay to happen between Server B and Server A, not between the the client an Server B.
The manual isn't that detailed ... Or did I miss anything.
Regards, Torsten
Pierangelo Masarati wrote:
Torsten Schlabach (Tascel eG) wrote:
database ldap suffix "o=world" uri "ldap://ldap.our.tld/" overlay rwm rwm-map attribute authzTo saslAuthzTo
The problem with that setup is that it will crash server B.
Trying to work around a crash doesn't seem a safe and reliable option. I suggest you provide some more information about the crash (which I couldn't reproduce), counting on the fact that OpenLDAP 2.4 will be maintained for a while (as opposed to 2.2 which is no longer maintained and you should upgrade rather than hide behind a proxy). Please see http://www.openldap.org/faq/data/cache/56.html for indications about providing useful information for debugging.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it
Torsten Schlabach (Tascel eG) wrote:
Pierangelo!
I will happily provide some detailed debugging output. I just wanted to make sure that I understood the concept of rwm-map properly. So looking at our config, there isn't anything obvious that we have missed?
No.
Just to confirm:
We have
Server A <--- Server B <--- Client (bdb) (ldap)
I need the overlay to happen between Server B and Server A, not between the the client an Server B.
The manual isn't that detailed ... Or did I miss anything.
It works this way:
<--- saslAuthzTo <--- <--- authzTo <--- Server A Server B Client ---> saslAuthzTo ---> ---> authzTo --->
(bdb) (ldap+rwm)
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Hi!
It works this way:
[...]
Ok. But in the very case, it's actually not the client who would want to read the authzTo attribute, but Server B. Server B tries to decide if a specific user who authenticated is allowed to assume the authorization of a different user. For that reason, Server B tries to read the authzTo attribute of the user object. That user object lives on Server A and does not have an authzTo attribute but only a saslAuthzTo attribute, due to the fact that the name of that internal attribute changed between 2.2 and 2.3.
We can see Server B querying Server a for the authzTo attribute. So that part is fine.
From the log files I can see there is something like "internal search". Would an overlay and a rwn-map apply to such an internal search as well?
Regards, Torsten
Pierangelo Masarati wrote:
Torsten Schlabach (Tascel eG) wrote:
Pierangelo!
I will happily provide some detailed debugging output. I just wanted to make sure that I understood the concept of rwm-map properly. So looking at our config, there isn't anything obvious that we have missed?
No.
Just to confirm:
We have
Server A <--- Server B <--- Client (bdb) (ldap)
I need the overlay to happen between Server B and Server A, not between the the client an Server B.
The manual isn't that detailed ... Or did I miss anything.
It works this way:
<--- saslAuthzTo <--- <--- authzTo <---Server A Server B Client ---> saslAuthzTo ---> ---> authzTo --->
(bdb) (ldap+rwm)
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it
Torsten Schlabach (Tascel eG) wrote:
Hi!
It works this way:
[...]
Ok. But in the very case, it's actually not the client who would want to read the authzTo attribute, but Server B. Server B tries to decide if a specific user who authenticated is allowed to assume the authorization of a different user. For that reason, Server B tries to read the authzTo attribute of the user object. That user object lives on Server A and does not have an authzTo attribute but only a saslAuthzTo attribute, due to the fact that the name of that internal attribute changed between 2.2 and 2.3.
We can see Server B querying Server a for the authzTo attribute. So that part is fine.
That's not fine: the mapping from authzTo to saslAuthzTo should have occurred before the request goes from server B to server A. The "internal search" means that server B tries to get an entry's authzTo attribute, and that entry happens to reside in server A through the proxy database, so server B tries to access what believes is a local database, but it's rather a proxy, and the internal request is treated by the proxy like any other request and is mapped accordingly.
From the log files I can see there is something like "internal search". Would an overlay and a rwn-map apply to such an internal search as well?
I can imagine a few scenarios where this type of request can happen. Can you specify yours, to speed up debugging? What I need is a minimal setup of both servers, complete of slapd.conf and any required LDIF, plus information about the operation that should trigger the internal search. Please make sure you strip any sensitive data, and keep it to a minimal size.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Torsten Schlabach (Tascel eG) wrote:
Hi!
It works this way:
[...]
Ok. But in the very case, it's actually not the client who would want to read the authzTo attribute, but Server B. Server B tries to decide if a specific user who authenticated is allowed to assume the authorization of a different user. For that reason, Server B tries to read the authzTo attribute of the user object. That user object lives on Server A and does not have an authzTo attribute but only a saslAuthzTo attribute, due to the fact that the name of that internal attribute changed between 2.2 and 2.3.
Why not just patch the 2.2 server to include authzTo as an alias of the saslAuthzTo attribute?
Howard Chu wrote:
Why not just patch the 2.2 server to include authzTo as an alias of the saslAuthzTo attribute?
Upgrading would be another option; but I was rather interested in seeing the alleged crash of the 2.4 server.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Hi!
Howard Chu wrote:
Why not just patch the 2.2 server to include authzTo as an alias of the saslAuthzTo attribute?
The issue here is that the 2.2 server is a legagy, but productive legacy. The reason for that proxy construct is to make sure that new systems can point to the new 2.4 server with better security, different SASL stuff, etc., then we plan to move the physical data from back-ldap to back-bdb.
So when you say "patch the 2.2 server", would be have to patch the code, i.e. compile the whole thing from scratch? I think given the above, this isn't really an option. Or would there be any other way (in 2.2) to make the authzTo attribute an alias of saslAuthzTo?
Pierangelo Masarati wrote:
I was rather interested in seeing the alleged crash of the 2.4 server.
I can produce that crashdump for you independent of a solution to our problem. And I am 99% sure that the crash in the 2.4 server will stay even after solving our problem.
Regards, Torsten
Torsten Schlabach (Tascel eG) wrote:
Pierangelo Masarati wrote:
I was rather interested in seeing the alleged crash of the 2.4 server.
I can produce that crashdump for you independent of a solution to our problem. And I am 99% sure that the crash in the 2.4 server will stay even after solving our problem.
That's why I'm interested in fixing it :)
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
openldap-software@openldap.org
-
Howard Chu -
Pierangelo Masarati -
Torsten Schlabach (Tascel eG)