The Zen of Hosting: Part 4 - HMC and AD
In part 2, I started to write about Active Directory and how to get a single domain to work with multiple organizations, so let’s get back to AD and look at how HMC helps with it. Well, what HMC does to AD is that it gives you a way to set up the OU structure and sets up a number of properties on the AD object.
One of the great things about the OU structure is that it allows you to have a top-level organization (which is called the hosting company), second-level organizations (the resellers), and third-level organizations (the customers). The second level is very exciting, as this is actually the level at which sales are done. Due to the structure, multiple resellers can exist and work with their customer bases while being secured from other customers and resellers. If you’re thinking of white-boxing a hosting solution, this is how it’s done.
Security is obviously taken into account by the HMC engine, which lets an administrator on a hosting company level manage anyone within the system. On the reseller level, you can add accounts to your own account and those of your customers via the web interface. But does this mean you’ll spend your admin days in the web interface? Definitely not! Your AD skills still apply, and you can still manage users, computers, set group policies, and reset passwords, etc. But you should be doing provisioning (creation of items) through the web interface or the engine, as it will save you from having to edit AD properties manually later—for instance.
If you aren’t looking at white-boxing, then you would just have your hosting company and one reseller, followed by various organizations as customers.
You may have picked up that I said you can use the engine to provision, and you may have thought that meant you needed to use the SDK and write code. Well, you don’t have to! Microsoft has actually included a tool called Provtest, a command-line tool on your HMC server. You pass it an XML file, and it parses the file, pushes it to the engine, and displays the result. This is actually the same way the SDK works—in that you pass XML to the web services or COM+ object to perform tasks. Microsoft also includes many samples with HMC, and even more in the SDK. So what you may find yourself doing a lot of is, especially when you get to Exchange management.
One of the ways HMC also modifies AD object properties is by setting the login name in such a way that it allows each customer to have their own domain name (sort of). However, it’s just on the AD account name. This isn’t an easy concept to grasp without an example, so let’s say the hosting company domain is Contoso.local, and let’s say a customer named Northwind signs up with one of their resellers (who the reseller is doesn’t matter). The Northwind team decides they want their domain to be Northwind.com, so via the web interface, they add Fred and set his login to be fred@northwind.com.
What HMC does is set the AD account name to fred@northwind.com, but in the background, it sets the SAM account name (or the pre-Windows 2000 name) to contoso.local\fred_northwind. Yes, it should be fred..northwind—the first dot for the SAM account and the second for grammar. So all customers are on the same domain at the core, but the account name is what they would use to log in to OWA, their machine, or an application like MSCRM.
The SAM account name is still vitally important, as most applications don’t like using account names internally. For example, MSCRM allows you to log in with the account name, but when adding users individually, you cannot use the account name—you must use the SAM account name. Oddly, though, the multiple-user add option does work with the account name. This is an annoying problem, as it means you need to expose the (ugly) SAM name to your customers. If you’ve named your hosting level with something distinctive, it could limit your white-boxing ability!
This disconnect between account name and SAM account is a massive pain for service accounts too, as I lost way too much time during deployment on many services just retyping passwords and resetting them—only to realize that the application didn’t like something in the username and wanted the SAM account name. The worst experience I had with passwords during all of this was with Forefront, where it not only didn’t like the account name but also didn’t like the fact that the domain name (on the hosting company level) had a dot in it.
The security isn’t perfect, though, as there are times when you can see all users in the system. In an earlier version of HMC, there was a problem with the address books where everyone could see everyone, but that has been corrected. For MSCRM, though, the add-multiple-user interface shows all users when you hit the lookup if you haven’t configured MSCRM correctly. I’ll come back to this point later in the series when I talk about MOSS.