AWS Directory Service

(1)

AWS Directory Service

Administration Guide

Version 1.0

(2)

AWS Directory Service: Administration Guide

Amazon's trademarks and trade dress may not be used in connection with any product or service that is not Amazon's, in any manner that is likely to cause confusion among customers, or in any manner that disparages or discredits Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who may or may not be aﬃliated with, connected to, or sponsored by Amazon.

(3)

What is AWS Directory Service?

AWS Directory Service provides multiple ways to use Microsoft Active Directory (AD) with other AWS services. Directories store information about users, groups, and devices, and administrators use them to manage access to information and resources. AWS Directory Service provides multiple directory choices for customers who want to use existing Microsoft AD or Lightweight Directory Access Protocol (LDAP)–

aware applications in the cloud. It also oﬀers those same choices to developers who need a directory to manage users, groups, devices, and access.

Which to choose

You can choose directory services with the features and scalability that best meets your needs. Use the following table to help you determine which AWS Directory Service directory option works best for your organization.

What do you need to do? Recommended AWS Directory Service options I need Active Directory or LDAP for my

applications in the cloud Select AWS Directory Service for Microsoft Active Directory (p. 1) (Standard Edition or Enterprise Edition) if you need an actual Microsoft Active Directory in the AWS Cloud that supports Active Directory–aware workloads, or AWS applications and services such as Amazon WorkSpaces and Amazon QuickSight, or you need LDAP support for Linux applications.

Use AD Connector if you only need to allow your on-premises users to log in to AWS applications and services with their Active Directory credentials. You can also use AD Connector to join Amazon EC2 instances to your existing Active Directory domain.

Use Simple AD if you need a low-scale, low-cost directory with basic Active Directory compatibility that supports Samba 4–compatible applications, or you need LDAP compatibility for LDAP-aware applications.

I develop SaaS applications Use Amazon Cognito if you develop high-scale SaaS applications and need a scalable directory to manage and authenticate your subscribers and that works with social media identities.

AWS Directory Service options

AWS Directory Service includes several directory types to choose from. For more information, select one of the following tabs:

AWS Directory Service for Microsoft Active Directory

Also known as AWS Managed Microsoft AD, AWS Directory Service for Microsoft Active Directory is powered by an actual Microsoft Windows Server Active Directory (AD), managed by AWS in the AWS

(7)

Cloud. It enables you to migrate a broad range of Active Directory–aware applications to the AWS Cloud. AWS Managed Microsoft AD works with Microsoft SharePoint, Microsoft SQL Server Always On Availability Groups, and many .NET applications. It also supports AWS managed applications and services including Amazon WorkSpaces, Amazon WorkDocs, Amazon QuickSight, Amazon Chime, Amazon Connect, and Amazon Relational Database Service for Microsoft SQL Server (Amazon RDS for SQL Server, Amazon RDS for Oracle, and Amazon RDS for PostgreSQL).

AWS Managed Microsoft AD is approved for applications in the AWS Cloud that are subject to U.S.

Health Insurance Portability and Accountability Act (HIPAA) or Payment Card Industry Data Security Standard (PCI DSS) compliance when you enable compliance for your directory.

All compatible applications work with user credentials that you store in AWS Managed Microsoft AD, or you can connect to your existing AD infrastructure with a trust and use credentials from an Active Directory running on-premises or on EC2 Windows. If you join EC2 instances to your AWS Managed Microsoft AD, your users can access Windows workloads in the AWS Cloud with the same Windows single sign-on (SSO) experience as when they access workloads in your on-premises network.

AWS Managed Microsoft AD also supports federated use cases using Active Directory credentials.

Alone, AWS Managed Microsoft AD enables you to sign in to the AWS Management Console. With AWS Single Sign-On, you can also obtain short-term credentials for use with the AWS SDK and CLI, and use preconﬁgured SAML integrations to sign in to many cloud applications. By adding Azure AD Connect, and optionally Active Directory Federation Service (AD FS), you can sign in to Microsoft Oﬃce 365 and other cloud applications with credentials stored in AWS Managed Microsoft AD.

The service includes key features that enable you to extend your schema, manage password policies, and enable secure LDAP communications through Secure Socket Layer (SSL)/Transport Layer Security (TLS). You can also enable multi-factor authentication (MFA) for AWS Managed Microsoft AD to provide an additional layer of security when users access AWS applications from the Internet.

Because Active Directory is an LDAP directory, you can also use AWS Managed Microsoft AD for Linux Secure Shell (SSH) authentication and for other LDAP-enabled applications.

AWS provides monitoring, daily snapshots, and recovery as part of the service—you add users and groups to AWS Managed Microsoft AD, and administer Group Policy using familiar Active Directory tools running on a Windows computer joined to the AWS Managed Microsoft AD domain. You can also scale the directory by deploying additional domain controllers and help improve application performance by distributing requests across a larger number of domain controllers.

AWS Managed Microsoft AD is available in two editions: Standard and Enterprise.

• Standard Edition: AWS Managed Microsoft AD (Standard Edition) is optimized to be a primary directory for small and midsize businesses with up to 5,000 employees. It provides you enough storage capacity to support up to 30,000* directory objects, such as users, groups, and computers.

• Enterprise Edition: AWS Managed Microsoft AD (Enterprise Edition) is designed to support enterprise organizations with up to 500,000* directory objects.

* Upper limits are approximations. Your directory may support more or less directory objects depending on the size of your objects and the behavior and performance needs of your applications.

When to use

AWS Managed Microsoft AD is your best choice if you need actual Active Directory features to support AWS applications or Windows workloads, including Amazon Relational Database Service for Microsoft SQL Server. It's also best if you want a standalone AD in the AWS Cloud that supports Oﬃce 365 or you need an LDAP directory to support your Linux applications. For more information, see AWS Managed Microsoft AD (p. 8).

AD Connector

(8)

AD Connector is a proxy service that provides an easy way to connect compatible AWS applications, such as Amazon WorkSpaces, Amazon QuickSight, and Amazon EC2 for Windows Server instances, to your existing on-premises Microsoft Active Directory. With AD Connector , you can simply add one service account to your Active Directory. AD Connector also eliminates the need of directory synchronization or the cost and complexity of hosting a federation infrastructure.

When you add users to AWS applications such as Amazon QuickSight, AD Connector reads your existing Active Directory to create lists of users and groups to select from. When users log in to the AWS applications, AD Connector forwards sign-in requests to your on-premises Active Directory domain controllers for authentication. AD Connector works with many AWS applications and services including Amazon WorkSpaces, Amazon WorkDocs, Amazon QuickSight, Amazon Chime, Amazon Connect, and Amazon WorkMail. You can also join your EC2 Windows instances to your on-premises Active Directory domain through AD Connector using seamless domain join. AD Connector also allows your users to access the AWS Management Console and manage AWS resources by logging in with their existing Active Directory credentials. AD Connector is not compatible with RDS SQL Server.

