Creating and managing trust relationships

1.Creating and managing trust relationships #

Active Directory Trust relation ships

Creating and managing trust relationships

Determine what kind of trust you should use

Parent-Child Trust

Tree-Root Trust

External Trust

Realm Trust

Forest Trust

Shortcut Trust

Get familiar with the Active Directory Domains And Trusts Console

Know the tools

Set up a test environment

Review privileges

Map out the trusts

Document trust relationships 8

Avoid making trust relationships too deep

Know how to manage different versions of Windows

Remove expired or overlapping trusts

The existing configuration

2 way trust with selective authentication

To configure selective authentication on an existing trust

To configure selective authentication during the creation of a new trust

Adding more or less Suffix to log on

Conditional Forwarders DNS server for name Resolving

Get trust configuration Topology with PowerShell

Creating and managing trust relationships

Domain trusts can be complicated to administer, and it is important to implement changes correctly the first time. Here are some key points to keep in mind to help ensure that your trusts are configured effectively with a minimum of headaches.

Determine what kind of trust you should use

Before deploying a domain trust, you should ensure that the type(s) used are correct for the tasks. Consider the following dimensions of a trust:

Type: Identifies the types of domains involved in trust(s).

Transitivity: Determines whether one trust can let a trusted domain pass through to a third domain.

Direction: Identifies the direction of access and trust (trusted accounts and trusting resources).

https://tr1.cbsistatic.com/hub/i/2015/06/03/3722dbf3-0988-11e5-940f-14feb5cc3d2a/trusts_a.jpg

Parent-Child Trust

A transitive, two-way parent-child trust relationship automatically created and establishes a relationship between a parent domain and a child domain whenever a new child domain is created using the AD DS installation process process within a domain tree. They can only exist between two domains in the same tree with the same contiguous namespace. The parent domain is always trusted by the child domain. You cannot manually create a Parent-Child trust.

Tree-Root Trust

A transitive, two-way tree-root trust relationship automatically created and establishes a relationship between the forest root domain and a new tree, when you run the AD DS installation process to add a new tree to the forest. A tree-root trust can only be established between the roots of two trees in the same forest and are always transitive. You cannot manually create a tree-root trust.

 

External Trust

An external trust is a one-way, non-transitive trust that is manually created to establish a trust relationship between AD DS domains that are in different forests, or between an AD DS domain and Windows NT 4.0 domain. External trusts allow you to provide users access to resources in a domain outside of the forest that is not already trusted by a Forest trust.

SID filter quarantining is enabled by default with Windows Server 2003 and newer AD DS domains. SID filtering verifies that incoming authentication requests made from security principals in the trusted domain contain only SIDs of security principals from the trusted domain.

External trusts are NTLM based, meaning users must authenticate using the Pre-Windows 2000 logon method (domain\username).NTLM requires NetBIOS name resolution support for functionality.

 

 

Realm Trust

A Realm trust can be established to provide resource access and cross-platform inter-operability between an AD DS domain and non-Windows Kerberos v5 Realm.

A Realm trust only uses Kerberos V5 authentication. NTLM is not used.

When the direction of the trust is from a non-Windows Kerberos Realm to an AD DS domain (Realm trusts AD DS domain), the non-Windows realm trusts all security principals in the AD DS domain.

Realm trusts are one-way by default, but you can create a trust in the other direction to allow two-way access.

Because non-Windows Kerberos tickets do not contain all the information AD DS requires, the AD DS domain only uses the account to which the proxy account (the non-Windows principal) is mapped to evaluate access requests and authorization. With Realm trusts, all AD DS domain proxy accounts can be used in an AD DS group in ACLs to control access for non-Windows accounts.

 

 

Forest Trust

Forest trusts are manually created, one-way transitive, or two-way transitive trusts that allow you to provide access to resources between multiple forests. Forest trusts uses both Kerberos v5 and NTLM authentication across forests where users can use their Universal Principal Name (UPN) or their Pre-Windows 2000 method (domainName\username). Kerberos v5 is attempted first, and if that fails, it will then try NTLM.

 

Shortcut Trust

Shortcut trusts are manually created, one-way, transitive trusts. They can only exist within a forest. They are created to optimize the authentication process shortening the trust path. The trust path is the series of domain trust relationships that the authentication process must traverse between two domains in a forest that are not directly trusted by each other. Shortcut trusts shorten the trust path.

Get familiar with the Active Directory Domains And Trusts Console

Trust relationships are managed via the Active Directory Domains And Trusts Console. It lets you perform these basic tasks:

  • Raise domain functional level
  • Raise forest functional level
  • Add UPN suffixes
  • Manage domain trust
  • Manage forest trust

Know the tools

As with most other elements of the Windows Server family, command-line tools can be used to script repetitive tasks or to ensure consistency in the case of trust creation. Some of the top tools include:

NETDOM: Used to establish or break trust types.

NETDIAG: The output of this tool can give basic status on trust relationships.

NLTEST: Can be used to verify a trust relationship.

You can also use Windows Explorer to view membership to shared resources as they are assigned from trusted domains and/or forests. Active Directory Users And Computers can also provide membership details of Active Directory Objects that have members from trusted domains and/or forests.

Set up a test environment

Depending on your environment and usage requirements, a simple mishap in the creation of domain trusts can have enterprise-wide repercussions. But it’s difficult to set up a completely similar test environment to replicate multi-domain and forest issues. Having similar domain scenarios is easier to facilitate, as a means to reinforce the principles and test basic functionality. Consider also template Active Directory objects to test on the live domain relationships to ensure that the desired functionality is obtained but not exceeded before using live groups, accounts, and other objects.

Review privileges

