Introduction
The pressure and work that goes along with moving from one network operating system to another network operating system can be intense. If you are contemplating moving from your Windows NT domain to a Windows Active Directory domain, your situation is not different.
You will be required to make many decisions during your journey. Some of these decisions include:
- Will you have Windows 2000 or Windows Server 2003 domain controllers?
- Will you run some of each type of domain controller?
- What client operating system will you run for the IT staff, executives, and other employees?
- How many Active Directory domains will you end up with?
- How many Active Directory forests will you end up with?
- How will you get from your Windows NT domains to Windows Active Directory domains?
- What tools will you use to get to your Windows Active Directory domains?
- Are there any security concerns that you need to consider during your move to Windows Active Directory?
It is this last question that we are going to focus on in this article. We will discuss the primary options for going from Windows NT domains to Windows Active Directory domains. We will then talk about each of the options, focusing on the different security considerations that you need to contemplate. When you are done reading this article, you should be able to pinpoint the key security considerations that you will face along your journey.
Your Options: Migration or Upgrade
You have two primary options for moving from Windows NT domains to Windows 2000 or Server 2003 Active Directory domains. The first is an upgrade. The second is to perform a migration.
A migration is more complex than an upgrade. With a migration, you will need to create your Active Directory domain(s) in conjunction with your Windows NT domain(s). This will require that you purchase additional hardware and server licenses. The overall concept of the migration is to gradually move objects (user, group, and computer accounts) from Windows NT to Windows Active Directory. This process duplicates these objects in the target Windows Active Directory domain(s).
An upgrade is much simpler in all aspects. With an upgrade you work with the existing Windows NT domain and domain controllers. You will take the Windows 2000 Server or Windows Server 2003 installation CD and place it in the Windows NT Primary Domain Controller. This will start the upgrade wizard. You follow the steps in the wizard and when the computer restarts, you have a Windows Active Directory domain. All of the objects that were once in the Windows NT domain have completely been retained and are immediately available in the Windows Active Directory domain.
Security Concerns for Migrations
If you choose to perform a migration, you most likely are consolidating multiple Windows NT domains into a few (hopefully one) Windows Active Directory domains. It is the method that is available for moving accounts from multiple domains into just a few domains. However, as you perform your migration, you will have unique security concerns that you need to consider during the process. Here are some of the most prominent security concerns that you will run into.
Dual user accounts
As you migrate user accounts from NT to Active Directory, you will end up with duplicate user accounts, with one in each domain. Most tools will allow you to control the state of both of the accounts after the migration. There might be times when you want the source user account to be active, and other times when the target user account should be active. Regardless of your decision, you need to be aware that there are two user accounts in two domains. You will need to keep track of these and ensure that users are using the correct one and that both are properly secured.
SIDHistory
When you migrate a user account from NT to Active Directory, you need to consider how the new user account will continue to access resources that exist in the Windows NT domain. This is a concern since the resources and resource servers in the NT domain reference the user and group accounts from the NT domain, not the Active Directory domain.
To take this one step further, when a user account is migrated, not only is the account copied (not moved), but the new account is given a new Security ID (SID). This new SID is not known in the old NT domain, so when a user logs on to the new Active Directory domain with the same username and password as before, they will be denied access to all of their familiar NT resources.
To combat this, the migration can include the old NT user account SID as a property of the new Active Directory user account. This new property is referred to as SIDHistory. A single user account might have numerous SIDHistory entries, depending on how many NT domains contained the username before the migration and consolidation.
This SIDHistory property needs to be protected during the migration and then cleaned up after the migration, to restrict inappropriate entries being placed in the SIDHistory property, allowing privileged access to resources.
Authenticating domain for users
After the user accounts are migrated from NT to Active Directory, there is a need for user education. This education requires that all users be briefed and trained on how to logon to the new Active Directory domain. Most users are stuck in a mode of just entering their username and password for their logon, that they don’t pay attention to the domain name.
Since a migration requires two domains (NT and Active Directory), these domains can’t have the same name. Therefore, users will need to authenticate to a new domain at logon. They will need to select this domain to ensure they are authenticated. If you left the old NT user account active, the user would be able to authenticate to either domain, causing potential security or access problems.
Re-acl
We have already discussed the concern of user accounts being able to access resources that reside in the NT domain. After all user, group, and computer accounts are migrated to the Active Directory domain, you will then need to consider the Access Control Lists (ACLs) on the servers that came from the NT domain.
As these computers were moved from the old NT domain to the new Active Directory domain, the ACLs did not change reference back to the NT user and group accounts. This requires that the old NT domain be running until these ACLs point to the new user and group accounts that exist in the Active Directory domain. This process is called re-acling. It requires that every entry on every file, folder, registry key, and printer be fixed. There are tools to complete this task, but it is certainly something that you need to consider well before it is time to decommission the NT domain.
Account policy needs to be configured
During a migration, the primary objects that you will migrate include user, group, and computer accounts, as well as trusts. However, the other configurations that you once had in Windows NT are not transposed to the Active Directory domain. This means that you will need to configure these settings in the Active Directory domain. This includes the account policy settings, which include the password min age, max age, min length, and password complexity.
Security Concerns of Upgrades
If you choose to perform an upgrade, you most likely only have a few Windows NT domains, or you are just trying to get the master domains moved to Active Directory domains. Upgrades are easy and nearly painless, but there are some security concerns that you need to consider. Here are some of the most prominent security concerns that you will run into.
Upgraded Domain Controllers are not properly secured
When a Windows NT domain controller is upgraded to become a Windows 2000 or Server 2003 domain controller, the security on the resulting domain controller is weaker than if the Windows 2000 or Server 2003 domain controller were installed afresh. This is done to ensure that the applications and services that are running on the Windows NT domain controller still function after the upgrade.
During the upgrade of the Windows NT PDC, a file named DCUP.INF is applied to the domain controller, instead of the DCFIRST.INF file. It is this file that keeps the security lower than if the computer were installed fresh.
The solution to this is to immediately install a fresh Active Directory domain controller (2000 or 2003) and configure it to be a replica domain controller. After the Active Directory database and other essential Active Directory services are moved to the new domain controller, the initial domain controller should be taken offline and reinstalled afresh as a replica domain controller. This will synch this domain controller with the other one, making sure you have the first two domain controllers freshly installed within your new Active Directory domain.
Delegation and GPOs
An upgrade is an easy way to keep all user, group, and computer accounts, but you need to move these accounts to the proper OUs after the upgrade is completed. This will require that you create the OU structure, move the accounts to the proper OUs, and then configure security on the OUs. The security that you need to configure at the OU level includes delegation of administration and GPO deployment.
Password Complexity might be missing
Even though a Windows Server 2003 Active Directory domain has password complexity configured by default, does not mean that the same Active Directory version will have the password complexity configured after an upgrade. You need to ensure that all Account Policy settings are configured immediately after you upgrade the first domain controller. This will include all password policies and account lockout policies.
Summary
There are numerous security considerations that you need to keep in mind, whether you are performing a migration or upgrade. When it comes to security, both options have their limitations and concerns. As long as you are fully aware of the concerns, you can take every precaution to ensure that all security issues are covered.