You can also use AD Connector to enable multi-factor authentication (MFA) for your AWS application users by connecting it to your existing RADIUS-based MFA infrastructure. This provides an additional layer of security when users access AWS applications.

With AD Connector, you continue to manage your Active Directory as you do now. For example, you add new users and groups and update passwords using standard Active Directory administration tools in your on-premises Active Directory. This helps you consistently enforce your security policies, such as password expiration, password history, and account lockouts, whether users are accessing resources on premises or in the AWS Cloud.

When to use

AD Connector is your best choice when you want to use your existing on-premises directory with compatible AWS services. For more information, see Active Directory Connector (p. 186).

Simple AD

Simple AD is a Microsoft Active Directory–compatible directory from AWS Directory Service that is powered by Samba 4. Simple AD supports basic Active Directory features such as user accounts, group memberships, joining a Linux domain or Windows based EC2 instances, Kerberos-based SSO, and group policies. AWS provides monitoring, daily snap-shots, and recovery as part of the service.

Simple AD is a standalone directory in the cloud, where you create and manage user identities and manage access to applications. You can use many familiar Active Directory–aware applications and tools that require basic Active Directory features. Simple AD is compatible with the following AWS applications: Amazon WorkSpaces, Amazon WorkDocs, Amazon QuickSight, and Amazon WorkMail.

You can also sign in to the AWS Management Console with Simple AD user accounts and to manage AWS resources.

Simple AD does not support multi-factor authentication (MFA), trust relationships, DNS dynamic update, schema extensions, communication over LDAPS, PowerShell AD cmdlets, or FSMO role transfer. Simple AD is not compatible with RDS SQL Server. Customers who require the features of an actual Microsoft Active Directory, or who envision using their directory with RDS SQL Server should use AWS Managed Microsoft AD instead. Please verify your required applications are fully compatible with Samba 4 before using Simple AD. For more information, see https://

www.samba.org.

When to use

You can use Simple AD as a standalone directory in the cloud to support Windows workloads that need basic AD features, compatible AWS applications, or to support Linux workloads that need LDAP service. For more information, see Simple Active Directory (p. 226).

(9)

Amazon Cognito

Amazon Cognito is a user directory that adds sign-up and sign-in to your mobile app or web application using Amazon Cognito User Pools.

When to use

You can also use Amazon Cognito when you need to create custom registration ﬁelds and store that metadata in your user directory. This fully managed service scales to support hundreds of millions of users. For more information, see Amazon Cognito user pools in the Amazon Cognito Developer Guide.

See Region availability for AWS Directory Service (p. 294) for a list of supported directory types per Region.

Working with Amazon EC2

A basic understanding of Amazon EC2 is essential to using AWS Directory Service. We recommend that you begin by reading the following topics:

• What is Amazon EC2? in the Amazon EC2 User Guide for Windows Instances.

• Launching EC2 instances in the Amazon EC2 User Guide for Windows Instances.

• Security groups in the Amazon EC2 User Guide for Windows Instances.

• What is Amazon VPC? in the Amazon VPC User Guide.

• Adding a Hardware Virtual Private Gateway to Your VPC in the Amazon VPC User Guide.

(10)

Setting up AWS Directory Service

To work with AWS Directory Service, you need to meet the prerequisites for AWS Directory Service for Microsoft Active Directory, AD Connector, or Simple AD. For more information, see AWS Managed Microsoft AD prerequisites (p. 9), AD Connector prerequisites (p. 187), or Simple AD prerequisites (p. 227).

If you haven't already done so, you'll also need to create an AWS account and use the AWS Identity and Access Management service to control access.

Topics

• Sign up for an AWS account (p. 5)

• Create an IAM user (p. 5)

Sign up for an AWS account

Your AWS account gives you access to all services, but you are charged only for the resources that you use.

If you do not have an AWS account, complete the following steps to create one.

To sign up for an AWS account

1. Open https://portal.aws.amazon.com/billing/signup.

2. Follow the online instructions.

Part of the sign-up procedure involves receiving a phone call and entering a veriﬁcation code on the phone keypad.

Your root account credentials identify you to services in AWS and grant you unlimited use of your AWS resources, such as your Amazon WorkSpaces. To allow other users to manage AWS Directory Service resources without sharing your security credentials, use AWS Identity and Access Management (IAM). We recommend that everyone work as an IAM user, even the account owner. You should create an IAM user for yourself, give that IAM user administrative privileges, and use it for all your work.

Create an IAM user

The AWS Management Console requires your username and password so that the service can determine whether you have permission to access its resources. However, we recommend that you avoid accessing AWS using the credentials for your root AWS account; instead, we recommend that you use AWS Identity and Access Management (IAM) to create an IAM user and add the IAM user to an IAM group with administrative permissions. This grants the IAM user administrative permissions. You then access the AWS Management Console using the credentials for the IAM user.

If you signed up for AWS but have not created an IAM user for yourself, you can create one using the IAM console.

(11)

To create an administrator user for yourself and add the user to an administrators group (console)

1. Sign in to the IAM console as the account owner by choosing Root user and entering your AWS account email address. On the next page, enter your password.

Note

We strongly recommend that you adhere to the best practice of using the Administrator IAM user that follows and securely lock away the root user credentials. Sign in as the root user only to perform a few account and service management tasks.

2. In the navigation pane, choose Users and then choose Add user.

3. For User name, enter Administrator.

4. Select the check box next to AWS Management Console access. Then select Custom password, and then enter your new password in the text box.

5. (Optional) By default, AWS requires the new user to create a new password when ﬁrst signing in. You can clear the check box next to User must create a new password at next sign-in to allow the new user to reset their password after they sign in.

6. Choose Next: Permissions.

7. Under Set permissions, choose Add user to group.

8. Choose Create group.

9. In the Create group dialog box, for Group name enter Administrators.

10. Choose Filter policies, and then select AWS managed - job function to ﬁlter the table contents.

11. In the policy list, select the check box for AdministratorAccess. Then choose Create group.

Note

You must activate IAM user and role access to Billing before you can use the

AdministratorAccess permissions to access the AWS Billing and Cost Management console. To do this, follow the instructions in step 1 of the tutorial about delegating access to the billing console.

12. Back in the list of groups, select the check box for your new group. Choose Refresh if necessary to see the group in the list.

13. Choose Next: Tags.

