What Services Require A Two-way Trust Aws

Many Amazon Spider web Services (AWS) customers employ Active Directory to centralize user authentication and authorization for a variety of applications and services. For these customers, Active Directory is a critical piece of their Information technology infrastructure. AWS offers AWS Directory Service for Microsoft Agile Directory, as well known as AWS Managed Microsoft AD, to provide a highly available and resilient Active Directory service.

One of the near mutual AWS Managed Microsoft AD utilise cases is for customers who need to integrate their on-bounds Active Directory domain or forest with AWS services like Amazon Relational Database Service (Amazon RDS), Amazon FSx, Amazon WorkSpaces, and other AWS applications and services. This type of integration can crave a trust human relationship. When it comes to trusts, there are some mutual misconceptions about what happens and doesn't happen when a trust is created.

In this post, I'grand going to dive deep into various aspects of Agile Directory trusts and debunk some common myths along the way. This post will cover the following areas:

Kerberos hallmark across trusts
Trust fundamentals
Trust creation process overview
Common trust scenarios
Trust myths and misconceptions
Troubleshooting trusts

Starting with Kerberos

The first office of agreement how trusts work is to understand how authentication flows across a trust, especially with Kerberos. Kerberos is a subject that, on the surface, is simple enough, only can rapidly go much more than complex. This postal service isn't going to become into detail about Kerberos in Microsoft Windows. If you wish to look further into the topic, see the Microsoft Kerberos documentation. In this post, I'm merely going to give yous an overview of how Kerberos hallmark works across trusts.

Figure 1: Kerberos authentication across trusts

Figure one: Kerberos authentication across trusts

If you simply retrieve i thing about Kerberos and trust, it should be referrals. Let'southward look at the workflow in Figure 1, which shows a user from Domain A who is logged into a figurer in Domain A and wants to access an Amazon FSx file share in Domain B. For simplicity's sake, I'll say at that place is a two-manner trust between Domains A and B.

Annotation: When a trust is integrated with AWS Managed Microsoft AD, you need to enable Kerberos preauthentication for accounts that traverse the trusts. Disabling Kerberos preauthentication isn't recommended, because a malicious user can directly ship dummy requests for authentication. The key distribution center (KDC) volition return an encrypted Ticket-Granting Ticket (TGT), which the malicious user tin brute force offline. Run into Kerberos Pre-Authentication: Why It Should Not Exist Disabled for more than details.

The steps of the Kerberos authentication procedure over trusts are as follows:

ane. Kerberos hallmark service asking (KRB_AS_REQ): The client contacts the hallmark service (Every bit) of the KDC (which is running on a domain controller) for Domain A, which the client is a member of, for a short-lived ticket called a Ticket-Granting Ticket (TGT). The default lifetime of the TGT is 10 hours. For Windows clients this happens at logon, but Linux clients might need to run a kinit command.

2. Kerberos authentication service response (KRB_AS_REP): The As constructs the TGT and creates a session cardinal that the client tin can use to encrypt advice with the ticket-granting service (TGS). At the time that the client receives the TGT, the client has not been granted access to whatsoever resources, even to resources on the local calculator.

three. Kerberos ticket-granting service asking (KRB_TGS_REQ): The user's Kerberos client sends a KRB_TGS_REQ message to a local KDC in Domain A, specifying fsx@domainb as the target. The Kerberos client compares the location with its own workstation's domain. Because these values are dissimilar, the customer sets a flag in the KDC Options field of the KRB_TGS_REQ message for NAME_CANONICALIZE, which indicates to the KDC that the server might be in another realm (domain).

4. Kerberos ticket-granting service response (KRB_TGS_REP): The user'southward local KDC (for Domain A) receives the KRB_TGS_REQ and sends back a TGT referral ticket for Domain B. The TGT is issued for the next intervening domain along the shortest path to Domain B. The TGT besides has a referral flag set up, so that the KDC volition be informed that the KRB_TGS_REQ is coming from another realm. This flag also tells the KDC to fill in the Transited Realms field. The referral ticket is encrypted with the interdomain primal that is decrypted past Domain B'southward TGS.

