Home / server / Questions / 1173792
Accepted
Sranda
Asked: 2025-02-27 18:16:10 +0800 CST

Domain migration, SIDHistory and inability to access resources cross domains

  • 772

I am executing a domain migration project (many single-site domains merged to one global AD) in my company.

I have migrated users, computers and groups (using Quest on-demand migration tool). and I have verified SID history is being written correctly to user+group accounts. I can see the SIDHistory attribute populated for both users and groups with correct values.

The user's account that is migrated to the new domain tries to access a fileserver in the old domain, in the log of the old-domain-fileserver, I see:

A network share object was checked to see whether client can be granted desired access.

Subject:
    Security ID:        NEWDOMAIN\admig2
    Account Name:       admig2
    Account Domain:     NEWDOMAIN
    Logon ID:       0x1B7Dxxxx

Network Information:    
    Object Type:        File
    Source Address:     10.ab.cd.ef
    Source Port:        49782
    
Share Information:
    Share Name:     \\*\SHARE
    Share Path:     \??\D:\SHARE
    Relative Target Name:   \

Access Request Information:
    Access Mask:        0x80
    Accesses:       ReadAttributes
                
Access Check Results:
    ReadAttributes: Not granted

I have run following commands both in old and new domains:

old domain

netdom trust <old domain fqdn> /domain:<new domain FQDN> /enablesidhistory:yes
netdom trust <old domain fqdn> /domain:<new domain FQDN> /quarantine:no

new domain

netdom trust <new domain FQDN> /domain:<old domain fqdn> /enablesidhistory:yes
netdom trust <new domain FQDN> /domain:<old domain fqdn> /quarantine:no

It's been already some hours so everything should be replicated everywhere. Still, I am getting the same error when trying to access the fileshare with the migrated user's credential: access denied, ask your administrator

Besides turning off the SIDfiltering and migrating user's groups as well, are there any other areas I need to check and I have missed in my post above? Thanks.

Outcome of one of the tests: I believe I have ruled the NTLM culprit out - it is not it. When I share new folder for R/W for Everyone and in security ACL, I give the OLDDOMAIN\admig2 permission for this new share, the NEWDOMAIN\admig2 can access this share. It is still the OLDDOMAIN-joined fileserver. I am confused by these symptoms. Yes, OLDDOMAIN\Domain users is a domain local group and NEWDOMAIN\admig2 is not member of it, but this is where SidHistory should kick in and due to old SID being member of OLDDOMAIN\Domain Users, I believe this should still work, but it does not. Or ... ?

I will continue with the tests tomorrow.

active-directory

1 Answers

  1. Best Answer

    The explanation of and solution to the problem is as follows:

    • The file share in the source domain, at the root-folder-level, used OLDDOMAIN\Domain users as traverse group
    • the new-domain-user & old-domain-group memberships are tied together as long as the old-domain-group gets migrated as well
    • OLDDOMAIN\Domain users never was and never will be a subject to migration, obviously

    The Domain Users group is a built-in group specific to each domain, and its SID is not migrated or replicated across domains. This means that even with SID history migration, users moved to domain NEWDOMAIN will not be members of domain OLDDOMAIN\Domain Users

    Solution was fairly simple, to create universal (it could be global) AD group in the new NEWDOMAIN and configure it as proper traverse group on the old-domain-joined-fileserver.

    Why that is set the way it is in the old domain, is beyond (not only my) comprehension.

    • 0