14. (Optional) Add metadata to the user by attaching tags as key-value pairs. For more information about using tags in IAM, see Tagging IAM entities in the IAM User Guide.

15. Choose Next: Review to see the list of group memberships to be added to the new user. When you are ready to proceed, choose Create user.

You can use this same process to create more groups and users and to give your users access to your AWS account resources. To learn about using policies that restrict user permissions to speciﬁc AWS resources, see Access management and Example policies.

To sign in as this new IAM user, sign out of the AWS Management Console, then use the following URL, where your_aws_account_id is your AWS account number without the hyphens (for example, if your AWS account number is 1234-5678-9012, your AWS account ID is 123456789012):

https://your_aws_account_id.signin.aws.amazon.com/console/

Enter the IAM user name and password that you just created. When you're signed in, the navigation bar displays "your_user_name @ your_aws_account_id".

If you don't want the URL for your sign-in page to contain your AWS account ID, you can create an account alias. From the IAM dashboard, click Customize and enter an alias, such as your company name.

To sign in after you create an account alias, use the following URL:

(12)

https://your_account_alias.signin.aws.amazon.com/console/

For more information about using IAM policies to control access to your AWS Directory Service resources, see Using identity-based policies (IAM policies) for AWS Directory Service (p. 282).

(13)

AWS Managed Microsoft AD

AWS Directory Service lets you run Microsoft Active Directory (AD) as a managed service. AWS Directory Service for Microsoft Active Directory, also referred to as AWS Managed Microsoft AD, is powered by Windows Server 2012 R2. When you select and launch this directory type, it is created as a highly available pair of domain controllers connected to your virtual private cloud (VPC). The domain

controllers run in diﬀerent Availability Zones in a Region of your choice. Host monitoring and recovery, data replication, snapshots, and software updates are automatically conﬁgured and managed for you.

With AWS Managed Microsoft AD, you can run directory-aware workloads in the AWS Cloud, including Microsoft SharePoint and custom .NET and SQL Server-based applications. You can also conﬁgure a trust relationship between AWS Managed Microsoft AD in the AWS Cloud and your existing on-premises Microsoft Active Directory, providing users and groups with access to resources in either domain, using single sign-on (SSO).

AWS Directory Service makes it easy to set up and run directories in the AWS Cloud, or connect your AWS resources with an existing on-premises Microsoft Active Directory. Once your directory is created, you can use it for a variety of tasks:

• Manage users and groups

• Provide single sign-on to applications and services

• Create and apply group policy

• Simplify the deployment and management of cloud-based Linux and Microsoft Windows workloads

• You can use AWS Managed Microsoft AD to enable multi-factor authentication by integrating with your existing RADIUS-based MFA infrastructure to provide an additional layer of security when users access AWS applications.

• Securely connect to Amazon EC2 Linux and Windows instances

Note

AWS manages the licensing of your Windows Server instances for you; all you need to do is pay for the instances you use. There is also no need to buy additional Windows Server CALs, as access is included in the price. Each instance comes with two remote connections for admin purposes only. If you require more than two connections, or need those connections for purposes other than admin, you may have to bring in additional Remote Desktop Services CALs for use on AWS.

Read the topics in this section to get started creating a AWS Managed Microsoft AD directory, creating a trust relationship between AWS Managed Microsoft AD and your on-premises directories, and extending your AWS Managed Microsoft AD schema.

Topics

• Getting started with AWS Managed Microsoft AD (p. 9)

• Key concepts for AWS Managed Microsoft AD (p. 18)

• Use cases for AWS Managed Microsoft AD (p. 21)

• How to administer AWS Managed Microsoft AD (p. 28)

• Best practices for AWS Managed Microsoft AD (p. 147)

• AWS Managed Microsoft AD quotas (p. 152)

(14)

• Application compatibility policy for AWS Managed Microsoft AD (p. 153)

• AWS Managed Microsoft AD test lab tutorials (p. 155)

• Troubleshooting AWS Managed Microsoft AD (p. 175)

Related AWS Security blog articles

• How to delegate administration of your AWS Managed Microsoft AD directory to your on-premises Active Directory users

• How to conﬁgure even stronger password policies to help meet your security standards by using AWS Directory Service for AWS Managed Microsoft AD

• How to increase the redundancy and performance of your AWS Directory Service for AWS Managed Microsoft AD by adding Domain controllers

• How to enable the use of remote desktops by deploying Microsoft remote desktop licensing manager on AWS Managed Microsoft AD

• How to access the AWS Management Console using AWS Managed Microsoft AD and your on-premises credentials

• How to enable multi-factor authentication for AWS services by using AWS Managed Microsoft AD and on-premises credentials

• How to easily log on to AWS services by using your on-premises Active Directory

Getting started with AWS Managed Microsoft AD

AWS Managed Microsoft AD creates a fully managed, Microsoft Active Directory in the AWS Cloud and is powered by Windows Server 2012 R2 and operates at the 2012 R2 Forest and Domain functional levels. When you create a directory with AWS Managed Microsoft AD, AWS Directory Service creates two domain controllers and adds the DNS service on your behalf. The domain controllers are created in diﬀerent subnets in a VPC; this redundancy helps ensure that your directory remains accessible even if a failure occurs. If you need more domain controllers, you can add them later. For more information, see Deploy additional domain controllers (p. 143).

Topics

• AWS Managed Microsoft AD prerequisites (p. 9)

• Create your AWS Managed Microsoft AD directory (p. 11)

• What gets created (p. 12)

• Admin account (p. 17)

AWS Managed Microsoft AD prerequisites

To create a AWS Managed Microsoft AD directory, you need a VPC with the following:

• At least two subnets. Each of the subnets must be in a diﬀerent Availability Zone.

• The VPC must have default hardware tenancy.

• You cannot create a AWS Managed Microsoft AD in a VPC using addresses in the 198.18.0.0/15 address space.

If you need to integrate your AWS Managed Microsoft AD domain with an existing on-premises Active Directory domain, you must have the Forest and Domain functional levels for your on-premises domain set to Windows Server 2003 or higher.

(15)

AWS Directory Service uses a two VPC structure. The EC2 instances which make up your directory run outside of your AWS account, and are managed by AWS. They have two network adapters, ETH0 and ETH1. ETH0 is the management adapter, and exists outside of your account. ETH1 is created within your account.

The management IP range of your directory's ETH0 network is 198.18.0.0/15.

AWS Single Sign-On prerequisites

If you plan to use AWS Single Sign-On (AWS SSO) with AWS Managed Microsoft AD, you need to ensure that the following are true:

• Your AWS Managed Microsoft AD directory is set up in your AWS organization’s management account.

• Your instance of AWS SSO is in the same Region where your AWS Managed Microsoft AD directory is set up.