Note: When a trust is established between domains or forests, an interdomain key based on the trust password becomes available for authenticating KDC functions and is used to encrypt and decrypt Kerberos tickets.

5. Kerberos ticket-granting service request (KRB_TGS_REQ): The user's Kerberos client sends a KRB_TGS_REQ forth with the TGT it received from the Domain A KDC to a KDC in Domain B.

half dozen. Kerberos ticket-granting service response (KRB_TGS_REP): The TGS in Domain B examines the TGT and the authenticator. If these are adequate, the TGS creates a service ticket. The client's identity is taken from the TGT and copied to the service ticket. Then the ticket is sent to the client.

For more details on the authenticator, run into How the Kerberos Version five Hallmark Protocol Works.

7. Application server service request (KRB_TGS_REQ): Later the client has the service ticket, the client sends the ticket and a new authenticator to the target server, requesting access. The server will decrypt the ticket, validate the authenticator, and (for Windows services), create an admission token for the user based on the SIDs in the ticket.

viii. Application server service response (KRB_TGS_REP): Optionally, the client might request that the target server verify its own identity. This is called mutual authentication. If mutual authentication is requested, the target server takes the client reckoner'south timestamp from the authenticator, encrypts it with the session key the TGS provided for client-target server letters, and sends it to the client.

The basics of trust transitivity, direction, and types

Let's start off past defining a trust. Agile Directory trusts are a relationship between domains, which makes it possible for users in one domain to exist authenticated past a domain controller in the other domain. Authenticated users, if given proper permissions, tin can access resources in the other domain.

Agile Directory Domain Services supports 4 types of trusts: External (Domain), Forest, Realm, and Shortcut. Out of those iv types of trusts, AWS Managed Microsoft AD supports the External (Domain) and Forest trust types. I'll focus on External (Domain) and Forest trust types for this post.

Transitivity: What is it?

Before I swoop into the types of trusts, it'south important to understand the concept of transitivity in trusts. A trust that is transitive allows authentication to flow through other domains (Kid and Trees) in the trusted forests or domains. In dissimilarity, a non-transitive trust is a point-to-signal trust that allows authentication to flow exclusively between the trusted domains.

Figure 2: Forest trusts between the Example.local and Example.com forests

Effigy two: Wood trusts between the Example.local and Instance.com forests

Don't worry about the trust types at this point, because I'll cover those shortly. The example in Figure 2 shows a Woods trust between Example.com and Example.local. The Example.local woods has a child domain named Child. With a transitive trust, users from the Example.local and Child.Example.local domain tin be authenticated to resources in the Example.com domain.

If Effigy 2 has an External trust, only users from Case.local tin be authenticated to resource in the Case.com domain. Users from Child.Example.local cannot traverse the trust to admission resources in the Case.com domain.

Trust direction

Two-manner trusts are bidirectional trusts that allow authentication referrals from either side of the trust to give users access resource in either domain or wood. If you await in the Agile Directory Domains and Trusts expanse of the Microsoft Management Console (MMC), which provides consoles to manage the hardware, software, and network components of Microsoft Windows operating system, you tin can encounter both an incoming and an outgoing trust for the trusted domain.

One-way trusts are a unmarried-direction trust that allows authentication referrals from one side of the trust simply. A 1-way trust is either approachable or incoming, but not both (that would be a two-way trust).

An approachable trust allows users from the trusted domain (Example.com) to authenticate in this domain (Example.local).
An incoming trust allows users from this domain (Example.local) to authenticate in the trusted domain (Case.com).

Figure 3: One-way trust direction

Figure iii: One-way trust direction

Let's utilize a diagram to further explain this concept. Effigy 3 shows a one-way trust between Example.com and Instance.local. This an outgoing trust from Example.com and an incoming trust on Example.local. Users from Instance.local can cosign and, if given proper permissions, admission resources in Example.com. Users from Instance.com cannot admission or cosign to resources in Example.local.

