Goal: LDAP server in Internet facing DMZ to provide authentication for externally hosted applications using internal AD credentials. I've done a LOT of reading and testing, and there is one thing I am still not 100% clear on: Is it possible to do this WITHOUT having a local user database on the OpenLDAP proxy? We will have thousands of users that will need to authenticate, and I can't maintain another user database (adds, removes, etc..). Is there a way to make OpenLDAP just act more like a reverse proxy and forward anything that matches a specific domain on to the internal LDAP/AD server for password verification?
I would start here:
http://www.openldap.org/software/man.cgi?query=slapd-ldap&apropos=0&...
and here:
http://www.openldap.org/software/man.cgi?query=slapo-rwm&sektion=5&m...
and see where that leads.
HTH, Stephan
On Tue, Oct 14, 2014 at 1:46 PM, Jeff Lebo jeflebo@outlook.com wrote:
Goal: LDAP server in Internet facing DMZ to provide authentication for externally hosted applications using internal AD credentials.
I've done a LOT of reading and testing, and there is one thing I am still not 100% clear on:
Is it possible to do this WITHOUT having a local user database on the OpenLDAP proxy? We will have thousands of users that will need to authenticate, and I can't maintain another user database (adds, removes, etc..). Is there a way to make OpenLDAP just act more like a reverse proxy and forward anything that matches a specific domain on to the internal LDAP/AD server for password verification?
Jeff,
The basic functionality is there. You can tell OpenLDAP to use SASL for authentication, against any available SASL mechanism that's supported on your platform. Part of the story is here:
http://www.openldap.org/doc/admin24/security.html#Pass-Through authentication
Pay very close attention to paragraph 14.5.1. That little SASL config file (not part of OpenLDAP) will stop the show if it's not right.
I almost had it working, but I couldn't do it, because I still needed local LDAP password hashes in my use case. I couldn't get the "{SASL}" password value to work for some reason. Turning on SASL pass-through seemed to be an all or nothing choice in my case. You will probably have to do some work to get it up and running.
Best,
--Bruce
On Tue, Oct 14, 2014 at 1:46 PM, Jeff Lebo jeflebo@outlook.com wrote:
Goal: LDAP server in Internet facing DMZ to provide authentication for externally hosted applications using internal AD credentials.
I've done a LOT of reading and testing, and there is one thing I am still not 100% clear on:
Is it possible to do this WITHOUT having a local user database on the OpenLDAP proxy? We will have thousands of users that will need to authenticate, and I can't maintain another user database (adds, removes, etc..). Is there a way to make OpenLDAP just act more like a reverse proxy and forward anything that matches a specific domain on to the internal LDAP/AD server for password verification?
Bruce, My SASL authentication is working... I am still confused on how to setup OpenLDAP to pass ALL attempts through to SASL. The only method I've found is to create users in a local OpenLDAP database and set the userPassword attribute to {SASL}username@REALM. What am I missing here?
Date: Tue, 14 Oct 2014 16:23:26 -0700 Subject: Re: OpenLDAP as proxy to Active Directory backend From: bruce.carleton@dena.com To: jeflebo@outlook.com CC: openldap-technical@openldap.org
Jeff,
The basic functionality is there. You can tell OpenLDAP to use SASL for authentication, against any available SASL mechanism that's supported on your platform. Part of the story is here:
http://www.openldap.org/doc/admin24/security.html#Pass-Through authentication
Pay very close attention to paragraph 14.5.1. That little SASL config file (not part of OpenLDAP) will stop the show if it's not right.
I almost had it working, but I couldn't do it, because I still needed local LDAP password hashes in my use case. I couldn't get the "{SASL}" password value to work for some reason. Turning on SASL pass-through seemed to be an all or nothing choice in my case. You will probably have to do some work to get it up and running.
Best,
--Bruce
On Tue, Oct 14, 2014 at 1:46 PM, Jeff Lebo jeflebo@outlook.com wrote:
Goal: LDAP server in Internet facing DMZ to provide authentication for externally hosted applications using internal AD credentials.
I've done a LOT of reading and testing, and there is one thing I am still not 100% clear on:
Is it possible to do this WITHOUT having a local user database on the OpenLDAP proxy? We will have thousands of users that will need to authenticate, and I can't maintain another user database (adds, removes, etc..). Is there a way to make OpenLDAP just act more like a reverse proxy and forward anything that matches a specific domain on to the internal LDAP/AD server for password verification?
That's right, you have to create LDAP entries for the passthrough authentication. I guess you could create some kind of sync service between AD and the LDAP proxy, but it might be kind of hairy to get it working properly. Others might have better suggestions.
On Tue, Oct 14, 2014 at 5:11 PM, Jeff Lebo jeflebo@outlook.com wrote:
Bruce,
My SASL authentication is working...
I am still confused on how to setup OpenLDAP to pass ALL attempts through to SASL. The only method I've found is to create users in a local OpenLDAP database and set the userPassword attribute to {SASL}username@REALM.
What am I missing here?
Date: Tue, 14 Oct 2014 16:23:26 -0700 Subject: Re: OpenLDAP as proxy to Active Directory backend From: bruce.carleton@dena.com To: jeflebo@outlook.com CC: openldap-technical@openldap.org
Jeff,
The basic functionality is there. You can tell OpenLDAP to use SASL for authentication, against any available SASL mechanism that's supported on your platform. Part of the story is here:
http://www.openldap.org/doc/admin24/security.html#Pass-Through authentication
Pay very close attention to paragraph 14.5.1. That little SASL config file (not part of OpenLDAP) will stop the show if it's not right.
I almost had it working, but I couldn't do it, because I still needed local LDAP password hashes in my use case. I couldn't get the "{SASL}" password value to work for some reason. Turning on SASL pass-through seemed to be an all or nothing choice in my case. You will probably have to do some work to get it up and running.
Best,
--Bruce
On Tue, Oct 14, 2014 at 1:46 PM, Jeff Lebo jeflebo@outlook.com wrote:
Goal: LDAP server in Internet facing DMZ to provide authentication for externally hosted applications using internal AD credentials.
I've done a LOT of reading and testing, and there is one thing I am still not 100% clear on:
Is it possible to do this WITHOUT having a local user database on the OpenLDAP proxy? We will have thousands of users that will need to authenticate, and I can't maintain another user database (adds, removes, etc..). Is there a way to make OpenLDAP just act more like a reverse proxy and forward anything that matches a specific domain on to the internal LDAP/AD server for password verification?
Yea, the logic I am looking for is: If user authenticates with @domain.com, passthrough/redirect authentication on to LDAP backend, WITHOUT looking for a local entry in the OpenLDAP database. This network doesn't have the resources to maintain another user database, even if it via some automated sync process... was just hoping to implement a "dumb" reverse proxy for LDAP in order to prevent storing usernames/passwords in an Internet facing DMZ (or in the case of using a Windows LDAP server, putting a DC member in the DMZ).
Date: Tue, 14 Oct 2014 17:18:01 -0700> Subject: Re: OpenLDAP as proxy to Active Directory backend From: bruce.carleton@dena.com To: jeflebo@outlook.com CC: openldap-technical@openldap.org
That's right, you have to create LDAP entries for the passthrough authentication. I guess you could create some kind of sync service between AD and the LDAP proxy, but it might be kind of hairy to get it working properly. Others might have better suggestions.
On Tue, Oct 14, 2014 at 5:11 PM, Jeff Lebo jeflebo@outlook.com wrote:
Bruce,
My SASL authentication is working...
I am still confused on how to setup OpenLDAP to pass ALL attempts through to SASL. The only method I've found is to create users in a local OpenLDAP database and set the userPassword attribute to {SASL}username@REALM.
What am I missing here?
Date: Tue, 14 Oct 2014 16:23:26 -0700 Subject: Re: OpenLDAP as proxy to Active Directory backend From: bruce.carleton@dena.com To: jeflebo@outlook.com CC: openldap-technical@openldap.org
Jeff,
The basic functionality is there. You can tell OpenLDAP to use SASL for authentication, against any available SASL mechanism that's supported on your platform. Part of the story is here:
http://www.openldap.org/doc/admin24/security.html#Pass-Through authentication
Pay very close attention to paragraph 14.5.1. That little SASL config file (not part of OpenLDAP) will stop the show if it's not right.
I almost had it working, but I couldn't do it, because I still needed local LDAP password hashes in my use case. I couldn't get the "{SASL}" password value to work for some reason. Turning on SASL pass-through seemed to be an all or nothing choice in my case. You will probably have to do some work to get it up and running.
Best,
--Bruce
On Tue, Oct 14, 2014 at 1:46 PM, Jeff Lebo jeflebo@outlook.com wrote:
Goal: LDAP server in Internet facing DMZ to provide authentication for externally hosted applications using internal AD credentials.
I've done a LOT of reading and testing, and there is one thing I am still not 100% clear on:
Is it possible to do this WITHOUT having a local user database on the OpenLDAP proxy? We will have thousands of users that will need to authenticate, and I can't maintain another user database (adds, removes, etc..). Is there a way to make OpenLDAP just act more like a reverse proxy and forward anything that matches a specific domain on to the internal LDAP/AD server for password verification?
Put a cluster of read-only DC's in one DMZ, then a TCP proxy cluster in front of the DC's, that's in a second DMZ?
On Tue, Oct 14, 2014 at 5:24 PM, Jeff Lebo jeflebo@outlook.com wrote:
Yea, the logic I am looking for is:
If user authenticates with @domain.com, passthrough/redirect authentication on to LDAP backend, WITHOUT looking for a local entry in the OpenLDAP database.
This network doesn't have the resources to maintain another user database, even if it via some automated sync process... was just hoping to implement a "dumb" reverse proxy for LDAP in order to prevent storing usernames/passwords in an Internet facing DMZ (or in the case of using a Windows LDAP server, putting a DC member in the DMZ).
Date: Tue, 14 Oct 2014 17:18:01 -0700 Subject: Re: OpenLDAP as proxy to Active Directory backend From: bruce.carleton@dena.com To: jeflebo@outlook.com CC: openldap-technical@openldap.org
That's right, you have to create LDAP entries for the passthrough authentication. I guess you could create some kind of sync service between AD and the LDAP proxy, but it might be kind of hairy to get it working properly. Others might have better suggestions.
On Tue, Oct 14, 2014 at 5:11 PM, Jeff Lebo jeflebo@outlook.com wrote:
Bruce,
My SASL authentication is working...
I am still confused on how to setup OpenLDAP to pass ALL attempts through to SASL. The only method I've found is to create users in a local OpenLDAP database and set the userPassword attribute to {SASL}username@REALM.
What am I missing here?
Date: Tue, 14 Oct 2014 16:23:26 -0700 Subject: Re: OpenLDAP as proxy to Active Directory backend From: bruce.carleton@dena.com To: jeflebo@outlook.com CC: openldap-technical@openldap.org
Jeff,
The basic functionality is there. You can tell OpenLDAP to use SASL for authentication, against any available SASL mechanism that's supported on your platform. Part of the story is here:
http://www.openldap.org/doc/admin24/security.html#Pass-Through authentication
Pay very close attention to paragraph 14.5.1. That little SASL config file (not part of OpenLDAP) will stop the show if it's not right.
I almost had it working, but I couldn't do it, because I still needed local LDAP password hashes in my use case. I couldn't get the "{SASL}" password value to work for some reason. Turning on SASL pass-through seemed to be an all or nothing choice in my case. You will probably have to do some work to get it up and running.
Best,
--Bruce
On Tue, Oct 14, 2014 at 1:46 PM, Jeff Lebo jeflebo@outlook.com wrote:
Goal: LDAP server in Internet facing DMZ to provide authentication for externally hosted applications using internal AD credentials.
I've done a LOT of reading and testing, and there is one thing I am still not 100% clear on:
Is it possible to do this WITHOUT having a local user database on the OpenLDAP proxy? We will have thousands of users that will need to authenticate, and I can't maintain another user database (adds, removes, etc..). Is there a way to make OpenLDAP just act more like a reverse proxy and forward anything that matches a specific domain on to the internal LDAP/AD server for password verification?
Jeff Lebo wrote:
Goal: LDAP server in Internet facing DMZ to provide authentication for externally hosted applications using internal AD credentials.
I've done a LOT of reading and testing, and there is one thing I am still not 100% clear on:
Is it possible to do this WITHOUT having a local user database on the OpenLDAP proxy? We will have thousands of users that will need to authenticate, and I can't maintain another user database (adds, removes, etc..). Is there a way to make OpenLDAP just act more like a reverse proxy and forward anything that matches a specific domain on to the internal LDAP/AD server for password verification?
That's exactly what back-ldap does. A couple other posts have already pointed you to its manpage/documentation. Everything else mentioned so far (SASL passthrough) is misdirection.
Excellent... I am now able to simulate the process that the external application will use: - Bind to OpenLDAP server using AD service account.- Search for DN of user account using sAMAccountName filter.- Bind to OpenLDAP server using DN and password of user account to provide auth for application. How can I limit what data is accessible via search? Since all I am trying to do is check user/pass, the only thing I'd like to allow returned to the client is the DN. I've tried with 'rwm-map attribute *' per a few documents I found, but I don't get anything returned via my LDAP search with that in the config (I've tried lots of different combos above that to allow data, then block all other data). Now that I think I've got this working for the most part... what are some best security practices for this setup?
Date: Wed, 15 Oct 2014 01:50:02 +0100 From: hyc@symas.com To: jeflebo@outlook.com; openldap-technical@openldap.org Subject: Re: OpenLDAP as proxy to Active Directory backend
Jeff Lebo wrote:
Goal: LDAP server in Internet facing DMZ to provide authentication for externally hosted applications using internal AD credentials.
I've done a LOT of reading and testing, and there is one thing I am still not 100% clear on:
Is it possible to do this WITHOUT having a local user database on the OpenLDAP proxy? We will have thousands of users that will need to authenticate, and I can't maintain another user database (adds, removes, etc..). Is there a way to make OpenLDAP just act more like a reverse proxy and forward anything that matches a specific domain on to the internal LDAP/AD server for password verification?
That's exactly what back-ldap does. A couple other posts have already pointed you to its manpage/documentation. Everything else mentioned so far (SASL passthrough) is misdirection.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
openldap-technical@openldap.org
-
Bruce Carleton -
Howard Chu -
Jeff Lebo -
Stephan Fabel