HELP! Active Directory Domain Migration involving 3020c Filers

[#1]

I am requesting any information the group may have on what is the best way to migrate NetApp filers to a new domain, WHILE translating the SIDHistory for the CIFS ACLS. I was led to believe that there was a "native" tool for this, but have yet to find one. I am not looking for 3rd party tools, because the migration is to end on Oct 1st and we do not have enough time to purchase any 3rd party software.

We are using the ADMT v3.0 tool to migrate all Active Directory objects from "Domain1" to "Domain2" I want to ensure that "Domain1\Group1" will be translated to "Domain2\Group1"

Thanks!

[#2]

Not sure about the migration tool but

CIFS shares

will list all the shares and their permissions. Not sure about the NTFS on each file however.

My understanding is the filer is a member server in the domain and when you join the new domain you could just recreate the CIFS shares and assign the new permissions.

I have found scripting this will be MUCH faster than filerview.

[#3]

To Brendon's point, you can definitely use 'cifs shares' in order to get a defined list of information about your shares.

Taking it a step further as well, you can take a look at the contents of /etc/cifsconfig_share.cfg which will provide you with the GUID's which are assigned to the individual shares.

If via using ADMT you migrate SIDHistory as well as the GUID's across, you shouldn't have much of a problem once you cut the filer from Domain1 to Domain2.

Do be careful to make sure and review the list of what you're migrating to make sure that you don't run into any odd duplicates, or end up not migrating over a particular user or group with its respective SID and GUID.

Once you've defined that you indeed have replicated this over, and that the data will match on both sides you can simply point it over to the new domain "Domain2" and if CIFS is configured correctly on the filer (talking to the new domain controllers) as far as the filer is concerned the data populated in that /etc/cifsconfig_share.cfg will not have changed as it remains static referencing GUID's all day long.

Hopefully this helps in what you're doing, luckily (unless I'm mistaken) you're only doing a domain migration and not an actual filer or data migration, so it's merely a matter of resolution and ACL verification!

Let us know how it goes Donnie!

Christopher

[#4]

another topic that would help me if we will migrate our storage to a new domain...

[#5]

Hi,

even if this Thread is "solved", i will give a tipp how to do this "Group-Convertion-Job" as easy as possible.

I had the same case and i used the Microsoft Tool "subinacl" for it. With the switch /migratetodomain=SOURCEDOM=TARGETDOM this tool will do this job perfectly and unattended.

To get it working against a filer, you could to the following:

• Take a machine that resides in same domain as the filer does.
• Logon to that machine as Domain Admin of the source domain.
• Map Drive(s) to the share(s) on the filer that has to be converted. (eq: X:\  points to \\filer\Data)
  
• Install subinacl on your machine. (newest version from MS, because it is bugfixed! Dont use the OS builtin version)
  
• Run the following command against your mapped drive:
  • subinacl /subdirectories X:\* /migratetodomain=SOURCEDOM=TARGETDOM
  • Tipp: If you get an error, that one of the domain could not be found / RPC error:
    • This seems to be caused by slightly different behavior of a Filer based CIFS.
    • Solution: Just make a subst to your already mapped drive:
      • subst Y: X:\ (so now the OS running subinacl "thinks" this is a native local drive and it should work)

Note: The switch /migratetodomain just adds the equivalent target groups / users to the ACLs if it finds them in the source domain.

So you have a very secure "DUAL-ACL-Scenario". But there is even a switch to REPLACE the ACEs... Just look into the subinacl Help

Hope this helps!

Greets

Manuel

[#6]

But How can we change the GUID in cifs config file?

[#7]

I know this is an old post, but I had quite a few issues using subinacl against NetApp filers and SetAcl caused some inheritance breakage issues when making changes against certain shares so I took the time to code up a version of subinacl that works better with NetApps and is multithreaded to support changes on large volumes.

It's available at the link below (free, open source).  Feature suggestions welcome.

https://nomorefood.github.io/Repacls