Trust types

In this department of the post, I'll examine the various types of Active Directory trusts and their capabilities.

External trusts

This trust blazon is used to share resource between two domains. These can exist individual domains inside or external to a wood. Recall of this as a point-to-point trust between two domains. See Understanding When to Create an External Trust for more details on this trust blazon.

Transitivity: Not-transitive
Direction: Ane-manner or ii-way
Hallmark types: NTLM Only* (Kerberos is possible with caveats; encounter the Microsoft Windows Server documentation for details)
AWS Managed Microsoft Ad support: Yes

Forest trusts

This trust type is used to share resource betwixt ii forests. This is the preferred trust model, considering it works fully with Kerberos without whatsoever caveats. See Understanding When to Create a Forest Trust for more details.

Transitivity: Transitive
Direction: One-way or two-fashion
Authentication types: Kerberos and NTLM
AWS Managed Microsoft Advert support: Yes

Realm trusts

This trust type is used to form a trust human relationship between a non-Windows Kerberos realm and an Active Directory domain. See Understanding When to Create a Realm Trust for more than details.

Transitivity: Non-transitive or transitive
Direction: I-fashion or ii-style
Hallmark types: Kerberos Only
AWS Managed Microsoft AD back up: No

Shortcut trusts

This trust type is used to shorten the authentication path between domains inside complex forests. Encounter Understanding When to Create a Shortcut Trust for more details.

Transitivity: Transitive
Direction: One-way or two-way
Authentication types: Kerberos and NTLM
AWS Managed Microsoft Advertisement support: No

User Principal Name suffixes

The default User Principal Name (UPN) suffix for a user account is the Domain Name System (DNS) domain name of the domain where the user account resides. In AWS Managed Microsoft Advertizing and self-managed Advert, alternative UPN suffixes are added to simplify administration and user logon processes by providing a single UPN suffix for all users. The UPN suffix is used inside the Active Directory woods, and is not required to be a valid DNS domain proper noun. See Adding User Principal Proper noun Suffixes for the process to add together UPN suffixes to a forest.

For example, if your domain is Example.local but you want your users to sign in with what appears to exist another domain proper noun (such every bit ExampleSuffix.local), you would need to add together a new UPN suffix to the domain. Figure 4 shows a user being created with an alternate UPN suffix.

Figure 4: UPN selection on object creation

If you're logged into a Windows system, you can use the whoami /upn command to see the UPN of the current user.

Forest trusts and proper name suffix routing

Proper noun suffix routing manages how authentication requests are routed across forest trusts. A unique proper name suffix is a proper noun suffix within a wood, such every bit a UPN suffix or DNS forest or domain tree name, that isn't subordinate to any other name suffix. For example, the DNS forest name Example.com is a unique proper name suffix within the example.com forest.

All names that are subordinate to unique name suffixes are routed implicitly. For example, if your forest root is named Example.local, authentication requests for all child domains of Case.local (Kid.Instance.local) will be routed because the child domains are subordinate to the Example.local name suffix. If you desire to exclude members of a child domain from authenticating in the specified forest, you can disable proper name suffix routing for that name. You can also disable routing for the forest name itself, if necessary. With domain trees and additional UPN suffixes, name suffix routing past default is disabled and must exist enabled if those suffixes are to exist able to traverse the trust.

Note: In AWS Managed Microsoft Advertizing, customers don't have the power to create or modify trusts by using the native Microsoft tools. If you lot demand a name suffix route enabled for your trust, open a support case with Premium Support.

A couple of diagrams will get in easier to digest this information. Figure v shows the trust configuration. In that location is a one-way outgoing forest trust from Instance.com to Case.local. Example.local has a UPN suffix named ExampleSuffix.local added to it. Example.local as well has a kid domain named Child and a tree domain named ExampleTree.local. By default, users in Instance.local and Child.Example.local will be able to authenticate to resources in Example.com. Users in the ExampleTree.local domain will not be able to authenticate to resources in Example.com, unless the name suffix route for ExampleTree.local is enabled on the trust object in Instance.com.