For more information, see AWS SSO prerequisites in the AWS Single Sign-On User Guide.

Multi-factor authentication prerequisites

To support multi-factor authentication with your AWS Managed Microsoft AD directory, you must conﬁgure either your on-premises or cloud-based Remote Authentication Dial-In User Service (RADIUS) server in the following way so that it can accept requests from your AWS Managed Microsoft AD directory in AWS.

1. On your RADIUS server, create two RADIUS clients to represent both of the AWS Managed Microsoft AD domain controllers (DCs) in AWS. You must conﬁgure both clients using the following common parameters (your RADIUS server may vary):

• Address (DNS or IP): This is the DNS address for one of the AWS Managed Microsoft AD DCs. Both DNS addresses can be found in the AWS Directory Service Console on the Details page of the AWS Managed Microsoft AD directory in which you plan to use MFA. The DNS addresses displayed represent the IP addresses for both of the AWS Managed Microsoft AD DCs that are used by AWS.

Note

If your RADIUS server supports DNS addresses, you must create only one RADIUS client conﬁguration. Otherwise, you must create one RADIUS client conﬁguration for each AWS Managed Microsoft AD DC.

• Port number: Conﬁgure the port number for which your RADIUS server accepts RADIUS client connections. The standard RADIUS port is 1812.

• Shared secret: Type or generate a shared secret that the RADIUS server will use to connect with RADIUS clients.

• Protocol: You might need to conﬁgure the authentication protocol between the AWS Managed Microsoft AD DCs and the RADIUS server. Supported protocols are PAP, CHAP MS-CHAPv1, and MS-CHAPv2. MS-CHAPv2 is recommended because it provides the strongest security of the three options.

• Application name: This may be optional in some RADIUS servers and usually identiﬁes the application in messages or reports.

2. Conﬁgure your existing network to allow inbound traﬃc from the RADIUS clients (AWS Managed Microsoft AD DCs DNS addresses, see Step 1) to your RADIUS server port.

3. Add a rule to the Amazon EC2 security group in your AWS Managed Microsoft AD domain that allows inbound traﬃc from the RADIUS server DNS address and port number deﬁned previously. For more information, see Adding rules to a security group in the EC2 User Guide.

For more information about using AWS Managed Microsoft AD with MFA, see Enable multi-factor authentication for AWS Managed Microsoft AD (p. 31).

(16)

Create your AWS Managed Microsoft AD directory

To create a new directory, perform the following steps. Before starting this procedure, make sure that you have completed the prerequisites identiﬁed in AWS Managed Microsoft AD prerequisites (p. 9).

To create an AWS Managed Microsoft AD directory

1. In the AWS Directory Service console navigation pane, choose Directories and then choose Set up directory.

2. On the Select directory type page, choose AWS Managed Microsoft AD, and then choose Next.

3. On the Enter directory information page, provide the following information:

Edition

Choose from either the Standard Edition or Enterprise Edition of AWS Managed Microsoft AD. For more information about editions, see AWS Directory Service for Microsoft Active Directory (p. 1).

Directory DNS name

The fully qualiﬁed name for the directory, such as corp.example.com.

Directory NetBIOS name

The short name for the directory, such as CORP.

Directory description

An optional description for the directory.

Admin password

The password for the directory administrator. The directory creation process creates an administrator account with the user name Admin and this password.

The password cannot include the word "admin."

The directory administrator password is case-sensitive and must be between 8 and 64 characters in length, inclusive. It must also contain at least one character from three of the following four categories:

• Lowercase letters (a-z)

• Uppercase letters (A-Z)

• Numbers (0-9)

