HowTo: ReACLing a File Server in a Domain Migration with SetACL 3.0

When you are planning a migration of user accounts between domains one task always pops up pretty quickly: reassigning the permissions of the users in the source domain to the corresponding users in the target domain, in other words reACLing the file server.

Migration - the Simple Way

SetACL, the free permissions management command line tool, has had a function to automate that task for a long time. Its domain action allows you to simply copy all permissions from a source domain to a target domain:

SetACL -on D:\Data -ot file -actn domain -dom n1:MyOldDomain;n2:MyNewDomain;da:cpydom -rec cont_obj

This copies permissions for all files and directories below D:\Data from MyOldDomain to MyNewDomain. This approach is easy and works very well, but, as always, there is a catch: it can be used only if the user names do not change in the migration. Unfortunately, this is not always the case. Organizations tend to use occasions like a migration to thoroughly spring-clean their account naming convention (“since we’re migrating anyway we might as well change the names, too!”). Or you might be involved in a more complex migration where multiple domains are consolidated. Or you just want more control over the reACLing process. Until yesterday, you had to put your scripting hat on and start hacking away to solve the more advanced scenarios. With the release of SetACL 3 this is not necessary any more.

Monte Vista Sandhill Crane Trip by Stepan Mazurov under CC

Migration - the Flexible Way

SetACL 3 comes with a more flexible way of handling permissions migrations. Its enhanced migration engine can be used to migrate intra-domain, inter-domain or any mix of the two. To start a migration using the flexible model use a command line similar to the following:

SetACL -on D:\Data -ot file -actn trustee -trst csv:C:\temp\mappings.csv;ta:cpytrst -rec cont_obj

This instructs SetACL to copy permissions between individual users or groups for the D:\Data directory tree. Which accounts the migrations is performed for is read from a simple CSV file, mappings.csv in the example, whose contents might look like this:

MyOldDomain\Joe,MyNewDomain\Peter
MyOldDomain\Mary,MyNewDomain\Mary
MyOldDomain\DG-OldDom-HelpDesk,MyNewDomain\DG-NewDom-HelpDesk
MyOtherDom\Fred,MyNewDomain\Fred

As you can see, the system is flexible, powerful, and easy to use. All you have to do is create a mapping table pairing old accounts with new accounts. If you do not want to do that or if you think it is just too much bother: the simpler method presented above still works and is still considered useful in many scenarios.

Comments

Related Posts

Finding (Executables in) User-Writeable Directories

Finding (Executables in) User-Writeable Directories
This article presents two different detection types for insecure filesystem permissions on Windows endpoints: scanning for directories that are user-writable, and detecting processes that are started from user-writeable directories. Directory Scan With ListUserWriteableDirectories & SetACL My ListUserWriteableDirectories script is an implementation of the first detection type: it scans the filesystem listing any permissions not known to be safe.
Security

Latest Posts

Scripted WordPress to Hugo Migration

Scripted WordPress to Hugo Migration
After having published in WordPress for almost 20 years, it was time for a change. This site is now rendered by Hugo, a static website generator built for Markdown content hosted in a Git repository. The migration from WordPress (HTML) to Hugo (Markdown) was far from trivial. Since I couldn’t find any tool for the job, I developed my own set of migration scripts that fully automate the migration process. You can find them on GitHub along with extensive documentation.
Website