Figure 5: Multi-domain and suffix forest with a trust

Effigy five: Multi-domain and suffix forest with a trust

Figure vi is from the trust properties dialog from the Example.com forest of a trust between Instance.com and Example.local. As you lot can see, *.instance.local is enabled. But the custom UPN suffix ExampleSuffix.local and the tree domain ExampleTree.local are disabled by default.

Figure 6: Example.local trusts details

Selective hallmark

With AWS Managed Microsoft Advert and cocky-managed Advertizing, you have the choice of configuring Selective Authentication. This selection restricts authentication admission over a trust to only the users in a trusted domain or forest who accept been explicitly given hallmark permissions to computer objects that reside in the trusting domain or forest.

When you utilize domain or forest-wide authentication, depending on the trust direction, users can cosign beyond the trust. Authentication by itself doesn't provide access—users take to be delegated permissions to access resources. When Selective Hallmark is enabled, you must set the Allowed to Cosign permission on each computer object the trusted user will exist accessing, in addition to any other permissions that are required to access the computer object.

While Selective Authentication is a mode to provide additional hardening of trusts, it requires a meaning amount of planning and delegation, because yous take to gear up the Immune to Authenticate permission on all computer objects that are beingness accessed. It can also make troubleshooting permissions and trust problems more hard.

For more details on Selective Authentication, see Selective Authentication and Configuring Selective Authentication Settings in the Microsoft documentation.

SID filtering

I won't spend a lot of time on the subject of SID filtering, since this feature is enabled in AWS Managed Microsoft AD and can't be disabled. SID filtering prevents malicious users who have domain or enterprise administrator level access in a trusted forest from granting elevated user rights to a trusting woods. It does this by preventing misuse of the attributes containing SIDs on security principals in the trusted forest. For instance, a malicious user with administrative credentials located in a trusted forest could, through various means, obtain the SID information of a domain or enterprise admin in the trusting woods. Later obtaining the SID of an administrator from the trusting forest, a malicious user with authoritative credentials can add together that SID to the SID history attribute of a security principal in the trusted wood and effort to gain full admission to the trusting forest and the resources within information technology.

Keeping SID filtering disabled on your on-premises domain can open your domain up to risks from malicious users. We understand that during a domain migration, you may demand to disable it to permit an object'southward SID from the original domain to be used during the migration. But in AWS Managed Microsoft Advertizing, this filtering cannot be disabled. See SID Filtering for more than details.

Network ports that are required to create trusts

The following network ports are required to be open between domain controllers on both domains or forests prior to attempting to create a trust. Note, the Security Group used by your AWS Managed Microsoft Ad directory already has these inbound ports open. Y'all will need to adjust the outbound rules of the Security Grouping to let it communicate with the to be trusted domains or forests. The following table is based on Microsoft's recommendations. Depending on your utilize instance, some of these ports might not need to be opened. For example, if LDAP over SSL isn't configured, then TCP 636 isn't needed.

Port	Protocol	Service
53	TCP and UDP	DNS
88	TCP and UDP	Kerberos
123	UDP	Windows Time
135	TCP	Remote Procedure Phone call (RPC)
389	TCP and UDP	Lightweight Directory Access Protocol (LDAP)
445	TCP	Server Message Block (SMB)
464	TCP and UDP	Kerberos Password Change
636	TCP	LDAP over SSL
3268	TCP	LDAP Global Catalog (GC)
3269	TCP	LDAP GC over SSL
49152–65535	TCP and UDP	RPC

Trust cosmos process overview

AWS Managed Microsoft AD is based on Windows Server Active Directory Domain Services, which means that Agile Directory trusts function the aforementioned mode they do with cocky-managed Active Directory. The only difference is how the trust is created. You use the AWS Management Panel or APIs to create the trust for the AWS Managed Microsoft Advertising side. This procedure has been documented thoroughly in the AWS Directory Service Assistants Guide, then I won't go into detail on the steps.

