This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

File Shares after migration

I am working on a domain migration. Migrating a domain from one forest into its own stand along domain/forest.

We are using the tool Quest Migration Manager for Active Directory.

Old domain: Forest/Domain functional level 2012 R2

New domain: Forest/Domain funtional level 2016

2 way external non-transitive trust in place.

SID history enabled, SID filtering disabled

All users have been migrated over (accounts kept active in old domain for now)

All security groups have been migrated and populated with the equivalent user accounts

All servers are forunately virtualized (VMWare if it matters), so we can roll back any issues.

3 DCs on each side, they can all speak to each other

This is my third server I am migrating to the new domain. We are still in the "test" phase and there is no lab to test with so, we are forced to test in production. The other two servers have both worked (one 2008r2 the other 2012 R2) with no issue. This server, however, is giving me plenty of lip.

After migrating this file server, the file shares are not being cooperative. Using my "old" credentials which are "old" domain Domain Admin, I can access the shares (NTFS and share permissions explicitly allowed) as was originally designed. using my "new" domain credentials ("new" domain Domain Admin) I cannot access the share. I have verified that the "new" Domain Admins security group is set on both the share and NTFS permissions.

I have also ensured that both domains Domain Admin security groups are listed in the local "Administrators" security group on this server. No Anti-Virus is currently on this server (had to remove it for the migration). The migration reported no issues. errors, or warnings.

Any ideas?

Asking this here as well as on MS forums

Parents
  • Have you resource processed the server? 

  • Yes I have. All of this is after processing the server.

  • So I am trying to understand what state you are in and what issue you are having. 
    1. You migrated the source objects to the target, users, groups and group membership. 
    2. You resource processed the server completely and appended the target objects to the ACLs.
    3. You moved the server to the target, and accessing it with a target account you cant access a resource you should? 
    4. Did you migrate Domain users and Domain Admins? To the same name or different names? 

    My Questions are:
    1. What is the share permissions? (this is easiest to see when the server is a member of the source, sidhistory makes it hard to see)
    2. What is the underlying file system permissions? 
    3. What entry in the ACL should allow you access to the resource.

    FYI, Well Known and built in accounts/groups do not support history and we don't migrated it. Even if we did migrate it, it would not work. Windows 2003 SP2 or higher discards well known sidhistory from the the access token. So migrating it is pointless. 

  • The problem is, only users from Old Domain have access. New Domain does not. This includes New Domain "Domain Admins", which was even manually added, and still no access. The underlying permissions are Local Admin, Domain Admin, user1, user2, user3, user4, user5. user1 and user2 (after processing user1..5 show up twice, as they should) have been migrated and I have kept their old accounts active while testing this out. They can access this through OLD FQDN but not NEW FQDN (DNS is updated to reflect NEW, checked that as well). When using NEW FQDN, they cannot access share1 or share2. Using OLD creds they can access both shares.

    Permissions have been verified and manually updated to reflect both sets of credentials, but still not working.

  • Can we see the share and ntfs security permissions of a particular share? (screen shots)

  • You need to stop talking in big pictures. This is a details type of problem.  DNS, FQDN, vague user reference make this hard to see the trees through the forest.  Right now this reads like “it’s broke”.  Lots of info and no details.  Remove sidhistory from the groups and users. That will make this easier to see. Because once you resource process the server, sid history is not needed to access it. 

    Pick a share, any share. List the share permissions. Yes, screenshots are best. 

    • source\domain users:read
    • target\user1:modify

    list the folder permissions for the shared folder. 

    • Source\group1:
    • local\administrators:full control

    what is the exact error when target\user1 tries to access the share. Can you manually add this user to the share, folder and ssystem object? If you do, what error does that now present?

Reply
  • You need to stop talking in big pictures. This is a details type of problem.  DNS, FQDN, vague user reference make this hard to see the trees through the forest.  Right now this reads like “it’s broke”.  Lots of info and no details.  Remove sidhistory from the groups and users. That will make this easier to see. Because once you resource process the server, sid history is not needed to access it. 

    Pick a share, any share. List the share permissions. Yes, screenshots are best. 

    • source\domain users:read
    • target\user1:modify

    list the folder permissions for the shared folder. 

    • Source\group1:
    • local\administrators:full control

    what is the exact error when target\user1 tries to access the share. Can you manually add this user to the share, folder and ssystem object? If you do, what error does that now present?

Children
No Data