Biting the Bullet
When the merged Enterprise Networking Services (ENS) team's integration discussions turned to domain structures, we unanimously agreed to replace the existing CHQ_COD_PROD domain with a new master domain named SFM that would support all the merged companies' users and resource domains. We all assumed that SFM would be a new domain because we knew that altering an existing domain's name was impossible.
After we decided to create a new SFM domain, we looked for ways to automate the process of migrating the existing master domain's user accounts and those accounts' permissions to access resources in the 21 resource domains. Microsoft tools offered little help. Microsoft Windows NT Server 4.0 Resource Kit's ADDUSERS utility transfers user accounts between domains, but it re-creates only the accounts' basic attributes—username, full name, description, and group memberships. (For information about the utility, see Mark Minasi, "AddUsers," May 1998.) These attributes only scratched the surface of CHQ_COD_PROD users' permissions, and our Help desk staff shuddered at the thought of helping so many users set new passwords.
None of the third-party tools we examined offered much help, either. We didn't find a tool that let us analyze the permissions that administrators can grant to users and groups in trusting domains, and no utilities consistently retained account passwords.
After our initial research, the ENS team agreed that SFM and CHQ_COD_PROD would have to operate in parallel for a time, during which we would migrate users in small groups. This procedure would not be attractive. Network administrators would have to gather data from servers in the resource domains to discover which permissions each CHQ_COD_PROD user account had, re-create the account in SFM, and grant the same permissions to the new account. The move would inconvenience users because administrators would need to switch users' workstations' logon domains, and the users' SFM accounts would initially have blank passwords. We estimated that switching all the accounts would take 4000 person hours and that we couldn't complete the process in less than 10 weeks.
Around the time that we came to this conclusion, I was using Microsoft's TechNet to research a different problem, and a provocative document title caught my eye: "Unable to Change Domain Name of Windows NT BDC." (The document is available at http://support.microsoft.com/support/kb/articles/q139/4/71.asp?FR=0.) When I examined the article, I was surprised to find that it suggested that you could change a domain's name. I read additional material within TechNet and began to realize that I had been foolish not to consider changing CHQ_COD_PROD's name. The fact that I wasn't alone was little consolation.
Microsoft Support Engineer Eric Fitzgerald, who assisted us in our domain renaming project, told me that Microsoft hadn't formally supported the procedure of renaming domains until 1997, but that changing domain names had always been possible. Fitzgerald, who wrote the Microsoft article "Renaming a Domain: Process and Side Effects" (http://support.microsoft.com/support/kb/articles/q178/0/09.asp?FR=0), cited corporate mergers and X.400 compatibility as reasons for Microsoft's support for renaming domains.
How It Works
As everyone who has taken a few NT classes or worked with NT knows, the security ID (SID) number is the cornerstone of NT security. NT assigns SIDs to users, groups, shares, servers, and domains. Internally, NT uses SIDs almost exclusively, although users and administrators generally identify system resources through the resources' convenient (to humans) alphanumeric symbol—their name. When resources' names change, their SIDs remain constant. You can change a domain's name because NT maintains domains' security relationships through SIDs, not alphanumeric names. For example, when you add a user account that resides in a master domain to a local group on a server in a domain that trusts the master domain, NT adds only the user account's SID to the server's SAM database. When you use User Manager to examine a list of user accounts in the server's local group, User Manager looks up the account's alphanumeric name for your sake, but NT doesn't care what that name is.
If you want to test NT's reliance on SIDs without renaming a domain, experiment with a trust relationship. On a server in a resource domain, grant permissions or group membership to a user account in the master domain. Then, break the two domains' trust relationship, and examine the properties of the object you changed the user's permissions on or the group you added the user to. The server will remember the account's permissions, but until you reestablish the trust relationship, utilities will list the account's name as Account Unknown. The resource domain's server can't look up the account's name, but the account's SID remains on the server. When you reestablish the domains' trust, NT will restore all account names on the server.
You create essentially the same situation when you rename a master domain because you break trust relationships during the renaming process. Renaming a domain that contains crucial servers and maintains vital trust relationships isn't simple, but you can accomplish the goal with careful planning.
Register
