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

In terms of security and manageability - What is best practice?

Should web servers

  • Be added to and managed from an Active Directory domain

or

  • Be part of a 'web server' workgroup that is separate from the 'resource server' active directory?

There is no a requirement for there to be user accounts on the web servers, only management accounts (server management, system reporting, content deployment etc.)

share|improve this question
    
Are these webservers in a Colo or in a DMZ at your office? –  Rob Bergin Jun 1 '09 at 20:10
    
Good point to raise. Servers are within our own control in our own server room. –  David Christiansen Jun 2 '09 at 8:33
add comment

5 Answers

up vote 6 down vote accepted

If you want to use Kerberos delegation to build a secure infrastructure (and YOU DO) you will need to join those Web servers to the domain. The web server (or service account) will need the ability to delegate assigned to it in order to allow user impersonation against your SQL server.

You proably want to stay away from using SQL-based authentication on the SQL server if you have any auditing or statutory requirements for tracking data access (HIPAA, SOX, etc.) You should be tracking access through your provisioning process (i.e. who is in what groups, how that was approved, and by whom) and all access to data should be through a user's assigned account.

For DMZ issues related to accessing the AD, you can resolve some of that with Server 2008 using a Read-Only DC (RODC) but there is still risk with deploying into the DMZ. There are also some ways to force a DC to use specific ports to punch through a firewall, but this type of cutomization can make it difficult to troublehsoot authentication problems.

If you have specific needs to allow both Internet and Intranet users access to the same application you might need to look into using one of the Federeated Services products, either the Microsoft offering or something like Ping Federated.

share|improve this answer
add comment

Internal use, absolutely. That way they get managed by GPO, patching isn't as difficult, and monitoring can be accomplished without a bunch of workarounds.

In the DMZ, generally I'd advise no, they should not be on the DMZ. If they are on the domain and in the DMZ, the issue that you run into is that the web server must have certain connectivity back to at least one DC. Therefore, if an external attacker compromises the web server, he or she can now directly launch attacks against one of the DCs. Own the DC, own the domain. Own the domain, own the forest.

share|improve this answer
    
Thanks KB and Rob. Creation of another AD in the perimeter network is one answer but I can't justify me having to buy another server just to be the host of a AD for web servers. Urg. Another complication is that the webservers must have SOME traffic allowed into the internal 'trusted' network (for example SQL) and that SQL traffic is secured using a trusted network connection. I guess we have to be talking about two ADs and a trust between the two? –  David Christiansen Jun 1 '09 at 13:37
    
That's the safest route, yes. You have a forest for the DMZ based servers and it has a one way trust back to the internal forest. However, I would look at allowing SQL Server based authentication first. –  K. Brian Kelley Jun 1 '09 at 14:04
    
I agree, this is the way to go. –  squillman Jun 1 '09 at 14:37
add comment

Why not have a Webserver's Domain in the DMZ?

It could be a separate forest with a one way trust relationship to administer the domain from your main domain without giving any permission to the WS's domain for your main domain.

All the joys of AD/WSUS/GPO - especially useful if you have a whole farm of them - and if it's compromised it's not your main network.

share|improve this answer
1  
That's the safest route to go if you have to use a domain. However, you're still talking about getting a direct attack on a DC. And in the scenario you give, if I get that DC, unless you've taken out cached credentials, I can still pull those and have credentials to use against the primary domain/forest. –  K. Brian Kelley Jun 1 '09 at 14:23
    
KB, Out of interest, can you describe 'cached credentials' –  David Christiansen Jun 1 '09 at 16:02
    
Unless you turn it off, a Windows system will cache the password credentials (actually a hash of a hash) when you log on. This is what permits you to have a laptop and log on with your domain logon when away from the corporate network. Extract that, use rainbow tables, you get the idea. –  K. Brian Kelley Jun 1 '09 at 16:22
1  
If the trust is only one, way cached credentials are irrelevant as the DMZ server will never authenticate against the primary domain. –  Jon Rhoades Jun 1 '09 at 22:30
add comment

If the webserver is on the same network as the Domain Controller(s), then I would definitely add it to the domain - as this obviously adds a great deal of manageability. However, I would usually strive to put webservers in a DMZ to increase security - which makes access to the domain impossible without pinholes (and that's a very bad idea!)

share|improve this answer
add comment

As others have mentioned, if these are public facing and do not require authenticating users against the directory, then do not put them in the domain.

However, should you require some sort of authentication or lookup of information from AD, possibly look into running Active Directory Application Mode (ADAM) in the DMZ. You may need to replicate the relavent information from AD into the Applicaton Partition as ADAM does not synchronize the standard AD partitions.

If you are just looking for management features though, ADAM does not apply.

share|improve this answer
add comment

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.