Your response will be most appreciated.
It's fine to run IIS on a BDC. Be aware that NT4 domain controllers have a different security context from member systems because the domain user database is the same as their local user database. So, instead of refering to "Administrators", you should refer to "Domain Admins". This will only be a complication if you're migrating a site from a member server to a domain controller -- if you're building a new site, or if the site is entirely anonymous, you won't run into any problems.
Editor's Note: SearchWin2000 member Larry Detar wrote to us regarding this Ask the Expert response. He asked:
"What about the security issues associated with having IIS on a domain controller?"
We sent the question along to Tony and he responded:
I didn't address security risk in my initial answer, but it's certainly worthwhile to discuss it. Many people would insist that IIS never be installed on a domain controller because of security risks. This concern is understandable, because IIS has had many well-publicized vulnerabilities and exploits. Also, IIS tends to be exposed to the public Internet more often than other services, so it may become a target for worms, viruses, malicious attackers.
If an IIS system had domain controller services running on it and they were compromised, a malicious attacker would have easier access to the domain user list. They could launch a process to run a brute-force attack against the domain user list to find other users names and passwords, and use those to launch attacks against other systems.Now, to understand how domain controller services increase risk in the scenario, consider the same situation with an IIS server without domain controller services. In that scenario, the attacker could do a couple of things to gain access to other systems on the network: perform brute-force attacks over the network, or create a trojan horse to gain elevated priviliges when a Domain Administrators logs in locally to the system.
The vast majority of IIS attacks are initiated by worms and scripts. I'm not aware of any worms or scripts that attempt to exploit local domain controller services. It's certainly possible that something could exist, but I prefer to stay out of the theoretical realm when assessing security risk. In my assessment, the level of increased risk that an organization takes by installing domain controllers services on an IIS system isn't much greater than having the domain controller sitting next to the IIS server, yet on the same network.Of course, best practices are to create a DMZ, and have externally facing services completely detached from internal services such as domain controllers. The IIS server should not be a member of an internal domain, and should not allow logins from the internal domain. In fact, it should have no access to the internal network whatsoever. A firewall should sit in front of the IIS server and look inside HTTP packets for attack signatures. An intrusion detection system should monitor login attemps at both the system and network level, and alert administrators if a break-in is attempted or succeeds. In the real world, however, there are many organizations that don't have the resources to separate services or to build multiple layers of firewalls. It's their decision to assess the cost and the risk of different architectures.
Thanks for writing in to us, Larry! We always appreciate feedback from our members.
This was first published in October 2001