2

This question already has an answer here:

I want to be specific about terms. When I say DMZ I'm talking about a place where you would put servers that expose a service to untrusted networks like the Internet, or in some cases merely networks that are less trusted.

I am attempting to shore up our network perimeter by auditing what we expose through our firewall. The firewall I am talking about is NOT a Microsoft ISA server and never will be. If any of you are in this situation you know that the ports required to allow a member server to connect to domain controllers is pretty extensive. Microsoft in attempting to address this provides several designs using RODC's to reduce the count of open ports, but even if it were just one port the Active Directory itself is a trove of intel for an unauthorized person who has compromised a DMZ member server.

What is the consensus about AD member servers in a DMZ? Too insecure, or acceptable risk? Assuming the former (where I'm leaning), aside from local account authentication are there any more secure options than AD for authenticating users who sign onto DMZ Windows servers? If not, then is there a mechanism that can associate a local account with a real person at login for auditing purposes? It seems like the only option for tracking users' behaviour in a standalone server DMZ would be to create local machine accounts for every user who logs onto the servers.

Of course, ideally you don't have people logging on to servers for normal operations; the whole thing should be managed by proxy using services accounts (that's a whole 'nother discussion). But right now our operation isn't "there" yet. We're hopeful that DSC makes that feasible.

The focus of Microsoft's recommendations are to me either impractical or missing the point. An Active Directory for just a DMZ reduces an intruder's ability to gather intel, but still leaves the vector pretty much in-place. The best their solutions can do is split the risk baby by limiting that intel to the DMZ (plus whatever else your DMZ AD might service). The trade-off is an AD for every DMZ. So now your admins are managing one account + N DMZ's.

Not that Microsoft is listening, but there needs to be a middle way that auths a windows user but doesn't require the use of credentials that can do things like enum LDAP users.

marked as duplicate by mdpc, Massimo, Hyppy, fukawi2, Rex May 8 '15 at 14:41

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • Whats your goal ? If we talk IIS in the DMZ, you can do a reverse lookup. It will mitigate the risk. (for a more generic answer, I will post a possible duplicate.) – yagmoth555 May 7 '15 at 1:53
  • AD membership comes with some advantages for managing servers at scale. Authentication and group policies are the two biggest examples. If we discard AD for security reasons we need to come with viable alternatives to these. As I mentioned DSC nicely replaces GPO, but what about authentication? If a team member logs onto a standalone server what's best practice? Shared accounts are easy but impossible to track who used them and not really very secure if all your member servers' accounts have the same passwords. – Cignul9 May 7 '15 at 18:22
  • Yes, but you need the authentication for what ? What is your goal. – yagmoth555 May 7 '15 at 18:48
0

I don't know how others feel, but my point of view is this:

If the AD server is being used for corporate/internal authentication/authorization then it should never be on the DMZ. If it's being used for auth on an externally available application, then yes - it belongs there, assuming it has no hooks at all into the DRN.

As you stated, a DMZ allows untrusted networks access to provided services. Those services can be compromised, and if your internal directory is there - it will be too.

Not the answer you're looking for? Browse other questions tagged or ask your own question.