4

The problem

Due to a merger in our organisation, we are migrating to a new common Active Directory domain. Our old legacy domain and the new domain have a two-way trust between them.

We have two main fileservers in our old domain, on which users have a personal folder. Some users have their folder on one server, others on the other one, depending on which department they work for. On these personal folders, NTFS permissions are granted using the users account directly.

A user has an account in both the old and the new domain. So now I was in the process of adding permissions to these personal folders for the corresponding user from the new (trusted) domain. Strangely, this works fine on one fileserver but not on the other.

I scripted this in powershell and it throws the following error:

Add-NTFSAccess : Cannot bind parameter 'Account'. Cannot convert value "<New Domain>\<New Username>" to type "Security2.IdentityReference2". Error: "The trust relationship between the primary domain and the trusted domain failed.

When i manually try to add the permission. I can see the other domain as well as check the name of the user. But when I try to apply the permissions I get the following error:

Trust error

Things I've checked so far

  • The DNS names of the DC's of the trusted domain resolve fine from the fileserver
  • Verified the trust in the "domains & trusts" mmc (All other trust related things work fine btw)
  • The fileservers are in different firewall zones. I asked the network guys to temporarily allow all traffic between the file servers and the DC's of the trusted domain for testing. (But the correct ports should have been open anyway, since the rules are the same for both fileservers)
Omnomnomnom
  • 659
  • 3
  • 10
  • 22

2 Answers2

0

I had the same issue on a fileserver. I checked the domain trust, ran Test-ComputerSecureChannel, ran all the test I could find. The DCs we're working fine and could edit these permissions on the DCs.

Found out i had error 4625 in the Security Event Log on the fileserver with Status 0xC000005E

There are currently no logon servers available to service the logon request.

Turned out I had to restart Netlogon service in services.msc on the fileserver.

Ties
  • 103
  • 4
0

Probably a trust problem .

Doucle check ntp :) Weird problems sometime are just a stupid clock problems . Set same ntp on the two domain .

Double check the trust , and dns name . If you ping the domain name and all ok check for eventslogs on source and target server .

Try with Test-computersecurechannel in pshell .

YuKYuK
  • 627
  • 3
  • 14
  • Time on the new domain is running on the DC's internal clock (default conifguration), while on the old domain it is synced to our ISP's time server. This situation is not very good and I will fix it. But the time difference is only three seconds or so. Could this be a problem? I can ping the new domain from the old fileserver. Test-computersecurechannel returns true with -Server . Which event log should I check for errors like these? – Omnomnomnom Feb 11 '15 at 12:47
  • best practice is to use external ntp for domain controler to prevent tombstone with battery failure . For you problem its in security event and test with domain tools : NETDOM: Used to establish or break trust types. NETDIAG: The output of this tool can give basic status on trust relationships. NLTEST: Can be used to verify a trust relationship. – YuKYuK Feb 11 '15 at 13:03