Hello all !
Does OpenLDAP provide a way to authenticate on it using a DN / pwd of another LDAP server ? I have read the manual page about the LDAP and META backends, but I did not find if it match my will.
At the end I would like to authenticate on OpenLDAP with a DN/pwd of another directory (or maybe SASL credentials ?), and access (probably only through OpenLDAP) to the data of both OpenLDAP and the other directory server.
I can customize the OpenLDAP server (in fact: our server), and not the other server (the customer server).
Thank you
François
François Beretti schrieb:
Does OpenLDAP provide a way to authenticate on it using a DN / pwd of another LDAP server ? I have read the manual page about the LDAP and META backends, but I did not find if it match my will.
At the end I would like to authenticate on OpenLDAP with a DN/pwd of another directory (or maybe SASL credentials ?), and access (probably only through OpenLDAP) to the data of both OpenLDAP and the other directory server.
OpenLDAP uses cyrus sasl for authentication. Cyrus sasl can use ldapdb. ldapdb can use another ldap server (your second server) to check the credentials. so theoretically this should work, I think.
Hans
Hans Moser wrote:
François Beretti schrieb:
Does OpenLDAP provide a way to authenticate on it using a DN / pwd of another LDAP server ? I have read the manual page about the LDAP and META backends, but I did not find if it match my will.
At the end I would like to authenticate on OpenLDAP with a DN/pwd of another directory (or maybe SASL credentials ?), and access (probably only through OpenLDAP) to the data of both OpenLDAP and the other directory server.
OpenLDAP uses cyrus sasl for authentication. Cyrus sasl can use ldapdb. ldapdb can use another ldap server (your second server) to check the credentials. so theoretically this should work, I think.
Yes, that would work, as long as the other LDAP server also supports SASL and Proxy Authorization.
François Beretti francois.beretti@gmail.com wrote:
Does OpenLDAP provide a way to authenticate on it using a DN / pwd of another LDAP server ? I have read the manual page about the LDAP and META backends, but I did not find if it match my will.
At the end I would like to authenticate on OpenLDAP with a DN/pwd of another directory (or maybe SASL credentials ?), and access (probably only through OpenLDAP) to the data of both OpenLDAP and the other directory server.
I can customize the OpenLDAP server (in fact: our server), and not the other server (the customer server).
Some time ago, I wrote a custom LDAP backend for hijacking authentication. My goal was to redirect it to a RADIUS server, but you could modify my code to authenticate against anything else.
Here is it: http://ftp.espci.fr/pub/ldap2radius/
Emmanuel Dreyfus wrote:
François Beretti francois.beretti@gmail.com wrote:
Does OpenLDAP provide a way to authenticate on it using a DN / pwd of another LDAP server ? I have read the manual page about the LDAP and META backends, but I did not find if it match my will.
At the end I would like to authenticate on OpenLDAP with a DN/pwd of another directory (or maybe SASL credentials ?), and access (probably only through OpenLDAP) to the data of both OpenLDAP and the other directory server.
I can customize the OpenLDAP server (in fact: our server), and not the other server (the customer server).
Some time ago, I wrote a custom LDAP backend for hijacking authentication. My goal was to redirect it to a RADIUS server, but you could modify my code to authenticate against anything else.
For the specific case of RADIUS, a full backend is not needed. If your users already have LDAP entries, you can set their userpassword to use the {RADIUS} scheme which will cause a RADIUS server to be used for Simple Bind authentication. That code is in the contrib/slapd-modules/passwd directory in HEAD and will also be in 2.4.
Here is it: http://ftp.espci.fr/pub/ldap2radius/
Howard Chu hyc@symas.com wrote:
Some time ago, I wrote a custom LDAP backend for hijacking authentication. My goal was to redirect it to a RADIUS server, but you could modify my code to authenticate against anything else.
For the specific case of RADIUS, a full backend is not needed. If your users already have LDAP entries, you can set their userpassword to use the {RADIUS} scheme which will cause a RADIUS server to be used for Simple Bind authentication. That code is in the contrib/slapd-modules/passwd directory in HEAD and will also be in 2.4.
I guess it did not exist at the time I hacked ldap2radius. Or I did not find it at that time.
Emmanuel Dreyfus wrote:
Howard Chu hyc@symas.com wrote:
Some time ago, I wrote a custom LDAP backend for hijacking authentication. My goal was to redirect it to a RADIUS server, but you could modify my code to authenticate against anything else.
For the specific case of RADIUS, a full backend is not needed. If your users already have LDAP entries, you can set their userpassword to use the {RADIUS} scheme which will cause a RADIUS server to be used for Simple Bind authentication. That code is in the contrib/slapd-modules/passwd directory in HEAD and will also be in 2.4.
I guess it did not exist at the time I hacked ldap2radius. Or I did not find it at that time.
That may be.
In general, unless you actually need to perform all of the functions of a backend, you can usually get by with something much smaller - like an overlay that only intercepts Bind operations, or a password hash module in this case.
how does the authorization system work when using such an overlay ? can one write acl giving access to a user dn not in the directory ?
2007/2/2, Howard Chu hyc@symas.com:
In general, unless you actually need to perform all of the functions of a backend, you can usually get by with something much smaller - like an overlay that only intercepts Bind operations, or a password hash module in this case.
François Beretti wrote:
how does the authorization system work when using such an overlay ? can one write acl giving access to a user dn not in the directory ?
Yes of course. Any valid DN (i.e., a DN that conforms to the schema) can be specified in an ACL, regardless of whether that DN corresponds to an entry residing in the current server. Otherwise distributed authentication and authorization would be impossible.
Note that SASL is already an example of this fact - SASL IDs don't have to exist in the directory, but if SASL says they are authenticated then we allow their use. Once an identity has been authenticated, by whatever means, it is valid.
2007/2/2, Howard Chu <hyc@symas.com mailto:hyc@symas.com>:
In general, unless you actually need to perform all of the functions of a backend, you can usually get by with something much smaller - like an overlay that only intercepts Bind operations, or a password hash module in this case.
[regarding the radius password scheme]
authentication. That code is in the contrib/slapd-modules/passwd directory in HEAD and will also be in 2.4.
For clarification: does "will also be in 2.4" mean that this will be mainstreamed (e.g. non-contrib) in 2.4, or just a reassurance that it's not going away from contrib during 2.4?
Aaron Richton wrote:
[regarding the radius password scheme]
authentication. That code is in the contrib/slapd-modules/passwd directory in HEAD and will also be in 2.4.
For clarification: does "will also be in 2.4" mean that this will be mainstreamed (e.g. non-contrib) in 2.4, or just a reassurance that it's not going away from contrib during 2.4?
It will be in contrib in 2.4, the same as it is in HEAD. Features of this sort will never be "mainstreamed" - it is not a core feature, and we provide APIs for dynamically loading these things so they can continue to be developed outside the core.
François Beretti wrote:
At the end I would like to authenticate on OpenLDAP with a DN/pwd of another directory (or maybe SASL credentials ?), and access (probably only through OpenLDAP) to the data of both OpenLDAP and the other directory server.
This is possible with back-ldap or back-meta and slapo-rwm.
Ciao, Michael.
openldap-software@openldap.org