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 stand alone, 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.
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 outway 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 applicatoins would need to blend with the AD DNS (or BIND DNS that supports SRV records). If you have some type of solution like Altris 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.
Thank you very much for the comprehensive and informative answer. I personally like AD. AD expertise and budget are not a problem in the project I am working on.
The only problem is the myth going on between infrastructure security people I am working with and they firmly believe that public web servers must be stand alone. Perhaps,
it is an old school way of public web server security.
Could you refer me to any online article or best practice document that endorses the use of a dedicated AD server for application pool identity of public web servers? I personally
believe that AD is a better option.
"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. :) Hpoe this helps. Any questions,
contact me off list if there are other concerns. Steve AT iislogs.com
Here is a post I did on ActiveDir regarding w2k8 r2 firewall management and GPO's
I've done a lot with this and it really depends on the environment as others have mentioned. 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
On top of that you are setuping a new AD env which is not your current internal AD env, so this remove the risk of internal AD being expose to the DMZ.
I just wanted thank you for such informative answer and sharing your successful experiences. You are my MVP++ :)
When I post similar type of question to some other forums, all I get is “It Depends”. This is one of the few times I get the exact thing that I am looking for.
I suggest this becomes a blog article on your site, so IIS community can benefits from your experiences and expertise.
Even if your security department seems 'stubborn' to accepting using AD in such an enviroment after they have read the information presented here, you do not have to use clear text sensitive information in your web.config.
There are several ways to protect that information depending on the version of .NET you are using to develop your applications.
Do a quick search in your favourtie search engine about 'Encoding ASP NET Connection string' and you will find a lot of information and best practices on how to achieve that.
26 Posts
Security best practices and using AD for server and process identity in a public facing web appli...
Jun 01, 2011 11:56 AM|Allan49|LINK
Hi,
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 stand alone, 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.
Thank you,
5619 Posts
Re: Security best practices and using AD for server and process identity in a public facing web a...
Jun 01, 2011 07:36 PM|steve schofield|LINK
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 outway 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 applicatoins would need to blend with the AD DNS (or BIND DNS that supports SRV records). If you have some type of solution like Altris 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.
Steve Schofield
Windows Server MVP - IIS
http://iislogs.com/steveschofield
http://www.IISLogs.com
Log archival solution
Install, Configure, Forget
26 Posts
Re: Security best practices and using AD for server and process identity in a public facing web a...
Jun 01, 2011 10:25 PM|Allan49|LINK
Hi Steve,
Thank you very much for the comprehensive and informative answer. I personally like AD. AD expertise and budget are not a problem in the project I am working on.
The only problem is the myth going on between infrastructure security people I am working with and they firmly believe that public web servers must be stand alone. Perhaps, it is an old school way of public web server security.
Could you refer me to any online article or best practice document that endorses the use of a dedicated AD server for application pool identity of public web servers? I personally believe that AD is a better option.
Many thanks,
5619 Posts
Re: Security best practices and using AD for server and process identity in a public facing web a...
Jun 01, 2011 10:43 PM|steve schofield|LINK
Here is an article published by the AD team at MS
http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=c1d0fd00-bf31-4b20-95c6-279a4ce7c2b4
"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. :) Hpoe this helps. Any questions, contact me off list if there are other concerns. Steve AT iislogs.com
Steve Schofield
Windows Server MVP - IIS
http://iislogs.com/steveschofield
http://www.IISLogs.com
Log archival solution
Install, Configure, Forget
5619 Posts
Re: Security best practices and using AD for server and process identity in a public facing web a...
Jun 01, 2011 10:45 PM|steve schofield|LINK
Here is a post I did on ActiveDir regarding w2k8 r2 firewall management and GPO's
I've done a lot with this and it really depends on the environment as others have mentioned. 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
Steve Schofield
Windows Server MVP - IIS
http://iislogs.com/steveschofield
http://www.IISLogs.com
Log archival solution
Install, Configure, Forget
7019 Posts
MVP
Re: Security best practices and using AD for server and process identity in a public facing web a...
Jun 02, 2011 03:17 AM|qbernard|LINK
On top of that you are setuping a new AD env which is not your current internal AD env, so this remove the risk of internal AD being expose to the DMZ.
Bernard Cheah
26 Posts
Re: Security best practices and using AD for server and process identity in a public facing web a...
Jun 02, 2011 02:01 PM|Allan49|LINK
Steve,
I just wanted thank you for such informative answer and sharing your successful experiences. You are my MVP++ :)
When I post similar type of question to some other forums, all I get is “It Depends”. This is one of the few times I get the exact thing that I am looking for.
I suggest this becomes a blog article on your site, so IIS community can benefits from your experiences and expertise.
5619 Posts
Re: Security best practices and using AD for server and process identity in a public facing web a...
Jun 04, 2011 02:18 PM|steve schofield|LINK
Here is a blog post. Thanks for the idea, I've never been called an MVP++, I kind of like it :))
http://www.iislogs.com/steveschofield/security-best-practices-using-ad-for-server-process-identity-in-a-public-facing-web-application-post.aspx
Steve Schofield
Windows Server MVP - IIS
http://iislogs.com/steveschofield
http://www.IISLogs.com
Log archival solution
Install, Configure, Forget
70 Posts
Re: Security best practices and using AD for server and process identity in a public facing web a...
Jun 05, 2011 12:18 PM|ArieH|LINK
Even if your security department seems 'stubborn' to accepting using AD in such an enviroment after they have read the information presented here, you do not have to use clear text sensitive information in your web.config.
There are several ways to protect that information depending on the version of .NET you are using to develop your applications.
Do a quick search in your favourtie search engine about 'Encoding ASP NET Connection string' and you will find a lot of information and best practices on how to achieve that.
Two quick examples would be:
http://www.4guysfromrolla.com/articles/021506-1.aspx
http://msdn.microsoft.com/en-us/library/dx0f3cf2.aspx
Best Regards,
Arie H.
26 Posts
Re: Security best practices and using AD for server and process identity in a public facing web a...
Jun 05, 2011 06:47 PM|Allan49|LINK
Hi Arie,
I personally like the use of application pool identities, especially when AD maintains identities and policies.
The encrypted connection strings become the second choice as it makes the deployment a bit more complicated.
Thanks,
5619 Posts
Re: Security best practices and using AD for server and process identity in a public facing web a...
Jun 05, 2011 07:44 PM|steve schofield|LINK
+1 I like integrated mode authentication too.
Steve Schofield
Windows Server MVP - IIS
http://iislogs.com/steveschofield
http://www.IISLogs.com
Log archival solution
Install, Configure, Forget