Archive for September 2013

Using Trusts in Windows environments

untitled

What is a Trust?

A trust is a relationship, which you establish between domains, that makes it possible for users in one domain to be authenticated by a domain controller in the other domain.

By using Windows Server 2008 domain and forest trusts, service administrators can create or extend collaborative relationships between two or more domains or forests. Windows Server 2008 domains and forests can also trust Kerberos realms and other Windows Server 2008 forests, as well as Windows Server 2003 domains, Microsoft® Windows® 2000 Server domains, and Microsoft Windows NT® Server 4.0 domains.

When a trust exists between two domains, the authentication mechanisms for each domain trust the authentications coming from the other domain. Trusts help to provide controlled access to shared resources in a resource domain (the trusting domain) by verifying that incoming authentication requests come from a trusted authority (the trusted domain). In this way, trusts act as bridges that allow only validated authentication requests to travel between domains.

How a specific trust passes authentication requests depends on how it is configured. Trust relationships can be one-way, providing access from the trusted domain to resources in the trusting domain, or two-way, providing access from each domain to resources in the other domain. Trusts are also either nontransitive, in which case a trust exists only between the two trust partner domains, or transitive, in which case a trust automatically extends to any other domains that either of the partners trusts.

In some cases, trust relationships are established automatically when domains are created. In other cases, administrators must choose a type of trust and explicitly establish the appropriate relationships. The specific types of trusts that are used and the structure of the resulting trust relationships in a given trust implementation depend on such factors as how Active Directory Domain Services (AD DS) is organized and whether different versions of Windows coexist on the network.

The key thing to remember is that the direction of trust is the opposite to the direction of access. An outgoing trust allows incoming access and an incoming trust allows outgoing access

Trusts

Trust Directions

One-way: incoming

Use this option when you want to allow authentication requests to be routed from your domain or forest (referred to as “this domain” or “this forest” in the wizard) to resources residing in a second domain or forest (referred to as “specified domain” or “specified forest” in the wizard). “One-way” in One-way: incoming means that this selection will create a one-way trust that can route authentications to resources in only one direction, while user access to those resources flows in the other direction. “Incoming” in One-way: incoming refers to the direction of the trust itself, not the direction in which authentication requests will flow. In other words, as shown in the following illustration, a “one-way incoming trust” means that your domain or forest will be the domain or forest that receives access to the resources in the other domain.

Oneway

One way:Outgoing

Use this option when you want to allow authentication requests to be routed to your domain or forest (referred to as “this domain” or “this forest” in the wizard) from users residing in a second domain or forest (referred to as “specified domain” or “specified forest” in the wizard). “One-way” in One-way: outgoing means that this selection will create a one-way trust that can route authentications to resources in only one direction, while user access to those resources flows in the other direction. “Outgoing” in One-way: outgoing refers to the direction of the trust itself, not the direction in which authentication requests will flow. In other words, as shown in the following illustration, a “one-way, outgoing trust” means that your domain or forest will provide access to resources that are located in your domain to users who are located in the other domain or forest.

1wayoutgoing

Types of Trust

wintrusts

When to create an external trust

You can create an external trust to form a one-way or two-way, nontransitive trust with domains that are outside your forest. External trusts are sometimes necessary when users need access to resources in a Windows NT 4.0 domain or in a domain that is located in a separate forest that is not joined by a forest trust

When to create a shortcut trust

Shortcut trusts are one-way or two-way, transitive trusts that administrators can use to optimize the authentication process.

Authentication requests must first travel a trust path between domain trees. In a complex forest this can take time, which you can reduce with shortcut trusts. A trust path is the series of domain trust relationships that authentication requests must traverse between any two domains. Shortcut trusts effectively shorten the path that authentication requests travel between domains that are located in two separate domain trees

When to create a realm trust

You can establish a realm trust between any non-Windows Kerberos version 5 (V5) realm and an Active Directory domain. This trust relationship allows cross-platform interoperability with security services that are based on other versions of the Kerberos V5 protocol, for example, UNIX and MIT implementations. Realm trusts can switch from nontransitive to transitive and back. Realm trusts can also be either one-way or two-way.

When to create a forest trust