When trusts are created, it’s important to ensure that the desired functionality is achieved. But be sure to review the configured trust to verify that the direction of access is correct. For example, if domain A needs to access only a limited amount of resources on domain B; a two-way trust would suffice. However, an administrator from domain B may be able to assign access to resources on domain A. Ensuring the desired direction, type, and transitivity of trusts is critical.

Map out the trusts

Create a map of trusts with simple arrows and boxes illustrating which domains will be trusting and trusted and which trusts will be 1-way and 2-way. Then, with the simple picture(s) in place, map out which domains will trust which—and determine the transitivity as well. This simple chart will make more sense of the greater task at hand and allow you to determine which domains need direction of access and in which direction. Some domains will simply act as a gateway for transitive access to other domains.

Document trust relationships

As organizations marry (and divorce) in today’s business world, it’s important to have clear documentation of the trust inventory—and to make sure it’s accessible without the trust or domain. For example, if you’re in Domain B and your headquarters in Domain A sells your division and breaks your trust, your concise documentation saved on a server in Domain A does you little good. Document the type of trust, transitivity, direction, business need for the trust, anticipated duration of the trust, credentials, domain/forest principal information (name, DNS, IP addresses, locations, computer names, etc.), and contact person(s) for the corresponding domains.

Avoid making trust relationships too deep

In the interest of everyone’s time, don’t nest membership more than one deep when using trusts in multiple domains and forests. Nesting membership can consolidate the number of manageable Active Directory objects, but determining actual membership administration is greatly increased.

Know how to manage different versions of Windows

When running in Windows 2000 and Windows Server 2003 native mode for Active Directory, full functionality is maintained for member domains and forests. If any NT domains or member systems are present in the enterprise, their trust entry functionality is limited by the inability to recognize the Active Directory objects. A frequent strategy in this scenario is to have “domain islands” of those that don’t connect to the more common enterprise infrastructure.

Remove expired or overlapping trusts

Changes in business organization may have left unused trusts in place on your domain. Clear out any trusts that are not actively being used. You should also ensure that the trusts you have are set up correctly for the required access and usage patterns. An audit of your trust inventory can be a strong supplement to your well-rounded security policy.

On the second tab Trust you will find:

Domain trusted by this domain (outgoing trust)

Domains that will trust this domain (incoming trust)

Domain trusted by this domain (outgoing trust)

I give you my car keys to use my car, I trust you to use my car.

Domains that will trust this domain (incoming trust)

I got the Car keys from you, thanks that you trust me so I can use your car.

The existing configuration.

When we click on the properties of the trust we see the:

2 way trust with selective authentication

We use a Forest 2 way trust, which means we trust each other for all domains.

However, when user or groups or computers need to access a resource (computer/server) we need to give this Resource extra rights to access it.

This is due the setting Selective authentication.

To configure selective authentication on an existing trust

Open the Active Directory Domains and Trusts snap-in.

Right click the domain that you wish to configure and click ‘Properties’.

Click on the ‘Trusts’ tab.

Select the trust you wish to configure and click the ‘Properties’ button.

Click the ‘Authentication’ Tab and then click the ‘Selective Authentication’ radio button.

Click ‘OK’.

To configure selective authentication during the creation of a new trust

Open the Active Directory Domains and Trusts snap-in.

Right click the domain that you wish to configure and click ‘Properties’.

Click on the ‘New Trust’ button.

While you are walking through the New Trust Wizard, you will be prompted for the authentication type. Select ‘Selective Authentication’ and finish the setup.

Take note, if you do not see the Selective Authentication option during the trust creation or you cannot select it from the ‘Authentication’ tab, it is most likely that the functional level of your domain is not set to 2003 or better.

The last step in this process is to create a Domain Local Group in which you wish to add users from the trusted domain. The users added to this group will be allowed to authenticate to specific computers/servers. After the group is created:

Open the “Active Directory Users and Computers snap-in.

Navigate the tree and locate the specific computer/server that you with to grant access to.

Right click on the computer/server object and choose ‘Properties’.

Click on the ‘Security’ tab.

Click the ‘add’ button and search and select the Domain Local Group that you have just created.

Once back at the ‘Security’ tab screen, in the lower half, find the “Allowed to Authenticate’ permission and check the ‘Allow’ box.

Click “Apply’/’OK’.

Adding more or less Suffix to log on.

To add a domain suffix open active directory Domains and Trust.

Right click Active directory Domains and trust ( srvhhwmo.paramelt.com)

After editing a new name suffix it can be seleted to use for an additional login naming suffix.

n the dialog box on the UPN Suffixes tab, type the name of the suffix that you would like to add to your AD forest in the Alternate UPN suffixes box. Click Add and then OK.

Close the Active Directory Domains and Trusts console.

Now when you add a new user account to Active Directory, you should see the new UPN suffix available in the list when setting the username.

Conditional Forwarders DNS server for name Resolving

Before we can talk or resolve naming in the other domain we need to set the DNS to forward DNS queries tot he trusted domain.

All DNS servers within Paramelt are active directory integrated and replicate all with each other.

To setup DNS Conditional forwarding to the external domain (in this case tergroup.net) open the DNS manager on the SRVHHWDC (or another within Paramelt).

Scroll to Conditional Forwarders and add the DNS server ip addresses to forward the request to.

Below steps:

Right click Conditional Forwarders and choose New.

Type in the Domain name, type one or more IP addresses that contains DNS servers.

Tick, “Store this conditional forwarder in Active Directory, and replicate it’s follows.

Choose All DNS Servers in this Domain (at least if we want that for the specified situation)

 

 

Help Guide Powered by Documentor
Suggest Edit