Welcome Guest!
Create Account | Login
Locator+ Code:

Search:
FTPOnline Channels Conferences Resources Hot Topics Partner Sites Magazines About FTP RSS 2.0 Feed

Home : Columns : XXX
email article
printer friendly
more resources

Make Smart Migration Choices
Take advantage of the Active Directory Migration Tool to consolidate domains and migrate from Windows NT to Windows Server 2003.
by Danielle Ruest and Nelson Ruest

September 2003 Issue

For This Solution: Windows Server 2003, Active Directory Migration Tool, Account Lockout and Management Tools

Q
We're planning our migration from Windows NT to Windows Server 2003, and we've had many discussions about how to migrate user accounts. We're not allowed to change user passwords, and our new VP of finance is concerned about security. He doesn't want us to generate new user passwords and send them out to our 2,000 users. What do you suggest?

—Louise, Philadelphia, Pa.

ADVERTISEMENT

A
Danielle: Security is today's hot topic. We've worked with organizations that have migrated to Windows 2000 and modified everyone's password during the migration. The problem with this approach is that you have to find a secure method for sending out everyone's new password. As you know, many users have bad password-protection habits: They write them down, leave them under keyboards or in desk drawers, and so on. It's hard to make sure a new password is secure. You also have to decide how you'll generate the new password. Some of our clients change all new passwords to the day of the week, but that's not particularly secure, because anyone can guess the password and appropriate someone else's account. This can be a serious problem, especially if a user is out of the office or on vacation without your knowledge. A malicious user can do a great deal of damage in that time. Other organizations use password generators to create passwords that are difficult to remember, but this isn't a good idea either, because the first thing users do is change their passwords to something simpler.

You also need to consider the delivery method. You can send the new passwords through e-mail, but you need to do it through the old system, which will probably lead users to print them out or write them down. You could also send them in sealed envelopes, but once again you must make sure everyone protects them properly. Educating users on the importance of a properly protected password isn't easy.

The best approach is to use a migration method that retains everyone's existing password. Then, implement an account policy in Windows Server 2003 that forces password complexity (Computer Configuration | Windows Settings | Security Settings | Password Policy | Password must meet complexity requirements), and set every migrated account to change the password at next logon. This way, users must change their passwords when they perform their first logon into the new network, and they have to use a new password that supports complexity rules, such as upper- and lowercase letters, numbers, and special characters. One more thing: Don't forget to communicate this strategy to users; otherwise, your migration help desk will get a lot of calls.

Nelson: There are a number of ways to migrate account databases and maintain the user password, but the two we've seen most commonly are the in-place upgrade and the account transfer. The in-place upgrade is often the easiest. You upgrade a Windows NT network's Primary Domain Controller (PDC) to Windows Server 2003 and Active Directory (AD). Before you do so, take one of your Backup Domain Controllers offline so you can roll back your network if something goes wrong. You transfer your Security Accounts Manager (SAM) database as is—including user passwords—by upgrading your PDC to AD.

However, this approach has a couple of issues. First, you don't have the opportunity to perform a SAM cleanup. The database is transferred as is, so it carries over all the unused and disabled accounts in the SAM. Some organizations like this method because they treat the SAM as an archive database, tombstoning all their unused accounts within this database. However, we don't recommend this method. If you want to keep track of all the security identifiers (SIDs) you've used, you should make a small database on the side, not leave them in the SAM or AD. However, you'll get a report on the SAM's status during the upgrade.

Back to top

Printer-Friendly Version











Java Pro | Visual Studio Magazine | Windows Server System Magazine
.NET Magazine | Enterprise Architect | XML & Web Services Magazine
VSLive! | Thunder Lizard Events | Discussions | Newsletters | FTP Home