A summary of creating a trust relationship between on-premises domain and AWS Directory Service

How to create a trust relationship between on-premises domain and AWS Directory Service

Most SQL Servers use a large portion of the authentication as Windows Authentication - utilising Kerberos and NTLM protocols via Active Directory. So when it comes to considering moving on-prem SQL Server resources to Cloud Providers - Active Directory is a foundational question.    There are other methods than Microsoft Directory - which I'll discuss in future posts.

Utilising AWS RDS SQL Server with Windows Authentication methods is only possible using the AWS Directory Service.  i.e The AWS RDS SQL Server is created and added as a resource to the AWS Directory Service . If on-prem users require access to the AWS RDS SQL Server via Kerberos , a forest trust is required between the AWS Directory Service and the on-prem AD. 

For this post - the focus is on an existing on-premises SQL Server inventory using Microsoft Active Directory Services.

For both domains consideration is required for the trust relationship. In a trust relationship there is the trusted and trusting domain , with trust flowing in one direction while access flows in the other . 

Required

1) AWS managed Microsoft Active Directory (AD)

2)On-premises network can communicate with the Amazon VPC containing the managed Active Directory Domain 

3)Kerberos Pre-Authentication is enabled for on-premises directories and AWS Managed AD domains

One of the benefits of enabling Kerberos pre-authentication is protection against password-guessing attacks.As part of the Authentication Service Request\Response process , Kerberos pre-authentication forces an encrypted timestamp using the user's password hash as an encryption key. 

*******This is not a fully detailed step-by-step guide on every configuration variable required by on-premises Active Directory , AWS Directory Services or network configurations. It is meant to serve as a summary . To access full details refer to AWS documentation*****

Summary of Steps 

Some ports must be open from on-premises network to the Classless Inter-Domain Routing (CIDR)s of the two subnets where the AWS Managed AD server resides.   AWS Knowledge base has specific details but the minimum would be :

TCP/UDP 53 - DNS

TCP/UDP 88 - Kerberos Authentication

TCP/UDP 389 - LDAP

TCP 445 - SMB

Configuring the on-premises AD

-New conditional forwarder on On-prem AD  - you will require AWS Directory Directory Services DNS names 

-Forest Trust 

-Decide on the direction of the Trust i.e  one-way or two way trust 

                 -Two-way trust - users in this can be authenticated in the specified doamin,realms or forest and users in the specified domain , realm or forset can be authenticated in this domain

                - One-way incoming - users in this domain can be authenticated in the specified domain, realm or forest

                - one-way outgoing - users in the specified domain realm or forset can be authenticated in this domain

On AWS managed AD services 

-Add a new trust to the Directory services 

-Forest trust 

-Decide on trust direction

One-way:outgoing - users in the existing or remote domain can access resources in the existing or remote domain 

One-way : incoming - Users in this domain can access resources in the existing or remote domain 

Two-way: Users in each domain can access resources in both domain

Conditional forwarder

Read more on Active Directory   

Best practices for running Microsoft Active Directory Services on AWS

How to view Service Principal Names in Active Directory

How to get Active Directory Group Scope