Unable to verify domain trust on one side of the trust (not all DCs can ping) HELP!!
-
Friday, March 08, 2013 12:56 PM
Here's a great one for the experts!!
Main Site LC Domain
LCDC1, LCDC2, LCDC3
Remote Site LC Domain
LCDC4
Newly Purchased Company NA Domain
NADC1, NADC2, NADC3
We have established comms between LC and NA sites but the issue is that LCDC1,2 & 3 are on a subnet we are unable to route to NA. The only domain controller able to communicate with NA is at a remote site LCDC4. DNS (conditional forwarders) is up and working. Servers in all three locations can talk to each other (apart from LCDC1,2,3) DNS resolves to correct IP but obviously due to network comms they dont repond.
Therefore I have logged into LCDC4 and established a one way external trust to NA. Everything worked to a point. I was able to validate the trust on NADC1 but not on LCDC4. The error coming back is 'The secure channel (SC) reset on domain controller. LCDC1 There are currently no logon servers to service this request'.
Looks to me like LCDC1 is trying to validate the trust with NA site. Can I force trust comms only between LCDC4 and NA site? I've read a great blog post where someone had something similar but our setup only has LC and NA domains.
One way trust is all that's required. We just need to provide NA with LC resources. Currently I can login to an LC domain controller and see NA accounts so I can add to AD groups. I'm just worried that because LC can't verify something might go wrong in the future.
Please help!
All Replies
-
Sunday, March 10, 2013 8:13 PM
See this part:
"Both domains in a trust relationship share a password, which is stored in the TDO object in Active Directory. As part of the account maintenance process, every thirty days, the trusting domain controller changes the password stored in the TDO. Because all two-way trusts are actually two one-way trusts going in opposite directions, the process occurs twice for two-way trusts. A trust has a trusting and a trusted side. On the trusted side, any writable domain controller can be used for the process. On the trusting side, the PDC emulator performs the password change. To change a password, the domain controllers complete the following process:"
Reference: http://technet.microsoft.com/en-us/library/cc773178%28v=ws.10%29.aspx
Note that there is no trust relatioship between a domain and a DC. Trust relationships are created between domains or forests.
Also, read that: http://blogs.metcorpconsulting.com/tech/?tag=pdc-emulator
It should explain behaviors you have.
This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.
- Marked As Answer by Vivian_WangMicrosoft Contingent Staff, Moderator Friday, March 15, 2013 1:12 AM
-
Tuesday, March 12, 2013 12:16 AM
1.You can verify the trust when at least one trusted DC is reachable & all AD standard posrts should be opened. That DC should be reachable with own domain PDC with All AD standard ports.
2.DNS should be worked properly . You can test the dns with dcdiag /e /v /test:dns >> dns.txt
Regards
Biswajit Biswas
My Blogs|TechnetWiki NinjaBest regards Biswajit Biswas Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights. MCP 2003,MCSA 2003, MCSA:M 2003, CCNA, MCTS, Enterprise Admin

