Network and Storage Protocols

Need to move a filer from one AD domian to another.

Lee_Buskey
7,845 Views

Hello.  we have a very basic setup.  Single filer, CIFS Shares only.   Currenty the files is styill on the source domain.   I need to move it to the new domain whach has no trust relationship to the new domian.  WE have home directores and share folders on it.   Obviously, once we shwith the filer to the new domianm our users will no longer have access, as their SID is different.   I am looking for a tool I can use to somehow provide a mapping file SourceDomainUser=TargetDomainUser after I move it to the target domain, which will simply replace all the existing ACLs for a given user with the new SID in the desitnation domain. Any suggestions?  

 

 

8 REPLIES 8

mbeattie
7,819 Views

Hi there,

 

The easiest method would be to use SID history though there are some security considerations:

 

http://technet.microsoft.com/en-us/library/cc755321(v=ws.10).aspx#w2k3tr_trust_security_eocv

 

Also you might want to consider re-setting file ownership on the users data to their new account if you are using quotas. 

 

Hope that helps.

 

Matt

If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.

aborzenkov
7,809 Views
SID history requires trusted relationships between domains; at least that is written in all documents I have seen. I am curious whether this is hard requirement or simply limitation of existing tools.

mbeattie
7,796 Views

Hi,

 

if creating a trust relationship so you can use ADMT to migrate users/apply SID History is NOT an option for security reasons then is data migration would be required.

Some info on the DsAddSidHistory function trust relationship requirements are listed in the links below:

 

http://msdn.microsoft.com/en-us/library/windows/desktop/ms675918(v=vs.85).aspx

http://msdn.microsoft.com/en-us/library/windows/desktop/ms677982(v=vs.85).aspx

 

/matt

If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.

Lee_Buskey
7,789 Views

Thanks for the replies so far!.   I'll do a double check,but there are a few peices of additional relevent info.   There is no,and will be no trust between the domain, fought that fight, lost, now we are pressing on.  Additionally, the users already have accounts in both domains.  As far as I know, you have to migrate user accounts in order to use SID history.  In this case, both user accounts exist and do have the same username, but different domains.   Honestly, all I really need is program that can crawel through the entire file structure, and for every instance of an ACE within an ACL,  add another ACE for the exact same user but in the new domain.   In fact, we could even live with replacing the ACL...

 

Possiblly doable in Powershell..

  

mbeattie
7,781 Views

Hi,

 

Definately possible to using .NET methods to edit ACL's in PowerShell or native cmdlet's (get-acl\set-acl). You could also use icacls.exe to re-permission the data? See the /substitute parameter.

 

http://technet.microsoft.com/en-us/library/cc753525.aspx

 

[/substitute <SidOld> <SidNew> [...]]
 Replaces an existing SID (SidOld) with a new SID (SidNew).

 

You could re-configure the NTFS permissions however this could take a long time depending on the amount of data you have. Home directories would be easy to migrate, you could snapmirror the volume from the source vfiler\vserver to the target vfiler\vserver and re-permission the data or you could use a script to create the home directories for users in the target domain, apply ntfs permissions and migrate the data automatically. SnapMirror is the most efficent method to migrate the data but you'd then have to have an outage for some time whilst you re-permission the users data. 

 

/matt

If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.

mbeattie
7,776 Views

Hi,

 

Actually having considered the options given there is no possibility of a domain trust then SnapMirror would be the only option to migrate your data as attempting to use other migration methods such as robocopy would result in access denied due to authentication failure between vfilers\vservers in seperate AD forests. I guess you could attempt to limit the outage by snapmirroring one FlexVol at a time, recreating the cifs shares and re-configuring NTFS permissions but ultimately you won't be able to avoid the outage\interuption to users without using SID History...then again re-permissioning the data might not be such a bad option...SID history can be a ticking time bomb (outage waiting to happen if the domain trust is removed)

 

/matt

If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.

mbeattie
7,758 Views

Hi Lee,

 

I tested using icacls.exe to replace the SID's using the /substitute parameter and found it actually results in the following errors:

 

C:\>icacls.exe <%uncpath%> /substitute S-1-5-21-3567637-1906459281-1427260136-1555232 S-1-5-21-3150332139-2813398079-754052488-1113
what?  Flags == 10000000
Successfully processed 0 files; Failed processing 0 files

 

So i tried combining it with the /restore parameter resulting in the following error:

 

C:\>icacls.exe <%uncpath%> /save "C:\temp\folder.acl"
processed file: <%uncpath%>
Successfully processed 1 files; Failed processing 0 files

 

C:\>icacls.exe <%uncpath%> /substitute "S-1-5-21-3150332139-2813398079-754052488-1113" "S-1-5-21-3567637-1906459281-1427260136-1555232" /restore C:\temp\folder.acl
S-1-5-21-3150332139-2813398079-754052488-1113: No mapping between account names and security IDs was done.
Successfully processed 0 files; Failed processing 1 files

 

So i turned to the old school method using cacls.exe (depreciated but still works)

 

/S            Displays the SDDL string for the DACL.
/S:SDDL       Replaces the ACLs with those specified in the SDDL string

You can use the /S:<SDDL> parameter to edit the SDDL (replacing the new sid with the old one)

 

EG:

 

List the SDDL

 

C:\>cacls.exe <%uncpath%> /S
<%uncpath%> "D:ARAI(A;OICI;0x1301bf;;;S-1-5-21-3567637-1906459281-1427260136-1555232)(A;OICI;FA;;;S-1-5-21-3150332139-2813398079-754
052488-1112)(A;OICI;FA;;;BA)(A;ID;FA;;;WD)(A;OICIIOID;GA;;;WD)"

 

Now Modify the SDDL (replacing the old SID "S-1-5-21-3567637-1906459281-1427260136-1555232" with the new sid "S-1-5-21-3150332139-2813398079-754052488-1113"

 

C:\>cacls.exe <%uncpath%> /S:"D:ARAI(A;OICI;0x1301bf;;;S-1-5-21-3150332139-2813398079-754052488-1113)(A;OICI;FA;;;S-1-5-21-3150332139-2813398079-754052488-1112)(A;OICI;FA;;;BA)(A;ID;FA;;;WD)(A;OICIIOID;GA;;;WD)"
Are you sure (Y/N)?Y
processed dir: <%uncpath%>

 

And if you wanted to automate this just pipe "echo Y" into the cacls.exe command. EG

 

C:\>echo Y|cacls.exe <%uncpath%> /S:"D:ARAI(A;OICI;0x1301bf;;;S-1-5-21-3150332139-2813398079-754052488-1113)(A;OICI;FA;;;S-1-5-21-3150332139-2813398079-754052488-1112)(A;OICI;FA;;;BA)(A;ID;FA;;;WD)(A;OICIIOID;GA;;;WD)"
Are you sure (Y/N)?processed dir: <%uncpath%>

 

This would make it really easy to update the ACL's for your home directories if you batch them together replacing source\target sids. So you could either create a batch file to do this or use PowerShell to edit the ACL's. Hope that helps

 

/matt

If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.
Public