locked
Forest Trust - Authentication problems RRS feed

  • Question

  • We currently have an external two-way trust between two domains (let's call them DomA.local and DomB.local) . Those domains are the only one in their respective forests.  Trust is used to access network shares and everything works fine. As we are planning to introduce a subdomain in one of the forest we changed the trust to Forest Trust and enabled name suffix routing. The problem is that users cannot access anymore the shares with their account and they have to specify it as  domA.local\username in order to access the share

    Are we missing a step in configuration ?

    Thanks

    Friday, February 15, 2013 9:05 PM

Answers

  • What I beliece is happening is due to the multiple domains in the forest, the authentication path must use the trust path, so the user needs to identify the domain, whether in netbiosDomName\user or the UPN (user@domain.local). For forest based trusts uses Kerberos, but Kerberos does not rely on Pass-through, rather it contacts the KDC of each domain in the trust path requesting a WT (workstation ticket) from the KDC's TGT (ticket granting ticket service), which is presented to the next KDC TGT for a WT for a resources in that domain or the next domain in the trust path, etc).

    Accessing resources across domains [and trusts]
     http://technet.microsoft.com/en-us/library/cc787646(v=ws.10).aspx

    .

    Accessing resources across forests
    "When two Windows Server 2003 forests are connected by a forest trust, authentication requests made using the Kerberos V5 or NTLM protocols can be routed between forests to provide access to resources in both forests. For more information about routing authentication requests across forests, see Routing name suffixes across forests(http://technet.microsoft.com/en-us/library/cc784334(v=ws.10).aspx)."
    "[...] When a forest trust is first established, each forest collects all of the trusted namespaces in its partner forest and stores the information in aTDO. (TDO explained here:http://technet.microsoft.com/en-us/library/cc786873(v=ws.10).aspx). Trusted namespaces include domain tree names, user principal name (UPN) suffixes, service principal name (SPN) suffixes, and security ID (SID) namespaces used in the other forest. TDO objects are replicated to the global catalog. For more information about TDOs, see Trusts: (http://technet.microsoft.com/en-us/library/cc786873(v=ws.10).aspx)"
    http://technet.microsoft.com/en-us/library/cc772808(v=ws.10).aspx

    .

    Name Suffix Routing
    I recently encountered an issue where authentication was failing across numerous forests after a second kerberos trust was made with a forest. Unlike most implementations of Active Directory which have a forest root and child domains that share a common DNS Namespace hierarchy, this customer had several forests sharing the same DNS Namespace, with CONTOSO.COM being the root of the DNS tree.
    http://blogs.technet.com/b/askds/archive/2009/04/10/name-suffix-routing.aspx


    Ace Fekay
    MVP, MCT, MCITP/EA, MCTS Windows 2008/R2 & Exchange 2007, Exchange 2010 EA, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Technical Blogs & Videos: http://www.delawarecountycomputerconsulting.com/

    This post is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    • Proposed as answer by VenkatSP Saturday, February 16, 2013 6:35 AM
    • Marked as answer by Cicely Feng Friday, March 1, 2013 8:56 AM
    Saturday, February 16, 2013 2:00 AM
  • In addition,

    1. Need to check all AD standard port should be open 

    Below ports should be opened in all the DCs for AD/DNS.

    Service

    Port/protocol

    RPC endpoint   mapper

    135/tcp, 135/udp

    Network basic   input/output system (NetBIOS) name service

    137/tcp, 137/udp

    NetBIOS datagram   service

    138/udp

    NetBIOS session   service

    139/tcp

    RPC dynamic   assignment

    Win   2k/2003:1024-65535/tcp
      Win 2008+:49152-65535/tcp

    Server message   block (SMB) over IP (Microsoft-DS)

    445/tcp, 445/udp

    Lightweight   Directory Access Protocol (LDAP)

    389/tcp

    LDAP ping

    389/udp

    LDAP over SSL

    636/tcp

    Global catalog   LDAP

    3268/tcp

    Global catalog   LDAP over SSL

    3269/tcp

    Kerberos

    88/tcp, 88/udp

    Domain Name   Service (DNS)

    53/tcp1, 53/udp

    Use port query for that.
    http://www.microsoft.com/en-in/download/details.aspx?id=17148 

    2. Check the DNS

    You can use NSLOOKUP for DNS troubleshooting. See the below example.
    cmd---nslookup
    set q=srv
    _ldap._tcp.dc._msdcs.trusteddomain.com
    _ldap._tcp.gc._msdcs.trusteddomain.com
    _ldap._tcp.pdc._msdcs.trusteddomain.com
    _ldap._tcp.dc._msdcs.trustingdomain.com
    _ldap._tcp.gc._msdcs.trustingdomain.com
    _ldap._tcp.pdc._msdcs.trustingdomain.com

    3. Rebuild the trust (If possible create the trust between PDC; Also need to select the authentication type forest wide)

    4. Known issue for creating the trust.

    Review the following known issues before creating domain and forest trusts in Windows Server 2008:

    <> You cannot delegate the creation of trusts to any user who is not a member of the Domain Admins group or the Enterprise Admins group. Even though you can grant a user the Create TDO (Trusted Domain Object) right or the Delete TDO right in the System container of a domain, the user will not be granted the right to create a trust. This issue occurs because Netlogon and the trust-creation tools (Active Directory Domains and Trusts and Netdom) are designed so that only members of the Domain Admins group and the Enterprise Admins group can create trusts. However, any user who is a member of the Incoming Forest Trust Builders group can create one-way, incoming forest trusts to your forest.

    <> When you are logged on locally to a domain controller and you try to create a new trust by using Active Directory Domains and Trusts, the operation may be unsuccessful and you may receive the message “Access denied.” This issue occurs only if you are logged on locally to the domain controller as an ordinary user (that is, you are not logged on as Administrator or as a member of any administrative groups for the domain). By default, ordinary users are blocked from logging on locally to a domain controller unless Group Policy is modified to permit this.

    <> When you use the Active Directory Domains and Trusts snap-in to create a trust, you may receive the message “Operation failed. Parameter incorrect.” This issue may occur if you try to establish a trust relationship when the source domain and the target domain have one or more of the following identifiers that are the same:

    <> Security identifier (SID)

    <> Domain Name System (DNS) name

    <> NetBIOS name

    To resolve this issue, do one of the following before you try to create the trust, as appropriate to your situation:

    <> Rename the conflicting identifier.

    <> Use a fully qualified domain name (FQDN) if there is a NetBIOS conflict.

    <> The option to create a forest trust may not appear in the New Trust Wizard. This issue typically occurs when one or both of the Windows Server 2008 forests are not set to the Windows Server 2003 forest functional level or higher. For more information about forest functional levels, see Active Directory Functional Levels Technical Reference (http://go.microsoft.com/fwlink/?LinkId=111466

    <> You cannot create a trust relationship with a Microsoft Windows Small Business Server 2003 (Windows SBS) domain. For information about Windows SBS software, see Introduction to Windows Small Business Server 2003 for Enterprise IT Pros (

    http://go.microsoft.com/fwlink/?LinkId=121891


    Regards
    Biswajit Biswas
    My Blogs|MCC|TNWiki 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



    • Edited by bshwjt Saturday, February 16, 2013 3:30 AM
    • Marked as answer by Cicely Feng Friday, March 1, 2013 8:56 AM
    Saturday, February 16, 2013 3:28 AM

All replies

  • What I beliece is happening is due to the multiple domains in the forest, the authentication path must use the trust path, so the user needs to identify the domain, whether in netbiosDomName\user or the UPN (user@domain.local). For forest based trusts uses Kerberos, but Kerberos does not rely on Pass-through, rather it contacts the KDC of each domain in the trust path requesting a WT (workstation ticket) from the KDC's TGT (ticket granting ticket service), which is presented to the next KDC TGT for a WT for a resources in that domain or the next domain in the trust path, etc).

    Accessing resources across domains [and trusts]
     http://technet.microsoft.com/en-us/library/cc787646(v=ws.10).aspx

    .

    Accessing resources across forests
    "When two Windows Server 2003 forests are connected by a forest trust, authentication requests made using the Kerberos V5 or NTLM protocols can be routed between forests to provide access to resources in both forests. For more information about routing authentication requests across forests, see Routing name suffixes across forests(http://technet.microsoft.com/en-us/library/cc784334(v=ws.10).aspx)."
    "[...] When a forest trust is first established, each forest collects all of the trusted namespaces in its partner forest and stores the information in aTDO. (TDO explained here:http://technet.microsoft.com/en-us/library/cc786873(v=ws.10).aspx). Trusted namespaces include domain tree names, user principal name (UPN) suffixes, service principal name (SPN) suffixes, and security ID (SID) namespaces used in the other forest. TDO objects are replicated to the global catalog. For more information about TDOs, see Trusts: (http://technet.microsoft.com/en-us/library/cc786873(v=ws.10).aspx)"
    http://technet.microsoft.com/en-us/library/cc772808(v=ws.10).aspx

    .

    Name Suffix Routing
    I recently encountered an issue where authentication was failing across numerous forests after a second kerberos trust was made with a forest. Unlike most implementations of Active Directory which have a forest root and child domains that share a common DNS Namespace hierarchy, this customer had several forests sharing the same DNS Namespace, with CONTOSO.COM being the root of the DNS tree.
    http://blogs.technet.com/b/askds/archive/2009/04/10/name-suffix-routing.aspx


    Ace Fekay
    MVP, MCT, MCITP/EA, MCTS Windows 2008/R2 & Exchange 2007, Exchange 2010 EA, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Technical Blogs & Videos: http://www.delawarecountycomputerconsulting.com/

    This post is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    • Proposed as answer by VenkatSP Saturday, February 16, 2013 6:35 AM
    • Marked as answer by Cicely Feng Friday, March 1, 2013 8:56 AM
    Saturday, February 16, 2013 2:00 AM
  • In addition,

    1. Need to check all AD standard port should be open 

    Below ports should be opened in all the DCs for AD/DNS.

    Service

    Port/protocol

    RPC endpoint   mapper

    135/tcp, 135/udp

    Network basic   input/output system (NetBIOS) name service

    137/tcp, 137/udp

    NetBIOS datagram   service

    138/udp

    NetBIOS session   service

    139/tcp

    RPC dynamic   assignment

    Win   2k/2003:1024-65535/tcp
      Win 2008+:49152-65535/tcp

    Server message   block (SMB) over IP (Microsoft-DS)

    445/tcp, 445/udp

    Lightweight   Directory Access Protocol (LDAP)

    389/tcp

    LDAP ping

    389/udp

    LDAP over SSL

    636/tcp

    Global catalog   LDAP

    3268/tcp

    Global catalog   LDAP over SSL

    3269/tcp

    Kerberos

    88/tcp, 88/udp

    Domain Name   Service (DNS)

    53/tcp1, 53/udp

    Use port query for that.
    http://www.microsoft.com/en-in/download/details.aspx?id=17148 

    2. Check the DNS

    You can use NSLOOKUP for DNS troubleshooting. See the below example.
    cmd---nslookup
    set q=srv
    _ldap._tcp.dc._msdcs.trusteddomain.com
    _ldap._tcp.gc._msdcs.trusteddomain.com
    _ldap._tcp.pdc._msdcs.trusteddomain.com
    _ldap._tcp.dc._msdcs.trustingdomain.com
    _ldap._tcp.gc._msdcs.trustingdomain.com
    _ldap._tcp.pdc._msdcs.trustingdomain.com

    3. Rebuild the trust (If possible create the trust between PDC; Also need to select the authentication type forest wide)

    4. Known issue for creating the trust.

    Review the following known issues before creating domain and forest trusts in Windows Server 2008:

    <> You cannot delegate the creation of trusts to any user who is not a member of the Domain Admins group or the Enterprise Admins group. Even though you can grant a user the Create TDO (Trusted Domain Object) right or the Delete TDO right in the System container of a domain, the user will not be granted the right to create a trust. This issue occurs because Netlogon and the trust-creation tools (Active Directory Domains and Trusts and Netdom) are designed so that only members of the Domain Admins group and the Enterprise Admins group can create trusts. However, any user who is a member of the Incoming Forest Trust Builders group can create one-way, incoming forest trusts to your forest.

    <> When you are logged on locally to a domain controller and you try to create a new trust by using Active Directory Domains and Trusts, the operation may be unsuccessful and you may receive the message “Access denied.” This issue occurs only if you are logged on locally to the domain controller as an ordinary user (that is, you are not logged on as Administrator or as a member of any administrative groups for the domain). By default, ordinary users are blocked from logging on locally to a domain controller unless Group Policy is modified to permit this.

    <> When you use the Active Directory Domains and Trusts snap-in to create a trust, you may receive the message “Operation failed. Parameter incorrect.” This issue may occur if you try to establish a trust relationship when the source domain and the target domain have one or more of the following identifiers that are the same:

    <> Security identifier (SID)

    <> Domain Name System (DNS) name

    <> NetBIOS name

    To resolve this issue, do one of the following before you try to create the trust, as appropriate to your situation:

    <> Rename the conflicting identifier.

    <> Use a fully qualified domain name (FQDN) if there is a NetBIOS conflict.

    <> The option to create a forest trust may not appear in the New Trust Wizard. This issue typically occurs when one or both of the Windows Server 2008 forests are not set to the Windows Server 2003 forest functional level or higher. For more information about forest functional levels, see Active Directory Functional Levels Technical Reference (http://go.microsoft.com/fwlink/?LinkId=111466

    <> You cannot create a trust relationship with a Microsoft Windows Small Business Server 2003 (Windows SBS) domain. For information about Windows SBS software, see Introduction to Windows Small Business Server 2003 for Enterprise IT Pros (

    http://go.microsoft.com/fwlink/?LinkId=121891


    Regards
    Biswajit Biswas
    My Blogs|MCC|TNWiki 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



    • Edited by bshwjt Saturday, February 16, 2013 3:30 AM
    • Marked as answer by Cicely Feng Friday, March 1, 2013 8:56 AM
    Saturday, February 16, 2013 3:28 AM