The old school of thought was that application and database servers should not be part of the domain. I have my network setup such that only the app servers can communicate with the db servers. The app servers are in their own workgroup and the db servers are in their own workgroup. The servers are completely isolated from the rest of the network and developers get access via vpn/rdp. Is this still a good way setting up the infrastructure?

The reason I ask is that I'm finally updating the environment with Active Directory and there is a window to redesigning the network architecture if it is appropriate.

I'm not really a sys admin, but need to fulfill the role...


I really appreciate everyone's patience and assistance. I know very little about Active Directory. My main concern is that a user machine will be compromised (zombie) and that this compromised machine could be used to access production servers via AD. Using AD would make my life a lot easier, but a single compromise would devastate the company. Right now, there is very little possibility of an unauthorized user getting access to internal production servers.

In any event, it seems that the consensus is that AD does not add risk to production servers and it is a generally acceptible practice to do so. So, I suppose I should start ramping up in my knowledge of AD and correct setup or see if there is a local expert who can do this.

Thanks for all the info.

  • 496
  • 1
  • 8
  • 16

9 Answers9


There is a reason why large enterprises use Active Directory. It makes more sense. Things to consider:

  • If I compromise your computer, you've either got different passwords everywhere, which means you likely have passwords stored somewhere or you're going to re-use the same password. Not everyone is going to have a decent password vault. In either case, I'm eventually going to get the keys somewhere else.
  • With the servers on AD, you get the advantage of a global lockout policy. Which means if you have X login failures over Y minutes in total, the account locks. So I don't get X chances here and X chances there and another X chances over younder for a total of 3X chances (if you're re-using passwords). I get X. When X > 0, X < 3X.
  • GPOs. Managed configurations such as Restrict Anonymous, Audit Settings, size of event logs, whether or not Administrator is renamed, whether to allow LM Hashes or do NTLM, etc. All of this can be controlled and pushed from AD and automatically enforced. From a security perspective, this blows the manual server by server process out of the water, as an good IT auditor will tell you.
  • Single source for security. You have a user go rogue. You figure it out. You disable that user's account on the domain. Guess what? That user isn't logging in anywhere else. You try that with multiple disparate systems, and you're going to have to hit every one.

Look, you can still hardware firewall the key servers off, and that's a good idea, carving the appropriate holes so these server can talk to DCs and so clients can only talk to these servers on the right ports. For instance, there's no reason why an end user should have NetBIOS access to a database server. And there's no reason the file server needs to talk to the SQL Server, so don't let them. And then you restrict the overall surface area.

K. Brian Kelley
  • 9,034
  • 32
  • 33

I'd put them on; at the very least the gains from integrated authentication far outweigh any perceived downsides. Overall management of the OS will be made a lot smoother, and if your apps and dbs have a security model that enables them to have their own dedicated admins and that doesn't grant standard domain admins full access to them, you're not really losing anything there.

I'm not sure if worries about your AD being compromised are valid here. If your AD is compromised, surely that means that you've got bigger problems anyway?

Maximus Minimus
  • 8,987
  • 2
  • 23
  • 36
  • The rest of the network has regular users... users who download viruses, users who install things they don't understand, etc. yes you could try to mitigate that, but when the vp/pres/ceo wants to try out some new fangled download, you end up having to let them. if any of the compromises are serious, the invading agent can take over your entire network. in my current case, i'd be somewhat annoyed, but we can recover. if i switch the app servers to ad, then my production (health care) data is compromised and we're out of business. – mson Aug 13 '09 at 16:44
  • 1
    mson - Please don't take this as a knock on you, because it isn't. There is a lot that you don't understand about how AD works and how machines are compromised. Just because a machine is a member of a domain does not mean that every user has permission to use it, and AD does not store passwords, it stores hashes, so even if a DC is compromised it does not expose credentials for your entire organization. I fail to see how a virus on an unprivileged user's computer could compromise a server. – MDMarra Aug 13 '09 at 18:00
  • thanks mark - i don't understand how AD works... can you confirm that a compromised machine in the same AD as production servers cannot access those production servers if i properly setup AD (with VLAN)? i'm not necessarily concerned about viruses - I'm concerned about compromised user machines. i do understand that passwords are hashed, but there are scripts to unhash a lot of implementations. the average user uses pretty easy to hack passwords. there are thousands of sleeper zombie machines in corporate lans... – mson Aug 13 '09 at 18:07
  • If you have "Thousands of sleeper zombies" in your corporate network, you need to reassess your antivirus, perimeter protection, and security policies. – phuzion Aug 13 '09 at 20:19
  • VLAN is a physical network solution, which is a good one. However, within Group Policy, you can set a parameter for the OU that the servers are in that permits logins only from certain users. Also it is a little more than just unhashing to get credentials out of a compromised machine as it is a "salt and hash" algorithm that is used to create them. Finally, the average user can easily hack passwords if the passwords are not strong passwords. If you limit logon to the servers to trusted users and enforce the password complexity GPO, you are on the right track to a secure network. – MDMarra Aug 13 '09 at 21:57
  • the zombie comment was directed at other networks. there are several cases of major corporations who use ad who have zombies in their network. i'm not sure what the ratio to discovered and undiscovered are, but i think it's safe to conjecture there are thousands of compromised machines. – mson Aug 13 '09 at 22:05
  • Local passwords are easy enough to walk through, but AD passwords are another matter. The way I would do it is to stick a firewall between the production boxes and the main network. Open the ports needed to communicate with AD and define rules for which boxes they can communicate with (DCs, DNS, etc), then only open the ports required by the apps for the rest of your main network. – Maximus Minimus Aug 13 '09 at 22:53
  • Hashes are generated by 1 way functions, meaning you can't unhash. You can use rainbow tables, yes, because AD does NOT use a salt. However, just because you compromise a workstation does not mean you have any rights on a server. By default you don't. If you give them access to a share, they can hit the share, but they aren't going to run interactive processes on the servers. And about zombies... egress filtering on your firewall. Web filtering software as well. Those are the mitigants. – K. Brian Kelley Aug 14 '09 at 02:16
  • If you read a little closer, you'll see that I was talking about cached login credentials on a workstation, which are salted – MDMarra Aug 14 '09 at 11:24
  • It's bad practice to make someone an admin on their machine *especially* if they keep installing trash, but we understand this happens sometimes. AD allows separation of roles - it's possible for a user to be a local admin of their desktop computer *without* being an admin of other desktop computers on the network, servers on the network, or of the domain in general. The same goes for the computers themselves - a compromised machine *whether in a domain or not* is a foothold on the network that malware can use to spread but again, control of one computer doesn't equate to control of others. – Rob Moir Aug 31 '13 at 09:12

