views:

382

answers:

3

I'm moving my dedicated server to another provider and I'm migrating everything over to the new server.

One thing that I haven't been able to figure out is how to save ACLs (access control lists) from an existing system into another.

I have 3 different local user accounts that I use on IIS to isolate each web site access from the other, IUSR_SITE1, IUSR_SITE2, IUSR_SITE3.

Is it possible to save and restore the ACLs from those directories into another computer? All the files will be the same, I just need to move the ACLs and create the respective local user accounts.

Thanks for any help provided.

+1  A: 

You can use XCACLS from the Windows Resource Kit, more info here. This is not a complete solution, but you could list all permissions you are interested in and use that output to generate a script that restores those permissions using XCACLS again.

You can also use Robocopy (also in the resource kit and installed by default on Vista) to copy the files with ACLs included. That might only work if the users are in the same domain as both servers, since the SID of the ACLs must exist on the other system for this to be useful. If they don't you end up with a bunch of ACLs for users that don't exist on your target system.

Gerco Dries
Exactly, I tried msdeploy to copy all the IIS settings and ACLs but the ACLs where not restored on the target system. I also tried the WinRAR option to copy file permissions and it did applied the ACL but it didn't existed on the target system. Would XCACLS re-create the users on the target system?
smartins
No, but you can generate the script by using the usernames of the ACLs and not the SIDs of the users. That way, when you run the script on your target system, the ACLs will be recreated with the correct SID.Generating that script won't be all that trivial though.
Gerco Dries
+1  A: 

Because you are using local accounts just copying the ACLs will not work, because the SIDs will be different on the different machines.

I would work this in several steps:

First: Get the account SIDs (both on old and new machines). The quickest way is using psgetsid (from PSTools)

PS G:\> psgetsid iusr_mymachine

PsGetSid v1.43 - Translates SIDs to names and vice versa
Copyright (C) 1999-2006 Mark Russinovich
Sysinternals - www.sysinternals.com

SID for MYMACHINE\iusr_mymachine:
S-1-5-21-3287596715-1315679848-4222504177-1004

Second: Get the SDDL ("Security Descriptor Definition Language", a way of writing ACLs in text, described on MSDN) of the files you want. Win32 and .NET have methods to do this, but the simplest route is PowerShell (with added line breaks to make structure visible):

PS E:\Dev\Sites> (get-acl .\WebSite).sddl
O:S-1-5-21-1527045006-1366868173-4125010901-1001
G:S-1-5-21-1527045006-1366868173-4125010901-513D:AI
(A;OICI;0x1200a9;;;NS)
(A;OICI;0x1200a9;;;S-1-5-21-1527045006-1366868173-4125010901-1012)
(A;ID;FA;;;S-1-5-21-1527045006-1366868173-4125010901-1001)
(A;OICIIOID;FA;;;CO)
(A;OICIID;FA;;;SY)
(A;OICIID;FA;;;BA)
(A;OICIIOID;FA;;;S-1-5-21-1527045006-1366868173-4125010901-1001)

Third: String substitutions can be applied for each {old machine SID, new machine SID) on this string.

Fourth: Set the new ACL on the folder (or file):

$sec = get-acl newfolder
$sec.SetSecurityDescriptorSddlForm($sddl)

Clearly the best route to do this for multiple files is to script it, with a script on the old machine doing 1 & 2, and generating a script to do 3 and 4 on the destination machine (to avoid setting an ACL with unknown SIDs remotely).

Richard
+1  A: 

To answer my own question, I've found a program named AccessEnum that lists all the folders that have different permissions than the parent.

http://technet.microsoft.com/en-us/sysinternals/bb897332.aspx

This has allowed me to identify which folders need write or write/execute permissions and apply them by hand. It's not ideal but the other alternative was also time consuming and somewhat complex.

smartins
+1, useful utility. I just wish the app would enable the backup privilege, so that I could see users' profiles as well.
avakar