The high-level overview of the process is:

Ensure that network and DNS name resolution is available and functional between the domains.
Create the trust on the on-bounds Active Directory.
Consummate the trust on the AWS Managed Microsoft Advertisement in the AWS Directory Service console.

Common trust scenarios with AWS Managed Microsoft AD

When you create trust between an on-premises domain and AWS Managed Microsoft AD, there are some items to have into consideration that volition help you decide what direction of trust you need to deploy. In this postal service, I'll cover a couple of the about common scenarios.

All scenarios: Selecting a trust type

Let's get-go with the choice between a Forest or External trust. We generally recommend using a Wood trust type. The reason for that is that Forest trusts fully support Kerberos without whatever caveats. With that said, if you accept a specific requirement to implement an External trust, y'all tin do and so—but be aware of these caveats.

Scenario 1: Use AWS Managed Microsoft AD as a resources forest for Amazon RDS, Amazon FSx for Windows File Server, or Amazon EC2 instances

In this scenario, you might want to use AWS Managed Microsoft AD as a resource forest for Amazon RDS, Amazon FSx for Windows File Server, or Amazon Elastic Compute Cloud (Amazon EC2). AWS Managed Microsoft AD is going to be a resource domain, and user accounts will reside on the on-premises side of the trust and need to be able to access the resources in the AWS Managed Microsoft Advertising side of the trust.

In this scenario, the AWS applications (Amazon RDS, Amazon FSx for Windows File Server, or Amazon EC2) don't require a two-way trust to function, because they are natively integrated with Active Directory. This tells you lot that you only demand authentication to flow one way. This scenario requires a one-way incoming trust on the on-premises domain and 1-manner outgoing trusts on the AWS Managed Microsoft AD domain. Figure 7 demonstrates this.

Figure 7: A one-way trust

Figure seven: A i-style trust

Scenario ii: Employ AWS Managed Microsoft AD equally a resource forest for all other supported AWS applications

In this scenario, y'all want to use AWS Managed Microsoft AD every bit a resource domain for all other supported AWS applications that aren't included in Scenario 1. Equally the previous scenario stated, AWS Managed Microsoft Advertisement will be a resource domain, and the user accounts will reside on the on-bounds side of the trust and need to be able to access the resources in the AWS Managed Microsoft Advertisement.

In this scenario, AWS applications (Amazon Chime, Amazon Connect, Amazon QuickSight, AWS Unmarried Sign-On, Amazon WorkDocs, Amazon WorkMail, Amazon WorkSpaces, AWS Customer VPN, AWS Direction Panel, and AWS Transfer Family) need to exist able to wait up objects from the on-premises domain in order for them to office. This tells yous that authentication needs to period both ways. This scenario requires a ii-way trust between the on-premises and AWS Managed Microsoft AD domains. Effigy 8 demonstrates this.

Figure 8: A two-way trust

Effigy 8: A 2-fashion trust

Mutual trust myths and misconceptions

I have had many conversations with customers concerning trusts between their on-premises domain and their AWS Managed Microsoft AD domain. These are some of the common myths and misconceptions we've come across in our conversations.

Trusts synchronize objects between each domain.

This is false. A trust between domains or forests acts every bit a bridge that allows validated authentication requests, in the form of Kerberos or NTLM traffic, to travel betwixt domains or forests. Objects are not synchronized between the domains or forests. Merely the trust password is synchronized, which is used for Kerberos.

My countersign is passed over the trust when authenticating.

This is false. As I showed earlier in the Starting with Kerberos department, when authenticating beyond trusts, the user'due south password is non passed between domains. The only things passed between domains are the Ticket Granting Service (TGS) requests and responses, which are generated in existent fourth dimension, are unmarried use, and elapse within hours.

A one-manner trust allows bidirectional authentication.

