# Using Active Directory with WorkSpaces Applications
You can join your Amazon WorkSpaces Applications Always-On and On-Demand Windows fleets and image builders to domains in Microsoft Active Directory and use your existing Active Directory domains, either cloud-based or on-premises, to launch domain-joined streaming instances. You can also use AWS Directory Service for Microsoft Active Directory, also known as AWS Managed Microsoft AD, to create an Active Directory domain and use that to support your WorkSpaces Applications resources. For more information about using AWS Managed Microsoft AD, see [Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) in the *AWS Directory Service Administration Guide*.
**Note**
Amazon Linux 2 fleets, image builders, elastic fleets, and app block builders currently do not support domain join.
By joining WorkSpaces Applications to your Active Directory domain, you can:
+ Allow your users and applications to access Active Directory resources such as printers and file shares from streaming sessions.
+ Use Group Policy settings that are available in the Group Policy Management Console (GPMC) to define the end user experience.
+ Stream applications that require users to be authenticated using their Active Directory login credentials.
+ Apply your enterprise compliance and security policies to your WorkSpaces Applications streaming instances.
**Topics**
+ [Overview of Active Directory Domains](active-directory-overview.md)
+ [Before You Begin Using Active Directory with Amazon WorkSpaces Applications](active-directory-prerequisites.md)
+ [Tutorial: Setting Up Active Directory](active-directory-directory-setup.md)
+ [Certificate-Based Authentication](certificate-based-authentication.md)
+ [WorkSpaces Applications Active Directory Administration](active-directory-admin.md)
+ [More Info](active-directory-more-info.md)
# Overview of Active Directory Domains
Using Active Directory domains with WorkSpaces Applications requires an understanding of how they work together and the configuration tasks that you'll need to complete. You'll need to complete the following tasks:
1. Configure Group Policy settings as needed to define the end user experience and security requirements for applications.
1. Create the domain-joined application stack in WorkSpaces Applications.
1. Create the WorkSpaces Applications application in the SAML 2.0 identity provider and assign it to end users either directly or through Active Directory groups.
For your users to be authenticated to a domain, several steps must occur when these users initiate an WorkSpaces Applications streaming session. The following diagram illustrates the end-to-end user authentication flow from the initial browser request through SAML and Active Directory authentication.
![\[Authentication flow diagram showing steps from user login to AWSWorkSpaces Applications session start.\]](http://docs.aws.amazon.com/appstream2/latest/developerguide/images/domain-join-UPDATED.png)
**User Authentication Flow**
1. The user browses to `https://applications.exampleco.com`. The sign-on page requests authentication for the user.
1. The federation service requests authentication from the organization's identity store.
1. The identity store authenticates the user and returns the authentication response to the federation service.
1. On successful authentication, the federation service posts the SAML assertion to the user's browser.
1. The user's browser posts the SAML assertion to the AWS Sign-In SAML endpoint (`https://signin.aws.amazon.com/saml`). AWS Sign-In receives the SAML request, processes the request, authenticates the user, and forwards the authentication token to the WorkSpaces Applications service.
1. Using the authentication token from AWS, WorkSpaces Applications authorizes the user and presents applications to the browser.
1. The user chooses an application and, depending on the Windows login authentication method that is enabled on the WorkSpaces Applications stack, they're prompted to enter their Active Directory domain password or choose a smart card. If both authentication methods are enabled, the user can choose whether to enter their domain password or use their smart card. Certificate-based authentication can also be used to authenticate users, removing the prompt.
1. The domain controller is contacted for user authentication.
1. After being authenticated with the domain, the user's session starts with domain connectivity.
From the user's perspective, this process is transparent. The user starts by navigating to your organization's internal portal and is redirected to an WorkSpaces Applications application portal, without having to enter AWS credentials. Only an Active Directory domain password or smart card credentials are required.
Before a user can initiate this process, you must configure Active Directory with the required entitlements and Group Policy settings and create a domain-joined application stack.
# Before You Begin Using Active Directory with Amazon WorkSpaces Applications
Before you use Microsoft Active Directory domains with WorkSpaces Applications, be aware of the following requirements and considerations.
**Topics**
+ [Active Directory Domain Environment](active-directory-prerequisites-domain-environment.md)
+ [Domain-Joined WorkSpaces Applications Streaming Instances](active-directory-prerequisites-streaming-instances.md)
+ [Group Policy Settings](active-directory-prerequisites-group-policy-settings.md)
+ [Smart Card Authentication](active-directory-prerequisites-smart-card-authentication.md)
# Active Directory Domain Environment
Your active directory domain environment must meet the following requirements.
+ You must have a Microsoft Active Directory domain to which to join your streaming instances. If you don't have an Active Directory domain or you want to use your on-premises Active Directory environment, see [Active Directory Domain Services on AWS Partner Solution Deployment Guide](https://aws-solutions-library-samples.github.io/cfn-ps-microsoft-activedirectory/).
+ You must have a domain service account with permissions to create and manage computer objects in the domain that you intend to use with WorkSpaces Applications. For information, see [How to Create a Domain Account in Active Directory](https://msdn.microsoft.com/en-us/library/aa545262(v=cs.70).aspx) in the Microsoft documentation.
When you associate this Active Directory domain with WorkSpaces Applications, provide the service account name and password. WorkSpaces Applications uses this account to create and manage computer objects in the directory. For more information, see [Granting Permissions to Create and Manage Active Directory Computer Objects](active-directory-permissions.md).
+ When you register your Active Directory domain with WorkSpaces Applications, you must provide an organizational unit (OU) distinguished name. Create an OU for this purpose. The default Computers container is not an OU and cannot be used by WorkSpaces Applications. For more information, see [Finding the Organizational Unit Distinguished Name](active-directory-oudn.md).
+ The directories that you plan to use with WorkSpaces Applications must be accessible through their fully qualified domain names (FQDNs) through the virtual private cloud (VPC) in which your streaming instances are launched. For more information, see [Active Directory and Active Directory Domain Services Port Requirements](https://technet.microsoft.com/en-us/library/dd772723.aspx) in the Microsoft documentation.
+ Domain controller access can also be supported over IPv6, and require [DHCP options set updates](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html).
# Domain-Joined WorkSpaces Applications Streaming Instances
SAML 2.0-based user federation is required for application streaming from domain-joined Always-On and On-Demand fleets. You cannot launch sessions to domain-joined instances by using [CreateStreamingURL](https://docs.aws.amazon.com/appstream2/latest/APIReference/API_CreateStreamingURL.html) or the WorkSpaces Applications user pool.
Also, you must use an image that supports joining image builders and fleets to an Active Directory domain. All public images published on or after July 24, 2017 support joining an Active Directory domain. For more information, see [WorkSpaces Applications Base Image and Managed Image Update Release Notes](base-image-version-history.md) and [Tutorial: Setting Up Active Directory](active-directory-directory-setup.md).
**Note**
You can join Always-On and On-Demand fleet streaming instances to an Active Directory domain. Supported operating systems include Windows, Red Hat Enterprise Linux, and Rocky Linux.
# Group Policy Settings
Verify your configuration for the following Group Policy settings. If required, update the settings as described in this section so that they don't block WorkSpaces Applications from authenticating and logging in your domain users. Otherwise, when your users try to log in to WorkSpaces Applications the login may not succeed. Instead, a message displays, notifying users that "An unknown error occurred."
+ **Computer Configuration > Administrative Templates > Windows Components > Windows Logon Options > Disable or Enable software Secure Attention Sequence** — Set this to **Enabled** for **Services**.
+ **Computer Configuration > Administrative Templates > System > Logon > Exclude credential providers** — Ensure that the following CLSID are *not* listed: `e7c1bab5-4b49-4e64-a966-8d99686f8c7c` and `f148bAed-5f7f-40c9-8D48-51e24e571825`
+ **Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Interactive Logon > Interactive Logon: Message text for users attempting to log on** — Set this to **Not defined**.
+ **Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Interactive Logon > Interactive Logon: Message title for users attempting to log on** — Set this to **Not defined**.
+ **Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Allow log on locally** — Set this to **Not defined** or add the domain user/group to this list.
+ **Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Deny log on locally** — Set this to **Not defined** or make sure that domain users/groups are not included in the list.
If you are using multi-session fleets, you also need the following Group Policy settings, in addition to the settings specified above.
+ **Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Allow log on through Remote Desktop Services** — Set this to **Not defined** or add the domain user/group to this list.
+ **Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Deny log on through Remote Desktop Services** — Set this to **Not defined** or make sure that domain users/groups are not included in the list.
# Smart Card Authentication
WorkSpaces Applications supports the use of Active Directory domain passwords or smart cards such as [Common Access Card (CAC)](https://www.cac.mil/Common-Access-Card) and [Personal Identity Verification (PIV)](https://piv.idmanagement.gov/) smart cards for Windows sign in to WorkSpaces Applications streaming instances. For information about how to configure your Active Directory environment to enable smart card sign in by using third-party certification authorities (CAs), see [Guidelines for enabling smart card logon with third-party certification authorities](https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/enabling-smart-card-logon-third-party-certification-authorities) in the Microsoft documentation.
**Note**
WorkSpaces Applications also supports the use of smart cards for in-session authentication after a user signs in to a streaming instance. This feature is supported only for users who have WorkSpaces Applications client for Windows version 1.1.257 or later installed. For information about additional requirements, see [Smart Cards](feature-support-USB-devices-qualified.md#feature-support-USB-devices-qualified-smart-cards).
# Tutorial: Setting Up Active Directory
To use Active Directory with WorkSpaces Applications, you must first register your directory configuration by creating a Directory Config object in WorkSpaces Applications. This object includes the information required to join streaming instances to an Active Directory domain. You create a Directory Config object by using the WorkSpaces Applications management console, AWS SDK, or AWS CLI. You can then use your directory configuration to launch domain-joined Always-On and On-Demand fleets and image builders.
**Note**
You can only join Always-On and On-Demand fleet streaming instances to an Active Directory domain.
**Topics**
+ [Step 1: Create a Directory Config Object](#active-directory-setup-config)
+ [Step 2: Create an Image by Using a Domain-Joined Image Builder](#active-directory-setup-image-builder)
+ [Step 3: Create a Domain-Joined Fleet](#active-directory-setup-fleet)
+ [Step 4: Configure SAML 2.0](#active-directory-setup-saml)
## Step 1: Create a Directory Config Object
The Directory Config object that you create in WorkSpaces Applications will be used in later steps.
If you are using the AWS SDK, you can use the [CreateDirectoryConfig](https://docs.aws.amazon.com/appstream2/latest/APIReference/API_CreateDirectoryConfig.html) operation. If you are using the AWS CLI, you can use the [create-directory-config](https://docs.aws.amazon.com/cli/latest/reference/appstream/create-directory-config.html) command.
**To create a Directory Config object by using the WorkSpaces Applications console**
1. Open the WorkSpaces Applications console at [https://console.aws.amazon.com/appstream2](https://console.aws.amazon.com/appstream2).
1. In the navigation pane, choose **Directory Configs**, **Create Directory Config**.
1. For **Directory Name**, provide the fully qualified domain name (FQDN) of the Active Directory domain (for example, `corp.example.com`). Each region can have only one **Directory Config** value with a specific directory name.
1. For **Service Account Name**, enter the name of an account that can create computer objects and that has permissions to join the domain. For more information, see [Granting Permissions to Create and Manage Active Directory Computer Objects](active-directory-permissions.md). The account name must be in the format `DOMAIN\username`.
1. For **Password** and **Confirm Password**, type the directory password for the specified account.
1. For **Organizational Unit (OU)**, type the distinguished name of at least one OU for streaming instance computer objects.
**Note**
The OU name can't contain spaces. If you specify an OU name that contains spaces, when a fleet or image builder attempts to rejoin the Active Directory domain, WorkSpaces Applications cannot cycle the computer objects correctly and the domain rejoin does not succeed. For information about how to troubleshoot this issue, see the *DOMAIN\$1JOIN\$1INTERNAL\$1SERVICE\$1ERROR* topic for "The account already exists" message in [Active Directory Domain Join](troubleshooting-notification-codes.md#troubleshooting-notification-codes-ad).
In addition, the default Computers container is not an OU and cannot be used by WorkSpaces Applications. For more information, see [Finding the Organizational Unit Distinguished Name](active-directory-oudn.md).
1. To add more than one OU, select the plus sign (**\$1**) next to **Organizational Unit (OU)**. To remove OUs, choose the **x** icon.
1. Choose **Next**.
1. Review the configuration information and choose **Create**.
## Step 2: Create an Image by Using a Domain-Joined Image Builder
Next, using the WorkSpaces Applications image builder, create a new image with Active Directory domain-join capabilities. Note that the fleet and image can be members of different domains. You join the image builder to a domain to enable domain join and to install applications. Fleet domain join is discussed in the next section.
**To create an image for launching domain-joined fleets**
1. Follow the procedures in [Tutorial: Create a Custom WorkSpaces Applications Image by Using the WorkSpaces Applications Console](tutorial-image-builder.md).
1. For the base image selection step, use an AWS base image released on or after July 24, 2017. For a current list of released AWS images, see [WorkSpaces Applications Base Image and Managed Image Update Release Notes](base-image-version-history.md).
1. For **Step 3: Configure Network**, select a VPC and subnets with network connectivity to your Active Directory environment. Select the security groups that are set up to allow access to your directory through your VPC subnets.
1. Also in **Step 3: Configure Network**, expand the **Active Directory Domain (Optional)** section, and select values for the **Directory Name** and **Directory OU** to which the image builder should be joined.
1. Review the image builder configuration and choose **Create**.
1. Wait for the new image builder to reach a **Running** state, and choose **Connect**.
1. Log in to the image builder in Administrator mode or as a directory user with local administrator permissions. For more information, see [Granting Local Administrator Rights on Image Builders](active-directory-image-builder-local-admin.md).
1. Complete the steps in [Tutorial: Create a Custom WorkSpaces Applications Image by Using the WorkSpaces Applications Console](tutorial-image-builder.md) to install applications and create a new image.
## Step 3: Create a Domain-Joined Fleet
Using the private image created in the previous step, create an Active Directory domain-joined Always-On or On-Demand fleet for streaming applications. The domain can be different than the one that you used for the image builder to create the image.
**To create a domain-joined Always-On or On-Demand fleet**
1. Follow the procedures in [Create a Fleet in Amazon WorkSpaces Applications](set-up-stacks-fleets-create.md).
1. For the image selection step, use the image that was created in the previous step, [Step 2: Create an Image by Using a Domain-Joined Image Builder](#active-directory-setup-image-builder).
1. For **Step 4: Configure Network**, select a VPC and subnets with network connectivity to your Active Directory environment. Select the security groups that are set up to allow communication to your domain.
1. Also in **Step 4: Configure Network**, expand the **Active Directory Domain (Optional)** section and select the values for the **Directory Name** and **Directory OU** to which the fleet should be joined.
1. Review the fleet configuration and choose **Create**.
1. Complete the remaining steps in [Create an Amazon WorkSpaces Applications Fleet and Stack](set-up-stacks-fleets.md) so that your fleet is associated with a stack and running.
## Step 4: Configure SAML 2.0
Your users must use your SAML 2.0-based identity federation environment to launch streaming sessions from your domain-joined fleet.
**To configure SAML 2.0 for single sign-on access**
1. Follow the procedures in [Setting Up SAML](external-identity-providers-setting-up-saml.md).
1. WorkSpaces Applications requires that the SAML\$1Subject `NameID` value for the user who is logging in be provided in either of the following formats:
+ `domain\username` using the sAMAccountName
+ `username@domain.com` using the userPrincipalName
If you are using the sAMAccountName format, you can specify the `domain` by using either the NetBIOS name or the fully qualified domain name (FQDN).
1. Provide access to your Active Directory users or groups to enable access to the WorkSpaces Applications stack from your identity provider application portal.
1. Complete the remaining steps in [Setting Up SAML](external-identity-providers-setting-up-saml.md).
**To log in a user with SAML 2.0**
1. Log in to your SAML 2.0 provider's application catalog and open the WorkSpaces Applications SAML application that you created in the previous procedure.
1. When the WorkSpaces Applications application catalog is displayed, select an application to launch.
1. When a loading icon is displayed, you are prompted to provide a password. The domain user name provided by your SAML 2.0 identity provider appears above the password field. Enter your password, and choose **log in**.
The streaming instance performs the Windows login procedure, and the selected application opens.
# Certificate-Based Authentication
You can use certificate-based authentication with WorkSpaces Applications fleets joined to Microsoft Active Directory. This removes the user prompt for the Active Directory domain password when a user logs in. By using certificate-based authentication with your Active Directory domain, you can:
+ Rely on your SAML 2.0 identity provider to authenticate the user and provide SAML assertions to match the user in Active Directory.
+ Create a single sign-on logon experience with fewer user prompts.
+ Enable passwordless authentication flows using your SAML 2.0 identity provider.
Certificate-based authentication uses AWS Private Certificate Authority (AWS Private CA) resources in your AWS account. With AWS Private CA, you can create private certificate authority (CA) hierarchies, including root and subordinate CAs. You can also create your own CA hierarchy and issue certificates from it that authenticate internal users. For more information, see [What is AWS Private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html).
When you use AWS Private CA for certificate-based authentication, WorkSpaces Applications requests certificates for your users automatically at session reservation for each WorkSpaces Applications fleet instance. It authenticates users to Active Directory with a virtual smart card provisioned with the certificates.
Certificate-based authentication (CBA) is supported on WorkSpaces Applications domain-joined fleets (both single-session and multi-session fleets) that run Windows instances. To enable CBA on multi-session fleets, you must use an WorkSpaces Applications image that uses an WorkSpaces Applications agent released on or after 02-07-2025. Or, your image must use managed WorkSpaces Applications image updates released on or after 02-11-2025.
**Topics**
+ [Prerequisites](certificate-based-authentication-prereq.md)
+ [Enable Certificate-based Authentication](certificate-based-authentication-enable.md)
+ [Manage Certificate-based Authentication](certificate-based-authentication-manage.md)
+ [Enable Cross-account PCA Sharing](pca-sharing.md)
# Prerequisites
Complete the following steps before you use certificate-based authentication.
1. Set up a domain-joined fleet and configure SAML 2.0. Ensure that you use the `username@domain.com` `userPrincipalName` format for the SAML\$1Subject `NameID`. For more information, see [Step 5: Create Assertions for the SAML Authentication Response](external-identity-providers-setting-up-saml.md#external-identity-providers-create-assertions).
**Note**
Don't enable **Smart card sign in for Active Directory** in your stack if you want to use certificate-based authentication. For more information, see [Smart Cards](feature-support-USB-devices-qualified.md#feature-support-USB-devices-qualified-smart-cards).
1. Use WorkSpaces Applications agent version 10-13-2022 or later with your image. For more information, see [Keep Your Amazon WorkSpaces Applications Image Up-to-Date](keep-image-updated.md).
1. Configure the `ObjectSid` attribute in your SAML assertion. You can use this attribute to perform strong mapping with the Active Directory user. Certificate-based authentication fails if the `ObjectSid` attribute doesn't match the Active Directory security identifier (SID) for the user specified in the SAML\$1Subject `NameID`. For more information, see [Step 5: Create Assertions for the SAML Authentication Response](external-identity-providers-setting-up-saml.md#external-identity-providers-create-assertions). The `ObjectSid` is mandatory for certificate-based authentication after September 10, 2025. For more information, see [KB5014754: Certificate-based authentication changes on Windows domain controllers](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16).
1. Add the `sts:TagSession` permission to the IAM role trust policy that you use with your SAML 2.0 configuration. For more information, see [Passing session tags in AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html.html). This permission is required to use certificate-based authentication. For more information, see [Step 2: Create a SAML 2.0 Federation IAM Role](external-identity-providers-setting-up-saml.md#external-identity-providers-grantperms).
1. Create a private certificate authority (CA) using AWS Private CA, if you don't have one configured with your Active Directory. AWS Private CA is required to use certificate-based authentication. For more information, see [Planning your AWS Private CA deployment](https://docs.aws.amazon.com/privateca/latest/userguide/PcaPlanning.html). The following AWS Private CA settings are common for many certificate-based authentication use cases:
+ **CA type options**
+ **Short-lived certificate CA usage mode** – Recommended if the CA only issues end user certificates for certificate-based authentication.
+ **Single level hierarchy with a Root CA** – Choose a subordinate CA to integrate it with an existing CA hierarchy.
+ **Key algorithm options** – RSA 2048
+ **Subject distinguished name options** – Use the most appropriate options to identify this CA in your Active Directory Trusted Root Certification Authorities store.
+ **Certificate revocation options** – CRL distribution
**Note**
Certificate-based authentication requires an online CRL distribution point accessible from both the WorkSpaces Applications fleet instance and the domain controller. This requires unauthenticated access to the Amazon S3 bucket configured for AWS Private CA CRL entries, or a CloudFront distribution with access to the Amazon S3 bucket if it blocks public access. For more information about these options, see [Planning a certificate revocation list (CRL)](https://docs.aws.amazon.com/privateca/latest/userguide/crl-planning.html).
1. Tag your private CA with a key entitled `euc-private-ca` to designate the CA for use with WorkSpaces Applications certificate-based authentication. This key doesn't require a value. For more information, see [Managing tags for your private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCaTagging.html). For more information about the AWS managed policies used with WorkSpaces Applications to grant permissions to resources in your AWS account, see [AWS Managed Policies Required to Access WorkSpaces Applications Resources](managed-policies-required-to-access-appstream-resources.md).
1. Certificate-based authentication uses virtual smart cards to log on. For more information, see [Guidelines for enabling smart card logon with third-party certification authorities](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/enabling-smart-card-logon-third-party-certification-authorities). Follow these steps:
1. Configure domain controllers with a domain controller certificate to authenticate smart card users. If you have an Active Directory Certificate Services enterprise CA configured in your Active Directory, it automatically enrolls domain controllers with certificates that enable smart card logon. If you don't have Active Directory Certificate Services, see [Requirements for domain controller certificates from a third-party CA](https://learn.microsoft.com/en-US/troubleshoot/windows-server/windows-security/requirements-domain-controller). AWS recommends Active Directory enterprise certificate authorities to automatically manage enrollment for domain controller certificates.
**Note**
If you use AWS Managed Microsoft AD, you can configure Certificate Services on an Amazon EC2 instance that satisfies the requirement for domain controller certificates. See [Deploy Active Directory to a new Amazon Virtual Private Cloud](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-ad-deploying-new-vpc.html) for example deployments of AWS Managed Microsoft AD configured with Active Directory Certificate Services.
With AWS Managed Microsoft AD and Active Directory Certificate Services, you must also create outbound rules from the controller's VPC security group to the Amazon EC2 instance running Certificate Services. You must provide the security group access to TCP port 135, and ports 49152 through 65535 to enable certificate auto-enrollment. The Amazon EC2 instance must also allow inbound access on these same ports from domain instances, including domain controllers. For more information on locating the security group for AWS Managed Microsoft AD, see [Configure your VPC subnets and security groups](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_setup_trust_prepare_mad.html#tutorial_setup_trust_open_vpc).
1. On the AWS Private CA console, or with the SDK or CLI, export the private CA certificate. For more information, see [Exporting a private certificate](https://docs.aws.amazon.com/acm/latest/userguide/export-private.html).
1. Publish the private CA to Active Directory. Log on to a domain controller or a domain-joined machine. Copy the private CA certificate to any `\` and run the following commands as a domain administrator. You can also use Group Policy and the Microsoft PKI Health Tool (PKIView) to publish the CA. For more information, see [Configuration instructions](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/enabling-smart-card-logon-third-party-certification-authorities#configuration-instructions).
```
certutil -dspublish -f \ RootCA
```
```
certutil -dspublish -f \ NTAuthCA
```
Make sure that the commands complete successfully, then remove the private CA certificate file. Depending on your Active Directory replication settings, it can take several minutes for the CA to publish to your domain controllers and WorkSpaces Applications fleet instances.
**Note**
Active Directory must distribute the CA to the Trusted Root Certification Authorities and Enterprise NTAuth stores automatically for WorkSpaces Applications fleet instances when they join the domain.
For Windows operating systems, the distribution of the CA (Certificate Authority) happens automatically. However, for Rocky Linux and Red Hat Enterprise Linux, you must download the root CA certificate(s) from the CA used by your WorkSpaces Applications Directory Config. If your KDC root CA certificate(s) are different, you must also download those. Before using certificate-based authentication, it's necessary to import these certificates onto an image or snapshot.
On the image, there should be a file named /`etc/sssd/pki/sssd_auth_ca_db.pem`. It should look like the following:
```
-----BEGIN CERTIFICATE-----
Base64-encoded certificate chain from ACM Private CA
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64-encoded certificate body from ACM private CA
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64-encoded root CA KDC certificate chain
-----END CERTIFICATE-----
```
**Note**
When copying an image across regions or accounts, or re-associating an image with a new Active Directory, this file will need to be reconfigured with the relevant certificates on an image builder and snapshotted again before use.
Below are instructions for downloading the root CA certificates:
1. On the image builder, create a file named `/etc/sssd/pki/sssd_auth_ca_db.pem`.
1. Open the [AWS Private CA console](https://console.aws.amazon.com/acm-pca/).
1. Choose the private certificate used with your WorkSpaces Applications Directory Config.
1. Choose the **CA certificate** tab.
1. Copy the certificate chain and certificate body to `/etc/sssd/pki/sssd_auth_ca_db.pem` on the image builder.
If the root CA certificates used by the KDCs are different from the root CA certificate used by your WorkSpaces Applications Directory Config, follow these example steps to download them:
1. Connect to a Windows instance joined to the same domain as your image builder.
1. Open `certlm.msc`.
1. In the left pane, choose **Trusted Root Certificate Authorities**, and then choose **Certificates**..
1. For each root CA certificate, open the context (right-click) menu.
1. Choose **All Tasks**, choose **Export** to open the Certificate Export Wizard, and then choose **Next**.
1. Choose **Base64-encoded X.509 (.CER)**, and choose **Next**.
1. Choose **Browse**, enter a file name, and choose **Next**.
1. Choose **Finish**.
1. Open the exported certificate in a text editor.
1. Copy the contents of the file to `/etc/sssd/pki/sssd_auth_ca_db.pem` on the image builder.
# Enable Certificate-based Authentication
Complete the following steps to enable certificate-based authentication.
**To enable certificate-based authentication**
1. Open the WorkSpaces Applications console at [https://console.aws.amazon.com/appstream2](https://console.aws.amazon.com/appstream2).
1. In the navigation pane, choose **Directory Configs**. Select the directory config you want to configure, and choose **Edit**.
1. Choose **Enable Certificate-Based Authentication.**
1. Confirm that your private CA ARN is associated in the list. To appear in the list, you should store the private CA in the same AWS account and AWS Region. You must also tag the private CA with a key named `euc-private-ca`.
1. Configure directory log in fallback. With Fallback, users can log in with their AD domain password if certificate-based authentication is unsuccessful. This is recommended only in cases where users know their domain passwords. When fallback is turned off, a session can disconnect the user if a lock screen or Windows log off occurs. If fallback is turned on, the session prompts the user for their AD domain password.
1. Choose **Save Changes**.
1. Certificate-based authentication is now enabled. When users authenticate with SAML 2.0 to an WorkSpaces Applications stack using the domain-joined fleet from the WorkSpaces Applications web client or the client for Windows (version 1.1.1099 and later), they will no longer receive a prompt for the domain password. Users will see a “Connecting with certificate-based authentication...” message when connecting to a session enabled for certificate-based authentication.
# Manage Certificate-based Authentication
After you enable certificate-based authentication, review the following tasks.
**Topics**
+ [Private CA Certificate](certificate-based-authentication-manage-CA.md)
+ [End User Certificates](certificate-based-authentication-manage-certs.md)
+ [Audit Reports](certificate-based-authentication-manage-audit.md)
+ [Logging and Monitoring](certificate-based-authentication-manage-logging.md)
# Private CA Certificate
In a typical configuration, the private CA certificate has a validity period of 10 years. For more information about replacing a private CA with an expired certificate, or reissuing the private CA with a new validity period, see [Managing the private CA lifecycle ](https://docs.aws.amazon.com/privateca/latest/userguide/ca-lifecycle.html)
# End User Certificates
End user certificates issued by AWS Private CA for WorkSpaces Applications certificate-based authentication don't require renewal or revocation. These certificates are short-lived. WorkSpaces Applications automatically issues a new certificate for each new session, or every 24 hours for sessions with a long duration. The WorkSpaces Applications session governs the use of these end user certificates. If you end a session, WorkSpaces Applications stops using that certificate. These end user certificates have a shorter validity period than a typical AWS Private CA CRL distribution. As a result, end user certificates don't need to be revoked and won't appear in a CRL.
# Audit Reports
You can create an audit report to list all of the certificates that your private CA has issued or revoked. For more information, see [Using audit reports with your private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaAuditReport.html).
# Logging and Monitoring
You can use CloudTrail to record API calls to a private CA by WorkSpaces Applications. For more information see [What Is AWS CloudTrail?](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) and [Using CloudTrail](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCtIntro.html). In CloudTrail Event history you can view **GetCertificate** and **IssueCertificate** event names from **acm-pca.amazonaws.com** event source made by the WorkSpaces Applications**EcmAssumeRoleSession** user name. These events will be recorded for every WorkSpaces Applications certificate-based authentication request. For more information, see [Viewing events with CloudTrail Event history](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html).
# Enable Cross-account PCA Sharing
Private CA (PCA) cross-account sharing offers the ability to grant permissions for other accounts to use a centralized CA. The CA can generate and issue certificates by using [AWS Resource Access Manager](https://aws.amazon.com/ram/) (RAM) to manage the permissions. This removes the need for a Private CA in every account. Private CA cross-account sharing can be used with WorkSpaces Applications certificate-based Authentication (CBA) within the same AWS Region.
To use a shared Private CA resource with WorkSpaces Applications CBA, complete the following steps:
1. Configure the Private CA for CBA in a centralized AWS account. For more information, see [Certificate-Based Authentication](certificate-based-authentication.md).
1. Share the Private CA with the resource AWS accounts where WorkSpaces Applications resources utilize CBA. To do this, follow the steps in [How to use AWS RAM to share your ACM Private CA cross-account](https://aws.amazon.com/blogs/security/how-to-use-aws-ram-to-share-your-acm-private-ca-cross-account/). You do not need to complete step 3 to create a certificate. You can either share the Private CA with individual AWS accounts, or share through AWS Organizations. If you share with individual accounts, you need to accept the shared Private CA in your resource account by using the AWS Resource Access Manager console or APIs.
When configuring the share, confirm that the AWS Resource Access Manager resource share for the Private CA in the resource account is using the `AWSRAMBlankEndEntityCertificateAPICSRPassthroughIssuanceCertificateAuthority` managed permission template. This template aligns with the PCA template used by the WorkSpaces Applications service role when issuing CBA certificates.
1. After the share is successful, view the shared Private CA by using the Private CA console in the resource account.
1. Use the API or CLI to associate the Private CA ARN with CBA in your WorkSpaces Applications Directory Config. At this time, the WorkSpaces Applications console does not support selection of shared Private CA ARNs. The following are example CLI commands:
`aws appstream update-directory-config --directory-name --certificate-based-auth-properties Status=,CertificateAuthorityArn=`
# WorkSpaces Applications Active Directory Administration
Setting up and using Active Directory with WorkSpaces Applications involves the following administrative tasks.
**Topics**
+ [Granting Permissions to Create and Manage Active Directory Computer Objects](active-directory-permissions.md)
+ [Finding the Organizational Unit Distinguished Name](active-directory-oudn.md)
+ [Granting Local Administrator Rights on Image Builders](active-directory-image-builder-local-admin.md)
+ [Updating the Service Account Used for Joining the Domain](active-directory-service-acct.md)
+ [Locking the Streaming Session When the User is Idle](active-directory-session-lock.md)
+ [Editing the Directory Configuration](active-directory-config-edit.md)
+ [Deleting a Directory Configuration](active-directory-config-delete.md)
+ [Configuring WorkSpaces Applications to Use Domain Trusts](active-directory-domain-trusts.md)
+ [Managing WorkSpaces Applications Computer Objects in Active Directory](active-directory-identify-objects.md)
# Granting Permissions to Create and Manage Active Directory Computer Objects
To allow WorkSpaces Applications to perform Active Directory computer object operations, you need an account with sufficient permissions. As a best practice, use an account that has only the minimum privileges necessary. The minimum Active Directory organizational unit (OU) permissions are as follows:
+ Create Computer Object
+ Change Password
+ Reset Password
+ Write Description
Before setting up permissions, you'll need to do the following first:
+ Obtain access to a computer or an EC2 instance that is joined to your domain.
+ Install the Active Directory User and Computers MMC snap-in. For more information, see [Installing or Removing Remote Server Administration Tools for Windows 7](https://technet.microsoft.com/en-us/library/ee449483.aspx) in the Microsoft documentation.
+ Log in as a domain user with appropriate permissions to modify the OU security settings.
+ Create or identify the user, service account, or group for which to delegate permissions.
**To set up minimum permissions**
1. Open **Active Directory Users and Computers** in your domain or on your domain controller.
1. In the left navigation pane, select the first OU on which to provide domain join privileges, open the context (right-click) menu , and then choose **Delegate Control**.
1. On the **Delegation of Control Wizard** page, choose **Next**, **Add**.
1. For **Select Users, Computers, or Groups**, select the pre-created user, service account, or group, and then choose **OK**.
1. On the **Tasks to Delegate** page, choose **Create a custom task to delegate**, and then choose **Next**.
1. Choose **Only the following objects in the folder**, **Computer objects**.
1. Choose **Create selected objects in this folder**, **Next**.
1. For **Permissions**, choose **Read**, **Write**, **Change Password**, **Reset Password**, **Next**.
1. On the **Completing the Delegation of Control Wizard** page, verify the information and choose **Finish**.
1. Repeat steps 2-9 for any additional OUs that require these permissions.
If you delegated permissions to a group, create a user or service account with a strong password and add that account to the group. This account will then have sufficient privileges to connect your streaming instances to the directory. Use this account when creating your WorkSpaces Applications directory configuration.
# Finding the Organizational Unit Distinguished Name
When you register your Active Directory domain with WorkSpaces Applications, you must provide an organizational unit (OU) distinguished name. Create an OU for this purpose. The default Computers container is not an OU and cannot be used by WorkSpaces Applications. The following procedure shows how to obtain this name.
**Note**
The distinguished name must start with **OU=** or it cannot be used for computer objects.
Before you complete this procedure, you'll need to do the following first:
+ Obtain access to a computer or an EC2 instance that is joined to your domain.
+ Install the Active Directory User and Computers MMC snap-in. For more information, see [Installing or Removing Remote Server Administration Tools for Windows 7](https://technet.microsoft.com/en-us/library/ee449483.aspx) in the Microsoft documentation.
+ Log in as a domain user with appropriate permissions to read the OU security properties.
**To find the distinguished name of an OU**
1. Open **Active Directory Users and Computers** in your domain or on your domain controller.
1. Under **View**, ensure that **Advanced Features** is enabled.
1. In the left navigation pane, select the first OU to use for WorkSpaces Applications streaming instance computer objects, open the context (right-click) menu, and then choose **Properties**.
1. Choose **Attribute Editor**.
1. Under **Attributes**, for **distinguishedName**, choose **View**.
1. For **Value**, select the distinguished name, open the context menu, and then choose **Copy**.
# Granting Local Administrator Rights on Image Builders
By default, Active Directory domain users do not have local administrator rights on image builder instances. You can grant these rights by using Group Policy preferences in your directory, or manually, by using the local administrator account on an image builder. Granting local administrator rights to a domain user allows that user to install applications on and create images in an WorkSpaces Applications image builder.
**Topics**
+ [Using Group Policy preferences](group-policy.md)
+ [Using the local Administrators group on the image builder](manual-procedure.md)
# Using Group Policy preferences
You can use Group Policy preferences to grant local administrator rights to Active Directory users or groups and to all computer objects in the specified OU. The Active Directory users or groups to which you want to grant local administrator permissions must already exist. To use Group Policy preferences, you'll need to do the following first:
+ Obtain access to a computer or an EC2 instance that is joined to your domain.
+ Install the Group Policy Management Console (GPMC) MMC snap-in. For more information, see [Installing or Removing Remote Server Administration Tools for Windows 7](https://technet.microsoft.com/en-us/library/ee449483.aspx) in the Microsoft documentation.
+ Log in as a domain user with permissions to create Group Policy objects (GPOs). Link GPOs to the appropriate OUs.
**To use Group Policy preferences to grant local administrator permissions**
1. In your directory or on a domain controller, open the command prompt as an administrator, type `gpmc.msc`, and then press ENTER.
1. In the left console tree, select the OU where you will create a new GPO or use an existing GPO, and then do either of the following:
+ Create a new GPO by opening the context (right-click) menu and choosing **Create a GPO in this domain, Link it here**. For **Name**, provide a descriptive name for this GPO.
+ Select an existing GPO.
1. Open the context menu for the GPO, and choose **Edit**.
1. In the console tree, choose **Computer Configuration**, **Preferences**, **Windows Settings**, **Control Panel Settings**, and **Local Users and Groups**.
1. Select **Local Users and Groups** selected, open the context menu , and choose **New**, **Local Group**.
1. For **Action**, choose **Update**.
1. For **Group name**, choose **Administrators (built-in)**.
1. Under **Members**, choose **Add…** and specify the Active Directory users or groups to which to assign local administrator rights on the streaming instance. For **Action**, choose **Add to this group**, and choose **OK**.
1. To apply this GPO to other OUs, select the additional OU, open the context menu and choose **Link an Existing GPO**.
1. Using the new or existing GPO name that you specified in step 2, scroll to find the GPO, and then choose **OK**.
1. Repeat steps 9 and 10 for additional OUs that should have this preference.
1. Choose **OK** to close the **New Local Group Properties** dialog box.
1. Choose **OK** again to close the GPMC.
To apply the new preference to the GPO, you must stop and restart any running image builders or fleets. The Active Directory users and groups that you specified in step 8 are automatically granted local administrator rights on the image builders and fleets in the OU to which the GPO is linked.
# Using the local Administrators group on the image builder
To grant Active Directory users or groups local administrator rights on your image builder, you can manually add these users or groups to the local Administrators group on the image builder. Image builders that are created from images with these rights maintain the same rights.
The Active Directory users or groups to which to grant local administrator rights must already exist.
**To add Active Directory users or groups to the local Administrators group on the image builder**
1. Open the WorkSpaces Applications console at [https://console.aws.amazon.com/appstream2](https://console.aws.amazon.com/appstream2).
1. Connect to the image builder in Administrator mode. The image builder must be running and domain-joined. For more information, see [Tutorial: Setting Up Active Directory](active-directory-directory-setup.md).
1. Choose **Start**, **Administrative Tools**, and then double-click **Computer Management**.
1. In the left navigation pane, choose **Local Users and Groups** and open the **Groups** folder.
1. Open the **Administrators** group and choose **Add...**.
1. Select all Active Directory users or groups to which to assign local administrator rights and choose **OK**. Choose **OK** again to close the **Administrator Properties** dialog box.
1. Close Computer Management.
1. To log in as an Active Directory user and test whether that user has local administrator rights on the image builder, choose **Admin Commands**, **Switch user**, and then enter the credentials of the relevant user.
# Updating the Service Account Used for Joining the Domain
To update the service account that WorkSpaces Applications uses for joining the domain, we recommend using two separate service accounts for joining image builders and fleets to your Active Directory domain. Using two separate service accounts ensures that there is no disruption in service when a service account needs to be updated (for example, when a password expires).
**To update a service account**
1. Create an Active Directory group and delegate the correct permissions to the group.
1. Add your service accounts to the new Active Directory group.
1. When needed, edit your WorkSpaces Applications Directory Config object by entering the sign-in credentials for the new service account.
After you've set up the Active Directory group with the new service account, any new streaming instance operations will use the new service account, while in-process streaming instance operations continue to use the old account without interruption.
The service account overlap time while the in-process streaming instance operations complete is very short, no more than a day. The overlap time is needed because you shouldn't delete or change the password for the old service account during the overlap period, or existing operations can fail.
# Locking the Streaming Session When the User is Idle
WorkSpaces Applications relies on a setting that you configure in the GPMC to lock the streaming session after your user is idle for specified amount of time. To use the GPMC, you'll need to do the following first:
+ Obtain access to a computer or an EC2 instance that is joined to your domain.
+ Install the GPMC. For more information, see [Installing or Removing Remote Server Administration Tools for Windows 7](https://technet.microsoft.com/en-us/library/ee449483.aspx) in the Microsoft documentation.
+ Log in as a domain user with permissions to create GPOs. Link GPOs to the appropriate OUs.
**To automatically lock the streaming instance when your user is idle**
1. In your directory or on a domain controller, open the command prompt as an administrator, type `gpmc.msc`, and then press ENTER.
1. In the left console tree, select the OU where you will create a new GPO or use an existing GPO, and then do either of the following:
+ Create a new GPO by opening the context (right-click) menu and choosing **Create a GPO in this domain, Link it here**. For **Name**, provide a descriptive name for this GPO.
+ Select an existing GPO.
1. Open the context menu for the GPO, and choose **Edit**.
1. Under **User Configuration**, expand **Policies**, **Administrative Templates**, **Control Panel**, and then choose **Personalization**.
1. Double-click **Enable screen saver**.
1. In the **Enable screen saver** policy setting, choose **Enabled**.
1. Choose **Apply**, and then choose **OK**.
1. Double-click **Force specific screen saver**.
1. In the **Force specific screen saver** policy setting, choose **Enabled**.
1. Under **Screen saver executable name**, enter **scrnsave.scr**. When this setting is enabled, the system displays a black screen saver on the user's desktop.
1. Choose **Apply**, and then choose **OK**.
1. Double-click **Password protect the screen saver**.
1. In the **Password protect the screen saver** policy setting, choose **Enabled**.
1. Choose **Apply**, and then choose **OK**.
1. Double-click **Screen saver timeout**.
1. In the **Screen saver timeout** policy setting, choose **Enabled**.
1. For **Seconds**, specify the length of time that users must be idle before the screen saver is applied. To set the idle time to 10 minutes, specify 600 seconds.
1. Choose **Apply**, and then choose **OK**.
1. In the console tree, under **User Configuration**, expand **Policies**, **Administrative Templates**, **System**, and then choose **Ctrl\$1Alt\$1Del Options**.
1. Double-click **Remove Lock Computer**.
1. In the **Remove Lock Computer** policy setting, choose **Disabled**.
1. Choose **Apply**, and then choose **OK**.
# Editing the Directory Configuration
After a WorkSpaces Applications directory configuration has been created, you can edit it to add, remove, or modify organizational units, update the service account username, or update the service account password.
**To update a directory configuration**
1. Open the WorkSpaces Applications console at [https://console.aws.amazon.com/appstream2](https://console.aws.amazon.com/appstream2).
1. In the left navigation pane, choose **Directory Configs** and select the directory configuration to edit.
1. Choose **Actions**, **Edit**.
1. Update the fields to be changed. To add additional OUs, select the plus sign (**\$1**) next to the topmost OU field. To remove an OU field, select the **x** next to the field.
**Note**
At least one OU is required. OUs that are currently in use cannot be removed.
1. To save changes, choose **Update Directory Config**.
1. The information in the **Details** tab should now update to reflect the changes.
Changes to the service account sign-in credentials do not impact in-process streaming instance operations. New streaming instance operations use the updated credentials. For more information, see [Updating the Service Account Used for Joining the Domain](active-directory-service-acct.md).
# Deleting a Directory Configuration
You can delete an WorkSpaces Applications directory configuration that is no longer needed. Directory configurations that are associated with any image builders or fleets cannot be deleted.
**To delete a directory configuration**
1. Open the WorkSpaces Applications console at [https://console.aws.amazon.com/appstream2](https://console.aws.amazon.com/appstream2).
1. In the left navigation pane, choose **Directory Configs** and select the directory configuration to delete.
1. Choose **Actions**, **Delete**.
1. Verify the name in the pop-up message, and choose **Delete**.
1. Choose **Update Directory Config**.
# Configuring WorkSpaces Applications to Use Domain Trusts
WorkSpaces Applications supports Active Directory domain environments where network resources such as file servers, applications, and computer objects reside in one domain, and the user objects reside in another. The domain service account used for computer object operations does not need to be in the same domain as the WorkSpaces Applications computer objects.
When creating the directory configuration, specify a service account that has the appropriate permissions to manage computer objects in the Active Directory domain where the file servers, applications, computer objects and other network resources reside.
Your end user Active Directory accounts must have the "Allowed to Authenticate" permissions for the following:
+ WorkSpaces Applications computer objects
+ Domain controllers for the domain
For more information, see [Granting Permissions to Create and Manage Active Directory Computer Objects](active-directory-permissions.md).
# Managing WorkSpaces Applications Computer Objects in Active Directory
WorkSpaces Applications does not delete computer objects from Active Directory. These computer objects can be easily identified in your directory. Each computer object in the directory is created with the `Description` attribute, which specifies a fleet or an image builder instance and the name.
**Computer Object Description Examples**
| Type | Name | Description Attribute |
| --- | --- | --- |
| Fleet | ExampleFleet | `WorkSpaces Applications - fleet:ExampleFleet` |
| Image builder | ExampleImageBuilder | `WorkSpaces Applications - image-builder:ExampleImageBuilder` |
You can identify and delete inactive computer objects created by WorkSpaces Applications by using the following `dsquery computer` and `dsrm` commands. For more information, see [Dsquery computer](https://technet.microsoft.com/en-us/library/cc730720.aspx) and [Dsrm](https://technet.microsoft.com/en-us/library/cc731865.aspx) in the Microsoft documentation.
The `dsquery` command identifies inactive computer objects over a certain period of time and uses the following format. The `dsquery` command should also be run with the parameter `-desc "WorkSpaces Applications*"` to display only WorkSpaces Applications objects.
```
dsquery computer "OU-distinguished-name" -desc "WorkSpaces Applications*" -inactive number-of-weeks-since-last-login
```
+ `OU-distinguished-name` is the distinguished name of the organizational unit. For more information, see [Finding the Organizational Unit Distinguished Name](active-directory-oudn.md). If you don't provide the *OU-distinguished-name* parameter, the command searches the entire directory.
+ `number-of-weeks-since-last-log-in` is the desired value based on how you want to define inactivity.
For example, the following command displays all computer objects in the `OU=ExampleOU,DC=EXAMPLECO,DC=COM` organizational unit that have not been logged into within the past two weeks.
```
dsquery computer OU=ExampleOU,DC=EXAMPLECO,DC=COM -desc "WorkSpaces Applications*" -inactive 2
```
If any matches are found, the result is one or more object names. The `dsrm` command deletes the specified object and uses the following format:
```
dsrm objectname
```
Where `objectname` is the full object name from the output of the `dsquery` command. For example, if the `dsquery` command above results in a computer object named "ExampleComputer", the `dsrm` command to delete it would be as follows:
```
dsrm "CN=ExampleComputer,OU=ExampleOU,DC=EXAMPLECO,DC=COM"
```
You can chain these commands together by using the pipe (`|`) operator. For example, to delete all WorkSpaces Applications computer objects, prompting for confirmation for each, use the following format. Add the `-noprompt` parameter to `dsrm` to disable confirmation.
```
dsquery computer OU-distinguished-name -desc "WorkSpaces Applications*" –inactive number-of-weeks-since-last-log-in | dsrm
```
# More Info
For more information related to this topic, see the following resources:
+ [Troubleshooting Notification Codes](troubleshooting-notification-codes.md)—Resolutions to notification code errors.
+ [Troubleshooting Active Directory](troubleshooting-active-directory.md)—Help with common difficulties.
+ [Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html)—Information about using Directory Service.