Security best practices using Active Directory for server, process identity in a public facing web application
I received a post on the forums that I was suggested to make a blog post. Here is the original post : http://forums.iis.net/t/1178739.aspx
Question:
We have an asp.net public facing web solution. The solution users SqlMembershipProvider to authenticate users and includes the following servers:
· Two Load balanced web servers in the DMZ
· Sql Server Database Server with many SSIS packages transfer files between the web server and database server
Traditionally, the web servers stay standalone servers and not part of any domain. We are thinking to use active directory.
We are thinking to have an AD server dedicated to this solution only (it is different than the company’s operational AD). The AD server in the server environment helps us to have webserver’s application pool be authenticated against the SQL server to prevent the requirement of having SQL server UID/PWD in the web.config files.
From the security bets practices approach, which one of the following options is recommended?
· Option 1) Public facing web servers stay standalone, SQL server authentication is used
· Option 2) Public facing web servers are part of an AD domain (different than company operational domain) and database server authenticates the web servers against their application pool identity.
The AD server won't be used to authenticate web application users.
Response:
I can make an argument for both solutions.
1) For stand-alone boxes, you could encrypt the connections strings to protect creds. Having AD introduces more expertise and administration. If you AD locally and some expertise, then it's not too bad. Having DC's costs more, administration more, more hardware to support. More licensing. The downside of stand-alone you have to manage each box as a stand-alone entity, depending on how many boxes, this is a BIG drawback. Yes, you can have the same user id and password if you have scripting.
2) For an AD environment, you get group policy, centralized administration, both are HUGE wins IMO. With group policy you can manage all kinds of settings including folder, registry security, auditing, distribute certificates along with 100's of other settings. Preferences is my favorite. Most of the negative for #2 is mentioned in #1. AD helps with administration / management however has overhead. I like using windows accounts vs. sql because of the integrated security, no passwords stored and needed to be managed in config files.
Over my years of experience, I tend to have a blend of security with administration. I've implemented AD in my environment and haven't looked back. The benefits out way the risks and additional administration. Once AD is setup, it kind of runs itself if not tinkered with. You need a very stable DNS infrastructure to support AD. Your applications would need to blend with the AD DNS (or BIND DNS that supports SRV records). If you have some type of solution like Altiris that is agent based and can go across forest (last I knew), management of apps, packages might be easier. I hope there is some advice and things to think about. PS - AD is really a core technology a lot of other MS solutions integrate with, it's worth having IMO.
Here is an article published by the AD team at MS
"Old school" is right, I've been using AD since w2k in a public facing environment. AD is the foundation of which many things can help provide a consistent, secure and stable environment. I use group policy extensively to lockdown servers with windows firewall. The only real opening is a few management / utility servers that are trusted. You can honestly lockdown them down hard but you still have to manage, monitor and deploy code to them. I've managed stand-alone machines (not since w2k3 / w2k) so my perspective is a bit aged on that front, however AD provides more benefit than hassle I probably could write a really long article on the topic of how I used, why and such. This is one of those topics near to my heart. :)
Here is a post I did on ActiveDir regarding w2k8 r2 firewall management and GPO's that relates to this post.
I've used GPO's to manage windows firewall on w2k8 and above. I hear Forefront enhancements management and functionality. This requires SCCM.
Here is how a description of what I've found effective.
1) Have a base settings policy, this applies at a higher and applies to ALL servers (No firewall polices, things like dns suffix search order, auditing, other base settings that apply to ALL boxes)
2) Have a base firewall policy storing all firewall polices that apply to all servers. Exceptions like backup servers, monitoring servers,AV etc..
3) Lastly, have your servers in different OU's based on Server Roles, each server role has their own GPO and rules. If you have rules specific to these servers, open the rules at this GPO level.
4) What I have found is to have a separate policy for WMI and File and Print sharing that are applied separately from the 'base' firewall policy mentioned in #2.
Base OU
ServersOU
AppRole1
AppRole2
AppRole3
Based on the example above, #1 and #2 would be linked at the ServersOU. The Base WMI and File and Print Sharing GPO's are linked at AppRole1, AppRole2, AppRole3. There would be a GPO for each AppRole1,AppRole2,AppRole3. If a particular role has unique File And Print Sharing or WMI, you create another GPO for File And Print Sharing for that role and link at the AppRole level. You remove the original File And Print Sharing GPO link. This is the architecture I've found the most manageable and running Windows Firewall. Personally, I like having the extra layer, it can depend on your environment.
This example would have the following polices
BaseSettingsPolicy
BaseFirewallPolicy (doesn't contain WMI or File and Print sharing rules) BaseFilePrintSharing BaseWMI
AppRole1
AppRole2
AppRole3
Enjoy,
Steve Schofield
Windows Server MVP - IIS
http://www.iislogs.com/steveschofield
http://www.IISLogs.com
Log archival solution
Install, Configure, Forget