Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 662
  • Last Modified:

AD migration ntfs issues........

We've having difficulty transferring our data ntfs permissions to a new AD domain from NT4.

When using robocopy with /sec the data  copied but all the ace's come up with ? s-1-5-2 1264763 etc.

Should I be using the subinacl command? If so where should this be run from??

thanks in advance....
0
scottyboy777
Asked:
scottyboy777
  • 6
  • 3
  • 2
2 Solutions
 
ian_chardCommented:
How did you move the user accounts/groups over? Did you just upgrade them or are you starting from fresh? If you're starting on a new domain with a new batch of users (rather than transferring them), the accounts won't be copied over. So the reason you are getting this is that when you are using robocopy it's coping the SIDS for the user accounts (or groups) from the NT Domain which is no longer there (or can't be seen by the AD domain). If you transferred the accounts over, then you're probably getting duplication (so for instance you could have a user called ABC in your NT domain who now has an AD log on with ABC2 (or ABC0).

Off the top of my head, you'll have either have to use subinacl to alter the ntfs permissions, or alter them manually on the folders yourself the normal way if the accounts are new in the AD structure.

0
 
schalcraftCommented:
The numbers you are seeing are the Security Identiers (or SIDS). You typically see the SID when your server cant resolve the SID to a object name. To resolve these issues, the action is determined by whether or not your NT4 server a member of the domain.

If it isnt, then you are getting errors as the SIDs on the old server dont match up to any object in your new domain. There is nothing you can do about this. Being to entirely disparate system the only solution is to manually re-assign the security permissions. The easiest way to do this is to creat the basic directory structure with the appropraite groups assigned with inheritance turned on. Then run your robocopy without the sec switch. The data will then inherit the predefined rights.

If the server IS a member of the domain, then you are seeing the SIDs as they are objects that have been defined on the local server. The new server cant resolve the objects that are part of the old server's local security database.
You can fix this by creating new domain based users and groups, and assigning the rights to the data on the NT4 server. After this has been done and the data re-copied, then the new server will still be able to resolve the SIDs as they are known to the domain.

This issue typically occurs when rights and permissions are assigned to local group. You can view these groups by running 'usrmgr \\myserver' after login to the old server. After creating the domain based groups, move the users to the new groups and remove the local groups from the filesystem permissions
0
 
scottyboy777Author Commented:
Thanks for the info...

The nt4 server is a member server in the original domain. I beleive the AD migration tool was used to migrate users and groups to new 2003 domain.

There is a trust setup between the old and new domain.

Ideally we want to transfer the data to a NAS box, however I don't beleive I can run the subinacl command on the NAS box as far as I'm aware....
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
schalcraftCommented:
As long as your NAS box is a member of the domain, robocopy will work perfectly okay. We use it for these types of data migrations regularly.
0
 
schalcraftCommented:
Forget that, I mis-read your reply.
0
 
schalcraftCommented:
Possibly you could use calcs to extract the permissions on the old server and then apply them to the new location. As long as the same object names are used, then the underlying security identifiers are not important.
0
 
scottyboy777Author Commented:
Is this still an option ..........

"If the server IS a member of the domain, then you are seeing the SIDs as they are objects that have been defined on the local server. The new server cant resolve the objects that are part of the old server's local security database.
You can fix this by creating new domain based users and groups, and assigning the rights to the data on the NT4 server. After this has been done and the data re-copied, then the new server will still be able to resolve the SIDs as they are known to the domain.

This issue typically occurs when rights and permissions are assigned to local group. You can view these groups by running 'usrmgr \\myserver' after login to the old server. After creating the domain based groups, move the users to the new groups and remove the local groups from the filesystem permissions"

And does subinacl have to be run from the destination NAS box?

thanks

scott
0
 
ian_chardCommented:
What you could try is logging on to the server that's giving you the issues and then try running gpresult from the command line. This will then tell you what group policies are being applied to it, if it's running group policies then you can confirm that you've got contact with the domain. (sometimes when you put servers/workstations in to domain they don't go in properly.). If you aren't getting any joy there you may have to put the server back in to a workgroup, delete the computer account from AD and then put it back in again.

You can run subinacl from anywhere, providing you run it on the shares, etc for the server hosting the files and folders.

Here's a sample subinacl command that I run from my remote machine on shares that go awry:

REM Prompt for username
set /p userin=Please user logon details:

REM Run subinacl command
start /wait subinacl.exe /noverbose /nostatistic /subdirectories \\SERVERNAME\SERVERSHARE$\* /Owner="%USERIN%" /Grant=%USERIN%=f /Grant="creator owner"=f /Grant="DOMAIN\domain admins"=f /Grant=system=f


I run it with no verbose, no statistics, so I don't get any report on what acls have been changed, but you can change this to suit your needs. This would give a user access rights (and change ownership to that user) for the entire share on the server, so you may need to chop and change it depending on your needs. I've also added domain admins in so that all domain administrators get full control. I can't emphasise enough though that you need to try this in test first...we've had guys alter my batch files who then ran it on our entire user profiles and documents shares, which wasn't nice to sort out after!

If I were you, I'd be looking at applying the user permissions manually first on one folder, this will at least let you know that there is no problem on the file server itself with connecting to AD and that it can recognise the correct SIDS.

Good luck
Ian
0
 
schalcraftCommented:
If your old nt4 domain trusts the new domain, then you can assign file permissions on the NT box to users and groups in the new domain. A robocopy will then assign the newdomain security to your NAS shares. Sadly though, any dag ends of allocation from the old domain will still show up as SIDs.

0
 
scottyboy777Author Commented:
Do we need a two way trust setup for me to complete the above work? We only have a one way trust at the moment - our new 2003 AD domain has an incoming trust from the old nt domain. Is this enough to robocopy the data inc ntfs permissions?

thanks
0
 
schalcraftCommented:
An incoming trust is one where the AD domain is trusted by another domain, so in this case, your NT4 domain can trust user accounts that exist in your new AD domain.

You dont need to setup two way trusts unless you need your old NT4 domain user accounts to be able to access resources in the new AD domain.
0

Featured Post

Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

  • 6
  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now