This is imitation. One-way trusts allow authentications to traverse in ane direction merely. Users or objects from the trusted domain are able to cosign and, if they are delegated, to access resources in the trusting domain. Users in the trusting domain can't cosign into the trusted domain, and aren't granted permissions to access resource. Let'due south say at that place is an Amazon FSx file system in Case.local and a one-way trust between Instance.com (outgoing trust management) and Instance.local (incoming trust direction). A user in Example.com can't exist delegated permission to the Amazon FSx file arrangement Example.local with the current trust configuration. That's the nature of a ane-fashion trust.

Trusts are inherently insecure by default.

This is false, although an improperly configured trust can increase your take chances and exposure. Trusts by themselves exercise very little to increment an Active Directory's assail surface. You lot should always apply all-time practices when creating a trust to minimize risk. For example, a trust without a purpose should exist removed. You should disable the SID History unless y'all're in the process of migrating domains. Come across Security Considerations for Trusts for more guidance on securing trusts.

Users in the trusted domain are granted permissions to my domain when a trust is created.

This is simulated. Past default, with two-way trusts, objects have read-only permission to Agile Directory in both directions. Objects are non delegated permissions or access to resources or servers past default. For example, if you lot want a user to log into a estimator in another domain, you first must delegate the user access to the resource in the other domain. Without that delegation, the user won't exist able to admission the resource.

Troubleshooting trusts

Based on our experience working with many customers, the vast majority of trust configuration issues are either DNS resolution or networking connectivity errors. These are some troubleshooting steps to help you resolve any of these common issues:

Check whether you allowed outbound networking traffic on the AWS Managed Microsoft Advertisement. Encounter Pace i: Set up your environment for trusts to acquire how to observe your directory's security group and how to change information technology.
If the DNS server or the network for your on-bounds domain uses a public (non-RFC 1918) IP address space, follow these steps:
1. In the AWS Directory Service console, go to the IP routing department for your directory, cull Deportment, and and then cull Add route.
2. Enter the IP address block of your DNS server or on-premises network using CIDR format, for example 203.0.113.0/24.
  This pace isn't necessary if both your DNS server and your on-premises network are using RFC 1918 private IP address spaces.
After you verify the security grouping and check whether any applicative routes are required, launch a Windows Server instance and join information technology to the AWS Managed Microsoft Advertisement directory. Come across Step 3: Deploy an EC2 instance to manage your AWS Managed Microsoft AD to learn how to do this. Once the instance is launched, practise the post-obit:
- Run the following PowerShell command to examination DNS connectivity:
  Resolve-DnsName -Name 'case.local' -DnsOnly
You should also wait through the message explanations in the Trust creation condition reasons guide in the AWS Directory Service documentation.

Summary of AWS Managed Microsoft AD trust considerations

In this weblog post, I covered Kerberos authentication over Agile Directory trusts and provided details on what Active Directory trusts are and how they function. Hither's a quick list of items that you should consider when you plan trust creation with AWS Managed Microsoft Advertisement:

Ensure that yous take a network connectedness and the advisable network ports opened betwixt both domains. Note, information technology is recommended all Active Directory traffic occur over private network connection like a VPN or Direct Connect.
Ensure that DNS resolution is working on both sides of the trust.
Decide whether you will implement selective authentication. If it volition exist used, programme your Agile Directory access control list (ACL) delegation strategy before implementation.
Every bit of this blog'south publication, continue in mind that AWS Managed Microsoft AD currently supports Forest trusts and External trusts only.
Ensure that Kerberos preauthentication is enabled for all objects that traverse trusts with AWS Managed Microsoft AD.
If y'all find that you need a proper noun suffix road enabled for your trust, open up a support instance with AWS Back up, requesting that the name suffix route exist enabled.
Finally, review Security Considerations for Trusts: Domain and Forest Trusts for additional considerations for trust configuration.

If you accept feedback about this post, submit comments in the Comments section below. If you accept questions about this post, starting time a new thread on the AWS Directory Service forum.

Want more AWS Security how-to content, news, and feature announcements? Follow u.s.a. on Twitter.