We have a public website. The site also contains the intranet (although none of the data on the intranet pages are terribly secret). Users have to login to the website using their Active Directory credentials to see intranet pages.

The web server is in the DMZ, but the port for LDAPS is open through the firewall from the website to the domain controller.

Internet-->Website-->Firewall-->Domain Controller (The above diagram is simplified. There is actually another firewall between the Internet and the website, but I digress.)

However, I don't feel terribly comfortable with this setup. If a party were to compromise the web server, the party would have some limited ability to see the domain controller through the LDAPS port. In addition, I'm not sure there is a good way to prevent brute-force attacks in this scenario.

Is there a safer setup to accomplish this same goal?

I don't have anything to do with it directly, but we're using Azure AD for Office 365, and it's synced to our on-premises AD. Would it be safer to use Azure AD for authentication? My understanding is that SSO through Azure costs additional dollars, though.

  • 1
    Do consider using VPN. It is costly to setup but it is easier than all sort hardening and patching to deal with unwanted penetration.
    – mootmoot
    Dec 29, 2017 at 10:56
  • VPN from where to where?
    – JasonF
    Dec 29, 2017 at 16:10

3 Answers 3


It does not appear to me that this produces a specifically dangerous attack surface - Provided your AD accounts are sufficiently secure that their passwords can't be brute forced, and that your LDAP server is properly secured and patched. While it's true that a compromise of the web server would open your LDAP server to attacks, there isn't necessarily much you can do to mitigate this.

I considered that if your web server gets compromised, it might be useful to have a proxy between your web server and the LDAP server, but that gives you one more server to update and patch, otherwise that will just be compromised and used to attack the LDAP server instead. That is, of course, not a certain thing, and requires another series of attacks to get into the same position as the situation without the web server, but it can provide some extra defense in depth.

  • Could you elaborate on the proxy? I know the term but not exactly what it is and how it would be useful. Or, if you know off-hand any web links about proxies in the sense that you're talking about them, that'd be great, too. As for the AD accounts and being brute-forced; there's not much I can do to ensure the passwords are great. I mean, we do enforce password complexity, but in my opinion, it doesn't add much. That's why I was wondering if Azure AD might be better option. I'm guessing Azure AD adds additional protections?
    – JasonF
    Dec 29, 2017 at 16:07
  • 1
    You can set up a system to receive the LDAP requests, check them for badness, and forward them on if appropriate. Here is an example of one service that does that. Dec 29, 2017 at 16:31

The book, Group Policy: Fundamentals, Security, and the Managed Desktop, Third Edition has an Appendix E which covers using Microsoft Intune for external patching in combination with PolicyPak Cloud for group policy settings when either remote and domain-joined (e.g., VPN) -- or remote and non-domain joined.


However, I don't feel terribly comfortable with this setup.

And IMO you're right with your feeling.

Example: If you're domain admins activated account lockout after repeated login failures an external attacker can start a denial-of-service attack in your whole domain guessing user names.

You could mitigate that by throttling failed logins in your web application. But you have to reliably implement that in every web application using this kind of login.

Another solution would be two-factor authentication used with checking the OTP before really checking the user's password.

Another thing to consider with your Domain Admins: Sometimes they update their domain controller (DC) infrastructure by installing new DCs with newer Windows version running on different IP address(es) but serving the same domain. This is no issue in the Windows world because DCs are announced via DNS SRV RRs. But you will likely have to adjust your firewall rules.

Additionally I'd suggest to install a LDAP application-level proxy based on OpenLDAP's back-ldap because OpenLDAP has rather strict input validation on LDAP PDUs. With such a setup you could also restrict LDAP access to e.g. a certain AD group mitigating the risk for the rest of your domain.

Regarding transport encryption: Yes, use TLS everywhere!

Regarding Web-SSO: Yes, that's a viable solution because with most SSO protocols the user's browser is redirected to an identity provider, the SSO messages are signed and thus there is no need to directly access a user management from your app. You have to dive into the protocols a bit to understand that.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .