Go Premium for a chance to win a PS4. Enter to Win


Domain Trust failing

Posted on 2010-09-17
Medium Priority
Last Modified: 2012-05-10
I am having an issue with a trust relationship that I have created.

Overview of my network

Domain A/B

2003 forest level
root domain (A)and child domain (B) fsmo roles within datacentre (firewalled)
Domain controller for domain B (Lets call it DC3) has been created at remote site (for Domain C) in DMZ
RPC ports have been tied down to allow traffic through the firewall

Domain C
2003 domain
Firewalled from domain B with exception of the domain controller (noted as placed at remote site)
Firewall is open between PDC of Domain C and domain controller (DC3) on all ports as RPC port settings have not been applied in domain C.

DNS zone transfers successfully created between both domains
WINS replication taking place between domains.

DC3 is able to communicate on standard AD ports (with RPC restricted) to Domain C subnets.

An incoming Trust has been established for domain C to trust domain B  but appears to have since broken.

From a DC in Domain C, the trust appears OK. I am told that the trust is valid and in place.

From Domain B, I am told that the trust cannot be validated as 'There are no logon servers available to service the logon request'. The strange things is that it attempts to validate the secure channel with a domain controller in domain C that it is firewalled from rather than the PDC with which it is able to communicate with.

Even stranger is that it seems to be OK one day and broken the next. Without anything changing everything may work tomorrow!

When I open AD users and computers from the DC in Domain B at the remote site and try connect to Domain C, I get an error;

The domain ** could not be found because: Access is denied

I have done some more investigations as it is back down again today. It was working OK yesterday and nothing has changed...

C:\Windows\system32>nltest /SC_query:ceg.company.org
I_NetLogonControl failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN

C:\Windows\system32>nltest /dsgetdc:ceg.company.org
           DC: \\s-49-4901-002.ceg.company.org
      Address: \\
     Dom Guid: 37a357fe-e492-43a2-8a1e-c0abcfcbf94e
     Dom Name: ceg.company.org
  Forest Name: ceg.company.org
 Dc Site Name: Koeln-HQ
The command completed successfully

Any ideas?

It would appear to be something wrong with name resolution but everything looks OK
Question by:aideb
  • 5
  • 2
  • 2
  • +1
LVL 11

Accepted Solution

Plantwiz earned 334 total points
ID: 33699840
It does sound as though it is a name resolution problem.
Repopulate AD DNS with netdiag /fix on the directory server.  See if that improves things.

Review these:
LVL 11

Expert Comment

ID: 33699861
Also, this may be of some help if you fall into a similar situation.

See here:

Assisted Solution

saL1Las earned 332 total points
ID: 33700166
I think I may have to pull out a pen and paper to draw this up properly.

Basically it looks like this. The domain you're logging into has more than one DC in it. Given that the DNS entry for "MYDOMAIN.LOCAL" will sort of round robin between different DCs, you will be unable to login if the DC point to is blocked by the firewall.

Solution is to either setup a host entry or edit DNS to point to only one server for said domain.
Visualize your virtual and backup environments

Create well-organized and polished visualizations of your virtual and backup environments when planning VMware vSphere, Microsoft Hyper-V or Veeam deployments. It helps you to gain better visibility and valuable business insights.


Author Comment

ID: 33700767
Sorry, I omitted to add that domains A & B are running 2008 DCs so therefore NetDiag is no longer available.

I thought about the round robin issue and tried to force the issue with setting a host file on DC3 with an entry for the domain name pointing to the DC on domain C that it is able to speak to.

Whilst when I ping ceg.company.org it resolves to the right DC, the
nltest /dsgetdc:ceg.company.org

returns a DC without connectivity...
LVL 26

Expert Comment

by:Leon Fester
ID: 33700840
I've seen instances where the trust behaves erratically. Some functionality is working one day then the next it isn't.

Even verifying the trust in AD Domains and Trusts Snap-in shows everything OK.

The easist way to fix a corrupt trust, even if verification works, is to break the trust and then set it up again. I spent a whole weekend chasing Event Log errors, and finally broke and re-established the trust and worked immediately.

Author Comment

ID: 33700883
I have previously removed and then re-established the trust. It went back in place and worked not problem for a few days then started playing up again! ARRRGH!!!!
LVL 26

Assisted Solution

by:Leon Fester
Leon Fester earned 334 total points
ID: 33701287
Did you remove the trust from both sides of the domain, and did you confirm that replication had taken place after deleting the domain?

C:\Windows\system32>nltest /SC_query:ceg.company.org
I_NetLogonControl failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN
I've seen the above happening when I run it on a bridgehead server, even when everything is working.

Did you try reseting the secure Channels to each server.
on DC1:
nltest /sc_reset:domain2
nltest /sc_reset:domain3

and then do the same for the other DC respectively.

Check if you've got any interesting errors/warnings recorded in your event viewer.

Author Comment

ID: 33723163
On oneside of the trust reseting the channel gave

I_NetLogonControl failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN

On the other side I got a succesful


Author Comment

ID: 33732333
I have uploaded a problem steps recorder.

In AD domains and trusts today it says that the trust is valid and in place (yesterday it said it was failed!)
At the command line it says no such domain.

Any help would be invaluable.

I may have to try break and re-establish the trust again if I cannot get this working reliably soon :(

Author Closing Comment

ID: 33877529
Issue was with firewall. Dc needs to have 389 opened to all DCs on the other domain

Featured Post

Nothing ever in the clear!

This technical paper will help you implement VMware’s VM encryption as well as implement Veeam encryption which together will achieve the nothing ever in the clear goal. If a bad guy steals VMs, backups or traffic they get nothing.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

After seeing many questions for JRNL_WRAP_ERROR for replication failure, I thought it would be useful to write this article.
How to deal with a specific error when using the Enable-RemoteMailbox cmdlet to create a mailbox in the cloud-based service, for an existing user in an on-premises Active Directory.
This Micro Tutorial hows how you can integrate  Mac OSX to a Windows Active Directory Domain. Apple has made it easy to allow users to bind their macs to a windows domain with relative ease. The following video show how to bind OSX Mavericks to …
Attackers love to prey on accounts that have privileges. Reducing privileged accounts and protecting privileged accounts therefore is paramount. Users, groups, and service accounts need to be protected to help protect the entire Active Directory …

886 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question