Dwarfsoft [GPA]

Well, I have been very slack in that I haven’t updated with my Group Policy investigations or the eDirectory VBScript classes I was working on, but what I have been involved in recently is working on Migrating Workstations from Novell eDirectory to Active Directory.

In this process I have come across an array of options in migrating accounts from a Local User account to Domain User account and transferring the profiles across to keep the user “look and feel” that they are accustomed to.

One problem: In this scenario it makes for a very manual rollback strategy, no matter how much scripting and automation is involved in the migration process. This boils down to Novells implementation of “Dynamic Local User” which effectively creates a Local User Account that is not really bound to a User Account in eDirectory for Authentication or mapping purposes (which you can see if you look at the account SIDs).

So, how can you Migrate a local profile to a Domain User account while still maintaining a seamless rollback option (without using Roaming Profiles… This is out of the question)? The solution I have worked on is what I am terming “pre-staging” or “seeding” the Domain User Profile.

1. Enumerate all Local Enabled Users (except for “Administrator”)
2. Get the SID for that User (and the SDDL/String SID)
3. Read the Profile Path for that User from Registry
4. Set an ACL on that folder for <Domain>\<UserName> (we have the UserName being replicated between eDirectory and Active Directory
5. Mount the existing users NTUser.dat into HKU\<UserName>
6. Set ACL on HKU\<UserName> and all subkeys for <Domain>\<UserName>
7. Set ACL on HKU\<LocalUserSID> and all subkeys for <Domain>\<UserName> (just in case the user is actually logged in)
8. Dismount HKU\<UserName>
9. Mount the User Class hive (UsrClass.dat) into HKU\<UserName>_Classes
10. Set ACL on HKU\<UserName>_Classes and all subkeys for <Domain>\<UserName>
11. Set ACL on HKU\<LocalUserSID>_Classes and all subkeys for <Domain>\<UserName> (just in case the user is actually logged in)
12. Dismount HKU\<UserName>_Classes
13. Read the ACL on the Profile Folder (set Earlier) for <Domain>\<UserName> to get the Domain User SID
14. Convert the Domain User SID to an SDDL/String SID
15. Pre-stage/Seed the Domain User Profile by creating a new Registry key in HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\<DomainUserSDDL>
16. Write in a few choice keys, the two most important being ProfileImagePath (String) and Sid (Binary). (The others I seeded were the DWords State and Flags, which were set to 0, and CentralProfile, which was an empty string).

Once the eDirectory user is no longer a member of a DLU enabled User Profile Package, they will be forced to log on through the Active Directory Domain (yes, we are still logging on through the Novell Client). The Profile used for the Domain User will be the same as that used by the Local user. The added benefit is that our rollback strategy becomes “Add user to a DLU enabled User Policy Package” and gets them to log back into their original profile. To safely secure a situation where there is a catastrophic failure of the profile (loss) a backup of the profile can also be done at the seeding stage (just check %userdomain% for equality with %computername% to see if they are logging on with a Local account or a Domain Account).

This has had only minor testing at this stage, but as no paths have changed and there appears to be no problem with the Domain User using the existing Profile I believe this is a reasonably comprehensive solution. This, I must stress, is not a recommended way to deal with migrating users, but it is a tricky little feature that can be abused as I have just demonstrated.

Code (or VBScript) will follow soon

Cheers, Chris.