If you ever performed a migration with the Active Directory Migration Tool (ADMT) it probably has come to your attention that you can’t migrate built-in domain groups, the reason for this is simple – those are groups has well-known SIDs ore more specifically well-known RIDs – meaning that their RIDs are the same in any domain.
The ADMT Migration Log will state the following:
Table 1: Migration Log
|
ADMT Migration Log – Sample |
| Active Directory Migration Tool – scripted group migration started. WRN1:0135 The object ‘Users’ is a built-in or well-known account. The object will not be migrated. WRN1:0135 The object ‘Domain Guests’ is a built-in or well-known account. The object will not be migrated. WRN1:0135 The object ‘Group Policy Creator Owners’ is a built-in or well-known account. The object will not be migrated. WRN1:0135 The object ‘Pre-Windows 2000 Compatible Access’ is a built-in or well-known account. The object will not be migrated. WRN1:0135 The object ‘Performance Log Users’ is a built-in or well-known account. The object will not be migrated. WRN1:0135 The object ‘Windows Authorization Access Group’ is a built-in or well-known account. The object will not be migrated. WRN1:0135 The object ‘Remote Desktop Users’ is a built-in or well-known account. The object will not be migrated. WRN1:0135 The object ‘Enterprise Admins’ is a built-in or well-known account. The object will not be migrated. WRN1:0135 The object ‘Schema Admins’ is a built-in or well-known account. The object will not be migrated. WRN1:0135 The object ‘Guests’ is a built-in or well-known account. The object will not be migrated. WRN1:0135 The object ‘Domain Users’ is a built-in or well-known account. The object will not be migrated. WRN1:0135 The object ‘Terminal Server License Servers’ is a built-in or well-known account. The object will not be migrated. WRN1:0135 The object ‘Domain Admins’ is a built-in or well-known account. The object will not be migrated. WRN1:0135 The object ‘Administrators’ is a built-in or well-known account. The object will not be migrated |
The problem
This causes an issue if you want to preserve access to resources in the source domain, once a user account has been migrated to the target domain, this is usually accomplished by using sIDHistory – (Migrated users and groups inherit their source SID in the sIDHistory attribute – You can read more here: Using SID History to Preserve Resource Access)
If you have ACLs (Access Control Lists) that contain ACEs (Access Control Entries) either granting or denying rights on a File Share to for example the “Domain Users” group (a group with a well-known SID) in “source.dom” and a user “John” who is member of “Domain Users” are migrated from “source.dom” to “target.dom” with sIDHistory (since built-in groups aren’t migrated – John would know lose the presence of the “Domain Users” group in “source.dom” in his token and can therefore no longer access resources in “source.dom” that was granted to him by the “Domain Users” group, the example below.
The solution using Security Translation
The Active Directory Migration Tool (ADMT) has a feature called Security Translation – briefly described; Security Translation can translate security references on objects in Windows NT:
- Files and Folders (NTFS)
- Shares (Share Permissions)
- Printers
- Registry
- Local Groups
- User Profiles
- User Rights
Usually security translation is taking place once a resource has been migrated from the source domain to the target domain, running the security translation will effectively replace SIDs (sIDHistory) for Security Principals from the source domain that has been migrated to SIDs in the target domain, this is referred to as the “Replace” operation.
We are going to use the “Add” operation in order to solve the issue with built-in groups – as we can’t migrate built-in groups.
We’re going to create a “fictive” “Domain Users” group in the target domain (Making source that all users being migrated from the source domain are being members of this group once migrated) and we’re going to use the Security Translation to grant this “fictive” “Domain Users” the exactly same permissions as the “Domain Users” group in the source domain has using the security Translation Wizard.
Step-by-Step
-
Let’s create group in “target.dom” named: “Source_Domain Users” – obtain the SID of the newly created group, as well obtin the SID of the “Domain Users” group in “source.dom”.Create a SID Mapping file that we’re going to use in ADMT and the Security Translation Wizard.
The format of this file is <source sid>,<target sid> in this case that is <real domain users group in source>, <fictive domain users group in target>Table 2: SIDMappingFile
|
SIDMappingFile Sample |
| S-1-5-21-1429931347-2825349181-4189204843-513,S-1-5-21-3530694592-736403133-1610603870-21311 |
Save the SIDMapping file as “SOURCE_TARGET_Domain Users.txt”
Star the Security Translation Wizard in the Active Directory Migration Tool (ADMT):
- Select the “Other objects specified in a file” option and type the path to the mapping file we created in Step 1.
- Select the appropriate target and source domains.
- You should now select all active member servers within the source domain (because you probably don’t know exactly which servers that contain ACEs (Access Control Entries) with the Domain Users group.Note: I recommend gathering a list of active member servers in the source domain and processing them in batches of 20-30.
- Select where you want to translate security.
Note:I recommend the selected only, as it’s very unlikely that the others contain ACLs/ACEs with Domain Users. (You more you select – the longer time it takes to process each server)
- Select the “Add” operation, as we want to grant our “fictive” “SOURCE_Domain Users” group the same permissions as the real “Domain Users” group without replacing/removing it – doing so will instead result in lost access for users that hasn’t been migrated yet.Note:Verify twice that you really have selected the “Add” operation.
- You’re now ready to start the operation.Note:You might end-up with security issues if the account you’re running this operation with isn’t member of the local administrators group on all servers you intend to translate security on (e.g all member servers in the source domain – you can accomplish that with GPOs or scripting)
Let’s see now how it works
Once security translation has been performed the “SOURCE_Domain Users” group should now have been granted the same rights as the real “Domain Users” group in the source domain “source.dom” it should look like:
Let’s now migrate “John” from “source.dom” to “target.dom” and make him a member of “SOURCE_Domain Users”
Summary
I’m working on a domain migration and consolidation project where we discovered that it was very common in the source domains that ACLs (Access Control Lists) contained ACEs (Access Control Entries) with the built-in “Domain Users” group – resulting in lost permissions for migrated uses (We applied this workaround on 80~ domains being all migrated to a single domain/forest) – Running Security Translation in domains with 1000+ member servers could take an entire week, I’ve recommend to perform security translations on lager file servers off business hours cause the ADMT agent can consume notable amount of CPU.
If someone is interested we had to write a script to do basically the same on NetApp Filers.
Hi, Thank you for this explanation.
Just a question : What about putting target “Domain users” group in the “Users” group on the AD of the source domain ?
Thanks for your question. It’s a very valid point.
We do this if the DCs are beeing used as a File/Print/Any other role – then we treat it as a “server” and run Security Translation on the DCs as well – actuelly doing that with the option “Local Groups” will add the ‘fictive’ “Domain Users” to the “Users” group in the domain. Dose that answer your question?
Christoffer,
I´m working on Interforest migration and we have some file shares using the Domain users permissions.
I have a question/doubt after read this part of your article: “We’re going to create a “fictive” “Domain Users” group in the target domain (Making source that all users being migrated from the source domain are being members of this group once migrated)”
Question:
Can i create a “domain local” group on source domain and include “domain users” group of the source domain at this group and after that do the security translation ?
Because i tested with success a sid history access of some Resources using a new “domain local group” with “domain users group” like member.
What do you think about this ?
Tks,
Claudio Santini
Hello Christoffer,
i am currently working on a Domain Migration and stubling over Roaming Profiles stored on a NetApp Filer.
Do you have any idea if ADMT 3.2 ist gernally able to do a security translation of the roaming profile stored on the NetApp?
Greetings,
Dirk
Hi
No ADMT isn’t able to do this, we used subinacl for NetApp that allows you to translate security as well.
What happens when the SIDs are the same? eg. for groups like Print Operators, Administrators, etc. I am making SID Mapping file but many of these SIDs are the same value. Will it know the format of the file OLDDOMAIN,NEWDOMAIN and prepend the proper domain automatically?
Thanks
You have to create your own ‘fictive’ group e.g “Domain Users_OLDOMAIN1” in your target domain and use that SID. (as you can’t use the real built-in group)
Christoffer,
Yet to read the blog fully, but it is very relevant to what I am about to do -security translation on my already migrated file server.
We are moving into a new forest/domain and have migrated most servers successfully (except exchange and a few others). The file server was also migrated successfully but without doing the security translation. Users stilll logon to the old domain, so access to file shares is fine. Pretty soon we’ll cut over to the new domain, and obviously i need to complete security translation on the file server’s data volumes.
Now the questions: How much time can I expect realistically to complete security translation on a 6 TB volume? Yes, we will do it off hours or over the weekend to avoid poor performance for users. Also, will throwing more cores (this is a VM) help speed up this process? Anything to be careful about as far as the translation itself goes?
Thank you
Mani
My guess is that it wouldn’t take longer than 6 hours – watch out for things like backups being made at the same time / replication / file copy and inform those who have the ability to define permissons on those server that they should assign those to security principals in the new domain from now on, otherwise you have to run the translation again to be 100% sure.
Thanks, that’s a relief to hear it won’t way too long. I’m the only one who manages permissions on the server for now, so I’ll be careful 🙂 And yes, I’ll ensure I won’t be running any backups at that hour.
Thank you, Christoffer!
Hi Christoffer,
Couldn’t you use this method to add the SID of the target domain’s “Domain Users” group to the source servers? That way you wouldn’t have to populate a new group with all users; the target Domain Users group has everyone in it by default. Just wondering why you created a new group in the target domain.
Nice article and thanks in advance for the response!
Yes if you’re doing a 1:1 migration you can do this, the sample was from many domains to 1 migration (where users from domain x, would be granted access to resources in domain y, if we just used the ‘Domain Users’ group in target)
please note at step 1 is says:
The format of this file is ; in this case that is ;
The format of the mapping file should contain a , instead of a ; to seperate the SIDs
Yes, you are correct Marc!
Thanks for pointing that out, I have now updated the text in “Step 1”.
Hi, I’m hoping to get an estimate of how long about 5 million files will take to re-acl? The file server and domain controllers are all virtual within the same cluster, so performance should be good.
Thanks,
Al
Hi Chris,
one question. Is it possible to use AMDT to perform translation from one group in old domain (Domain Users) to new group also in old domain (another group with all domain users)?
It would be the easiest way to replace one group with another.
Or if I prepare this file with SID translation will ADMT will look for new SID in new domain?
Thx for your help.
hi Chris,
you mentioned in this article using subinacl for a migration involving Netapp filers. we are going to be doing the same thing. can you elaborate more on your process?
thanks.
For the netapp filer you need to use SUBINACL instead.
Instructions:
Download SUBINACL.EXE
Step 1 – Run subinacl to scan for domain users:
subinacl.exe /outputlog=collect.txt /subdirectories share\* /findsid=”domain users”
—-
Step 2 – run subinacl in test mode
Example:==MappingFile.txt
Create a mappingfile.txt
subinacl /outputlog=precheck.txt /testmode /subdirectories yourtestsubfolder\* /migratetodomain=
Format of the mapping file:
[mappingfile.txt]
Domain Users=Source_Domain Users
—-==MappingFile.txt
Step 3 – run subinacl sharp
subinacl /subdirectories fileshare\* /migratetodomain=
[mappingfile.txt]
Domain Users=Source_Domain Users
Hi,
does anybody know, why security translation in ADMT skips choosing source and target domain step?