I can't think of a single good reason to segregate DB and App servers from the domain. We're running untold amounts of SQL and Oracle servers, and application servers (in excess of 100), in our forest.

I dread to think what a logistical pain in the neck it would be for us to operate if they were segregated into workgroups.

  • 8,224
  • 2
  • 31
  • 35
  • if you're ad gets compromised, your production data gets compromised sure - it's more convenient, but it seems you sacrifice security – mson Aug 13 '09 at 15:17
  • also - you have lots of users in ad. if your app/db servers are part of ad, then there is a chance that either through security flaw or admin mistake that someone could get access to production data – mson Aug 13 '09 at 15:18
  • are you suggesting that ad is nearly impossible to hack? data security is extremely important for my organization. a single compromise would make us liable for millions of dollars and would put the company under. – mson Aug 13 '09 at 15:23
  • 1
    From the sounds of it you've already made your choice. If it were such a big security hole I'm pretty sure AD wouldn't be in use the way it is today. The mistake in AD to allow someone access to production data can happen just as easily without AD, if not more so since all accounts are local machine accounts. Does every developer have their own login or do you use generic ones with shared passwords? Does every machine have the same hardened security policy? Are you sure without auditing each one? Human error is human error. – SpaceManSpiff Aug 13 '09 at 16:33
  • Seems everyone else concurs with my assessment? – Izzy Aug 13 '09 at 16:33
  • i've made the decision in the past and am open to changing the setup (it is a pain to manage even just 8 servers). the current setup does not readily allow for accidental access to production data. the only external interface to the app server is port 80/443. the only interface to the db server is single port from specified internal ips. all access to the apps is logged on web server and on db server. all access to db needs to be explicitly provided. only 2-3 users have authority to log on to production. passwords are 12+ characters and cannot be brute forced in time 12+^64k. – mson Aug 13 '09 at 16:55
  • i'm new to ad and do not fully understand the security that it offers. – mson Aug 13 '09 at 16:57
  • You're substituting good server-hardening practices (in domain) with the soft option of just hiving your machines away where you **think** nobody can see them. Worms/viruses are network aware, not AD aware. Users/intruders can still *see* those servers. Logging makes no difference whether it's in domain or not - it'll still happen. You make plenty of valid points, but they are all outweighed by the advantages of centrally managing and securing your machines inside AD, with such things as Group Policy (which you can use to totally lock down access to those boxes - CENTRALLY). – Izzy Aug 13 '09 at 17:11
  • there is no network connection between production machines and office network. – mson Aug 13 '09 at 18:26
  • the office network has been brought down before (several user machines compromised), but our production apps have never been down or compromised. – mson Aug 13 '09 at 18:27
  • What you want is a DMZ, and it sounds like you may already have it you just don't know the name of it. – MDMarra Aug 13 '09 at 18:51

Complexity is the enemy of security. Put your servers inside Active Directory.

Carl C
  • 1,038
  • 3
  • 10
  • 19

AD & the domain allows central management of the server restricting things like user accounts, GPO, internet browsing, installing software, the list is endless. Not to mention password resets if an account that is used on 10 machines is compromised, since in a work group its 10 machines to login to and reset, now if that was 100 machines thats crazy, not to mention if you miss one machine you have a hole. Unless you start scripting all that out.