You can create a forest trust between forest root domains if the forest functional level is Windows Server 2003 or higher. Creating a forest trust between two root domains with a forest functional level of Windows Server 2003 or higher provides a one-way or two-way, transitive trust relationship between every domain in each forest.  Forest trusts are useful for application service providers, organizations undergoing mergers or acquisitions, collaborative business extranets, and organizations seeking a solution for administrative autonomy.

Using one-way, forest trusts

A one-way, forest trust between two forests allows members of the trusted forest to use resources that are located in the trusting forest. However, the trust operates in only one direction. For example, when a one-way, forest trust is created between forest A (the trusted forest) and forest B (the trusting forest), members of forest A can access resources that are located in forest B, but members of forest B cannot access resources that are located in forest A, using the same trust.

Using two-way, forest trusts

A two-way, forest trust between two forests allows members from either forest to use resources that are located in the other forest, and domains in each respective forest trust domains in the other forest implicitly. For example, when a two-way, forest trust is established between forest A and forest B, members of forest A can access resources that are located in forest B, and members of forest B can access resources in forest A, using the same trust.

Checklist for creating Trusts

  1. Ensure that DNS is set up properly.
  2. If there is a root DNS server that can be the root DNS server for both of the forest DNS namespaces, make it the root server by ensuring that the root zone contains delegations for each of the DNS namespaces. Also, update the root hints of all DNS servers with the new root DNS server
  3. If there is no shared root DNS server and the root DNS servers for each forest DNS namespace are running a Windows Server operating system, configure DNS conditional forwarders in each DNS namespace to route queries for names in the other namespace.
  4. If there is no shared root DNS server and the root DNS servers for each forest DNS namespace are not running a Windows Server operating system, configure DNS secondary zones in each DNS namespace to route queries for names in the other namespace.
  5. Create the forest trust.

Permissions

Permissions required to create trusts is domain admin or enterprise admin group.

What tool do you use to create Trusts?

You can use the Active Directory Domains and Trusts snap-in to create trust relationships between domains by going Start > All Programs > Administrative Tools > Active Directory Domains and Trusts. Membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum required to complete this procedure.

Creating a Forest Trust

  • Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts in Windows Server® 2012, click Start , type domain.msc

Trust1

  • In the console tree, right-click the domain that you want to administer, and then click Properties. Check your Domain and Forest Functional Level

Trust2

  • Click Trusts

Trust3

  • On the Trusts tab, click New trust, and then click Next

Trust4

  • On the Trust Name page, type the Domain Name System (DNS) name (or NetBIOS name) of the domain, and then click Next

Trust5

On the Trust Type page, click Forest trust, and then click Next

Trust6

  • Choose the Direction of the trust

Trust7

  • Next you will need to create the sides of the trust relationship

Trust9

  • Specify the user name and password of the Active Directory domain administrator, then click Next.

Trust10

  • Select Forest-wide authentication to authorize users to use resources in the local forest or those identified by the administrator, then click Next.

Trust11

  • Select Forest-wide authentication to authenticate Active Directory forest users to use resources in the forest or those identified by the administrator, then click Next.

Trust12

  • Trust creation complete. Review your settings

Trust13

  • Confirm Outgoing Trust

trust14

  • Confirm Incoming Trust

Trust15

  • Complete the new trust wizard

Trust16

Verifying the Trust

To verify that the DNS configuration is correct there are several commands you can run in a command prompt or Firewall.

  • nslookup
  • netdom
  • nltest

nltest

Common ports which need to be open for trusts to work

  • 123/UDP  – W32Time
  • 135/TCP  – RPC Endpoint Mapper
  • 464 – Kerberos password change
  • 49152-65535/TCP  – RPC for LSA, SAM, Netlogon (*)
  • 389/TCP/UDP – LDAP
  • 636/TCP  – LDAP SSL
  • 3268/TCP – LDAP GC
  • 3269/TCP – LDAP GC SSL
  • 53/TCP/UDP – DNS
  • 49152 -65535/TCP – FRS RPC (*)
  • 88/TCP/UDP – Kerberos
  • 445/TCP – SMB
  • 49152-65535/TCP  – DFSR RPC (*)

(*) For information about how to define RPC server ports that are used by the LSA RPC services, see the following Microsoft Knowledge Base articles:

Port Query Tool

Microsoft do a port query tool which is really useful for checking connectivity

http://www.microsoft.com/en-us/download/confirmation.aspx?id=24009

Portquerying