[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1080
  • Last Modified:

securing Miscrosoft LDAP for cloud applicaton and sigle sign-on

We have a a web based application that is hosted in the cloud. We want to enable single sign-on for our staff. We are entirely a Microsoft shop. The vendor does not provide any federated services integration. The only way is allow integration via LDAP. They require us to install software on our DC and then allow an LDAP sync on port 389 to one of their servers. What is the best way to to secure this authentication? On the firewall side I only plan on allowing communication between the IP's they provided and only on port 389. We have a reverse proxy, which will handle the requests.

Is there a better way to do this? I hate to install this on our DC. I read an artcile (can't seem to find it now) that suggested installing AD LDS on a server and syning it with AD DS and using the AD LDS server for LDAP syncing.
1 Solution
btanExec ConsultantCommented:
Was thinking that ADFS 2.0 and Windows Identity Foundation would be more straightforward, but you highlighted no federation from the cloud provider, that is a waste then to make the deployment seamless and secure. The concept of claim based authentication will be for web2.0 architecture as way forward using Windows LiveID etc

@ http://www.microsoft.com/downloads/en/details.aspx?FamilyID=1296e52c-d869-4f73-a112-8a37314a1632&pf=true

This paper contains step-by-step instructions for using Windows® Identity Foundation, Windows Azure, and Active Directory Federation Services (AD FS) 2.0 for achieving SSO across web applications that are deployed both on premises and in the cloud.

Moving forward, the challenge is how trusting is your organisation to the cloud provider. By having the sync, there is sort of two way implicit trust, meaning an user in cloud provider can access the organisation resource? We cannot allow that and it need to be restricted for such remote access especially when firewall is going to open up 389 port - opening for attacker to come in as well. There will need to have some user mapping so that the SSO and for application to be aware to service accordingly to the access control list (if any). Just felt that we should reduce exposing the internal AD if possible - security breach (and cost) is not easily recoverable and justifiable for just application support.

Nonetheless, we note that you will require an authentication store to save authorization information for the identities that the provider and application can service. More of Internet-Facing Solutions

@ http://msdn.microsoft.com/en-us/library/ee373797.aspx

In your case, may want to explore AD LDS which is a candidate for this authentication store because it can host user objects that are not Windows security principals but that can be authenticated with LDAP simple binds. In other words, Web clients can be serviced by portal applications that can run on any platform while they use AD LDS as a simple LDAP authentication store.

@ http://technet.microsoft.com/en-us/library/cc754361%28WS.10%29.aspx

However, AD LDS can be difficult to implement Web applications in an extranet or intranet and provide strong and effective authentication. Kerberos does not work over the Internet, so providing a seamless Web single sign-on (SSO) login experience for users is quite difficult. Solutions often involve placing a policy server in the perimeter network (also known as the DMZ, or demilitarized zone, and screened subnet) that can manage authentication and provide tokens to users for Web SSO. But with ADFS2.0, I am thinking it would handle the authentication and LDS store the credentials of application users. May not be as straightforward but may explore with provider...it may go back to token base cookie for access (claim based identity), this need not be federated though

@ http://technet.microsoft.com/en-us/magazine/2006.07.customdir.aspx

As for the user account in LDS, you may want to note Proxy Authentication that allows a user to perform a simple bind to an AD LDS instance, while still maintaining an association to an Active Directory account.

@ http://technet.microsoft.com/en-us/magazine/2008.12.proxy.aspx

This is helpful when you're using a third-party LDAP client or trying to integrate with a third party directory that requires the X.500 format. In this way, LDS can be an intermediary directory between a third-party directory and Active Directory. Using proxy authentication, the service account that the third-party directory needs to use to bind to the LDS instance can be held in Active Directory instead of LDS itself.

pardon for the lengthy extraction since we are trying to understand which is suitable and the pro/cons. As for security, the key is in the channel and data security. See the following links

@ http://technet.microsoft.com/en-us/library/cc725767%28WS.10%29.aspx
@ http://technet.microsoft.com/en-us/magazine/2006.05.smarttips.aspx

mvozilaAuthor Commented:
This was incredibly helpful. Thank you.

Featured Post

Automating Your MSP Business

The road to profitability.
Delivering superior services is key to ensuring customer satisfaction and the consequent long-term relationships that enable MSPs to lock in predictable, recurring revenue. What's the best way to deliver superior service? One word: automation.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now