• Non-alphanumeric characters (~!@#$%^&*_-+=`|\(){}[]:;"'<>,.?/) Conﬁrm password

Retype the administrator password.

4. On the Choose VPC and subnets page, provide the following information, and then choose Next.

VPC

The VPC for the directory.

Subnets

Choose the subnets for the domain controllers. The two subnets must be in diﬀerent Availability Zones.

5. On the Review & create page, review the directory information and make any necessary changes.

When the information is correct, choose Create directory. Creating the directory takes 20 to 40 minutes. Once created, the Status value changes to Active.

(17)

What gets created

When you create a directory with AWS Managed Microsoft AD, AWS Directory Service performs the following tasks on your behalf:

• Automatically creates and associates an elastic network interface (ENI) with each of your domain controllers. Each of these ENIs are essential for connectivity between your VPC and AWS Directory Service domain controllers and should never be deleted. You can identify all network interfaces reserved for use with AWS Directory Service by the description: "AWS created network interface for directory directory-id". For more information, see Elastic Network Interfaces in the Amazon EC2 User Guide for Windows Instances.

Note

Domain controllers are deployed across two Availability Zones in a region by default and connected to your Amazon Virtual Private Cloud (VPC). Backups are automatically taken once per day, and the Amazon Elastic Block Store (EBS) volumes are encrypted to ensure that data is secured at rest. Domain controllers that fail are automatically replaced in the same Availability Zone using the same IP address, and a full disaster recovery can be performed using the latest backup.

• Provisions Active Directory within your VPC using two domain controllers for fault tolerance and high availability. More domain controllers can be provisioned for higher resiliency and performance after the directory has been successfully created and is Active. For more information, see Deploy additional domain controllers (p. 143).

Note

AWS does not allow the installation of monitoring agents on AWS Managed Microsoft AD domain controllers.

• Creates an AWS security group that establishes network rules for traffic in and out of your domain controllers. The default outbound rule permits all traffic ENIs or instances attached to the created AWS Security Group. The default inbound rules allows only traffic through ports that are required by Active Directory from any source (0.0.0.0/0). The 0.0.0.0/0 rules do not introduce security vulnerabilities as traffic to the domain controllers is limited to traffic from your VPC, from other peered VPCs, or from networks that you have connected using AWS Direct Connect, AWS Transit Gateway, or Virtual Private Network. For additional security, the ENIs that are created do not have Elastic IPs attached to them and you do not have permission to attach an Elastic IP to those ENIs. Therefore, the only inbound traffic that can communicate with your AWS Managed Microsoft AD is local VPC and VPC routed traffic. Use extreme caution if you attempt to change these rules as you may break your ability to communicate with your domain controllers. The following AWS Security Group rules are created by default:

Inbound Rules

Protocol Port range Source Type of traﬃc Active Directory

usage

ICMP N/A 0.0.0.0/0 Ping None

TCP & UDP 53 0.0.0.0/0 DNS User and

computer authentication, name resolution, trusts

TCP & UDP 88 0.0.0.0/0 Kerberos User and

computer authentication, forest level trusts

(18)

Protocol Port range Source Type of traﬃc Active Directory usage

TCP & UDP 389 0.0.0.0/0 LDAP Directory,

replication, user and computer authentication group policy, trusts

TCP & UDP 445 0.0.0.0/0 SMB / CIFS Replication, user

and computer authentication, group policy, trusts

TCP & UDP 464 0.0.0.0/0 Kerberos change /

set password Replication, user and computer authentication, trusts

TCP 135 0.0.0.0/0 Replication RPC, EPM

TCP 636 0.0.0.0/0 LDAP SSL Directory,

replication, user and computer authentication, group policy, trusts

TCP 1024 - 65535 0.0.0.0/0 RPC Replication, user

and computer authentication, group policy, trusts

TCP 3268 - 3269 0.0.0.0/0 LDAP GC & LDAP

GC SSL Directory,

replication, user and computer authentication, group policy, trusts

UDP 123 0.0.0.0/0 Windows Time Windows Time,

trusts

UDP 138 0.0.0.0/0 DFSN & NetLogon DFS, group policy

All All sg-

##################All Traﬃc

Outbound Rules

(19)

Protocol Port range Destination Type of traﬃc Active Directory usage

All All sg-

##################All Traﬃc

• Creates a directory administrator account with the user name Admin and the speciﬁed password. This account is located under the Users OU (For example, Corp > Users). You use this account to manage your directory in the AWS Cloud. For more information, see Admin account (p. 17).

Important

Be sure to save this password. AWS Directory Service does not store this password, and it cannot be retrieved. However, you can reset a password from the AWS Directory Service console or by using the ResetUserPassword API.

• Creates the following three organizational units (OUs) under the domain root:

OU name Description

AWS Delegated Groups Stores all of the groups that you can use to delegate AWS speciﬁc permissions to your users.

AWS Reserved Stores all AWS management speciﬁc accounts.

<yourdomainname> The name of this OU is based oﬀ of the NetBIOS name you typed when you created your

directory. If you did not specify a NetBIOS name, it will default to the ﬁrst part of your Directory DNS name (for example, in the case of corp.example.com, the NetBIOS name would be corp). This OU is owned by AWS and contains all of your AWS-related directory objects, which you are granted Full Control over. Two child OUs exist under this OU by default; Computers and Users.

For example:

• Corp

• Computers

• Users

• Creates the following groups in the AWS Delegated Groups OU:

Group name Description

AWS Delegated Account Operators Members of this security group have limited account management capability such as password resets

AWS Delegated Active Directory Based Activation

Administrators Members of this security group can create Active

Directory volume licensing activation objects, which enables enterprises to activate computers through a connection to their domain.

AWS Delegated Add Workstations To Domain

Users Members of this security group can join 10

computers to a domain.

(20)

Group name Description

AWS Delegated Administrators Members of this security group can manage AWS Managed Microsoft AD, have full control of all the objects in your OU and can manage groups contained in the AWS Delegated Groups OU.

AWS Delegated Allowed to Authenticate Objects Members of this security group are provided the ability to authenticate to computer resources in the AWS Reserved OU (Only needed for on- premises objects with Selective Authentication enabled Trusts).

AWS Delegated Allowed to Authenticate to

Domain Controllers Members of this security group are provided the ability to authenticate to computer resources in the Domain Controllers OU (Only needed for on- premises objects with Selective Authentication enabled Trusts).

AWS Delegated Deleted Object Lifetime

Administrators Members of this security group can modify the

msDS-DeletedObjectLifetime object, which deﬁnes how long a deleted object will be available to recover from the AD Recycle Bin.

AWS Delegated Distributed File System

Administrators Members of this security group can add and

remove FRS, DFS-R, and DFS name spaces.

AWS Delegated Domain Name System

Administrators Members of this security group can manage

Active Directory integrated DNS.

AWS Delegated Dynamic Host Conﬁguration

Protocol Administrators Members of this security group can authorize Windows DHCP servers in the enterprise.

AWS Delegated Enterprise Certiﬁcate Authority

Administrators Members of this security group can deploy

and manage Microsoft Enterprise Certiﬁcate Authority infrastructure.

AWS Delegated Fine Grained Password Policy

Administrators Members of this security group can modify

precreated ﬁne-grained password policies.

AWS Delegated FSx Administrators Members of this security group are provided the ability to manage Amazon FSx resources.

AWS Delegated Group Policy Administrators Members of this security group can perform group policy management tasks (create, edit, delete, link).

AWS Delegated Kerberos Delegation

Administrators Members of this security group can enable

delegation on computer and user account objects.

AWS Delegated Managed Service Account

Administrators Members of this security group can create and

delete Managed Service Accounts.

AWS Delegated MS-NPRC Non-Compliant

Devices Members of this security group will be provided

an exclusion from requiring secure channel communications with domain controllers. This group is for computer accounts.

(21)

Group name Description AWS Delegated Remote Access Service

remove RAS servers from the RAS and IAS Servers group.

AWS Delegated Replicate Directory Changes

Administrators Members of this security group can synchronize

proﬁle information in Active Directory with SharePoint Server.

AWS Delegated Server Administrators Members of this security group are included in the local administrators group on all domain joined computers.

AWS Delegated Sites and Services Administrators Members of this security group can rename the Default-First-Site-Name object in Active Directory Sites and Services.

AWS Delegated System Management

Administrators Members of this security group can create and

manage objects in the System Management container.

AWS Delegated Terminal Server Licensing

remove Terminal Server License Servers from the Terminal Server License Servers group.

AWS Delegated User Principal Name Suﬃx

remove user principal name suﬃxes.

• Creates and applies the following Group Policy Objects (GPOs):

Note

You do not have permissions to delete, modify, or unlink these GPOs. This is by design as they are reserved for AWS use. You may link them to OUs that you control if needed.

Group policy name Applies to Description

Default Domain Policy Domain Includes domain password and

Kerberos policies.

ServerAdmins All non domain controller

computer accounts Adds the 'AWS Delegated Server Administrators' as a member of the BUILTIN\Administrators Group.

AWS Reserved Policy:User AWS Reserved user accounts Sets recommended security settings on all user accounts in the AWS Reserved OU.

AWS Managed Active Directory

Policy All domain controllers Sets recommended security

settings on all domain controllers.

TimePolicyNT5DS All non PDCe domain

controllers Sets all non PDCe domain

controllers time policy to use Windows Time (NT5DS).

(22)

Group policy name Applies to Description

TimePolicyPDC The PDCe domain controller Sets the PDCe domain controller's time policy to use Network Time Protocol (NTP).

Default Domain Controllers

Policy Not used Provisioned during domain

creation, AWS Managed Active Directory Policy is used in its place.

If you would like to see the settings of each GPO, you can view them from a domain joined Windows instance with the Group policy management console (GPMC) enabled.

Admin account

When you create an AWS Directory Service for Microsoft Active Directory directory, AWS creates an organizational unit (OU) to store all AWS related groups and accounts. For more information about this OU, see What gets created (p. 12). This includes the Admin account. The Admin account has permissions to perform the following common administrative activities for your OU:

• Add, update, or delete users, groups, and computers. For more information, see Manage users and groups in AWS Managed Microsoft AD (p. 100).

• Add resources to your domain such as ﬁle or print servers, and then assign permissions for those resources to users and groups in your OU.

• Create additional OUs and containers.

• Delegate authority of additional OUs and containers. For more information, see Delegate directory join privileges for AWS Managed Microsoft AD (p. 98).

• Create and link group policies.

• Restore deleted objects from the Active Directory Recycle Bin.

• Run Active Directory and DNS Windows PowerShell modules on the Active Directory Web Service.

• Create and conﬁgure group Managed Service Accounts. For more information, see Group Managed Service Accounts (p. 20).

• Conﬁgure Kerberos constrained delegation. For more information, see Kerberos constrained delegation (p. 20).

The Admin account also has rights to perform the following domainwide activities:

• Manage DNS conﬁgurations (add, remove, or update records, zones, and forwarders)

• View DNS event logs

• View security event logs

Only the actions listed here are allowed for the Admin account. The Admin account also lacks permissions for any directory-related actions outside of your speciﬁc OU, such as on the parent OU.

Important

AWS Domain Administrators have full administrative access to all domains hosted on AWS. See your agreement with AWS and the AWS data protection FAQ for more information about how AWS handles content, including directory information, that you store on AWS systems.

(23)

Note

We recommend that you do not delete or rename this account. If you no longer want to use the account, we recommend you set a long password (at most 64 random characters) and then disable the account.

Enterprise and domain administrator privileged accounts

AWS automatically rotates the built-in Administrator password to a random password every 90 days.

Anytime the built in Administrator password is requested for human use an AWS ticket is created and logged with the AWS Directory Service team. Account credentials are encrypted and handled over secure channels. Also the Administrator account credentials can only be requested by the AWS Directory Service management team.

To perform operational management of your directory, AWS has exclusive control of accounts with Enterprise Administrator and Domain Administrator privileges. This includes exclusive control of the AD administrator account. AWS protects this account by automating password management through the use of a password vault. During automated rotation of the administrator password, AWS creates a temporary user account and grants it Domain Administrator privileges. This temporary account is used as a backup in the event of password rotation failure on the administrator account. After AWS successfully rotates the administrator password, AWS deletes the temporary administrator account.

Normally AWS operates the directory entirely through automation. In the event that an automation process is unable to resolve an operational problem, AWS may need to have a support engineer sign in to your domain controller (DC) to perform diagnosis. In these rare cases, AWS implements a request/

notiﬁcation system to grant access. In this process, AWS automation creates a time-limited user account in your directory that has Domain Administrator permissions. AWS associates the user account with the engineer who is assigned to work on your directory. AWS records this association in our log system and provides the engineer with the credentials to use. All actions taken by the engineer are logged in the Windows event logs. When the allocated time elapses, automation deletes the user account.

You can monitor administrative account actions by using the log forwarding feature of your directory.

This feature enables you to forward the AD Security events to your CloudWatch system where you can implement monitoring solutions. For more information, see Enable log forwarding (p. 55).

Security Event IDs 4624, 4672 and 4648 are all logged when someone logs onto a DC interactively. You can view each DC’s Windows Security event log using the Event Viewer Microsoft Management Console (MMC) from a domain joined Windows computer. You can also Enable log forwarding (p. 55) to send all of the Security event logs to CloudWatch Logs in your account.

You might occasionally see users created and deleted within the AWS Reserved OU. AWS is responsible for the management and security of all objects in this OU and any other OU or container where we have not delegated permissions for you to access and manage. You may see creations and deletions in that OU. This is because AWS Directory Service uses automation to rotate the Domain Administrator password on a regular basis. When the password is rotated, a backup is created in the event that the rotation fails. Once the rotation is successful, the backup account is automatically deleted. Also in the rare event that interactive access is needed on the DCs for troubleshooting purposes, a temporary user account is created for an AWS Directory Service engineer to use. Once an engineer has completed their work, the temporary user account will be deleted. Note that every time interactive credentials are requested for a directory, the AWS Directory Service management team is notiﬁed.

Key concepts for AWS Managed Microsoft AD

You'll get more out of AWS Managed Microsoft AD if you become familiar with the following key concepts.

Topics

(24)

• Active Directory schema (p. 19)

• Patching and maintenance for AWS Managed Microsoft AD (p. 20)

• Group Managed Service Accounts (p. 20)

• Kerberos constrained delegation (p. 20)

Active Directory schema

A schema is the definition of attributes and classes that are part of a distributed directory and is similar to fields and tables in a database. Schemas include a set of rules which determine the type and format of data that can be added or included in the database. The User class is one example of a class that is stored in the database. Some example of User class attributes can include the user’s first name, last name, phone number, and so on.

Schema elements

Attributes, classes and objects are the basic elements that are used to build object deﬁnitions in the schema. The following provides details about schema elements that are important to know before you begin the process to extend your AWS Managed Microsoft AD schema.

Attributes

Each schema attribute, which is similar to a field in a database, has several properties that define the characteristics of the attribute. For example, the property used by LDAP clients to read and write the attribute is LDAPDisplayName. The LDAPDisplayName property must be unique across all attributes and classes. For a complete list of attribute characteristics, see Characteristics of Attributes on the MSDN website. For additional guidance on how to create a new attribute, see Defining a New Attribute on the MSDN website.

Classes

The classes are analogous to tables in a database and also have several properties to be deﬁned.

For example, the objectClassCategory deﬁnes the class category. For a complete list of class characteristics, see Characteristics of Object Classes on the MSDN website. For more information about how to create a new class, see Deﬁning a New Class on the MSDN website.

Object identiﬁer (OID)

Each class and attribute must have an OID that is unique for all of your objects. Software vendors must obtain their own OID to ensure uniqueness. Uniqueness avoids conflicts when the same attribute is used by more than one application for different purposes. To ensure uniqueness, you can obtain a root OID from an ISO Name Registration Authority. Alternatively, you can obtain a base OID from Microsoft. For more information about OIDs and how to obtain them, see Object Identifiers on the MSDN website.

Schema linked attributes

Some attributes are linked between two classes with forward and back links. The best example is groups. When you look at a group it shows you the members of the group; if you look at a user you can see what groups it belongs to. When you add a user to a group, Active Directory creates a forward link to the group. Then Active Directory adds a back link from the group to the user. A unique link ID must be generated when creating an attribute that will be linked. For more information, see Linked Attributes on the MSDN website.

Patching and maintenance for AWS Managed Microsoft AD

AWS Directory Service for Microsoft Active Directory, also known as AWS DS for AWS Managed Microsoft AD, is actually Microsoft Active Directory Domain Services (AD DS), delivered as a managed service. The system uses Microsoft Windows Server 2012 R2 for the domain controllers (DCs), and AWS adds software to the DCs for service management purposes. AWS updates (patches) DCs to add new functionality and keep the Microsoft Windows Server software current. During the patching process, your directory remains available for use.

Ensuring availability

By default each directory consists of two DCs, each installed in a diﬀerent Availability Zone. At your option, you may add DCs to further increase availability. AWS patches your DCs sequentially, during which time the DC that AWS is actively patching is unavailable. In the event that one or more of your DCs is temporarily out of service, AWS defers patching until your directory has at least two operational DCs. This lets you use the other operating DCs during the patch process, which typically takes 30 to 45 minutes per DC, although this time may vary. To ensure your applications can reach an operating DC in the event that one or more DCs is unavailable for any reason, including patching, your applications should use the Windows DC locator service and not use static DC addresses.

Understanding the patching schedule

To keep the Microsoft Windows Server software current on your DCs, AWS utilizes Microsoft updates. As Microsoft makes monthly rollup patches available for Windows Server, AWS makes a best effort to test and apply the rollup to all customer DCs within three calendar weeks. In addition, AWS reviews updates that Microsoft releases outside of the monthly rollup based on applicability to DCs and urgency. For security patches that Microsoft rates as Critical or Important, and that are relevant to DCs, AWS makes every effort to test and deploy the patch within five days.

Group Managed Service Accounts

With Windows Server 2012, Microsoft introduced a new method that administrators could use to manage service accounts called group Managed Service Accounts (gMSAs). Using gMSAs, service administrators no longer needed to manually manage password synchronization between service instances. Instead, an administrator could simply create a gMSA in Active Directory and then conﬁgure multiple service instances to use that single gMSA.

To grant permissions so users in AWS Managed Microsoft AD can create a gMSA, you must add their accounts as a member of the AWS Delegated Managed Service Account Administrators security group. By default, the Admin account is a member of this group. For more information about gMSAs, see Group Managed Service Accounts Overview on the Microsoft TechNet website.

Related AWS Security Blog post

• How AWS Managed Microsoft AD Helps to Simplify the Deployment and Improve the Security of Active Directory–Integrated .NET Applications

Kerberos constrained delegation

Kerberos constrained delegation is a feature in Windows Server. This feature gives service administrators the ability to specify and enforce application trust boundaries by limiting the scope where application

(26)

services can act on a user’s behalf. This can be useful when you need to conﬁgure which front-end service accounts can delegate to their backend services. Kerberos constrained delegation also prevents your gMSA from connecting to any and all services on behalf of your Active Directory users, avoiding the potential for abuse by a rogue developer.

For example, let’s say user jsmith logs into an HR application. You want the SQL Server to apply jsmith’s database permissions. However, by default SQL Server opens the database connection using the service account credentials that apply hr-app-service’s permissions instead of jsmith’s conﬁgured permissions.

You must make it possible for the HR payroll application to access the SQL Server database using the jsmith’s credentials. To do that, you enable Kerberos constrained delegation for the hr-app-service service account on your AWS Managed Microsoft AD directory in AWS. When jsmith logs on, Active Directory provides a Kerberos ticket that Windows automatically uses when jsmith attempts to access other services in the network. Kerberos delegation enables the hr-app-service account to reuse the jsmith Kerberos ticket when accessing the database, thus applying permissions speciﬁc to jsmith when opening the database connection.

To grant permissions that allow users in AWS Managed Microsoft AD to conﬁgure Kerberos constrained delegation, you must add their accounts as a member of the AWS Delegated Kerberos Delegation Administrators security group. By default, the Admin account is a member of this group. For more information about Kerberos constrained delegation, see Kerberos Constrained Delegation Overview on the Microsoft TechNet website.

Resource-based constrained delegation was introduced with Windows Server 2012. It provides the backend service administrator the ability to conﬁgure constrained delegation for the service.

Use cases for AWS Managed Microsoft AD

With AWS Managed Microsoft AD, you can share a single directory for multiple use cases. For example, you can share a directory to authenticate and authorize access for .NET applications, Amazon RDS for SQL Server with Windows authentication enabled, and Amazon Chime for messaging and video conferencing.

The following diagram shows some of the use cases for your AWS Managed Microsoft AD directory.

These include the ability to grant your users access to external cloud applications and allow your on- premises AD users to manage and have access to resources in the AWS Cloud.

(27)

Use AWS Managed Microsoft AD for either of the following business use cases.

Topics

• Use Case 1: Sign in to AWS applications and services with AD credentials (p. 23)

• Use Case 2: Manage Amazon EC2 instances (p. 26)

• Use Case 3: Provide directory services to your AD-aware workloads (p. 26)

• Use Case 4: SSO to Oﬃce 365 and other cloud applications (p. 26)

• Use Case 5: Extend your on-premises AD to the AWS Cloud (p. 27)

(28)

• Use Case 6: Share your directory to seamlessly join Amazon EC2 instances to a domain across AWS accounts (p. 28)

Use Case 1: Sign in to AWS applications and services with AD credentials

You can enable multiple AWS applications and services such as AWS Client VPN, AWS Management Console, AWS Single Sign-On, Amazon Chime, Amazon Connect, Amazon FSx, Amazon QuickSight, Amazon RDS for SQL Server, Amazon WorkDocs, Amazon WorkMail, and WorkSpaces to use your AWS Managed Microsoft AD directory. When you enable an AWS application or service in your directory, your users can access the application or service with their AD credentials.

For example, you can enable your users to sign in to the AWS Management Console with their AD credentials. To do this, you enable the AWS Management Console as an application in your directory, and then assign your AD users and groups to IAM roles. When your users sign in to the AWS Management Console, they assume an IAM role to manage AWS resources. This makes it easy for you to grant your users access to the AWS Management Console without needing to conﬁgure and manage a separate SAML infrastructure.

To further enhance the end user experience you can enable Single sign-on (SSO) capabilities for Amazon WorkDocs, which provides your users the ability to access Amazon WorkDocs from a computer joined to the directory without having to enter their credentials separately.

You can grant access to user accounts in your directory or in your on-premises AD, so they can sign in to the AWS Management Console or through the AWS CLI using their existing credentials and permissions to manage AWS resources by assigning IAM roles directly to the existing user accounts.

FSx for Windows File Server integration with AWS Managed Microsoft AD

Integrating FSx for Windows File Server with AWS Managed Microsoft AD provides a fully managed native Microsoft Windows based Server Message Block (SMB) protocol ﬁle system that allows you to easily move your Windows-based applications and clients (that utilize shared ﬁle storage) to AWS.

Although FSx for Windows File Server can be integrated with a self-managed Microsoft Active Directory, we do not discuss that scenario here.

Common Amazon FSx use cases and resources

This section provides a reference to resources on common FSx for Windows File Server integrations with AWS Managed Microsoft AD use cases. Each of the use cases in this section start with a basic AWS Managed Microsoft AD and FSx for Windows File Server conﬁguration. For more information about how to create these conﬁgurations, see:

• Getting started with Amazon FSx

FSx for Windows File Server as persistent storage on Windows containers

Amazon Elastic Container Service (ECS) supports Windows containers on container instances that are launched with the Amazon ECS-optimized Windows AMI. Windows container instances use their own version of the Amazon ECS container agent. On the Amazon ECS-optimized Windows AMI, the Amazon ECS container agent runs as a service on the host.

(29)

Amazon ECS supports Active Directory authentication for Windows containers through a special kind of service account called a group Managed Service Account (gMSA). Because Windows containers cannot be domain-joined, you must conﬁgure a Windows container to run with gMSA.

Related Items

• Using FSx for Windows File Server as persistent storage on Windows Containers

• Group Managed Service Accounts

Amazon AppStream 2.0 support

Amazon AppStream 2.0 is a fully managed application streaming service. It provides a range of solutions for users to save and access data through their applications. Amazon FSx with AppStream 2.0 provides a personal persistent storage drive using Amazon FSx and can be conﬁgured to provide a shared folder to access common ﬁles.

Related Items

• Walkthrough 4: Using Amazon FSx with Amazon AppStream 2.0

• Using Amazon FSx with Amazon AppStream 2.0

• Using Active Directory with AppStream 2.0

Microsoft SQL Server support

FSx for Windows File Server can be used as a storage option for Microsoft SQL Server 2012 (starting with 2012 version 11.x) and newer system databases (including Master, Model, MSDB, and TempDB), and for Database Engine user databases.

Related Items

• Install SQL Server with SMB ﬁleshare storage

• Simplify your Microsoft SQL Server high availability deployments using FSx for Windows File Server

• Group Managed Service Accounts

Home folders and roaming user proﬁle support

FSx for Windows File Server can be used to store data from Active Directory user home folders and My Documents in a central location. FSx for Windows File Server can also be used to store data from Roaming User Proﬁles.

Related items

• Windows home directories made easy with Amazon FSx

• Deploying roaming user proﬁles

• Using FSx for Windows File Server with WorkSpaces

Networked ﬁle share support

Networked ﬁle shares on an FSx for Windows File Server provide a managed and scalable ﬁle sharing solution. One use case is mapped drives for clients that can be created manually or via Group Policy.

Related items

• Walkthrough 6: Scaling out performance with Shards

(30)

• Drive mapping

• Using FSx for Windows File Server with WorkSpaces

Group policy software installation support

Because the size and performance of the SYSVOL folder is limited, you should as a best practice, avoid storing data such as software installation files in that folder. As a possible solution to this, FSx for Windows File Server can be configured to store all software files that are installed using Group Policy.

Related items

• How to use Group Policy to remotely install software in Windows Server 2008 and in Windows Server 2003

Windows Server Backup target support

FSx for Windows File Server can be conﬁgured as a target drive in Windows Server Backup using the UNC ﬁle share. In this case, you would specify the UNC path to your FSx for Windows File Server instead of to the attached EBS volume.

Related Items

• Perform a system state recovery of your server

Amazon FSx also supports AWS Managed Microsoft AD Directory Sharing. For more information, see:

• Share your directory (p. 63)

• Using Amazon FSx with AWS Managed Microsoft AD in a diﬀerent VPC or account

Amazon RDS integration with AWS Managed Microsoft AD

Amazon RDS supports external authentication of database users using Kerberos with Microsoft Active Directory. Kerberos is a network authentication protocol that uses tickets and symmetric-key cryptography to eliminate the need to transmit passwords over the network. Amazon RDS support for Kerberos and Active Directory provides the beneﬁts of single sign-on and centralized authentication of database users so you can keep your user credentials in Active Directory.

To get started with this use case you'll ﬁrst need to set up a basic AWS Managed Microsoft AD and Amazon RDS conﬁguration.

• Getting started with Amazon RDS

All of the use cases referenced below will start with a base AWS Managed Microsoft AD and Amazon RDS and cover how to integrate Amazon RDS with AWS Managed Microsoft AD .

• Using Windows authentication with an Amazon RDS for SQL Server DB instance

• Using Kerberos authentication for MySQL

• Using Kerberos authentication with Amazon RDS for Oracle

• Using Kerberos authentication with Amazon RDS for PostgreSQL

Amazon RDS also supports AWS Managed Microsoft AD Directory Sharing. For more information, see:

AWS Directory Service

AWS Directory Service

Administration Guide

Version 1.0

AWS Directory Service: Administration Guide

Table of Contents

What is AWS Directory Service?

Which to choose

AWS Directory Service options

Working with Amazon EC2

Setting up AWS Directory Service

Sign up for an AWS account

To sign up for an AWS account

Create an IAM user

To create an administrator user for yourself and add the user to an administrators group (console)

Note

Note

AWS Managed Microsoft AD

Note

Getting started with AWS Managed Microsoft AD

AWS Managed Microsoft AD prerequisites

AWS Single Sign-On prerequisites

Multi-factor authentication prerequisites

Note

Create your AWS Managed Microsoft AD directory

To create an AWS Managed Microsoft AD directory

What gets created

Note

Note

Important

Note

Admin account

Important

Note

Enterprise and domain administrator privileged accounts

Key concepts for AWS Managed Microsoft AD

Active Directory schema

Schema elements

Related topics

Patching and maintenance for AWS Managed Microsoft AD

Ensuring availability

Understanding the patching schedule

Group Managed Service Accounts

Kerberos constrained delegation

Use cases for AWS Managed Microsoft AD

Use Case 1: Sign in to AWS applications and services with AD credentials

FSx for Windows File Server integration with AWS Managed Microsoft AD

Common Amazon FSx use cases and resources

Amazon RDS integration with AWS Managed Microsoft AD