Active Directory on a Public Facing Website

Permalink
I'm not a hugely knowledgeable network admin, and only know enough (to be dangerous), but can someone confirm that Active Directory sign-on functionality is for Intranet's and systems from within a network? And not a public facing website?

I'm trying to wrap my head around a client's question on integrating A.D.

Thanks.

Deladroid
 
Mainio replied on at Permalink Reply
Mainio
I don't think exposing it to the public internet sounds like a good idea.

Here's some good answers on that that mainly back my opinion:
http://serverfault.com/questions/573681/should-i-expose-my-active-d...

But as stated there, you're still able to build SSO for your website that relies on the AD backend. You just need to build some middle-layer for web authentication that connects securely to the AD network.

Shibboleth is one good option for SSO and I believe it connects to AD as well. I've seen quite large organizations use it, which of course is no guarantee of anything but at least tells you that it passes quite extensive security testing as well as other requirements of larger organizations.

Other alternatives also exist, that's just one example.
exchangecore replied on at Permalink Reply
exchangecore
Late reply but while all things LDAP are fresh in my head...

You can most certainly have a public facing website which uses active directory authentication. Most OWA (outlook webmail) sites for instance do this essentially. I do recommend that any time you do this though, you force an SSL connection on the site, and additionally recommend using LDAPS or StartTLS when you connect from your web server to your Active Directory server.

Also, you should almost never expose your LDAP server directly to the internet (i.e. exposing ports 389/636), but rather should leverage it "behind the firewall" from your webserver. This means that your web server should be on the same internal network as your LDAP server if you're going to use this setup.
ijessup replied on at Permalink Reply
ijessup
If the web server is internal, you don't have much to worry about. If the web server is external you have a a couple options.

You can set up a secondary LDAP server that is read only. A lot of EDUs and municipalities do this.

Or you can set up a HAProxy server that can relay requests to the AD server, but only accepts requests from the IP address of your public web server.

If the client is using Active Directory, it is likely they are also using Exchange. If that is the case, instead of validating against the AD, it might be easier to validate against Exchange's SMTP service. That won't work for situations where you need access to user policy data, but if all you need to do is validate credentials it works like a charm.
ijessup replied on at Permalink Reply
ijessup
If the web server is internal, you don't have much to worry about. If the web server is external you have a a couple options.

You can set up a secondary LDAP server that is read only. A lot of EDUs and municipalities do this.

Or you can set up a HAProxy server that can relay requests to the AD server, but only accepts requests from the IP address of your public web server.

If the client is using Active Directory, it is likely they are also using Exchange. If that is the case, instead of validating against the AD, it might be easier to validate against Exchange's SMTP service. That won't work for every case, and you won't have access to user policy data; but if all you need to do is validate credentials it works like a charm.