Wednesday, July 9, 2008

Fixing ACLs on Permissioned Resources

ADMT can be used to an extent to re-ACL Servers and Workstations in preparation for migrating to a new domain, however often times mass re-ACL'ing of data (whether to replace or append ACE entries to an ACL) is required for large data moves. A great tool to effectively copy/move/sync source and target data (while retaining security permissions) is Robocopy. This is a freely available tool from Microsoft, and there is even a free GUI front-end for the command-line challenged (or if you just want to avoid fat-fingering a critical data copy/move operation).

In conjunction with Robocopy, you can use the SubInACL free tool to replace/append SIDs to the ACL of each file/folder. SubInACL can be fed a mapping file which maps source to target user names/SIDs. Usually you'll want to start off by appending ACE entries to the ACLs to allow for co-existence (especially if the data migration activities happen to be occuring in parallel with user/group migrations). Once user/group migration activities are complete, and the environment has stabilized, you can re-run SubInACL to remove the unneeded source SIDs.

Remember that when using SIDHistory to access resources, you can only reach back in to the source, and not forward from the source to target. Even when moving data in the above scenario, I would always make it standard practice to be bringing over users with their SIDHistory attribute populated with their source domain SID (attribute name in source: ObjectSID)

As always with SIDHistory, make sure you have it correctly enable on your trust. Different versions of NETDOM (unfortunately you can only do it from a command-line) have different switches to enable SIDHistory. Running a netdom /? will let you know whether you should be using the /EnableSIDHistory:Yes switch, or /Quarantine:No switch. Here are examples:

Netdom Syntax:

Netdom trust TrustingDomainName /domain:TrustedDomainName /quarantine:No

netdom trust trusted_domain /domain:trusting_domain /enablesidhistory:yes

Depending what security context you're running this command in, you may need to specify source and target domain credentials (syntax again can be found with netdom /?)

Robocopy (included as part of the 2003 Resource Kit - free to licensed Windows users)
Robocopy GUI
SubInACL

1 comment:

Anonymous said...

"As always with SIDHistory, make sure you have it correctly enable on your trust. Different versions of NETDOM (unfortunately you can only do it from a command-line) have different switches to enable SIDHistory. Running a netdom /? will let you know whether you should be using the /EnableSIDHistory:Yes switch, or /Quarantine:No switch."

Are you sure that both parameters are identical?
It seems for me that first must be implemented in result domain but second - in source domain.

Odissey@freeola.net