# Using Active Directory with WorkSpaces Pools
You can join your Windows WorkSpaces in WorkSpaces Pools 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 Pools 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*.
By joining WorkSpaces Pools 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 in WorkSpaces Pools.
**Topics**
+ [Overview of Active Directory Domains](active-directory-overview.md)
+ [Before You Begin Using Active Directory with WorkSpaces Pools](active-directory-prerequisites.md)
+ [Certificate-Based Authentication](pools-certificate-based-authentication.md)
+ [WorkSpaces Pools 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 Pools 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 directory in WorkSpaces Pools.
1. Create the WorkSpaces Pools application in the SAML 2.0 identity provider and assign it to end users either directly or through Active Directory groups.
**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 Pools service.
1. Using the authentication token from AWS, WorkSpaces Pools 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 Pools directory, 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 a WorkSpaces Pools 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 WorkSpaces Pools directory.
# Before You Begin Using Active Directory with WorkSpaces Pools
Before you use Microsoft Active Directory domains with WorkSpaces Pools, be aware of the following requirements and considerations.
**Topics**
+ [Active Directory Domain Environment](#active-directory-prerequisites-domain-environment)
+ [Domain-Joined WorkSpaces in WorkSpaces Pools](#active-directory-prerequisites-streaming-instances)
+ [Group Policy Settings](#active-directory-prerequisites-group-policy-settings)
+ [Smart Card Authentication](#active-directory-prerequisites-smart-card-authentication)
## Active Directory Domain Environment
+ You must have a Microsoft Active Directory domain to which to join your WorkSpaces. 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 the AWS Cloud: Quick Start Reference Deployment](https://docs.aws.amazon.com/quickstart/latest/active-directory-ds/).
+ 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 Pools. 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 Pools, provide the service account name and password. WorkSpaces Pools 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-admin.md#active-directory-permissions).
+ When you register your Active Directory domain with WorkSpaces Pools, 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 Pools. For more information, see [Finding the Organizational Unit Distinguished Name](active-directory-admin.md#active-directory-oudn).
+ The directories that you plan to use with WorkSpaces Pools must be accessible through their fully qualified domain names (FQDNs) through the virtual private cloud (VPC) in which your WorkSpaces 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-Joined WorkSpaces in WorkSpaces Pools
SAML 2.0-based user federation is required for application streaming from domain-joined WorkSpaces. Also, you must use a Windows image that supports joining to an Active Directory domain. All public images published on or after July 24, 2017 support joining an Active Directory domain.
## 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 Pools from authenticating and logging in your domain users. Otherwise, when your users try to log in to WorkSpaces 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 is *not* listed: `e7c1bab5-4b49-4e64-a966-8d99686f8c7c`
+ **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**.
## Smart Card Authentication
WorkSpaces Pools 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 in WorkSpaces Pools. 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.
# Certificate-Based Authentication
You can use certificate-based authentication with WorkSpaces Pools 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 Pools requests certificates for your users automatically at session reservation for each WorkSpace in a WorkSpaces Pool. It authenticates users to Active Directory with a virtual smart card provisioned with the certificates.
Certificate-based authentication is supported on domain-joined WorkSpaces Pools that run Windows instances.
**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. Configure your WorkSpaces Pools directory with SAML 2.0 integration to use certificate-based authentication. For more information, see [Configure SAML 2.0 and create a WorkSpaces Pools directory](create-directory-pools.md).
**Note**
Don't enable **Smart card sign in** in your pool directory if you want to use certificate-based authentication.
1. Configure the `userPrincipalName` attribute in your SAML assertion. For more information, see [Step 7: Create assertions for the SAML authentication response](create-directory-pools.md#saml-directory-create-assertions).
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 7: Create assertions for the SAML authentication response](create-directory-pools.md#saml-directory-create-assertions).
**Note**
According to [Microsoft KB5014754](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16), the `ObjectSid` attribute will become mandatory for certificate-based authentication after September 10, 2025.
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) in the *AWS Identity and Access Management User Guide*. This permission is required to use certificate-based authentication. For more information, see [Step 5: Create a SAML 2.0 federation IAM role](create-directory-pools.md#saml-directory-saml-federation-role-in-iam).
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) in the *AWS Private Certificate Authority User Guide*. 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 in WorkSpaces Pools 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) in the *AWS Private Certificate Authority User Guide*.
1. Tag your private CA with a key entitled `euc-private-ca` to designate the CA for use with WorkSpaces Pools 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) in the *AWS Private Certificate Authority User Guide*..
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). You can create a domain controller certificate with AWS Private CA. If you do this, don't use a private CA configured for short-lived 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 in WorkSpaces Pools.
**Note**
Active Directory must distribute the CA to the Trusted Root Certification Authorities and Enterprise NTAuth stores automatically for WorkSpaces in WorkSpaces Pools when they join the domain.
**Note**
Active Directory domain controllers must be in Compatibility mode for certificate strong enforcement to support certificate-based authentication. 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) in the Microsoft Support documentation. If you are using AWS Managed Microsoft AD, see [Configure directory security settings](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_directory_settings.html) for more information.
# Enable Certificate-based Authentication
Complete the following steps to enable certificate-based authentication.
**To enable certificate-based authentication**
1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).
1. Choose **Directories** in the navigation pane.
1. Choose the **Pools directories** tab.
1. Choose the directory you want to configure.
1. Choose **Edit** in the **Authentication** section of the page.
1. Choose **Edit Certificate-Based Authentication** in the **Certificate-Based Authentication** section of the page.
1. Choose **Enable Certificate-Based Authentication**.
1. Choose the certificate in the **AWS Certificate Manager (ACM) Private Certificate Authority (CA)** drop-down.
To appear in the drop-down, 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**.
Certificate-based authentication is now enabled. When users authenticate with SAML 2.0 to an WorkSpaces Pools directory using the domain-joined WorkSpaces, 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.
## 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 Certificate Authority for WorkSpaces Pools certificate-based authentication don't require renewal or revocation. These certificates are short-lived. WorkSpaces Pools automatically issues a new certificate for each new session, or every 24 hours for sessions with a long duration. The WorkSpaces Pools session governs the use of these end user certificates. If you end a session, WorkSpaces Pools stops using that certificate. These end user certificates have a shorter validity period than a typical AWS Private Certificate Authority 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 Pools. For more information see [What Is AWS CloudTrail?](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) in the *AWS CloudTrail User Guide*, and [Using CloudTrail](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCtIntro.html) in the *AWS Private Certificate Authority User Guide*. In CloudTrail Event history you can view **GetCertificate** and **IssueCertificate** event names from **acm-pca.amazonaws.com** event source made by the WorkSpaces Pools **EcmAssumeRoleSession** user name. These events will be recorded for every WorkSpaces Pools 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) in the *AWS CloudTrail User Guide*.
# 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 Pools CBA, complete the following steps:
1. Configure the Private CA for CBA in a centralized AWS account. For more information, see [Certificate-based authentication and WorkSpaces Personal](certificate-based-authentication.md).
1. Share the Private CA with the resource AWS accounts where WorkSpaces Pools 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 Pools 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 Pools directory. At this time, the WorkSpaces Pools console does not support selection of shared Private CA ARNs. For more information, see the [Amazon WorkSpaces Service API Reference](https://docs.aws.amazon.com/workspaces/latest/api/welcome.html).
# WorkSpaces Pools Active Directory Administration
Setting up and using Active Directory with WorkSpaces Pools involves the following administrative tasks.
**Topics**
+ [Granting Permissions to Create and Manage Active Directory Computer Objects](#active-directory-permissions)
+ [Finding the Organizational Unit Distinguished Name](#active-directory-oudn)
+ [Granting Local Administrator Rights on custom images](#active-directory-image-builder-local-admin)
+ [Locking the Streaming Session When the User is Idle](#active-directory-session-lock)
+ [Configuring WorkSpaces Pools to Use Domain Trusts](#active-directory-domain-trusts)
## Granting Permissions to Create and Manage Active Directory Computer Objects
To allow WorkSpaces Pools 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 WorkSpaces to the directory. Use this account when creating your WorkSpaces Pools directory configuration.
## Finding the Organizational Unit Distinguished Name
When you register your Active Directory domain with WorkSpaces Pools, 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 Pools. 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 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 custom images
By default, Active Directory domain users do not have local administrator rights on images. You can grant these rights by using Group Policy preferences in your directory, or manually, by using the local administrator account on an image. Granting local administrator rights to a domain user allows that user to install applications on and create custom images in WorkSpaces Pools.
**Topics**
+ [Using Group Policy preferences](#group-policy)
+ [Using the local Administrators group on the WorkSpace to create images](#manual-procedure)
### 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 WorkSpace to create images
To grant Active Directory users or groups local administrator rights on an image, you can manually add these users or groups to the local Administrators group on the image.
The Active Directory users or groups to which to grant local administrator rights must already exist.
1. Connect to the WorkSpace you use to build images. The WorkSpace must be running and domain-joined.
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 WorkSpaces, choose **Admin Commands**, **Switch user**, and then enter the credentials of the relevant user.
## Locking the Streaming Session When the User is Idle
WorkSpaces Pools 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**.
## Configuring WorkSpaces Pools to Use Domain Trusts
WorkSpaces Pools 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 Pools 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 Pools computer objects
+ Domain controllers for the domain
For more information, see [Granting Permissions to Create and Manage Active Directory Computer Objects](#active-directory-permissions).
# More Info
For more information related to this topic, see the following resources:
+ [Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html)—Information about using Directory Service.