Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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...

EDIT

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.

share|improve this question

9 Answers 9

up vote 4 down vote accepted

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?

share|improve this answer
    
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

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.

share|improve this answer

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.

share|improve this answer
    
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

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

share|improve this answer
    
my current situation is not complex - it's just somewhat cumbersome. –  mson Aug 13 '09 at 18:52

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.

share|improve this answer
    
I was going to suggest exactly this. Good answer. –  phuzion Aug 13 '09 at 20:21

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.

share|improve this answer
    
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

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

share|improve this answer

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.

share|improve this answer
    
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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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