If seperating the production machines from the workstation network is really what you want to do then you can firewall between the two networks and still have the on the same AD.

Or have 2 completely independant domains with trusts (or not) between them as needed.

or have a domain with 2 forests

or well the list is endless its really what your needs are.

One of your concerns is a user's machine being infected with a virus and then infecting the production server if it's they are both on AD. AD does not work like that. AD is in itself a database of your domain.

If machine A has a virus and has network access to machine B, then machine A can attack machine B. There is no AD involved. Machine A is just doing what a virus does to attack another machine. It can try and brute for machine B, it can try an RPC attack and so on. AD has nothing to do with enabling that attach. What is needed in this case is a firewall between the 2 networks. So you would have Network A for workstions and Network B for production. That is a common setup in companies is how you prevent what you are worried about.

Check out Evan's answer about what AD is.

  • 2,547
  • 18
  • 20
  • let's say i'm a virus/trojan writer. i get someone to visit my site and that user's machine is compromised. if my production machines are on the same network, couldn't i set a background process to start brute forcing other accounts? isn't my current setup much more secure? there are 8 servers and yes it's annoying to change passwords, but there are only 2-3 people with access and the passwords cannot be readily brute-forced. – mson Aug 13 '09 at 16:47
  • perhaps i don't understand AD well enough. if i have 2 completely independent domains with no trusts between them, wouldn't compromising an account in 1 given me access in some fashion to AD and then from there i can start trying to get into the other domain? – mson Aug 13 '09 at 16:48
  • Somewhere else you said that your servers' user accounts are complex and would be hard to brute force, why are you worried about brute force now? In AD, you can limit what users can log into a specific machine. Why don't you limit it to a small group of users and enforce a password complexity and length rule on them via GPO? – MDMarra Aug 13 '09 at 18:03
  • if i can compromise the ad machine, i can just change the password – mson Aug 13 '09 at 18:24
  • "couldn't i set a background process to start brute forcing other accounts?" Sure, but the way to battle that is to set AD to lock an account after x amount of consecutive failed password attempts. – phuzion Aug 13 '09 at 20:21
  • does the failed password attempts work even if i just use it for mapping a directory and not for logging in? – mson Aug 13 '09 at 22:07
  • Yes, any failed password attempts without a successful login in between. Also, if you have IDS in place (even an open source solution), you're going to see the attack. – K. Brian Kelley Aug 14 '09 at 02:13

I'd put the servers inside AD, as everyone else is suggesting. If you're really concerned about security, put those specific servers on a seperate VLAN and only allow them to communicate to specific hosts on specific ports. This will prevent RDP, UNC access, etc etc and only allow what's necessary.

  • 470
  • 2
  • 7

I agree with Izzy. Domains make managing those servers MUCH easier which in turn can make them more secure.

Multiverse IT
  • 1,825
  • 9
  • 11

It seems you know a bit of AD, but not a whole lot, so I'm going to suggest that you go and take either a introductory course on AD, or a more in-depth course on AD and Windows Server Management as a whole. It will answer tons of your questions, and the people administering the course should be able to answer some of your questions with hypothetical scenarios. You should be able to pitch your current network layout to them, and they should give you suggestions on where to improve, why integrating the servers into AD is a good idea, how to secure people out of them, etc.

Chances are, if your company values you as a sysadmin, they might pay for your courses as well, which is a bonus.

But I'm going to go with everyone on this: Definitely add your servers to AD, but do it right. I'm not at liberty to say exactly what is right for your organization, because I don't know anything about it, but lock it down as much as you can without making it unusable to the people that need to use it.

And here's a hypothetical situation that might make you think again about adding your servers to AD: You have a developer or fellow system admin, who is terminated. Your boss calls you up and says "This person MUST be locked out of the system IMMEDIATELY. We suspect they may be attempting to steal HIPAA protected information from us, and he no longer works here. Lock him out now." (I'm assuming you guys have data that is covered under HIPAA, as you mentioned healthcare)

With your current setup, not only do you have to lock out his AD account, but you also have to go to each server, and disable his account there as well. If the servers were in AD, you could instantly disable his access to those servers in less than 30 seconds. It's a simple matter of: RDP to DC, Open Active Directory Users and Computers, Right click on his name, Click Disable. Bam, done. He's locked out.

But definitely, get those into AD as soon as you understand the best way to keep them secure.

  • 2,213
  • 1
  • 19
  • 23
  • i wish i had time to take a course. but as to your security scenario, it's quite simple to lock someone out. I disable his vpn account and he can no longer get in. then i can run a script to disable his account on all the servers. – mson Aug 13 '09 at 22:02

Servers in workgroups are a management nightmare for most networks. The security gained is more imaginary than real. If a compromised machine has permissions to access the server it matters not one iota whether it's a workgroup or domain server. As permissions are very much easier to manage at the domain level I believe having servers in the domain actually enhances security, provided of course it's all done properly.

John Gardeniers
  • 27,458
  • 12
  • 55
  • 109