none
Unable to verify domain trust on one side of the trust (not all DCs can ping) HELP!!

    질문

  • 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!

    2013년 3월 8일 금요일 오후 12:56

답변

  • 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.

    2013년 3월 10일 일요일 오후 8:13

모든 응답

  • 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.

    2013년 3월 10일 일요일 오후 8:13
  • 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 Ninja


    Best 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

    2013년 3월 12일 화요일 오전 12:16