Why does the 2003 ADC randomize the logon name?

[The_Exchange_Team]

I’m often asked the question: Why does the Exchange 2003 ADC create accounts with a bizarre logon field? (For Example, ADC_BDZQOKNUIZDWPPHG )

It’s usually hard to answer this question if the person asking it doesn’t have a certain level of ADC knowledge. So let’s discuss a couple of common pitfalls that can go wrong during the Exchange 2000 migration scenario, beginning with how the ADC is running through its very first replication cycle for an object. In the situation where an Exchange 5.5 mailbox is configured with a Primary Windows NT account (assoc-NT-account) residing in an NT4 domain, a properly-configured connection agreement directs the ADC service to perform object-creation. (By contrast, if the mailbox’s “Primary Windows NT Account” was configured with an AD account in the same forest as the ADC, it simply copies 5.5 mailbox information to the pre-existing AD object.) In the former case (object-creation), Exchange 2000’s ADC will create a disabled accounts (called placeholders) in Active Directory, each having the Exchange 5.5 object’s attributes as well as a samaccountname (also known as “Pre-Windows 2000 logon name”) based the Exchange 5.5 object’s alias name. This naming caused problems for a couple of reasons:

          1. People often had the misunderstanding that ADC object-creation was an easy way to migrate Windows NT 4 accounts to Active Directory. With that misunderstanding, they would improperly enable these “placeholder” accounts that were generated by the ADC, not knowing that this will cause delegation problems, Public Folder permission problems, and other permissions problems that may prevent logons, mailbox moves, and OWA access in some scenarios. (For information regarding problems caused by enabling the placeholder accounts, see http://support.microsoft.com/?id=316047.) To illustrate this first problem, here is a state diagram beginning with pre-ADC replication:

5.5 Mailbox	ADC-generated account
Primary Windows NT Account = NT4domain\UserA	Nonexistent

When the 2000 ADC examines the above state, it uses matching rules to see if the numerical value of the NT4 domain account matches any objectSID or SIDHistory attribute in Active Directory. In this case, none is found in Active Directory, so the 2000 ADC will create a placeholder AD account with Exchange attributes. The new account will also be given a pre-Windows 2000 logon name matching the value of the 5.5 mailbox alias:

5.5 Mailbox	ADC-generated account
Primary Windows NT Account = NT4domain\UserA Mailbox Alias = UserA	·       Disabled ·       Samaccountname= ADdomain\UserA

At this point in time, the admins are often tempted to enable the placeholder account since it “appears” that the ADC has performed some sort of account-migration functionality.

5.5 Mailbox	ADC-generated account
Primary Windows NT Account = NT4domain\UserA Mailbox Alias = UserA	·       Enabled (wrong) ·       Samaccountname= ADdomain\UserA

Of course, this is the absolute wrong thing to do, as there will be repercussions as explained above.

          2. Another migration problem is that ADC-generated objects conflict with the ability of Active Directory Migration Tool (ADMT) to migrate user logon names from their source domains. (This situation only applies if ADMT is used after initial ADC replication, and if the administrators used the default naming convention where all users’ aliases were the same as their NT logon account names.). So when ADMT attempts to create user objects in the target domain, it encounters conflicts with the ADC-generated accounts. ADMTv1 will, by default, resolve these conflicts by appending a number (usually  “-1”) to each samaccountname it generates – in order to satisfy the uniqueness logon name within a domain. Although ADMT is a proper and supported migration method for user accounts, the “-1” object causes an issue for end users who are now required to append “-1” to their logon process. One may believe that ADClean may be used to merge the two objects into a single account, thereby resolving this issue. However, ADClean ignores samaccountname when it merges the disabled objects’ attributes to the ADMT-generated account. In the end, users are still stuck with different user logon names (i.e. user was accustomed to logging onto source NT4 domain as “johnsmith,” but must now log onto AD as “johnsmith-1”). To illustrate this second problem with the 2000 ADC, here is a state diagram, continuing with post-replication state:

5.5 Mailbox	ADC-generated account
Primary Windows NT Account = NT4domain\UserA (0105…4000) Mailbox Alias = UserA	·       Samaccountname= ADdomain\UserA ·       Disabled

When it comes time for the domain admins to perform an account migration from the NT4 domain, ADMT (or similar 3^rd party tool) is used to clone the NT4 account SID to a new Active Directory account’s SIDHistory. The user-account migration process will result in 2 security principals corresponding with the same user. The -1 suffix would be appended since there cannot be 2 accounts in a domain having the same pre-windows 2000 logon name:

5.5 Mailbox	ADC-generated account	ADMT-generated account
Primary Windows NT Account = NT4domain\UserA (0105…4000) Mailbox Alias = UserA	·       Samaccountname= ADdomain\UserA ·       Disabled	·       Samaccountname= ADdomain\UserA-1 ·       No Exchange attributes ·       SIDHistory=0105…4000

The Active Directory Cleanup wizard (ADClean) is used to consolidate/merge the ADC’d and ADMT’d accounts. It works by transferring all the Exchange attributes from the ADC-generated placeholder account to a target account, and then it deletes the placeholder account. Logically, ADClean is the next migration step. If it is run in against UserA and UserA-1, the following will be the result:

5.5 Mailbox	ADC-generated account	ADMT-generated account
Primary Windows NT Account = NT4domain\UserA (0105…4000) Mailbox Alias = UserA	·       Nonexistent (deleted)	·       Samaccountname= ADdomain\UserA-1 ·       SIDHistory=0105…4000 ·       Exchange attributes exist

The next time the ADC replicates changes to the 5.5 server, the 5.5 mailbox will have Primary Windows NT account = ADDomain\UserA-1.  Functionality-wise, there is not a problem. However, from a usability standpoint, we wouldn’t want to instruct all (possibly thousands) of the migrated users to add a “-1” to their logon process!

With the above lessons learned from Exchange 2000 migrations, you can deduce that randomizing samaccountnames resolve the 2 problem scenarios. So in Exchange 2003, the ADC behaves differently, as illustrated below:

5.5 Mailbox	ADC-generated account
Primary Windows NT Account = NT4domain\UserA	Nonexistent

The Exchange 2003 ADC replicates, and matching rules find no corresponding AD account, so ADC generates a placeholder account with a randomized logon name (for example “ADC_BDZQ OKNUIZDWPPHG”) where the characters following the underscore are always randomized. Since this random username is difficult to type when a user logs on, it detracts administrators from improperly enabling the placeholder accounts for user-logon purposes.

5.5 Mailbox	ADC-generated account
Primary Windows NT Account = NT4domain\UserA (0105…4000) Mailbox Alias = UserA	·       Samaccountname= ADdomain\ADC_ABCDEFGHIJKLMNOP ·       Disabled

ADMT is run. This time, ADMT doesn’t encounter conflicts in translating the 5.5 mailbox alias into a samaccountname for a new account:

 

5.5 Mailbox	ADC-generated account	ADMT-generated account
Primary Windows NT Account = NT4domain\UserA (0105…4000) Mailbox Alias = UserA	·       Samaccountname= ADdomain\ADC_ABCDEFGHIJKLMNOP ·       Disabled	·       Samaccountname= ADdomain\UserA ·       SIDHistory=0105…4000 ·       No Exchange attributes

ADClean is run, and the Exchange attributes are transferred to the ADMT-generated account. ADClean also deletes the placeholder account, so the final merged account doesn’t have a “-1” suffix.

5.5 Mailbox	ADC-generated account	ADMT-generated account
Primary Windows NT Account = NT4domain\UserA (0105…4000) Mailbox Alias = UserA	·       Nonexistent (deleted)	·   ;     Samaccountname= ADdomain\UserA ·       SIDHistory=0105…4000 ·       Exchange attributes exist

The last ADC replication cycle will update the 5.5 object’s assoc-NT account field using the AD account’s objectSID value, thereby fixing-up permissions in the 5.5 directory.

5.5 Mailbox	ADC-generated account	ADMT-generated account
Primary Windows NT Account = ADDomain\UserA Mailbox Alias = UserA	·       Nonexistent (deleted)	·       Samaccountname= ADdomain\UserA ·       SIDHistory=0105…4000 ·       Exchange attributes exist

With a much cleaner migration process (among many other things), you can see why our folks in the field are telling customers to skip the E2k migration, and instead migrate Exchange 5.5 directly to 2003!

There are still a couple intended instances where the Exchange 2003 ADC will not randomize th e Pre-Windows 2000 logon name:

• If the Exchange 5.5 mailbox has been designated as a resource mailbox (i.e. “NTDSNoMatch” value exists on custom attribute 10), samaccountname randomization will not occur.
• If the ADC matches the 5.5 mailbox with an existing Active Directory account, the pre-existing account will not have its logon name randomized.

In summary, here are the conditions where the 2003 ADC creates accounts with randomized samaccountname:

• The Exchange 5.5 mailbox’s Primary Windows NT Account is a local or global group.
• The Exchange 5.5 mailbox’s Primary Windows NT Account exists in an external NT4 domain.
• The Exchange 5.5 mailbox’s Primary Windows NT Account exists in a different forest from the ADC service.
• The Exchange 5.5 mailbox does not have NTDSNoMatch value, even though it is really a resource mailbox (i.e. its Primary Windows NT Account is already mail-enabled in Active Directory with some other legacyExchangeDN).

 - Vincent Yim

[#2]

With this in mind is the recomendation then to not use the ADC migration / cleanup tools included in NetIQ's DMA ?

[#3]

Awesome info. I'd seen this behavior, but wasn't able to get a support guy to re-create this behavior, as I didn't know the rules.

I know some of the 3rd party migration tools had a bugger of a time dealing with this behavior. Last I checked, Quest Fastlane Migrator was one of these. It ended up leaving the randomized samaccountname instead of restoring the original samaccountname during AD migrations where the 2003 ADC is used.

Have the 3rd party migration vendors been "educated" on this so that they can update their products appropriately?

Thanks again for the great info!
-Bozford

[#4]

Would be nice to have a feature in ADMT to add the SID History(and all the other attributes) to the ADC'd object and the ability to choose which username will be created when ADC runs("Normal" SAM or "bizarre" SAM). This would ease the migration - ADClean would'nt be necessary... Maybe in ADMT 3.0?

[#5]

Why does the Exchange 2003 ADC create accounts with a bizarre logon field? (For Example, ADC_BDZQOKNUIZDWPPHG...