none
Trusted domain authentication problem (with RODCs)

    Dotaz

  • We have the following setup.

    • DMZ network layer containing member servers and RODCs belonging to domain 'A'.
    • Internal network containing member servers and RWDCs for domain 'A' and RWDCs for domain 'B'.
    • Domain 'A' trusts domain 'B' (but not vice versa).
    • The firewalls currently allow domain 'A' member servers and RODCs in the DMZ network layer to talk to domain 'A' and domain 'B' RWDCs on the internal network, although this will be locked down in future.

    The problem is that we can log on to DMZ network member servers (via RDP) without any problems using domain 'A' credentials, but we cannot log on to these servers using credentials from the trusted domain 'B'. The error message is "The system cannot log you on due to the following error: The specified domain either does not exist or could not be contacted.".

    DNS is working ok, the domain 'A' member servers can see their own RODCs and their RWDCs and the RWDCs in domain 'B' through the firewalls. Also, we can log on to domain 'A' member servers on the internal network using domain 'B' trusted credentials without any problems.

    I assume that the authentication traffic flow when logging on to a member server using trusted domain credentials is as follows:

    1. User attempts to log on to DMZ network member server using trusted domain credentials.
    2. Authentication request is passed to RODC (the 'local' DC according to Sites & Services).
    3. The RODC sees the credentials are for the trusted domain so passes the request to one of the RWDCs.
    4. The RWDC then passes the request to a trusted domain RWDC for authentication.
    5. The trusted domain RWDC authenticates the user and passes the response back to the trusting domain RWDC.
    6. The trusting domain RWDC passes the successful request back to the RODC.
    7. The trusting domain RODC passes the request back to the server that then allows the trusted domain user to log on.

    Is this correct? What else (besides DNS and firewalls) should I be looking at to try and diagnose the problem?

    Many thanks.

    14. března 2012 16:03

Odpovědi

  • Since the member server and RODC are in DMZ and as you are aware that DMZ zone is isolated zone it is not possible to login to member server(DMZ) with trusted domainB credential.

    You can move the member server from DMZ zone to internal domainA n/w to have access(for trusted DomainB).

    OR you can put RWDC in DMZ zone and create trust with DomainB with required port open for communication but this will not make any sense.If RWDC is not placed in DMZ then it is not possible to create trust since with RODC trust cannot be created.


    Best Regards,

    Sandesh Dubey.

    MCSE|MCSA:Messaging|MCTS|MCITP:Enterprise Adminitrator | My Blog

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.

    14. března 2012 23:17
  • When you login to the RODC site using B user account, RODC forward this to the writable domain controller in its own domain and then writable domain controller makes it referral to the RWDC in B's domain and in turn via RWDC in domain A, rodc allows user to authenticate. RODC doesn't store trust password, so it has to contact RWDC to obtain referral ticket. Also, rodc can't issue kerberos ticket. The solution i can think of best over here is either introduce one more RODC or RWDC of the Domain B else its going to follow long chain and if there is some latency or network issue in contacting RWDC authentication will fail. I would suggest check the network(firewall port) and dns configuration.

    http://technet.microsoft.com/en-us/library/cc754218%28v=ws.10%29.aspx#BKMK_XDomAuthN

    Also, you can use wireshark or netmon tool to trace the packet.

    All About  (RODC) Read Only Domain Controllers

    http://awinish.wordpress.com/2011/10/04/rodc-read-only-domain-controller/


    Awinish Vishwakarma - MVP-DS

    My Blog: awinish.wordpress.com

    Disclaimer This posting is provided AS-IS with no warranties/guarantees and confers no rights.

    15. března 2012 4:35
    Moderátor

