Well, I have been working on this question and have had an idea.
Would a way to accomplish this is by using SASL? It took me about 10 minutes to figure out how to configure saslauthd to verify binds to the other LDAP server.
Openldap can use SASL right? So I just need to get slapd to use SASL to verify the binds to the other external ldap server.
So I would have: ldapclient bind request-> openldap slapd -> SASL-> external ldap server bind
Is this a good idea?
I don't see how to make slapd use the sasl server for this though, the only examples I can find are to use kerberos.
Any ideas on how to get slapd to just use sasl like I have it setup?
Don Hoover wrote:
Well, I have been working on this question and have had an idea.
Would a way to accomplish this is by using SASL? It took me about 10 minutes
to figure out how to configure saslauthd to verify binds to the other LDAP server.
Openldap can use SASL right? So I just need to get slapd to use SASL to
verify the binds to the other external ldap server.
So I would have: ldapclient bind request-> openldap slapd -> SASL-> external ldap server bind
Is this a good idea?
It would work. Whether it's a good idea or not... The mailing list archives are already full of discussions on that topic, no point in repeating.
I don't see how to make slapd use the sasl server for this though, the only
examples I can find are to use kerberos.
Any ideas on how to get slapd to just use sasl like I have it setup?
You have to configure OpenLDAP with --enable-spasswd. And then you have to actually set the proper values in each user's userPassword.
You should also look into the ITS contributions.
http://www.openldap.org/its/index.cgi/Contrib?id=5042 http://www.openldap.org/its/index.cgi/Contrib?id=5856
They still need some cleaning up, which is why they have not been pushed into CVS yet.
Ok. I have it working pretty well.
I can believe how simple it really was.
The peice I was missing was putting "{SASL}username" into the password field for the openldap record.
This apparently toggles openldap to use SASL for the authentication instead of the local info.
This lets me toggle a user between being authenticated by the openldap server itself or asking SASL to do the authentication for it.
Funny thing is, after I figure this all out, I came across this documentation today which does a pretty good job explaining some of it...At this point I could have written this myself but hopefully it will explain some stuff to others: http://www.openldap.org/doc/admin24/security.html
The one place I differed was I didn't really use a 'realm', because SASL does not need one for just doing authentication to another LDAP server.
I found just putting in {SASL}username, or {SASL}username@realm worked pretty much the same in my case.
I also just configured saslauthd to have a ldap_servers, and ldap_search_base only, since SASL is using username and password provided through openldap to do the binds.
I guess in some ways I am doing a unique thing in that I am actually proxying another real ldap server, and not doing active directory which so many seem to be doing these days.
This was easy enough to encourage me to look at doing some of that data merging to meld data from this external ldapserver with the local data in the record it returns to queries.
--- On Wed, 2/3/10, Howard Chu hyc@symas.com wrote:
From: Howard Chu hyc@symas.com Subject: Re: >Proxy Just Binds/Authentications from another LDAP? To: "Don Hoover" dxh@yahoo.com Cc: openldap-technical@openldap.org Date: Wednesday, February 3, 2010, 4:11 PM Don Hoover wrote:
Well, I have been working on this question and have
had an idea.
Would a way to accomplish this is by using SASL? It
took me about 10
minutes
to figure out how to configure saslauthd to verify binds to the other LDAP server.
Openldap can use SASL right? So I just need to get
slapd to use SASL to verify the binds to the other external ldap server.
So I would have: ldapclient bind request-> openldap slapd
-> SASL-> external ldap server bind
Is this a good idea?
It would work. Whether it's a good idea or not... The mailing list archives are already full of discussions on that topic, no point in repeating.
I don't see how to make slapd use the sasl server for
this though, the
only
examples I can find are to use kerberos.
Any ideas on how to get slapd to just use sasl like I
have it setup?
You have to configure OpenLDAP with --enable-spasswd. And then you have to actually set the proper values in each user's userPassword.
You should also look into the ITS contributions.
http://www.openldap.org/its/index.cgi/Contrib?id=5042 http://www.openldap.org/its/index.cgi/Contrib?id=5856
They still need some cleaning up, which is why they have not been pushed into CVS yet.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Don Hoover wrote:
I also just configured saslauthd to have a ldap_servers, and ldap_search_base only, since SASL is using username and password provided through openldap to do the binds.
I guess in some ways I am doing a unique thing in that I am actually proxying another real ldap server, and not doing active directory which so many seem to be doing these days.
You could also use back-ldap together with slapo-rwm rewriting the bind requests. This would avoid having to set userPassword value and running saslauthd.
Ciao, Michael.
Michael Ströder wrote:
Don Hoover wrote:
I also just configured saslauthd to have a ldap_servers, and ldap_search_base only, since SASL is using username and password provided through openldap to do the binds.
I guess in some ways I am doing a unique thing in that I am actually proxying another real ldap server, and not doing active directory which so many seem to be doing these days.
You could also use back-ldap together with slapo-rwm rewriting the bind requests. This would avoid having to set userPassword value and running saslauthd.
Except that back-ldap will forward all requests to the remote server, not just Bind requests.
I've just added in CVS HEAD a simple extension to back-ldap to allow it to be used as an overlay that only forwards Bind requests. Have a look at that...
http://www.openldap.org/lists/openldap-commit/201002/msg00003.html http://www.openldap.org/lists/openldap-commit/201002/msg00004.html
Howard Chu wrote:
Michael Ströder wrote:
Don Hoover wrote:
I also just configured saslauthd to have a ldap_servers, and ldap_search_base only, since SASL is using username and password provided through openldap to do the binds.
I guess in some ways I am doing a unique thing in that I am actually proxying another real ldap server, and not doing active directory which so many seem to be doing these days.
You could also use back-ldap together with slapo-rwm rewriting the bind requests. This would avoid having to set userPassword value and running saslauthd.
Except that back-ldap will forward all requests to the remote server, not just Bind requests.
Isn't it possible to only rewrite the bind requests to a different naming context which is served by back-ldap?
Ciao, Michael.
Michael Ströder wrote:
Howard Chu wrote:
Michael Ströder wrote:
You could also use back-ldap together with slapo-rwm rewriting the bind requests. This would avoid having to set userPassword value and running saslauthd.
Except that back-ldap will forward all requests to the remote server, not just Bind requests.
Isn't it possible to only rewrite the bind requests to a different naming context which is served by back-ldap?
Probably, but that's much clumsier.
openldap-technical@openldap.org
-
Don Hoover -
Howard Chu -
Michael Ströder