Installing IIS on a domain controller.

2 Jul 2009 3:14 PM

Jonny Bergdahl

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

3 Jul 2009 2:43 AM

Ken Schaefer

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

Show quoteHide quote

"Jonny Bergdahl" <jonnybergdahl@newsgroup.nospam> wrote in message
news:efHAJfy#JHA.4168@TK2MSFTNGP05.phx.gbl...
> 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
>
>

3 Jul 2009 8:33 AM

Jonny Bergdahl

> 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

Not a problem when the "entire domain" is a single server, you still only
gets access to that machine.

> 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

Yes, the security is tightened on a DC, which I consider to be a good thing.

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

Yes, that is true.

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

This would require a totally separate server for the DC role, adding both
hardware and license costs without any real benefits.

Regards;
/jb

3 Jul 2009 9:00 AM

Grant Taylor

On 7/3/2009 3:33 AM, Jonny Bergdahl wrote:

> This would require a totally separate server for the DC role, adding
> both hardware and license costs without any real benefits.

I think the benefit starts to show its self when companies are large
enough to warrant three or more servers, if not more like five.
Unfortunately none of my customers qualify here.

Grant. . . .

4 Jul 2009 10:10 PM

Roberto Franceschetti

If you are going to be using that domain *exclusively* to host a single
server - your IIS server, then... sure! why not :-) Despite what others
say, this is not at all a bad idea to to the absence of the SAM (again
on condition the domain has only one member - IIS).

However this applies only if you have a single computer in the domain.
If you were to add the SQL server to the domain, then we're back to the
"do not recommend". Remember that once your IIS is compromised, it's
possible for the attacker to gain "SYSTEM" privileges on the DC. At that
point, it really doesn't matter how you secured the access between the
SQL Server and the DC running IIS. Once the malicious attacker has
SYSTEM rights, they can pretty much do anything to bypass your security
on the domain and gain easy access to your SQL Server. That SQL Server
should then still be installed on a separate domain (or standalone).

--
Roberto Franceschetti
LogSat Software
http://www.logsat.com

Jonny Bergdahl wrote:

Show quoteHide quote

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