About time for a somewhat technical post:
In some Newsgroup we recently discussed if it’s considered Best-Practice to deploy a lot of single-domain forests as opposed to a single multi-domain forest. The major reason herefore was that in the early Windows 2000 days, somebody said that the domain is the security boundary. After they’ve figured out that you can elevate yourself as domain admins for a inner-forest trusted domain, they revised this statement and said that the only security boundary is the forest, not the domain.
Since this attack is not that likely, I prefer to state this differentelly:
- The forest is the security boundary against malicious attacks (the attack is being done on purpose)
- The domain is the security boundary against (domain) administrative mistakes
So for many things the domain might be enough of a security boundary. If you don’t trust admins of a different domain enough that you think they might perform an attack (= elevate their rights in an area where they don’t belong) on purpose, either fire them, fire them, don’t give them administrative rights, fire them or put them into a separate forest.
Ressource-Forests (yeah – back to the NT days) are sometimes a good idea too, especially if separate companies want to share ressources, however keep in mind that they are a bit harder to manage and it depends on the application how well it integrates. You are also better of to use some solution like the Microsoft Identity Integration Server (or the Identity Integration Feature Pack) which is now part of Identity Lifecycle Manager to synchronize accounts into the ressource forest, however make sure to protect them well enough and to trust the admins of the resource forest from all parties. MIIS/IIFP allows you to sync the passwords of the users in question (by using a password filter on all DCs to notify MIIS, who’s changing the passwords in the connected directories) to allow a better integration via single sign on / single credentials . Don’t forget to design processes for the changes in the ressource forest which are signed off by all participating companies.
OK – back to the subject – don’t take any recommendations to deploy many single-domain forests only or to put everything in the same forest – think about it if it’s really necessary and valuable to deploy multiple forests/domains. At one point there was a recommendation: If you are designing your active directory, and you think you need to add a different domain, rethink that decision. Not true in all scenarios, however think about your design.
One reason for multiple domains have been different password policies - and as I posted before this reason is vanishing in Windows Server 2008.
There are multiple opinions on this, so don’t hold back on feedback / your thoughts.
P.S.: I do respect statements like the one “to recommend multiple single-domain forests” – they are a bit extreme however deliver the message. For example a friend of mine was at one of the top security sessions at TechEd US (where they showed a real-world-unlikely attack), and afterwards in the bathroom he heard attendees who just phoned back their companies to instruct them patching their Servers. So even after the attack was not to likely to happen in a real company, it delivered the message to keep your systems secure.
 Single Sign-On: The user is logging in once to his workstation, and getting access to other ressources automatically without re-authenticating
Single Credentials: I made this up a couple years ago – I think more valuable in the beginning are single credentials (combinations of username/password). Users in enterprises are sick of multiple accounts, because they have to remember different usernames and/or passwords, which is leading to weak passwords. If you are able to synchronize the password for the user more easily than providing him with single sign-on this is still valualbe, since the users don’t have to remember multiple passwords. I wouldn’t mind entering the same password to access multiple applications, however I do mind remembering different credentials.