Re: Installing IIS on a domain controller.

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.

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.

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)