Všechny reakce

  • Since the member server and RODC are in DMZ and as you are aware that DMZ zone is isolated zone it is not possible to login to member server(DMZ) with trusted domainB credential.

    You can move the member server from DMZ zone to internal domainA n/w to have access(for trusted DomainB).

    OR you can put RWDC in DMZ zone and create trust with DomainB with required port open for communication but this will not make any sense.If RWDC is not placed in DMZ then it is not possible to create trust since with RODC trust cannot be created.


    Best Regards,

    Sandesh Dubey.

    MCSE|MCSA:Messaging|MCTS|MCITP:Enterprise Adminitrator | My Blog

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.

    14. března 2012 23:17
  • I would have agree with Sandesh, You have following 2 options:

    1. Move member server from DMZernal domain.
    2. Add RWDC in DMZ, open required ports and create trust with domain B. 

    Active Directory Firewall Ports - Let's Try To Make This Simple
    http://msmvps.com/blogs/acefekay/archive/2011/11/01/active-directory-firewall-ports-let-s-try-to-make-this-simple.aspx


    Best Regards,

    Abhijit Waikar.
    MCSA 2003 | MCSA:Messaging | MCTS | MCITP:Server Administrator | Microsoft Community Contributor | My Blog

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.

    14. března 2012 23:35
  • When you login to the RODC site using B user account, RODC forward this to the writable domain controller in its own domain and then writable domain controller makes it referral to the RWDC in B's domain and in turn via RWDC in domain A, rodc allows user to authenticate. RODC doesn't store trust password, so it has to contact RWDC to obtain referral ticket. Also, rodc can't issue kerberos ticket. The solution i can think of best over here is either introduce one more RODC or RWDC of the Domain B else its going to follow long chain and if there is some latency or network issue in contacting RWDC authentication will fail. I would suggest check the network(firewall port) and dns configuration.

    http://technet.microsoft.com/en-us/library/cc754218%28v=ws.10%29.aspx#BKMK_XDomAuthN

    Also, you can use wireshark or netmon tool to trace the packet.

    All About  (RODC) Read Only Domain Controllers

    http://awinish.wordpress.com/2011/10/04/rodc-read-only-domain-controller/


    Awinish Vishwakarma - MVP-DS

    My Blog: awinish.wordpress.com

    Disclaimer This posting is provided AS-IS with no warranties/guarantees and confers no rights.

    15. března 2012 4:35
    Moderátor
  • Many thanks for the replies.

    Awinish, thanks for the link - it confirms what we understood in that the Microsoft article states "Authentication: If the RODC can communicate with a writable domain controller, any user from a trusted domain can successfully authenticate to the RODC. If the RODC cannot communicate with a writable domain controller, only those accounts that exist in the same domain as the RODC have the ability to be authenticated by the RODC.". The long-term plan is that the RODCs in the DMZ will be allowed to communicate with their RWDCs on the internal network, but all the other member servers in the DMZ will only be able to communicate with the RODCs. 

    As I mentioned, while the setup is being tested, the firewalls are actually open, so DMZ network member servers can actually see their own DMZ network RODCs, their internal RWDCs and RWDCs belonging to the trusted domain. However despite this we are seeing authentication failure on the DMZ member servers when using trusted domain credentials. What is strange is that we can actually log on to the RODCs in the DMZ using trusted domain credentials without any problem, so it's only the member servers that have the issue.

    15. března 2012 12:12
  • I guess, you can use tool like wireshark/Netmon to see what is happening in the background and where actually problem lies.

    Awinish Vishwakarma - MVP-DS

    My Blog: awinish.wordpress.com

    Disclaimer This posting is provided AS-IS with no warranties/guarantees and confers no rights.

    15. března 2012 12:20
    Moderátor
  • After a bit more investigation, it has been confirmed that DNS appears to be fine and no network traffic is being dropped at the firewalls.

    What is very interesting is that the problem is confined to Windows Server 2003/2003 R2 member servers only. So, if the user logs on to a Windows Server 2008/2008 R2 member server using trusted domain credentials, authentication works fine. If they attempt to log on to a 2003/2003 R2 member server with the exact same trusted domain credentials, then authentication fails with the message that the (trusted) domain doesn't exist or can't be contacted. This would suggest that a difference between the authentication mechanism between 2003/R2 and 2008/R2 is the cause of the problem, but I thought Kerberos v5 was used for both? 

    25. března 2012 13:56
  • Have you deployed compatibility pack for the windows 2003/XP/Vista to be compatible with RODC.

    http://support.microsoft.com/kb/944043

    http://technet.microsoft.com/en-us/library/cc725669.aspx

    http://policelli.com/blog/archive/2008/12/05/windows-server-2008-rodc-compatibility-pack-for-windows-server-2003-clients-and-for-windows-xp-clients/


    Awinish Vishwakarma - MVP-DS

    My Blog: awinish.wordpress.com

    Disclaimer This posting is provided AS-IS with no warranties/guarantees and confers no rights.

    26. března 2012 8:55
    Moderátor
  • Yes, the RODC compatibility pack has been deployed on affected servers but it has not corrected the problem.

    A further observation - most of these servers are virtual (running under VMware ESX). Logging on to the server with trusted domain credentials via the VM Console is successful. It's only when attempting to log on via RDP that the 'Domain does not exist or could not be contacted' message appears. There are no GPOs restricting RDP access to these servers and RDP logon to Windows 2000 and Windows 2008 servers on the same network via RDP using trusted credentials works fine.

    Very baffling!

    28. března 2012 11:47