Re: Installing IIS on a domain controller.




Running IIS (or SQL Server) on a DC is not recommended.

There are a number of reasons for this:
a) every account used now has privileges in the entire domain
b) DCs hold the "keys to the kingdom" - compromising a DC effectively compromises your entire domain, and from that potentially your entire Forest
c) making a member server a DC results in a different security template being applied. This changes file/registry permissions in a way that may break your IIS or SQL Server application if you then try to lock those applications down
d) restoring a domain controller + application from backup is more complex than simply restoring a server that has a single role or just runs Active Directory.

Whilst there are tools that can "edit" the local SAM, most accounts used by IIS are now in-built principals (e.g. Network Service). These do not exist in the local SAM.

The recommended strategy would be to have a new domain in your DMZ. Your IIS and SQL Servers would be member servers joined to that domain.

There is plenty of guidance on this in the Windows System Reference Architecture (etc) on the Microsoft website.

Cheers
Ken

--
http://adopenstatic.com/blog

"Jonny Bergdahl" <jonnybergdahl@xxxxxxxxxxxxxxxx> wrote in message news:efHAJfy#JHA.4168@xxxxxxxxxxxxxxxxxxxxxxx
I have seen numerous recommendations that says that it is a no-no to run IIS on a domain controller. What I haven't seen is any solid/sound reasons for that?

On non-domain controller server, the passwords are stored in the local SAM file, a file numerous different hacking tools knows how to decode and edit. On domain controllers on the other hand, the passwords are stored in the AD, and I am not aware of a single tool for decode or edit of the AD file.

This leads me to the simple conclusion that it is indeed a good idea to promote the web server to a domain controller just for the added password protection. As a clarification, I don't suggest adding the web server to an existing domain (or worse, the internal), but instead create a new domain just for the web server.

Also, say you have a web application consisting of two separate servers, one running IIS and the other SQL Server. Both machines is set up as domain controllers for the reason given above. In this case it is possible to only give SQL logon to the IIS server COMPUTER ACCOUNT, an account with a password that is managed by the domain controller, which also changes the password on a regular basis. In my view this is a very much more secure environment than running the same system without domain accounts.

Does anybody has any objections or opinions on this?

Regards;
/jb


.



Relevant Pages

  • RE: SOME Users cannot access OWA others do, error HTTP 500
    ... I understand that some account access OWA ... IIS 6.0 compression corruption causes access violations ... compressed copy of the affected files on the SBS server: ...
    (microsoft.public.windows.server.sbs)
  • Re: Virtual Directory - Permission Denied with fso CopyFile
    ... TestUser (normal user account with same credentials on all machines). ... I logged into the IIS server as vdirUser and simply typed ... open and I had read and write permissions to the share. ... I logged off and back into the IIS server as the administrator and deleted ...
    (microsoft.public.inetserver.iis)
  • Re: Compromise?
    ... Yes, if you don't provide a password on your SA account, anybody able to run ... and connect now has complete control over your SQL Server. ... Server has. ...
    (microsoft.public.sqlserver.security)
  • Re: Windows Auth to SQL Server from ATL Web Service not working...
    ... account I'm logged on as. ... SQL on a different box from my web service in an Atl Server web ... impersonation token is not passed on to the SQL Server. ... Event Category: Account Logon ...
    (microsoft.public.vc.atl)
  • Re: Discussing 3 different strategies for deleting from multiple tables
    ... I will be using SQL Server but I am riding on top of a third party ... FYI, Account contains around 20K ... >>> This results in one parameterized query followed by two more trips to ...
    (microsoft.public.data.ado)