Forest Trust - Authentication problems

Answers

• 

  

  1

  Sign in to vote

  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.

  

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

  

  0

  Sign in to vote

  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