# Networking protocols and access for WorkSpaces Personal
<a name="amazon-workspaces-networking"></a>

As a WorkSpace administrator, you must understand how to manage WorkSpaces networking and access, beginning with protocols.

## Protocols for WorkSpaces Personal
<a name="amazon-workspaces-protocols"></a>

Amazon WorkSpaces supports two protocols: PCoIP and DCV. The protocol that you choose depends on several factors, such as the type of devices your users will be accessing their WorkSpaces from, which operating system is on your WorkSpaces, what network conditions your users will be facing, and whether your users require bidirectional video support.

### Requirements
<a name="w2aac11c25b5b5"></a>

DCV WorkSpaces are only supported with the following minimum requirements.

Host agent requirements:
+ Windows host agent version 2.0.0.312 or above
+ Ubuntu host agent version 2.1.0.501 or above
+ Amazon Linux 2 host agent version 2.0.0.596 or above
+ Rocky Linux host agent version 2.1.0.1628 or above
+ Red Hat Enterprise Linux host agent version 2.1.0.1628 or above

Client requirements:
+ Windows native client version 5.1.0.329 or higher
+ macOS native client version 5.5.0 or higher
+ Ubuntu 22.04 client version 2024.x or higher
+ Amazon WorkSpaces Thin Client (For more information, see the [Amazon WorkSpaces Thin Client Documentation](https://docs.aws.amazon.com/workspaces-thin-client/))
+ Web Access

For more information about how to check your WorkSpace client version and host agent version, see the [FAQ](https://aws.amazon.com/workspaces/faqs/#:~:text=Q%3A%20How%20do%20I%20find%20my%20WSP%20host%20agent%20version%3F).

### When to use DCV
<a name="w2aac11c25b5b7"></a>
+ If you need higher loss/latency tolerance to support your end user network conditions. For example, you have users who are accessing their WorkSpaces across global distances or using unreliable networks.
+ If you need your users to authenticate with smart cards or to use smart cards in-session.
+ If you need webcam support capabilities in-session.
+ If you need to use Web Access with the Windows Server 2022 or Windows Server 2025-powered WorkSpaces bundle.
+ If you need to use Ubuntu WorkSpaces.
+ If you need to use Windows 11 BYOL WorkSpaces.
+ If you need to use GPU-enabled WorkSpaces bundles with Windows.
+ If you need to use Windows GPU-based bundles (Graphics.g6, Graphics.g4dn and GraphicsPro.g4dn) or Ubuntu GPU-based bundles (Graphics.g4dn and GraphicsPro.g4dn).
+ If you need your users to authenticate in-session with WebAuthn authenticators such as YubiKey or Windows Hello.

### When to use PCoIP
<a name="w2aac11c25b5b9"></a>
+ If you want to use the iPad or Android Linux clients.
+ If you use Teradici zero client devices.
+ If you need to use a Linux bundle for non-smart card use cases.
+ If you need to use WorkSpaces in the China (Ningxia) Region.

**Note**  
A directory can have a mix of PCoIP and DCV WorkSpaces in it.
A user can have both a PCoIP and a DCV WorkSpace as long as the two WorkSpaces are located in separate directories. The same user cannot have a PCoIP and a DCV WorkSpace in the same directory. For more information about creating multiple WorkSpaces for a user, see [Create multiple WorkSpaces for a user in WorkSpaces Personal](create-multiple-workspaces-for-user.md).
You can migrate a WorkSpace between the two protocols by using the WorkSpaces migration feature, which requires a rebuild of the WorkSpace. For more information, see [Migrate a WorkSpace in WorkSpaces Personal](migrate-workspaces.md).
If your WorkSpace was created with PCoIP bundles you can modify the streaming protocol to migrate between the two protocols without requiring a rebuild, while retaining the root volume. For more information, see [ Modify protocols](https://docs.aws.amazon.com/workspaces/latest/adminguide/modify-workspaces.html#modify_protocols).
For the best experience with video conferencing we recommend using Power, PowerPro, GeneralPurpose.4xlarge, or GeneralPurpose.8xlarge bundles only.

The following topics offer additional detail about how to manage networking and access for WorkSpaces Personal:

# Configure a VPC for WorkSpaces Personal
<a name="amazon-workspaces-vpc"></a>

WorkSpaces launches your WorkSpaces in a virtual private cloud (VPC).

You can create a VPC with two private subnets for your WorkSpaces and a NAT gateway in a public subnet. Alternatively, you can create a VPC with two public subnets for your WorkSpaces and associate a public IP address or Elastic IP address with each WorkSpace.

For more information about VPC design considerations, see [Best Practices for VPCs and Networking in Amazon WorkSpaces Deployments](https://d1.awsstatic.com/whitepapers/best-practices-vpcs-networking-amazon-workspaces-deployments.pdf) and [Best Practices for Deploying WorkSpaces - VPC Design](https://docs.aws.amazon.com/whitepapers/latest/best-practices-deploying-amazon-workspaces/vpc-design.html).

**Topics**
+ [Requirements](#configure-vpc-requirements)
+ [Configure a VPC with private subnets and a NAT gateway](#configure-vpc-nat-gateway)
+ [Configure a VPC with public subnets](#configure-vpc-public-subnets)

## Requirements
<a name="configure-vpc-requirements"></a>

Your VPC's subnets must reside in different Availability Zones in the Region where you're launching WorkSpaces. Availability Zones are distinct locations that are engineered to be isolated from failures in other Availability Zones. By launching instances in separate Availability Zones, you can protect your applications from the failure of a single location. Each subnet must reside entirely within one Availability Zone and cannot span zones.

**Note**  
Amazon WorkSpaces is available in a subset of the Availability Zones in each supported Region. To determine which Availability Zones you can use for the subnets of the VPC that you're using for WorkSpaces, see [Availability Zones for WorkSpaces Personal](azs-workspaces.md). 

## Configure a VPC with private subnets and a NAT gateway
<a name="configure-vpc-nat-gateway"></a>

If you use Directory Service to create an AWS Managed Microsoft or a Simple AD, we recommend that you configure the VPC with one public subnet and two private subnets. Configure your directory to launch your WorkSpaces in the private subnets. To provide internet access to WorkSpaces in a private subnet, configure a NAT gateway in the public subnet.

![\[Configure your WorkSpaces VPC\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/images/vpc-configuration-new.png)


**To create a VPC with one public subnet and two private subnets**

1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. Choose **Create VPC**.

1. Under **Resources to create**, choose **VPC and more**.

1. For **Name tag auto-generation**, enter a name for the VPC.

1. To configure the subnets, do the following:

   1. For **Number of Availability Zones**, choose **1** or **2**, depending on your needs.

   1. Expand **Customize AZs** and choose your Availability Zones. Otherwise, AWS selects them for you. To make an appropriate selection, see [Availability Zones for WorkSpaces Personal](azs-workspaces.md).

   1. For **Number of public subnets**, ensure that you have one public subnet per Availability Zone.

   1. For **Number of private subnets**, ensure that you have at least one private subnet per Availability Zone.

   1. Enter a CIDR block for each subnet. For more information, see [Subnet sizing](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-sizing) in the *Amazon VPC User Guide*.

1. For **NAT gateways**, choose **1 per AZ**.

1. Choose **Create VPC**.

**IPv6 CIDR blocks**  
You can associate IPv6 CIDR blocks with your VPC and its subnets, and configure those subnets to automatically assign IPv6 addresses to newly launched instances. For customer-created subnets, auto-assign IPv6 addressing is disabled by default. To view or update this setting in the Amazon VPC console, choose Subnets in the navigation pane, select the target subnet, and then choose **Actions**, **Modify auto-assign IP settings**.

## Configure a VPC with public subnets
<a name="configure-vpc-public-subnets"></a>

If you prefer, you can create a VPC with two public subnets. To provide internet access to WorkSpaces in public subnets, configure the directory to assign Elastic IP addresses automatically or manually assign an Elastic IP address to each WorkSpace.

**Topics**
+ [Step 1: Create a VPC](#create-vpc-public-subnet)
+ [Step 2: Assign public IP addresses to your WorkSpaces](#assign-eip)

### Step 1: Create a VPC
<a name="create-vpc-public-subnet"></a>

Create a VPC with one public subnet as follows.

**To create the VPC**

1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. Choose **Create VPC**.

1. Under **Resources to create**, choose **VPC and more**.

1. For **Name tag auto-generation**, enter a name for the VPC.

1. To configure the subnets, do the following:

   1. For **Number of Availability Zones**, choose **2**.

   1. Expand **Customize AZs** and choose your Availability Zones. Otherwise, AWS selects them for you. To make an appropriate selection, see [Availability Zones for WorkSpaces Personal](azs-workspaces.md).

   1. For **Number of public subnets**, choose **2**.

   1. For **Number of private subnets**, choose **0**.

   1. Enter a CIDR block for each public subnet. For more information, see [Subnet sizing](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-sizing) in the *Amazon VPC User Guide*.

1. Choose **Create VPC**.

**IPv6 CIDR blocks**  
You can associate IPv6 CIDR blocks with your VPC and its subnets, and configure those subnets to automatically assign IPv6 addresses to newly launched instances. For customer-created subnets, auto-assign IPv6 addressing is disabled by default. To view or update this setting in the Amazon VPC console, choose Subnets in the navigation pane, select the target subnet, and then choose **Actions**, **Modify auto-assign IP settings**.

### Step 2: Assign public IP addresses to your WorkSpaces
<a name="assign-eip"></a>

You can assign public IP addresses to your WorkSpaces automatically or manually. To use automatic assignment, see [Configure automatic public IP addresses for WorkSpaces Personal](automatic-assignment.md). To assign public IP addresses manually, use the following procedure.

**To assign a public IP address to a WorkSpace manually**

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose **WorkSpaces**.

1. Expand the row (choose the arrow icon) for the WorkSpace and note the value of **WorkSpace IP**. This is the primary private IP address of the WorkSpace.

1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. In the navigation pane, choose **Elastic IPs**. If you do not have an available Elastic IP address, choose **Allocate Elastic IP address** and choose **Amazon's pool of IPv4 addresses** or **Customer owned pool of IPv4 addresses**, and then choose **Allocate**. Make note of the new IP address.

1. In the navigation pane, choose **Network Interfaces**.

1. Select the network interface for your WorkSpace. To find the network interface for your WorkSpace, enter the **WorkSpace IP** value (which you noted earlier) in the search box, and then press **Enter**. The **WorkSpace IP** value matches the primary private IPv4 address for the network interface. Note that the VPC ID of the network interface matches the ID of your WorkSpaces VPC.

1. Choose **Actions**, **Manage IP Addresses**. Choose **Assign new IP**, and then choose **Yes, Update**. Make note of the new IP address.

1. Choose **Actions**, **Associate Address**.

1. On the **Associate Elastic IP Address** page, choose an Elastic IP address from **Address**. For **Associate to private IP address**, specify the new private IP address, and then choose **Associate Address**.

# Configure AWS Global Accelerator (AGA) for WorkSpaces Personal
<a name="amazon-workspaces-aga"></a>

You can enable AWS Global Accelerator (AGA) either at the WorkSpaces directory level or for individual WorkSpaces running DCV protocol. When enabled, the service automatically routes the streaming traffic through the nearest AWS edge location and across the AWS global network, which is congestion-free and redundant. This helps deliver a more responsive and stable streaming experience. The WorkSpaces service fully manages AGA usage and is subject to outbound data volume limits.

**Topics**
+ [Requirements](#configure-aga-requirements)
+ [Limitations](#configure-aga-limitations)
+ [Outbound data limits](#configure-aga-outbound-data-limits)
+ [Enable AGA for a WorkSpaces directory](#enabling-aga-directory)
+ [Enable AGA for individual WorkSpaces](#enabling-aga-individual)

## Requirements
<a name="configure-aga-requirements"></a>
+ WorkSpaces use a range of public IPv4 addresses for the dedicated AWS Global Accelerator (AGA) endpoints. Make sure to configure your firewall policies for devices that access WorkSpaces through AGA. If the AGA endpoints are blocked by the firewall, WorkSpaces streaming traffic won't be routed through AGA. For more information about the AGA endpoint IP ranges in each AWS region, see [DCV gateway servers](workspaces-port-requirements.md#gateway_WSP).
+ To access WorkSpaces through AGA, users must use WorkSpaces client versions 5.23 or later.

## Limitations
<a name="configure-aga-limitations"></a>
+ You can enable AGA for DCV WorkSpaces only. If you enable AGA at WorkSpaces directory level, it will only apply to the DCV WorkSpaces in the directory.
+ You can't enable AGA for a directory (or the WorkSpaces in the directory) that has both FIPS and IP access control groups enabled. You must disable FIPS or IP access control groups before enabling AGA for the directory.

## Outbound data limits
<a name="configure-aga-outbound-data-limits"></a>

The following are applicable data volume limits for WorkSpaces bundles.
+ **Value, Standard, and Performance bundles:** Includes 20 GB of AGA outbound data per user per month.
+ **Power, PowerPro, and Graphics bundles:** Includes 50 GB of AGA outbound data per user per month.

These outbound data limits are intended to cover the data usage of users streaming from their WorkSpaces. Beyond the limits, the WorkSpaces service might restrict AGA usage and route WorkSpaces traffic off of AGA on a case-by-case basis.

## Enable AGA for a WorkSpaces directory
<a name="enabling-aga-directory"></a>

You can configure AGA settings on a directory level. The settings will apply to all the DCV WorkSpaces in the directory unless overridden by the individual WorkSpaces.

**To enable AGA for a directory**

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose **Directories**.

1. Under the **Directory ID** column, choose the directory ID of the directory you want to configure AGA settings for.

1. On the Directory Details page, scroll down to the AWS Global Accelerator (AGA) configuration section and choose **Edit**.

1. Choose **Enable AGA (automatic)**.

1. **Always use TCP with AGA** is selected by default. If you unselect it, your WorkSpaces client will determine whether TCP or UDP is used with AGA based on the DCV streaming protocol settings on your clients.

1. Choose **Save**.

After you enable AGA for a WorkSpaces directory, DCV WorkSpaces in the directory use AGA for streaming starting from the next session. No reboot is needed.

## Enable AGA for individual WorkSpaces
<a name="enabling-aga-individual"></a>

You can configure AGA settings for individual WorkSpaces, which overrides the settings inherited from the directory that the WorkSpaces are associated with.

**To enable AGA for individual WorkSpaces**

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose **WorkSpaces**, **Personal**.

1. Under the **WorkSpace ID** column, choose the WorkSpace ID of the WorkSpace you want to configure AGA settings for.

1. On the WorkSpaces Details page, scroll down to the AWS Global Accelerator (AGA) configuration section and choose **Edit**.

1. Choose **Manually override AGA configurations for this WorkSpace**.

1. Choose **Enable AGA (automatic)**.

1. **Always use TCP with AGA** is selected by default. If you unselect it, your WorkSpaces client will determine whether TCP or UDP is used with AGA based on the DCV streaming protocol settings on your clients.

1. Choose **Save**.

# Availability Zones for WorkSpaces Personal
<a name="azs-workspaces"></a>

When you are creating a virtual private cloud (VPC) for use with Amazon WorkSpaces, your VPC's subnets must reside in different Availability Zones in the Region where you're launching WorkSpaces. Availability Zones are distinct locations that are engineered to be isolated from failures in other Availability Zones. By launching instances in separate Availability Zones, you can protect your applications from the failure of a single location. Each subnet must reside entirely within one Availability Zone and cannot span zones.

An Availability Zone is represented by a Region code followed by a letter identifier; for example, `us-east-1a`. To ensure that resources are distributed across the Availability Zones for a Region, we independently map Availability Zones to names for each AWS account. For example, the Availability Zone `us-east-1a` for your AWS account might not be the same location as `us-east-1a` for another AWS account.

To coordinate Availability Zones across accounts, you must use the *AZ ID*, which is a unique and consistent identifier for an Availability Zone. For example, `use1-az2` is an AZ ID for the `us-east-1` Region and it has the same location in every AWS account.

Viewing AZ IDs enables you to determine the location of resources in one account relative to the resources in another account. For example, if you share a subnet in the Availability Zone with the AZ ID `use1-az2` with another account, this subnet is available to that account in the Availability Zone whose AZ ID is also `use1-az2`. The AZ ID for each VPC and subnet is displayed in the Amazon VPC console.

Amazon WorkSpaces is only available in a subset of the Availability Zones for each supported Region. The following table lists the AZ IDs that you can use for each Region. To see the mapping of AZ IDs to Availability Zones in your account, see [ AZ IDs for Your Resources](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html) in the *AWS RAM User Guide*.


| Region name | Region code | Supported AZ IDs | 
| --- | --- | --- | 
| US East (N. Virginia) | us-east-1 | use1-az2, use1-az4, use1-az6 | 
| US East (Ohio) | us-east-2 | use2-az1, use2-az2, use2-az3 | 
| US West (Oregon) | us-west-2 | usw2-az1, usw2-az2, usw2-az3 | 
| Asia Pacific (Mumbai) | ap-south-1 | aps1-az1, aps1-az2, aps1-az3 | 
| Asia Pacific (Seoul) | ap-northeast-2 | apne2-az1, apne2-az3 | 
| Asia Pacific (Singapore) | ap-southeast-1 | apse1-az1, apse1-az2 | 
| Asia Pacific (Sydney) | ap-southeast-2 | apse2-az1, apse2-az3 | 
| Asia Pacific (Malaysia) | ap-southeast-5 | apse5-az1, apse5-az2, apse5-az3 | 
| Asia Pacific (Tokyo) | ap-northeast-1 | apne1-az1, apne1-az4 | 
| Canada (Central) | ca-central-1 | cac1-az1, cac1-az2 | 
| Europe (Frankfurt) | eu-central-1 | euc1-az2, euc1-az3 | 
| Europe (Ireland) | eu-west-1 | euw1-az1, euw1-az2, euw1-az3 | 
| Europe (London) | eu-west-2 | euw2-az2, euw2-az3 | 
| Europe (Paris) | eu-west-3 | euw3-az1, euw3-az2, euw3-az3 | 
| South America (São Paulo) | sa-east-1 | sae1-az1, sae1-az3 | 
| Africa (Cape Town) | af-south-1 | afs1-az1, afs1-az2, afs1-az3 | 
| Israel (Tel Aviv) | il-central-1 | ilc1-az1, ilc1-az2, ilc1-az3 | 
| AWS GovCloud (US-West) | us-gov-west-1 | usgw1-az1, usgw1-az2, usgw1-az3 | 
| AWS GovCloud (US-East) | us-gov-east-1 | usge1-az1, usge1-az2, usge1-az3 | 

For more information about Availability Zones and AZ IDs, see [ Regions, Availability Zones, and Local Zones](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) in the *Amazon EC2 User Guide*.

# IP address and port requirements for WorkSpaces Personal
<a name="workspaces-port-requirements"></a>

To connect to your WorkSpaces, the network that your WorkSpaces clients are connected to must have certain ports open to the IP address ranges for the various AWS services (grouped in subsets). These address ranges vary by AWS Region. These same ports must also be open on any firewall running on the client. For more information about the AWS IP address ranges for different Regions, see [AWS IP Address Ranges](https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html) in the *Amazon Web Services General Reference*.

For additional architecture diagrams, see [Best Practices for Deploying Amazon WorkSpaces](https://docs.aws.amazon.com/whitepapers/latest/best-practices-deploying-amazon-workspaces/best-practices-deploying-amazon-workspaces.html).

## Ports for client applications
<a name="client-application-ports"></a>

The WorkSpaces client application requires outbound access on the following ports:

Port 53 (UDP)  
This port is used to access DNS servers. It must be open to your DNS server IP addresses so that the client can resolve public domain names. This port requirement is optional if you are not using DNS servers for domain name resolution.

Port 443 (UDP and TCP)  
This port is used for client application updates, registration, and authentication. The desktop client applications support the use of a proxy server for port 443 (HTTPS) traffic. To enable the use of a proxy server, open the client application, choose **Advanced Settings**, select **Use Proxy Server**, specify the address and port of the proxy server, and choose **Save**.  
This port must be open to the following IP address ranges:  
+ The `AMAZON` subset in the `GLOBAL` Region.
+ The `AMAZON` subset in the Region that the WorkSpace is in.
+ The `AMAZON` subset in the `us-east-1` Region.
+ The `AMAZON` subset in the `us-west-2` Region.
+ The `S3` subset in the `us-west-2` Region.

Port 4172 (UDP and TCP)  
This port is used for streaming the WorkSpace desktop and health checks for PCoIP WorkSpaces. This port must be open to the PCoIP Gateway and to the health check servers in the Region that the WorkSpace is in. For more information, see [Health check servers](#health_check) and [PCoIP gateway servers](#gateway_IP).  
For PCoIP WorkSpaces, the desktop client applications do not support the use of a proxy server nor TLS decryption and inspection for port 4172 traffic in UDP (for desktop traffic). They require a direct connection to ports 4172. 

Port 4195 (UDP and TCP)  
This port is used for streaming the WorkSpace desktop and health checks for DCV WorkSpaces. This port must be open to the DCV Gateway IP address ranges and the health check servers in the Region that the WorkSpace is in. For more information, see [Health check servers](#health_check) and [DCV gateway servers](#gateway_WSP).  
For DCV WorkSpaces, the WorkSpaces Windows client application (version 5.1 and above) and macOS client application (version 5.4 and above) support the use of HTTP proxy servers for port 4195 TCP traffic, but the use of a proxy is not recommended. TLS decryption and inspection are not supported. For more information, see **Configure device proxy server settings for internet access** for [ Windows WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/group_policy.html#gp_device_proxy), [ Amazon Linux WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/group_policy.html#gp_device_proxy_linux), and [ Ubuntu WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/group_policy.html#gp_device_proxy_ubuntu).

**Note**  
If your firewall uses stateful filtering, ephemeral ports (also known as dynamic ports) are automatically opened to allow return communication. If your firewall uses stateless filtering, you must open ephemeral ports explicitly to allow return communication. The required ephemeral port range that you must open will vary depending on your configuration.
Proxy server function is not supported for UDP traffic. If you choose to use a proxy server, the API calls that the client application makes to the Amazon WorkSpaces services are also proxied. Both API calls and desktop traffic should pass through the same proxy server.
The WorkSpaces client application first attempts to stream using UDP (QUIC) for optimal performance. If the client network only allows TCP, then TCP will be used. The WorkSpaces web client will connect over TCP port 4195 or 443. If port 4195 is blocked, the client will only attempt to connect to over port 443. 

## Ports for Web Access
<a name="web-access-ports"></a>

WorkSpaces Web Access requires outbound access for the following ports:

Port 53 (UDP)  
This port is used to access DNS servers. It must be open to your DNS server IP addresses so that the client can resolve public domain names. This port requirement is optional if you are not using DNS servers for domain name resolution.

Port 80 (UDP and TCP)  
This port is used for initial connections to `https://clients.amazonworkspaces.com`, which then switch to HTTPS. It must be open to all IP address ranges in the `EC2` subset in the Region that the WorkSpace is in. 

Port 443 (UDP and TCP)  
This port is used for registration and authentication using HTTPS. It must be open to all IP address ranges in the `EC2` subset in the Region that the WorkSpace is in.

Port 4195 (UDP and TCP)  
For WorkSpaces that are configured for DCV, this port is used for streaming the WorkSpaces desktop traffic. This port must be open to the DCV Gateway IP address ranges. For more information, see [DCV gateway servers](#gateway_WSP).  
DCV web access supports the use of a proxy server for port 4195 TCP traffic, but it’s not recommended. For more information, see **Configure device proxy server settings for internet access** for [ Windows WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/group_policy.html#gp_device_proxy), [ Amazon Linux WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/group_policy.html#gp_device_proxy_linux), or [ Ubuntu WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/group_policy.html#gp_device_proxy_ubuntu).

**Note**  
If your firewall uses stateful filtering, ephemeral ports (also known as dynamic ports) are automatically opened to allow return communication. If your firewall uses stateless filtering, you must open ephemeral ports explicitly to allow return communication. The required ephemeral port range that you must open varies depending on your configuration.
The WorkSpaces client application first attempts to stream using UDP (QUIC) for optimal performance. If the client network only allows TCP, then TCP will be used. The WorkSpaces web client will connect over TCP port 4195 or 443. If port 4195 is blocked, the client will only attempt to connect to over port 443. 

Typically, the web browser randomly selects a source port in the high range to use for streaming traffic. WorkSpaces Web Access does not have control over the port that the browser selects. You must ensure that return traffic to this port is allowed.

## Domains and IP addresses to add to your allow list
<a name="whitelisted_ports"></a>

For the WorkSpaces client application to be able to access the WorkSpaces service, you must add the following domains and IP addresses to the allow list on the network from which the client is trying to access the service.


**Domains and IP addresses to add to your allow list**  

| Category | Domain or IP address | 
| --- | --- | 
| CAPTCHA |  https://opfcaptcha-prod.s3.amazonaws.com/  | 
| Client Auto-update |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Connectivity Check |  https://connectivity.amazonworkspaces.com/  | 
| Client Metrics (for 3.0\$1 WorkSpaces client applications) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Dynamic Messaging Service (for 3.0\$1 WorkSpaces client applications) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Directory Settings |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Forrester Log Service  |  https://fls-na.amazon.com/  | 
| Health Check (DRP) Servers | [Health check servers](#health_check) | 
| Pre-session Smart Card Authentication Endpoints |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| User Login Pages |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) https://*directory\$1id*.awsapps.com/ **directory id** is the customer's domain. In the AWS GovCloud (US-West) and AWS GovCloud (US-East) Regions: https://login.us-gov-home.awsapps.com/directory/*directory id*/  **directory id** is the customer's domain.  | 
| WS Broker |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| WorkSpaces API Endpoints |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| WorkSpaces Endpoints for SAML Single Sign-On (SSO) |  Domains: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 


**Domains and IP addresses to add to your allow list for PCoIP**  

| Category | Domain or IP address | 
| --- | --- | 
| PCoIP Session Gateway (PSG) | [PCoIP gateway servers](#gateway_IP) | 
| Session Broker (PCM) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Web Access TURN Servers for PCoIP |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 


**Domains and IP addresses to add to your allow list for DCV**  

| Category | Domain or IP address | 
| --- | --- | 
| DCV Session Gateway (WSG) |  [DCV gateway servers](#gateway_WSP)  | 
| Web Access TURN Servers for DCV |  [DCV gateway servers](#gateway_WSP)  | 

## Health check servers
<a name="health_check"></a>

The WorkSpaces client applications perform health checks over ports 4172 and 4195. These checks validate whether TCP or UDP traffic streams from the WorkSpaces servers to the client applications. For these checks to finish successfully, your firewall policies must allow outbound traffic to the IP addresses of the following Regional health check servers.


| Region | Health check hostname | IP addresses | 
| --- | --- | --- | 
| US East (N. Virginia) |  IPv4: drp-iad.amazonworkspaces.com IPv6: drp-workspaces.us-east-1.api.aws  |  IPv4: 3.209.215.252 3.212.50.30 3.225.55.35 3.226.24.234 34.200.29.95 52.200.219.150 IPv6: 2600:1f18:74e9:4400::/56  | 
| US West (Oregon) |  IPv4: drp-pdx.amazonworkspaces.com IPv6: drp-workspaces.us-west-2.api.aws  |  IPv4: 34.217.248.177 52.34.160.80 54.68.150.54 54.185.4.125 54.188.171.18 54.244.158.140 IPv6: 2600:1f14:278e:5700::/56  | 
| Asia Pacific (Mumbai) |  IPv4: drp-bom.amazonworkspaces.com IPv6: drp-workspaces.ap-south-1.api.aws  |  IPv4: 13.127.57.82 13.234.250.73 IPv6: 2406:da1a:502:b800::/56  | 
| Asia Pacific (Seoul) |  IPv4: drp-icn.amazonworkspaces.com IPv6: drp-workspaces.ap-northeast-2.api.aws  |  IPv4: 13.124.44.166 13.124.203.105 52.78.44.253 52.79.54.102 IPv6: 2406:da12:c8c:4900::/56  | 
| Asia Pacific (Singapore) |  IPv4: drp-sin.amazonworkspaces.com IPv6: drp-workspaces.ap-southeast-1.api.aws  |  IPv4: 3.0.212.144 18.138.99.116 18.140.252.123 52.74.175.118 IPv6: 2406:da18:991:4a00::/56  | 
| Asia Pacific (Sydney) |  IPv4: drp-syd.amazonworkspaces.com IPv6: drp-workspaces.ap-southeast-2.api.aws  |  IPv4: 3.24.11.127 13.237.232.125 IPv6: 2406:da1c:9b5:9d00::/56  | 
| Asia Pacific (Tokyo) |  IPv4: drp-nrt.amazonworkspaces.com IPv6: drp-workspaces.ap-northeast-1.api.aws  |  IPv4: 18.178.102.247 54.64.174.128 IPv6: 2406:da14:785:5300::/56  | 
| Canada (Central) |  IPv4: drp-yul.amazonworkspaces.com IPv6: drp-workspaces.ca-central-1.api.aws  |  IPv4: 52.60.69.16 52.60.80.237 52.60.173.117 52.60.201.0 IPv6: 2600:1f11:759:d900::/56  | 
| Europe (Frankfurt) |  IPv4: drp-fra.amazonworkspaces.com IPv6: drp-workspaces.eu-central-1.api.aws  |  IPv4: 52.59.191.224 52.59.191.225 52.59.191.226 52.59.191.227 IPv6: 2a05:d014:b5c:500::/56  | 
| Europe (Ireland) |  IPv4: drp-dub.amazonworkspaces.com IPv6: drp-workspaces.eu-west-1.api.aws  |  IPv4: 18.200.177.86 52.48.86.38 54.76.137.224 IPv6: 2a05:d018:10ca:f400::/56  | 
| Europe (London) |  IPv4: drp-lhr.amazonworkspaces.com IPv6: drp-workspaces.eu-west-2.api.aws  |  IPv4: 35.176.62.54 35.177.255.44 52.56.46.102 52.56.111.36 IPv6: 2a05:d01c:263:f400::/56  | 
| Europe (Paris) |  IPv4: drp-cdg.amazonworkspaces.com IPv6: drp-workspaces.eu-west-3.api.aws  |  IPv4: 51.17.52.90 51.17.109.231 51.16.190.43 IPv6: 2a05:d012:16:8600::/56  | 
| South America (São Paulo) |  IPv4: drp-gru.amazonworkspaces.com IPv6: drp-workspaces.sa-east-1.api.aws  |  IPv4: 18.231.0.105 52.67.55.29 54.233.156.245 54.233.216.234 IPv6: 2600:1f1e:bbf:fa00::/56  | 
| Africa (Cape Town) |  IPv4: drp-cpt.amazonworkspaces.com/ IPv6: drp-workspaces.af-south-1.api.aws  |  IPv4: 13.244.128.155 13.245.205.255 13.245.216.116 IPv6: 2406:da11:685:2400::/56  | 
| Israel (Tel Aviv) |  IPv4: drp-tlv.amazonworkspaces.com/ IPv6: drp-workspaces.il-central-1.api.aws  |  IPv4: 51.17.52.90 51.17.109.231 51.16.190.43 IPv6: 2a05:d025:c78:fc00::/56  | 
| AWS GovCloud (US-West) |  IPv4: drp-pdt.amazonworkspaces.com IPv6: drp-workspaces.us-gov-west-1.api.aws  |  IPv4: 52.61.60.65 52.61.65.14 52.61.88.170 52.61.137.87 52.61.155.110 52.222.20.88 IPv6: 2600:1f12:28f:af00::/56  | 
| AWS GovCloud (US-East) |  IPv4: drp-osu.amazonworkspaces.com IPv6: drp-workspaces.us-gov-east-1.api.aws  |  IPv4: 18.253.251.70 18.254.0.118 IPv6: 2600:1f15:a45:3e00::/56  | 

## PCoIP gateway servers
<a name="gateway_IP"></a>

WorkSpaces uses PCoIP to stream the desktop session to clients over port 4172. For its PCoIP gateway servers, WorkSpaces uses a small range of Amazon EC2 public IPv4 and IPv6 addresses. This enables you to set more finely grained firewall policies for devices that access WorkSpaces. Note that the WorkSpaces client prioritizes IPv6 connections when IPv6 is supported and gateways are reachable. If IPv6 is unavailable, it falls back to IPv4.


| Region | Region code | Public IP address range | 
| --- | --- | --- | 
| US East (N. Virginia) | us-east-1 |  3.217.228.0 - 3.217.231.255 3.235.112.0 - 3.235.119.255 52.23.61.0 - 52.23.62.255 2600:1f32:8000::/39   | 
| US West (Oregon) | us-west-2 |  35.80.88.0 - 35.80.95.255 44.234.54.0 - 44.234.55.255 54.244.46.0 - 54.244.47.255 2600:1f32:4000::/39   | 
| Asia Pacific (Mumbai) | ap-south-1 |  13.126.243.0 - 13.126.243.255 2406:da32:a000::/40  | 
| Asia Pacific (Seoul) | ap-northeast-2 |  3.34.37.0 - 3.34.37.255 3.34.38.0 - 3.34.39.255 13.124.247.0 - 13.124.247.255 2406:da32:2000::/40  | 
| Asia Pacific (Singapore) | ap-southeast-1 |  18.141.152.0 - 18.141.152.255 18.141.154.0 - 18.141.155.255 52.76.127.0 - 52.76.127.255 2406:da32:8000::/40  | 
| Asia Pacific (Sydney) | ap-southeast-2 |  3.25.43.0 - 3.25.43.255 3.25.44.0 - 3.25.45.255 54.153.254.0 - 54.153.254.255 2406:da32:c000::/40  | 
| Asia Pacific (Tokyo) | ap-northeast-1 |  18.180.178.0 - 18.180.178.255 18.180.180.0 - 18.180.181.255 54.250.251.0 - 54.250.251.255 2406:da32:4000::/40  | 
| Canada (Central) | ca-central-1 |  15.223.100.0 - 15.223.100.255 15.223.102.0 - 15.223.103.255 35.183.255.0 - 35.183.255.255 2600:1f32:1000::/40  | 
| Europe (Frankfurt) | eu-central-1 |  18.156.52.0 - 18.156.52.255 18.156.54.0 - 18.156.55.255 52.59.127.0 - 52.59.127.255 2a05:d032:4000::/40  | 
| Europe (Ireland) | eu-west-1 |  3.249.28.0 - 3.249.29.255 52.19.124.0 - 52.19.125.255 2a05:d032:8000::/40  | 
| Europe (London) | eu-west-2 |  18.132.21.0 - 18.132.21.255 18.132.22.0 - 18.132.23.255 35.176.32.0 - 35.176.32.255 2a05:d032:c000::/40  | 
| Europe (Paris) | eu-west-3 |  51.44.204.0-51.44.207.255  | 
| South America (São Paulo) | sa-east-1 |  18.230.103.0 - 18.230.103.255 18.230.104.0 - 18.230.105.255 54.233.204.0 - 54.233.204.255 2600:1f32:e000::/40  | 
| Africa (Cape Town) | af-south-1 |  13.246.120.0 - 13.246.123.255 2406:da32:1000::/40  | 
| Israel (Tel Aviv) | il-central-1 |   51.17.28.0-51.17.31.255 2a05:d032:5000::/40  | 
| AWS GovCloud (US-West) | us-gov-west-1 |  52.61.193.0 - 52.61.193.255 2600:1f32:2000::/40  | 
| AWS GovCloud (US-East) | us-gov-east-1 |  18.254.140.0 - 18.254.143.255 2600:1f32:5000::/40  | 

## DCV gateway servers
<a name="gateway_WSP"></a>

**Important**  
Starting in June 2020, WorkSpaces streams the desktop session for DCV WorkSpaces to clients over port 4195 instead of port 4172. If you want to use DCV WorkSpaces, make sure that port 4195 is open to traffic.

**Note**  
For non-BYOL WorkSpaces Pools, IP address ranges are not guaranteed. Instead, you must allowlist the DCV gateway domain names. For more information, see [ DCV gateway domain names](https://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html#dns-wsp). 

WorkSpaces uses a small range of Amazon EC2 public IPv4 and IPv6 addresses for its DCV gateway servers. This enables you to set more finely grained firewall policies for devices that access WorkSpaces. WorkSpaces use a separate range of public IPv4 addresses for the dedicated AWS Global Accelerator (AGA) endpoints. Make sure to configure your firewall policies to allowlist the IP ranges if you plan to enable AGA for your WorkSpaces. Note that the WorkSpaces client prioritizes IPv6 connections when IPv6 is supported and gateways are reachable. If IPv6 is unavailable, it falls back to IPv4.

If you use AGA \$1 IPv6, you need to allowlist the IPv6 CIDR ranges from the `GLOBALACCELERATOR` ranges. See [Location and IP address ranges of Global Accelerator Edge servers](https://docs.aws.amazon.com/global-accelerator/latest/dg/introduction-ip-ranges.html) in the *AWS Global Accelerator Developer Guide* for more information.


| Region | Region code | Public IP address range | 
| --- | --- | --- | 
| US East (N. Virginia) | us-east-1 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| US East (Ohio) | us-east-2 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| US West (Oregon) | us-west-2 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Asia Pacific (Mumbai) | ap-south-1 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Asia Pacific (Seoul) | ap-northeast-2 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Asia Pacific (Singapore) | ap-southeast-1 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Asia Pacific (Sydney) | ap-southeast-2 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Asia Pacific (Malaysia) | ap-southeast-5 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Asia Pacific (Tokyo) | ap-northeast-1 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Canada (Central) | ca-central-1 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Europe (Frankfurt) | eu-central-1 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Europe (Ireland) | eu-west-1 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Europe (London) | eu-west-2 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Europe (Paris) | eu-west-3 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| South America (São Paulo) | sa-east-1 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Africa (Cape Town) | af-south-1 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Israel (Tel Aviv) | il-central-1 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| AWS GovCloud (US-West) | us-gov-west-1 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| AWS GovCloud (US-East) | us-gov-east-1 |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 

## DCV gateway domain names
<a name="dns-wsp"></a>

The following table lists the DCV WorkSpace gateway domain names. These domains must be contactable, for the WorkSpaces client application to be able to access the WorkSpace DCV service. 


| Region | Domain | 
| --- | --- | 
| US East (N. Virginia) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| US West (Oregon) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Asia Pacific (Mumbai) | \$1.prod.ap-south-1.highlander.aws.a2z.com | 
| Asia Pacific (Seoul) | \$1.prod.ap-northeast-2.highlander.aws.a2z.com | 
| Asia Pacific (Singapore) | \$1.prod.ap-southeast-1.highlander.aws.a2z.com | 
| Asia Pacific (Sydney) | \$1.prod.ap-southeast-2.highlander.aws.a2z.com | 
| Asia Pacific (Tokyo) | \$1.prod.ap-northeast-1.highlander.aws.a2z.com | 
| Canada (Central) | \$1.prod.ca-central-1.highlander.aws.a2z.com | 
| Europe (Frankfurt) | \$1.prod.eu-central-1.highlander.aws.a2z.com | 
| Europe (Ireland) | \$1.prod.eu-west-1.highlander.aws.a2z.com | 
| Europe (London) | \$1.prod.eu-west-2.highlander.aws.a2z.com | 
| Europe (Paris) | \$1.prod.eu-west-3.highlander.aws.a2z.com | 
| South America (São Paulo) | \$1.prod.sa-east-1.highlander.aws.a2z.com | 
| Africa (Cape Town) | \$1.prod.af-south-1.highlander.aws.a2z.com | 
| Israel (Tel Aviv) | \$1.prod.il-central-1.highlander.aws.a2z.com | 
| AWS GovCloud (US-West) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| AWS GovCloud (US-East) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 

## DCV PrivateLink domain names
<a name="dns-wsp-privatelink"></a>

If you use VPC endpoints for WorkSpaces streaming, the following domains must be allowed through your firewall or proxy. Replace <region> with your AWS Region (for example, us-east-1).


| DNS Name Type | Domain | 
| --- | --- | 
| Unique publicly resolvable DNS name | \$1.prod.highlander.<region>.vpce.amazonaws.com | 
| Generic private DNS name | privatelink.prod.<region>.highlander.aws.a2z.com | 

## Network interfaces
<a name="network-interfaces"></a>

Each WorkSpace has the following network interfaces:
+ The primary network interface (eth1) provides connectivity to the resources within your VPC and on the internet, and is used to join the WorkSpace to the directory.
+ The management network interface (eth0) is connected to a secure WorkSpaces management network. It is used for interactive streaming of the WorkSpace desktop to WorkSpaces clients, and to allow WorkSpaces to manage the WorkSpace.

WorkSpaces selects the IP address for the management network interface from various address ranges, depending on the Region that the WorkSpaces are created in. When a directory is registered, WorkSpaces tests the VPC CIDR and the route tables in your VPC to determine if these address ranges create a conflict. If a conflict is found in all available address ranges in the Region, an error message is displayed and the directory is not registered. If you change the route tables in your VPC after the directory is registered, you might cause a conflict.

**Warning**  
Do not modify or delete any of the network interfaces that are attached to a WorkSpace. Doing so might cause the WorkSpace to become unreachable or lose internet access. For example, if you have [enabled automatic assignment of Elastic IP addresses](automatic-assignment.md) at the directory level, an [ Elastic IP address](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-eips.html) (from the Amazon-provided pool) is assigned to your WorkSpace when it is launched. However, if you associate an Elastic IP address that you own to a WorkSpace, and then you later disassociate that Elastic IP address from the WorkSpace, the WorkSpace loses its public IP address, and it doesn't automatically get a new one from the Amazon-provided pool.  
To associate a new public IP address from the Amazon-provided pool with the WorkSpace, you must [rebuild the WorkSpace](rebuild-workspace.md). If you don't want to rebuild the WorkSpace, you must associate another Elastic IP address that you own to the WorkSpace.

### Management interface IP ranges
<a name="management-ip-ranges"></a>

The following table lists the IP address ranges used for the management network interface.

**Note**  
**If you're using Bring Your Own License (BYOL) Windows WorkSpaces**, the IP address ranges in the following table do not apply. Instead, PCoIP BYOL WorkSpaces use the 54.239.224.0/20 IP address range for management interface traffic in all AWS Regions. For DCV BYOL Windows WorkSpaces, both the 54.239.224.0/20 and 10.0.0.0/8 IP address ranges apply in all AWS Regions. (These IP address ranges are used in addition to the /16 CIDR block that you select for management traffic for your BYOL WorkSpaces.)
**If you're using DCV WorkSpaces created from public bundles**, the IP address range 10.0.0.0/8 also applies for management interface traffic in all AWS Regions, in addition to the PCoIP/DCV ranges shown in the following table.


| Region | IP address range | 
| --- | --- | 
| US East (N. Virginia) | PCoIP/WSP: 172.31.0.0/16, 192.168.0.0/16, 198.19.0.0/16 WSP: 10.0.0.0/8 | 
| US West (Oregon) | PCoIP/WSP: 172.31.0.0/16, 192.168.0.0/16, and 198.19.0.0/16 WSP: 10.0.0.0/8 | 
| Asia Pacific (Mumbai) | PCoIP/WSP: 192.168.0.0/16 WSP: 10.0.0.0/8 | 
| Asia Pacific (Seoul) | PCoIP/WSP: 198.19.0.0/16 WSP: 10.0.0.0/8 | 
| Asia Pacific (Singapore) | PCoIP/WSP: 198.19.0.0/16 WSP: 10.0.0.0/8 | 
| Asia Pacific (Sydney) | PCoIP/WSP: 172.31.0.0/16, 192.168.0.0/16, and 198.19.0.0/16 WSP: 10.0.0.0/8 | 
| Asia Pacific (Tokyo) | PCoIP/WSP: 198.19.0.0/16 WSP: 10.0.0.0/8 | 
| Canada (Central) | PCoIP/WSP: 198.19.0.0/16 WSP: 10.0.0.0/8 | 
| Europe (Frankfurt) | PCoIP/WSP: 198.19.0.0/16 WSP: 10.0.0.0/8 | 
| Europe (Ireland) | PCoIP/WSP: 172.31.0.0/16, 192.168.0.0/16, and 198.19.0.0/16 WSP: 10.0.0.0/8 | 
| Europe (London) | PCoIP/WSP: 198.19.0.0/16 WSP: 10.0.0.0/8 | 
| Europe (Paris) | PCoIP/WSP: 198.19.0.0/16 WSP: 10.0.0.0/8 | 
| South America (São Paulo) | PCoIP/WSP: 198.19.0.0/16 WSP: 10.0.0.0/8 | 
| Africa (Cape Town) | PCoIP/WSP: 172.31.0.0/16 and 198.19.0.0/16 WSP: 10.0.0.0/8 | 
| Israel (Tel Aviv) | PCoIP/WSP: 198.19.0.0/16 WSP: 10.0.0.0/8 | 
| AWS GovCloud (US-West) | PCoIP/WSP: 198.19.0.0/16 WSP: 10.0.0.0/8 and 192.169.0.0/16 | 
| AWS GovCloud (US-East) | PCoIP/WSP: 198.19.0.0/16 WSP: 10.0.0.0/8 | 

### Management interface ports
<a name="management_ports"></a>

The following ports must be open on the management network interface of all WorkSpaces:
+ Inbound TCP on port 4172. This is used for establishment of the streaming connection on the PCoIP protocol.
+ Inbound UDP on port 4172. This is used for streaming user input on the PCoIP protocol.
+ Inbound TCP on port 4489. This is used for access using the web client.
+ Inbound TCP on port 8200. This is used for management and configuration of the WorkSpace.
+ Inbound TCP on ports 8201-8250. These ports are used for establishment of the streaming connection and for streaming user input on the DCV protocol.
+ Inbound UDP on port 8220. This port is used for establishment of the streaming connection and for streaming user input on the DCV protocol
+ Outbound TCP on ports 8443 and 9997. This is used for access using the web client.
+ Outbound UDP on ports 3478, 4172, and 4195. This is used for access using the web client.
+ Outbound UDP on ports 50002 and 55002. This is used for streaming. If your firewall uses stateful filtering, the ephemeral ports 50002 and 55002 are automatically opened to allow return communication. If your firewall uses stateless filtering, you must open ephemeral ports 49152 - 65535 to allow return communication.
+ Outbound TCP on port 80, as defined in [ Management interface IP ranges](https://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html#management-ip-ranges), to IP address 169.254.169.254 for access to the EC2 metadata service. Any HTTP proxy assigned to your WorkSpaces must also exclude 169.254.169.254.
+ Outbound TCP on port 1688 to IP addresses 169.254.169.250 and 169.254.169.251 to allow access to Microsoft KMS for Windows activation for Workspaces that are based on public bundles. If you're using Bring Your Own License (BYOL) Windows WorkSpaces, you must allow access to your own KMS servers for Windows activation.
+ Outbound TCP on port 1688 to IP address 54.239.236.220 to allow access to Microsoft KMS for Office activation for BYOL WorkSpaces.

  If you're using Office through one of the WorkSpaces public bundles, the IP address for Microsoft KMS for Office activation varies. To determine that IP address, find the IP address for the management interface of the WorkSpace, and then replace the last two octets with `64.250`. For example, if the IP address of the management interface is 192.168.3.5, the IP address for Microsoft KMS Office activation is 192.168.64.250.
+ Outbound TCP to IP address 127.0.0.2 for DCV WorkSpaces when the WorkSpace host is configured to use a proxy server.
+ Communications originating from loopback address 127.0.01.

Under normal circumstances, the WorkSpaces service configures these ports for your WorkSpaces. If any security or firewall software is installed on a WorkSpace that blocks any of these ports, the WorkSpace may not function correctly or may be unreachable.

### Primary interface ports
<a name="primary_ports"></a>

No matter which type of directory you have, the following ports must be open on the primary network interface of all WorkSpaces:
+ For internet connectivity, the following ports must be open outbound to all destinations and inbound from the WorkSpaces VPC. You need to add these manually to the security group for your WorkSpaces if you want them to have internet access.
  + TCP 80 (HTTP)
  + TCP 443 (HTTPS)
+ To communicate with the directory controllers, the following ports must be open between your WorkSpaces VPC and your directory controllers. For a Simple AD directory, the security group created by Directory Service will have these ports configured correctly. For an AD Connector directory, you might need to adjust the default security group for the VPC to open these ports.
  + TCP/UDP 53 - DNS
  + TCP/UDP 88 - Kerberos authentication
  + UDP 123 - NTP
  + TCP 135 - RPC
  + UDP 137-138 - Netlogon
  + TCP 139 - Netlogon
  + TCP/UDP 389 - LDAP
  + TCP/UDP 445 - SMB
  + TCP/UDP 636 - LDAPS (LDAP over TLS/SSL)
  + TCP 1024-65535 - Dynamic ports for RPC
  + TTCP 3268-3269 - Global Catalog

  If any security or firewall software is installed on a WorkSpace that blocks any of these ports, the WorkSpace may not function correctly or may be unreachable.

## IP address and port requirements by Region
<a name="ip-address-regions"></a>

### US East (N. Virginia)
<a name="us-east"></a>


**Domains and IP Addresses to add to your allowlist**  

| Category | Details | 
| --- | --- | 
| CAPTCHA | https://opfcaptcha-prod.s3.amazonaws.com/ | 
| Client Auto-update |  https://d2td7dqidlhjx7.cloudfront.net/  | 
| Connectivity Check |  https://connectivity.amazonworkspaces.com/  | 
| Client Metrics (for 3.0\$1 WorkSpaces client applications) |  Domain: https://skylight-client-ds.us-east-1.amazonaws.com   | 
| Dynamic Messaging Service (for 3.0\$1 WorkSpaces client applications) |  Domain: https://ws-client-service.us-east-1.amazonaws.com  | 
| Directory Settings |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Forrester Log Service  | https://fls-na.amazon.com/ | 
| Health Check (DRP) Servers | [Health check servers](#health_check) | 
| Pre-session Smart Card Authentication Endpoints | https://smartcard.us-east-1.signin.aws | 
| Registration Dependency (for Web Access and Teradici PCoIP Zero Clients) | https://s3.amazonaws.com | 
| User Login Pages | https://<directory id>.awsapps.com/ (where <directory id> is the customer's domain)  | 
| WS Broker |  Domains: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| WorkSpaces API Endpoints |  Domains: https://workspaces.us-east-1.amazonaws.com  | 
| Session Broker (PCM) | Domains: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Web Access TURN Servers for PCoIP | Server: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Health check hostname | drp-iad.amazonworkspaces.com | 
| Health check IP addresses |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| PCoIP gateway servers public IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| DCV gateway servers IP address range |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| DCV gateway domain name | \$1.prod.us-east-1.highlander.aws.a2z.com | 
| Management interface IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 

### US West (Oregon)
<a name="us-west"></a>


**Domains and IP Addresses to add to your allowlist**  

| Category | Details | 
| --- | --- | 
| CAPTCHA | https://opfcaptcha-prod.s3.amazonaws.com/ | 
| Client Auto-update |  https://d2td7dqidlhjx7.cloudfront.net/  | 
| Connectivity Check |  https://connectivity.amazonworkspaces.com/  | 
| Client Metrics (for 3.0\$1 WorkSpaces client applications) |  Domain: https://skylight-client-ds.us-west-2.amazonaws.com   | 
| Dynamic Messaging Service (for 3.0\$1 WorkSpaces client applications) |  Domain: https://ws-client-service.us-west-2.amazonaws.com  | 
| Directory Settings |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Forrester Log Service  | https://fls-na.amazon.com/ | 
| Health Check (DRP) Servers | [Health check servers](#health_check) | 
| Pre-session Smart Card Authentication Endpoints | https://smartcard.us-west-2.signin.aws | 
| Registration Dependency (for Web Access and Teradici PCoIP Zero Clients) | https://s3.amazonaws.com | 
| User Login Pages | https://<directory id>.awsapps.com/ (where <directory id> is the customer's domain)  | 
| WS Broker |  Domains: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| WorkSpaces API Endpoints |  Domains: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Session Broker (PCM) | Domains: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Web Access TURN Servers for PCoIP | Server: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Health check hostname | drp-pdx.amazonworkspaces.com | 
| Health check IP addresses |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| PCoIP gateway servers public IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| DCV gateway servers IP address range | 34.223.96.0/22 | 
| DCV gateway domain name | \$1.prod.us-west-2.highlander.aws.a2z.com | 
| Management interface IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 

### Asia Pacific (Mumbai)
<a name="ap-south"></a>


**Domains and IP Addresses to add to your allowlist**  

| Category | Details | 
| --- | --- | 
| CAPTCHA | https://opfcaptcha-prod.s3.amazonaws.com/ | 
| Client Auto-update |  https://d2td7dqidlhjx7.cloudfront.net/  | 
| Connectivity Check |  https://connectivity.amazonworkspaces.com/  | 
| Client Metrics (for 3.0\$1 WorkSpaces client applications) |  Domain: https://skylight-client-ds.ap-south-1.amazonaws.com   | 
| Dynamic Messaging Service (for 3.0\$1 WorkSpaces client applications) |  Domain: https://ws-client-service.ap-south-1.amazonaws.com  | 
| Directory Settings |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Forrester Log Service  | https://fls-na.amazon.com/ | 
| Health Check (DRP) Servers | [Health check servers](#health_check) | 
| Registration Dependency (for Web Access and Teradici PCoIP Zero Clients) | https://s3.amazonaws.com | 
| User Login Pages | https://<directory id>.awsapps.com/ (where <directory id> is the customer's domain)  | 
| WS Broker |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| WorkSpaces API Endpoints |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Session Broker (PCM) | Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Web Access TURN Servers for PCoIP | Web Access isn't currently available in the Asia Pacific (Mumbai) Region | 
| Health check hostname | drp-bom.amazonworkspaces.com | 
| Health check IP addresses |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| PCoIP gateway servers public IP address ranges | 13.126.243.0 - 13.126.243.255 | 
| DCV gateway servers IP address range | 65.1.156.0/22 | 
| DCV gateway domain name | \$1.prod.ap-south-1.highlander.aws.a2z.com | 
| Management interface IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 

### Asia Pacific (Seoul)
<a name="ap-northeast-2"></a>


**Domains and IP Addresses to add to your allowlist**  

| Category | Details | 
| --- | --- | 
| CAPTCHA | https://opfcaptcha-prod.s3.amazonaws.com/ | 
| Client Auto-update |  https://d2td7dqidlhjx7.cloudfront.net/  | 
| Connectivity Check |  https://connectivity.amazonworkspaces.com/  | 
| Device Metrics (for 1.0\$1 and 2.0\$1 WorkSpaces client applications) | https://device-metrics-us-2.amazon.com/ | 
| Client Metrics (for 3.0\$1 WorkSpaces client applications) |  Domain: https://skylight-client-ds.ap-northeast-2.amazonaws.com  | 
| Dynamic Messaging Service (for 3.0\$1 WorkSpaces client applications) |  Domain: https://ws-client-service.ap-northeast-2.amazonaws.com  | 
| Directory Settings |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Forrester Log Service  | https://fls-na.amazon.com/ | 
| Health Check (DRP) Servers | [Health check servers](#health_check) | 
| Registration Dependency (for Web Access and Teradici PCoIP Zero Clients) | https://s3.amazonaws.com | 
| User Login Pages | https://<directory id>.awsapps.com/ (where <directory id> is the customer's domain)  | 
| WS Broker |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| WorkSpaces API Endpoints |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Session Broker (PCM) | Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Web Access TURN Servers for PCoIP | Server: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Health check hostname | drp-icn.amazonworkspaces.com | 
| Health check IP addresses |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| PCoIP gateway servers public IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| DCV gateway servers IP address range | 3.35.160.0/22 | 
| DCV gateway domain name | \$1.prod.ap-northeast-2.highlander.aws.a2z.com | 
| Management interface IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 

### Asia Pacific (Singapore)
<a name="ap-southeast-1"></a>


**Domains and IP Addresses to add to your allowlist**  

| Category | Details | 
| --- | --- | 
| CAPTCHA | https://opfcaptcha-prod.s3.amazonaws.com/ | 
| Client Auto-update |  https://d2td7dqidlhjx7.cloudfront.net/  | 
| Connectivity Check |  https://connectivity.amazonworkspaces.com/  | 
| Client Metrics (for 3.0\$1 WorkSpaces client applications) |  Domain: https://skylight-client-ds.ap-southeast-1.amazonaws.com  | 
| Dynamic Messaging Service (for 3.0\$1 WorkSpaces client applications) |  Domain: https://ws-client-service.ap-southeast-1.amazonaws.com  | 
| Directory Settings |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Forrester Log Service  | https://fls-na.amazon.com/ | 
| Health Check (DRP) Servers | [Health check servers](#health_check) | 
| Registration Dependency (for Web Access and Teradici PCoIP Zero Clients) | https://s3.amazonaws.com | 
| User Login Pages | https://<directory id>.awsapps.com/ (where <directory id> is the customer's domain)  | 
| WS Broker |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| WorkSpaces API Endpoints |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Session Broker (PCM) | Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Web Access TURN Servers for PCoIP | Server: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Health check hostname | drp-sin.amazonworkspaces.com | 
| Health check IP addresses |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| PCoIP gateway servers public IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| DCV gateway servers IP address range | 13.212.132.0/22 | 
| DCV gateway domain name | \$1.prod.ap-southeast-1.highlander.aws.a2z.com | 
| Management interface IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 

### Asia Pacific (Sydney)
<a name="ap-southeast-2"></a>


**Domains and IP Addresses to add to your allowlist**  

| Category | Details | 
| --- | --- | 
| CAPTCHA | https://opfcaptcha-prod.s3.amazonaws.com/ | 
| Client Auto-update |  https://d2td7dqidlhjx7.cloudfront.net/  | 
| Connectivity Check |  https://connectivity.amazonworkspaces.com/  | 
| Client Metrics (for 3.0\$1 WorkSpaces client applications) |  Domain: https://skylight-client-ds.ap-southeast-2.amazonaws.com  | 
| Dynamic Messaging Service (for 3.0\$1 WorkSpaces client applications) |  Domain:  https://ws-client-service.ap-southeast-2.amazonaws.com  | 
| Directory Settings |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Forrester Log Service  | https://fls-na.amazon.com/ | 
| Health Check (DRP) Servers | [Health check servers](#health_check) | 
| Pre-session Smart Card Authentication Endpoints | https://smartcard.ap-southeast-2.signin.aws | 
| Registration Dependency (for Web Access and Teradici PCoIP Zero Clients) | https://s3.amazonaws.com | 
| User Login Pages | https://<directory id>.awsapps.com/ (where <directory id> is the customer's domain)  | 
| WS Broker |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| WorkSpaces API Endpoints |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Session Broker (PCM) | Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Web Access TURN Servers for PCoIP | Server: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Health check hostname | drp-syd.amazonworkspaces.com | 
| Health check IP addresses |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| PCoIP gateway servers public IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| DCV gateway servers IP address range | 3.25.248.0/22 | 
| DCV gateway domain name | \$1.prod.ap-southeast-2.highlander.aws.a2z.com | 
| Management interface IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 

### Asia Pacific (Tokyo)
<a name="ap-northeast-1"></a>


**Domains and IP Addresses to add to your allowlist**  

| Category | Details | 
| --- | --- | 
| CAPTCHA | https://opfcaptcha-prod.s3.amazonaws.com/ | 
| Client Auto-update |  https://d2td7dqidlhjx7.cloudfront.net/  | 
| Connectivity Check |  https://connectivity.amazonworkspaces.com/  | 
| Client Metrics (for 3.0\$1 WorkSpaces client applications) |  Domain: https://skylight-client-ds.ap-northeast-1.amazonaws.com  | 
| Dynamic Messaging Service (for 3.0\$1 WorkSpaces client applications) |  Domain:  https://ws-client-service.ap-northeast-1.amazonaws.com  | 
| Directory Settings |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Forrester Log Service  | https://fls-na.amazon.com/ | 
| Health Check (DRP) Servers | [Health check servers](#health_check) | 
| Pre-session Smart Card Authentication Endpoints | https://smartcard.ap-northeast-1.signin.aws | 
| Registration Dependency (for Web Access and Teradici PCoIP Zero Clients) | https://s3.amazonaws.com | 
| User Login Pages | https://<directory id>.awsapps.com/ (where <directory id> is the customer's domain)  | 
| WS Broker |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| WorkSpaces API Endpoints |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Session Broker (PCM) | Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Web Access TURN Servers for PCoIP | Server: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Health check hostname | drp-nrt.amazonworkspaces.com | 
| Health check IP addresses |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| PCoIP gateway servers public IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| DCV gateway servers IP address range | 3.114.164.0/22 | 
| DCV gateway domain name | \$1.prod.ap-northeast-1.highlander.aws.a2z.com | 
| Management interface IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 

### Canada (Central)
<a name="ca-central-1"></a>


**Domains and IP Addresses to add to your allowlist**  

| Category | Details | 
| --- | --- | 
| CAPTCHA | https://opfcaptcha-prod.s3.amazonaws.com/ | 
| Client Auto-update |  https://d2td7dqidlhjx7.cloudfront.net/  | 
| Connectivity Check |  https://connectivity.amazonworkspaces.com/  | 
| Client Metrics (for 3.0\$1 WorkSpaces client applications) |  Domain: https://skylight-client-ds.ca-central-1.amazonaws.com  | 
| Dynamic Messaging Service (for 3.0\$1 WorkSpaces client applications) |  Domain:  https://ws-client-service.ca-central-1.amazonaws.com  | 
| Directory Settings |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Forrester Log Service  | https://fls-na.amazon.com/ | 
| Health Check (DRP) Servers | [Health check servers](#health_check) | 
| Registration Dependency (for Web Access and Teradici PCoIP Zero Clients) | https://s3.amazonaws.com | 
| User Login Pages | https://<directory id>.awsapps.com/ (where <directory id> is the customer's domain)  | 
| WS Broker |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| WorkSpaces API Endpoints |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Session Broker (PCM) | Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Web Access TURN Servers for PCoIP | Server: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Health check hostname | drp-yul.amazonworkspaces.com | 
| Health check IP addresses |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| PCoIP gateway servers public IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| DCV gateway servers IP address range | 3.97.20.0/22 | 
| DCV gateway domain name | \$1.prod.ca-central-1.highlander.aws.a2z.com | 
| Management interface IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 

### Europe (Frankfurt)
<a name="eu-central-1"></a>


**Domains and IP Addresses to add to your allowlist**  

| Category | Details | 
| --- | --- | 
| CAPTCHA | https://opfcaptcha-prod.s3.amazonaws.com/ | 
| Client Auto-update |  https://d2td7dqidlhjx7.cloudfront.net/  | 
| Connectivity Check |  https://connectivity.amazonworkspaces.com/  | 
| Client Metrics (for 3.0\$1 WorkSpaces client applications) |  Domain: https://skylight-client-ds.eu-central-1.amazonaws.com  | 
| Dynamic Messaging Service (for 3.0\$1 WorkSpaces client applications) |  Domain:  https://ws-client-service.eu-central-1.amazonaws.com  | 
| Directory Settings |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Forrester Log Service  | https://fls-na.amazon.com/ | 
| Health Check (DRP) Servers | [Health check servers](#health_check) | 
| Registration Dependency (for Web Access and Teradici PCoIP Zero Clients) | https://s3.amazonaws.com | 
| User Login Pages | https://<directory id>.awsapps.com/ (where <directory id> is the customer's domain)  | 
| WS Broker |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| WorkSpaces API Endpoints |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Session Broker (PCM) | Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Web Access TURN Servers for PCoIP | Server: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Health check hostname | drp-fra.amazonworkspaces.com | 
| Health check IP addresses |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| PCoIP gateway servers public IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| DCV gateway servers IP address range | 18.192.216.0/22 | 
| DCV gateway domain name | \$1.prod.eu-central-1.highlander.aws.a2z.com | 
| Management interface IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 

### Europe (Ireland)
<a name="eu-west-1"></a>


**Domains and IP Addresses to add to your allowlist**  

| Category | Details | 
| --- | --- | 
| CAPTCHA | https://opfcaptcha-prod.s3.amazonaws.com/ | 
| Client Auto-update |  https://d2td7dqidlhjx7.cloudfront.net/  | 
| Connectivity Check |  https://connectivity.amazonworkspaces.com/  | 
| Client Metrics (for 3.0\$1 WorkSpaces client applications) |  Domain: https://skylight-client-ds.eu-west-1.amazonaws.com  | 
| Dynamic Messaging Service (for 3.0\$1 WorkSpaces client applications) |  Domain:  https://ws-client-service.eu-west-1.amazonaws.com  | 
| Directory Settings |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Forrester Log Service  | https://fls-na.amazon.com/ | 
| Health Check (DRP) Servers | [Health check servers](#health_check) | 
| Pre-session Smart Card Authentication Endpoints | https://smartcard.eu-west-1.signin.aws | 
| Registration Dependency (for Web Access and Teradici PCoIP Zero Clients) | https://s3.amazonaws.com | 
| User Login Pages | https://<directory id>.awsapps.com/ (where <directory id> is the customer's domain)  | 
| WS Broker |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| WorkSpaces API Endpoints |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Session Broker (PCM) | Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Web Access TURN Servers for PCoIP | Server: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Health check hostname | drp-dub.amazonworkspaces.com | 
| Health check IP addresses |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| PCoIP gateway servers public IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| DCV gateway servers IP address range | 3.248.176.0/22 | 
| DCV gateway domain name | \$1.prod.eu-west-1.highlander.aws.a2z.com | 
| Management interface IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 

### Europe (London)
<a name="eu-west-2"></a>


**Domains and IP Addresses to add to your allowlist**  

| Category | Details | 
| --- | --- | 
| CAPTCHA | https://opfcaptcha-prod.s3.amazonaws.com/ | 
| Client Auto-update |  https://d2td7dqidlhjx7.cloudfront.net/  | 
| Connectivity Check |  https://connectivity.amazonworkspaces.com/  | 
| Client Metrics (for 3.0\$1 WorkSpaces client applications) |  Domain: https://skylight-client-ds.eu-west-2.amazonaws.com  | 
| Dynamic Messaging Service (for 3.0\$1 WorkSpaces client applications) |  Domain:  https://ws-client-service.eu-west-2.amazonaws.com  | 
| Directory Settings |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Forrester Log Service  | https://fls-na.amazon.com/ | 
| Health Check (DRP) Servers | [Health check servers](#health_check) | 
| Registration Dependency (for Web Access and Teradici PCoIP Zero Clients) | https://s3.amazonaws.com | 
| User Login Pages | https://<directory id>.awsapps.com/ (where <directory id> is the customer's domain)  | 
| WS Broker |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| WorkSpaces API Endpoints |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Session Broker (PCM) | Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Web Access TURN Servers for PCoIP | Server: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Health check hostname | drp-lhr.amazonworkspaces.com | 
| Health check IP addresses |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| PCoIP gateway servers public IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| DCV gateway servers IP address range | 18.134.68.0/22 | 
| DCV gateway domain name | \$1.prod.eu-west-2.highlander.aws.a2z.com | 
| Management interface IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 

### Europe (Paris)
<a name="eu-west-3"></a>


**Domains and IP Addresses to add to your allowlist**  

| Category | Details | 
| --- | --- | 
| CAPTCHA | https://opfcaptcha-prod.s3.amazonaws.com/Client  | 
| Client Auto-update |  https://d2td7dqidlhjx7.cloudfront.net/  | 
| Connectivity Check |  https://connectivity.amazonworkspaces.com/  | 
| Client Metrics (for 3.0\$1 WorkSpaces client applications) |  Domain: https://skylight-client-ds.eu-west-3.amazonaws.com  | 
| Dynamic Messaging Service (for 3.0\$1 WorkSpaces client applications) |  Domain:  https://ws-client-service.eu-west-3.amazonaws.com  | 
| Directory Settings |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Forrester Log Service  | https://fls-na.amazon.com/ | 
| Health Check (DRP) Servers | [Health check servers](#health_check) | 
| Registration Dependency (for Web Access and Teradici PCoIP Zero Clients) | https://s3.amazonaws.com | 
| User Login Pages | https://<directory id>.awsapps.com/ (where <directory id> is the customer's domain)  | 
| WS Broker |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| WorkSpaces API Endpoints |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Session Broker (PCM) | Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Web Access TURN Servers for PCoIP | Server: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Health check hostname | drp-cdg.amazonworkspaces.com | 
| Health check IP addresses |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| PCoIP gateway servers public IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| DCV gateway servers IP address range |  51.17.72.0/22 | 
| DCV gateway domain name | \$1.prod.eu-west-3.highlander.aws.a2z.com | 
| Management interface IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 

### South America (São Paulo)
<a name="sa-east-1"></a>


**Domains and IP Addresses to add to your allowlist**  

| Category | Details | 
| --- | --- | 
| CAPTCHA | https://opfcaptcha-prod.s3.amazonaws.com/ | 
| Client Auto-update |  https://d2td7dqidlhjx7.cloudfront.net/  | 
| Connectivity Check |  https://connectivity.amazonworkspaces.com/  | 
| Client Metrics (for 3.0\$1 WorkSpaces client applications) |  Domain: https://skylight-client-ds.sa-east-1.amazonaws.com  | 
| Dynamic Messaging Service (for 3.0\$1 WorkSpaces client applications) |  Domain:  https://ws-client-service.sa-east-1.amazonaws.com  | 
| Directory Settings |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Forrester Log Service  | https://fls-na.amazon.com/ | 
| Health Check (DRP) Servers | [Health check servers](#health_check) | 
| Registration Dependency (for Web Access and Teradici PCoIP Zero Clients) | https://s3.amazonaws.com | 
| User Login Pages | https://<directory id>.awsapps.com/ (where <directory id> is the customer's domain)  | 
| WS Broker |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| WorkSpaces API Endpoints |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Session Broker (PCM) | Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Web Access TURN Servers for PCoIP | Server: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Health check hostname | drp-gru.amazonworkspaces.com | 
| Health check IP addresses |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| PCoIP gateway servers public IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| DCV gateway servers IP address range | 15.228.64.0/22 | 
| DCV gateway domain name | \$1.prod.sa-east-1.highlander.aws.a2z.com | 
| Management interface IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 

### Africa (Cape Town)
<a name="sa-east-1"></a>


**Domains and IP Addresses to add to your allowlist**  

| Category | Details | 
| --- | --- | 
| CAPTCHA | https://opfcaptcha-prod.s3.amazonaws.com/ | 
| Client Auto-update |  https://d2td7dqidlhjx7.cloudfront.net/  | 
| Connectivity Check |  https://connectivity.amazonworkspaces.com/  | 
| Client Metrics (for 3.0\$1 WorkSpaces client applications) |  Domain: https://skylight-client-ds.af-south-1.amazonaws.com  | 
| Dynamic Messaging Service (for 3.0\$1 WorkSpaces client applications) |  Domain:  https://ws-client-service.af-south-1.amazonaws.com  | 
| Directory Settings |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Forrester Log Service  | https://fls-na.amazon.com/ | 
| Health Check (DRP) Servers | [Health check servers](#health_check) | 
| Registration Dependency (for Web Access and Teradici PCoIP Zero Clients) | https://s3.amazonaws.com | 
| User Login Pages | https://<directory id>.awsapps.com/ (where <directory id> is the customer's domain)  | 
| WS Broker |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| WorkSpaces API Endpoints |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Session Broker (PCM) | Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Health check hostname | drp-cpt.amazonworkspaces.com | 
| Health check IP addresses |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| PCoIP gateway servers public IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| DCV gateway servers IP address range | 15.228.64.0/22 | 
| DCV gateway domain name | \$1.prod.af-south-1.highlander.aws.a2z.com | 
| Management interface IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 

### Israel (Tel Aviv)
<a name="il-central-1"></a>


**Domains and IP Addresses to add to your allowlist**  

| Category | Details | 
| --- | --- | 
| CAPTCHA | https://opfcaptcha-prod.s3.amazonaws.com/ | 
| Client Auto-update |  https://d2td7dqidlhjx7.cloudfront.net/  | 
| Connectivity Check |  https://connectivity.amazonworkspaces.com/  | 
| Client Metrics (for 3.0\$1 WorkSpaces client applications) |  Domain: https://skylight-client-ds.il-central-1.amazonaws.com  | 
| Dynamic Messaging Service (for 3.0\$1 WorkSpaces client applications) |  Domain:  https://ws-client-service.il-central-1.amazonaws.com  | 
| Directory Settings |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Forrester Log Service  | https://fls-na.amazon.com/ | 
| Health Check (DRP) Servers | [Health check servers](#health_check) | 
| Registration Dependency (for Web Access and Teradici PCoIP Zero Clients) | https://s3.amazonaws.com | 
| User Login Pages | https://<directory id>.awsapps.com/ (where <directory id> is the customer's domain)  | 
| WS Broker |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| WorkSpaces API Endpoints |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Session Broker (PCM) | Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Web Access TURN Servers for PCoIP | Server: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Health check hostname | drp-tlv.amazonworkspaces.com | 
| Health check IP addresses |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| PCoIP gateway servers public IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| DCV gateway servers IP address range | 51.17.72.0/22 | 
| DCV gateway domain name | \$1.prod.il-central-1.highlander.aws.a2z.com | 
| Management interface IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 

### AWS GovCloud (US-West) Region
<a name="govcloud-west-region"></a>


**Domains and IP Addresses to add to your allowlist**  

| Category | Details | 
| --- | --- | 
| CAPTCHA | https://opfcaptcha-prod.s3.amazonaws.com/ | 
| Client Auto-update |  https://s3.amazonaws.com/workspaces-client-updates/prod/pdt/windows/WorkSpacesAppCast.xml  | 
| Connectivity Check |  https://connectivity.amazonworkspaces.com/  | 
| Client Metrics (for 3.0\$1 WorkSpaces client applications) |  Domain: hhttps://skylight-client-ds.us-gov-west-1.amazonaws.com  | 
| Dynamic Messaging Service (for 3.0\$1 WorkSpaces client applications) |  Domain: https://ws-client-service.us-gov-west-1.amazonaws.com  | 
| Directory Settings |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Forrester Log Service  | https://fls-na.amazon.com/ | 
| Health Check (DRP) Servers | [Health check servers](#health_check) | 
| Pre-session Smart Card Authentication Endpoints | https://smartcard.signin.amazonaws-us-gov.com | 
| Registration Dependency (for Web Access and Teradici PCoIP Zero Clients) | https://s3.amazonaws.com | 
| User Login Pages | https://login.us-gov-home.awsapps.com/directory/<directory id>/ (where <directory id> is the customer's domain)  | 
| WS Broker |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| WorkSpaces API Endpoints |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Session Broker (PCM) | Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Health check hostname | drp-pdt.amazonworkspaces.com | 
| Health check IP addresses |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| PCoIP gateway servers public IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| DCV gateway servers IP address range | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| DCV gateway domain name | \$1.prod.us-gov-west-1.highlander.aws.a2z.com | 
| Management interface IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 

### AWS GovCloud (US-East) Region
<a name="govcloud-east-region"></a>


**Domains and IP Addresses to add to your allowlist**  

| Category | Details | 
| --- | --- | 
| CAPTCHA | https://opfcaptcha-prod.s3.amazonaws.com/ | 
| Client Auto-update |  https://s3.amazonaws.com/workspaces-client-updates/prod/osu/windows/WorkSpacesAppCast.xml  | 
| Connectivity Check |  https://connectivity.amazonworkspaces.com/  | 
| Client Metrics (for 3.0\$1 WorkSpaces client applications) |  Domain: hhttps://skylight-client-ds.us-gov-east-1.amazonaws.com  | 
| Dynamic Messaging Service (for 3.0\$1 WorkSpaces client applications) |  Domain: https://ws-client-service.us-gov-east-1.amazonaws.com  | 
| Directory Settings |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Forrester Log Service  | https://fls-na.amazon.com/ | 
| Health Check (DRP) Servers | [Health check servers](#health_check) | 
| Pre-session Smart Card Authentication Endpoints | https://smartcard.signin.amazonaws-us-gov.com | 
| Registration Dependency (for Web Access and Teradici PCoIP Zero Clients) | https://s3.amazonaws.com | 
| User Login Pages | https://login.us-gov-home.awsapps.com/directory/<directory id>/ (where <directory id> is the customer's domain)  | 
| WS Broker |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| WorkSpaces API Endpoints |  Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)  | 
| Session Broker (PCM) | Domain: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| Health check hostname | drp-osu.amazonworkspaces.com | 
| Health check IP addresses |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| PCoIP gateway servers public IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 
| DCV gateway servers IP address range | 18.254.148.0/22 | 
| DCV gateway domain name | \$1.prod.us-gov-east-1.highlander.aws.a2z.com | 
| Management interface IP address ranges |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) | 

# Client network requirements for WorkSpaces Personal
<a name="workspaces-network-requirements"></a>

Your WorkSpaces users can connect to their WorkSpaces by using the client application for a supported device. Alternatively, they can use a web browser to connect to WorkSpaces that support this form of access. For a list of WorkSpaces that support web browser access, see "Which Amazon WorkSpaces bundles support web access?" in [ Client Access, Web Access, and User Experience](https://aws.amazon.com/workspaces/faqs/#Client_Access.2C_Web_Access.2C_and_User_Experience).

**Note**  
A web browser cannot be used to connect to Amazon Linux WorkSpaces.

**Important**  
Beginning October 1, 2020, customers will no longer be able to use the Amazon WorkSpaces Web Access client to connect to Windows 7 custom WorkSpaces or to Windows 7 Bring Your Own License (BYOL) WorkSpaces.

To provide your users with a good experience with their WorkSpaces, verify that their client devices meet the following network requirements:
+ The client device must have a broadband internet connection. We recommend planning for a minimum of 1 Mbps per simultaneous user watching a 480p video window. Depending on your user-quality requirements for video resolution, more bandwidth might be required.
+ The network that the client device is connected to, and any firewall on the client device, must have certain ports open to the IP address ranges for various AWS services. For more information, see [IP address and port requirements for WorkSpaces Personal](workspaces-port-requirements.md).
+ For the best performance for PCoIP, the round trip time (RTT) from the client's network to the Region that the WorkSpaces are in should be less than 100ms. If the RTT is between 100ms and 200ms, the user can access the WorkSpace, but performance is affected. If the RTT is between 200ms and 375ms, the performance is degraded. If the RTT exceeds 375ms, the WorkSpaces client connection is terminated.

  For the best performance for DCV, the RTT from the client's network to the Region that the WorkSpaces are in should be less than 250ms. If the RTT is between 250ms and 400ms, the user can access the WorkSpace, but the performance is degraded.

  To check the RTT to the various AWS Regions from your location, use the [Amazon WorkSpaces Connection Health Check](https://clients.amazonworkspaces.com/Health.html).
+ To use webcams with DCV, we recommend a minimum upload bandwidth of 1.7 megabits per second.
+ If users will access their WorkSpaces through a virtual private network (VPN), the connection must support a maximum transmission unit (MTU) of at least 1200 bytes.
**Note**  
You cannot access WorkSpaces through a VPN connected to your virtual private cloud (VPC). To access WorkSpaces using a VPN, internet connectivity (through the VPN's public IP addresses) is required, as described in [IP address and port requirements for WorkSpaces Personal](workspaces-port-requirements.md).
+ The clients require HTTPS access to WorkSpaces resources hosted by the service and Amazon Simple Storage Service (Amazon S3). The clients do not support proxy redirection at the application level. HTTPS access is required so that users can successfully complete registration and access their WorkSpaces.
+ To allow access from PCoIP zero client devices, you must be using a PCoIP protocol bundle for WorkSpaces. You must also enable Network Time Protocol (NTP) in Teradici. For more information, see [Set up PCoIP zero clients for WorkSpaces Personal](set-up-pcoip-zero-client.md).

You can verify that a client device meets the networking requirements as follows.

## To verify networking requirements for 3.0\$1 clients
<a name="verify-requirements-new-clients"></a>

1. Open your WorkSpaces client. If this is the first time you have opened the client, you are prompted to enter the registration code that you received in the invitation email.

1. Depending on which client you're using, do one of the following.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-network-requirements.html)

   The client application tests the network connection, ports, and round-trip time, and reports the results of these tests.

1. Close the **Network** dialog box to return to the sign-in page.

## To verify networking requirements for 1.0\$1 and 2.0\$1 clients
<a name="verify-requirements-legacy-clients"></a>

1. Open your WorkSpaces client. If this is the first time you have opened the client, you are prompted to enter the registration code that you received in the invitation email.

1. Choose **Network** in the lower-right corner of the client application. The client application tests the network connection, ports, and round-trip time, and reports the results of these tests.

1. Choose **Dismiss** to return to the sign-in page.

# Restrict access to trusted devices for WorkSpaces Personal
<a name="trusted-devices"></a>

By default, users can access their WorkSpaces from any supported device that is connected to the internet. If your company limits corporate data access to trusted devices (also known as managed devices), you can restrict WorkSpaces access to trusted devices with valid certificates.

**Note**  
This feature is currently available only when your WorkSpaces Personal directories are managed through Directory Service including Simple AD, AD Connector, and AWS Managed Microsoft AD directory.

When you enable this feature, WorkSpaces uses certificate-based authentication to determine whether a device is trusted. If the WorkSpaces client application can't verify that a device is trusted, it blocks attempts to log in or reconnect from the device.

For each directory, you can import up to two root certificates. If you import two root certificates, WorkSpaces presents them both to the client and the client finds the first valid matching certificate that chains up to either of the root certificates.

**Supported clients**
+ Android, running on Android or Android-compatible Chrome OS systems
+ macOS
+ Windows

**Important**  
This feature is not supported by the following clients:  
WorkSpaces client applications for Linux or iPad
Third-party clients, including but not limited to, Teradici PCoIP, RDP clients, and remote desktop applications.

**Note**  
When you enable access for specific clients, make sure that you block access for other device types that you don't need. For more information about how to do this, see Step 3.7 below.

## Step 1: Create the certificates
<a name="create-certificate"></a>

This feature requires two types of certificates: root certificates generated by an internal Certificate Authority (CA) and client certificates that chain up to a root certificate.

**Requirements**
+ Root certificates must be Base64-encoded certificate files in CRT, CERT, or PEM format.
+ Root certificates must satisfy the following regular expression pattern, which means that every encoded line, beside the last one, has to be exactly 64 characters long: `-{5}BEGIN CERTIFICATE-{5}\u000D?\u000A([A-Za-z0-9/+]{64} \u000D?\u000A)*[A-Za-z0-9/+]{1,64}={0,2}\u000D?\u000A-{5}END CERTIFICATE-{5}(\u000D?\u000A)`.
+ Device certificates must include a Common Name.
+ Device certificates must include the following extensions: `Key Usage: Digital Signature`, and `Enhanced Key Usage: Client Authentication`.
+ All the certificates in the chain from the device certificate to the trusted root Certificate Authority must be installed on the client device.
+ The maximum supported length of certificate chain is 4.
+ WorkSpaces does not currently support device revocation mechanisms, such as certificate revocation lists (CRL) or Online Certificate Status Protocol (OCSP), for client certificates.
+ Use a strong encryption algorithm. We recommend SHA256 with RSA, SHA256 with ECDSA, SHA384 with ECDSA, or SHA512 with ECDSA.
+ For macOS, if the device certificate is in the system keychain, we recommend that you authorize the WorkSpaces client application to access those certificates. Otherwise, users must enter keychain credentials when they log in or reconnect.

## Step 2: Deploy client certificates to the trusted devices
<a name="deploy-certificate"></a>

On the trusted devices for your users, you must install a certificate bundle that includes all the certificates in the chain from the device certificate to the trusted root Certificate Authority. You can use your preferred solution to install certificates to your fleet of client devices; for example, System Center Configuration Manager (SCCM) or mobile device management (MDM). Note that SCCM and MDM can optionally perform a security posture assessment to determine whether the devices meet your corporate policies to access WorkSpaces.

The WorkSpaces client applications search for certificates as follows:
+ Android - Go to **Settings**, choose **Security & location**, **Credentials**, then choose **Install from SD card**.
+ Android-compatible Chrome OS systems - Open Android settings and choose **Security & location**, **Credentials**, then choose **Install from SD card**.
+ macOS - Searches the keychain for client certificates.
+ Windows - Searches the user and root certificate stores for client certificates.

## Step 3: Configure the restriction
<a name="configure-restriction"></a>

After you have deployed the client certificates on the trusted devices, you can enable restricted access at the directory level. This requires the WorkSpaces client application to validate the certificate on a device before allowing a user to log in to a WorkSpace.

**To configure the restriction**

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose **Directories**.

1. Select the directory and then choose **Actions**, **Update Details**.

1. Expand **Access Control Options**.

1. Under **For each device type, specify which devices can access WorkSpaces**, choose **Trusted Devices**.

1. Import up to two root certificates. For each root certificate, do the following:

   1. Choose **Import**.

   1. Copy the body of the certificate to the form.

   1. Choose **Import**.

1. Specify whether other types of devices have access to WorkSpaces.

   1. Scroll down to the **Other Platforms** section. By default, WorkSpaces Linux clients are disabled, and users can access their WorkSpaces from their iOS devices, Android devices, Web Access, Chromebooks, and PCoIP zero client devices.

   1. Select the device types to enable and clear the device types to disable.

   1. To block access from all selected device types, choose **Block**.

1. Choose **Update and Exit**.

# Integrate SAML 2.0 with WorkSpaces Personal
<a name="amazon-workspaces-saml"></a>

**Note**  
SAML 2.0 is available only when your WorkSpaces Personal directories are managed through Directory Service including Simple AD, AD Connector, and AWS Managed Microsoft AD directory. The feature doesn't apply to directories that are managed by Amazon WorkSpaces, which normally use IAM Identity Center for user authentication instead of SAML 2.0 federation.

Integrating SAML 2.0 with your WorkSpaces for desktop session authentication allows your users to use their existing SAML 2.0 identity provider (IdP) credentials and authentication methods through their default web browser. By using your IdP to authenticate users for WorkSpaces, you can protect WorkSpaces by employing IdP features like multi-factor authentication and contextual access policies.

## Authentication workflow
<a name="authentication-workflow"></a>

The following sections describe the authentication workflow initiated by WorkSpaces client application, WorkSpaces Web Access, and a SAML 2.0 identity provider (IdP):
+ When the flow is initiated by the IdP. For example, when users choose an application in the IdP user portal in a web browser.
+ When the flow is initiated by the WorkSpaces client. For example, when users open the client application and sign in.
+ When the flow is initiated by WorkSpaces Web Access. For example, when users open Web Access in a browser and sign in.

In these examples, users enter `user@example.com`to sign in to the IdP. The IdP has a SAML 2.0 service provider application configured for a WorkSpaces directory and users are authorized for the WorkSpaces SAML 2.0 application. Users create a WorkSpace for their usernames, `user`, in a directory that's enabled for SAML 2.0 authentication. Additionally, users install the [WorkSpaces client application](https://clients.amazonworkspaces.com/) on their device or the user uses Web Access in a web browser.

**Identity provider (IdP)-initiated flow with client application**

The IdP-initiated flow allows users to automatically register the WorkSpaces client application on their devices without having to enter a WorkSpaces registration code. Users don't sign in to their WorkSpaces using the IdP-initiated flow. WorkSpaces authentication must originate from the client application.

1. Using their web browser, users sign in to the IdP.

1. After signing in to the IdP, users choose the WorkSpaces application from the IdP user portal.

1. Users are redirected to this page in the browser, and the WorkSpaces client application is opened automatically.   
![\[Opening WorkSpaces application redirection page\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/images/saml-redir.png)

1. The WorkSpaces client application is now registered and users can continue to sign by clicking **Continue to sign in to WorkSpaces**.

**Identity provider (IdP)-initiated flow with Web Access**

The IdP-initiated Web Access flow allows users to automatically register their WorkSpaces through a web browser without having to enter a WorkSpaces registration code. Users don't sign in to their WorkSpaces using the IdP-initiated flow. WorkSpaces authentication must originate from Web Access.

1. Using their web browser, users sign in to the IdP.

1. After signing in to the IdP, users click the WorkSpaces application from the IdP user portal.

1. Users are redirected to this page in the browser. To open WorkSpaces, choose **Amazon WorkSpaces in the browser**.  
![\[Opening WorkSpaces application redirection page\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/images/saml-redir.png)

1. The WorkSpaces client application is now registered and users can continue to sign in through WorkSpaces Web Access.

**WorkSpaces client-initiated flow**

The client-initiated flow allows users to sign in to their WorkSpaces after signing in to an IdP.

1. Users launch the WorkSpaces client application (if it isn't already running) and clicks **Continue to sign in to WorkSpaces**.

1. Users are redirected to their default web browser to sign in to the IdP. If the users are already signed in to the IdP in their browser, they don't need to sign in again and will skip this step.

1. Once signed in to the IdP, users are redirected to a pop up. Follow the prompts to allow your web browser to open the client application.  
![\[Open client application prompt.\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/images/saml-open-client-app.png)

1. Users are redirected to the WorkSpaces client application to complete sign in to their WorkSpace. WorkSpaces usernames are populated automatically from the IdP SAML 2.0 assertion. When you use [ certificate-based authentication (CBA)](certificate-based-authentication.md) , users are automatically signed in.

1. Users are signed in to their WorkSpace.

**WorkSpaces Web Access-initiated flow**

The Web Access-initiated flow allows users to sign in to their WorkSpaces after signing in to an IdP.

1. Users launch the WorkSpaces Web Access and chooses **Sign in**.

1. In the same browser tab, users are redirected to IdP portal. If the users are already signed in to the IdP in their browser, they don't need to sign in again and can skip this step.

1. Once signed in to the IdP, users redirected to this page in the browser, and clicks **Log in to WorkSpaces**.

1. Users redirected to the WorkSpaces client application to complete sign in to their WorkSpace. WorkSpaces usernames are populated automatically from the IdP SAML 2.0 assertion. When you use [ certificate-based authentication (CBA)](certificate-based-authentication.md) , users are automatically signed in.

1. Users are signed in to their WorkSpace.

# Set up SAML 2.0 for WorkSpaces Personal
<a name="setting-up-saml"></a>

Enable WorkSpaces client application registration and signing in to WorkSpaces for your users by using their SAML 2.0 identity provider (IdP) credentials and authentication methods by setting up identity federation using SAML 2.0. To set up identity federation using SAML 2.0, use an IAM role and a relay state URL to configure your IdP and enable AWS. This grants your federated users access to a WorkSpaces directory. The relay state is the WorkSpaces directory endpoint to which users are forwarded after successfully signing in to AWS. 

**Topics**
+ [Requirements](#setting-up-saml-requirements)
+ [Prerequisites](#setting-up-saml-prerequisites)
+ [Step 1: Create a SAML identity provider in AWS IAM](#create-saml-identity-provider)
+ [Step 2: Create a SAML 2.0 federation IAM role](#create-saml-iam-role)
+ [Step 3: Embed an inline policy for the IAM role](#embed-inline-policy)
+ [Step 4: Configure your SAML 2.0 identity provider](#configure-saml-id-provider)
+ [Step 5: Create assertions for the SAML authentication response](#create-assertions-saml-auth)
+ [Step 6: Configure the relay state of your federation](#configure-relay-state)
+ [Step 7: Enable integration with SAML 2.0 on your WorkSpaces directory](#enable-integration-saml)

## Requirements
<a name="setting-up-saml-requirements"></a>
+ SAML 2.0 authentication is available in the following Regions:
  + US East (N. Virginia) Region
  + US West (Oregon) Region
  + Africa (Cape Town) Region
  + Asia Pacific (Mumbai) Region
  + Asia Pacific (Seoul) Region
  + Asia Pacific (Singapore) Region
  + Asia Pacific (Sydney) Region
  + Asia Pacific (Tokyo) Region
  + Canada (Central) Region
  + Europe (Frankfurt) Region
  + Europe (Ireland) Region
  + Europe (London) Region
  + South America (São Paulo) Region
  + Israel (Tel Aviv) Region
  + AWS GovCloud (US-West)
  + AWS GovCloud (US-East)
+ To use SAML 2.0 authentication with WorkSpaces,the IdP must support unsolicited IdP-initiated SSO with a deep link target resource or relay state endpoint URL. Examples of IdPs include ADFS, Azure AD, Duo Single Sign-On, Okta, PingFederate, and PingOne. Consult your IdP documentation for more information.
+ SAML 2.0 authentication will function with WorkSpaces launched using Simple AD, but this isn't recommended as Simple AD doesn't integrate with SAML 2.0 IdPs.
+ SAML 2.0 authentication is supported on the following WorkSpaces clients. Other client versions are unsupported for SAML 2.0 authentication. Open Amazon WorkSpaces [Client Downloads](https://clients.amazonworkspaces.com/) to find the latest versions:
  + Windows client application version 5.1.0.3029 or later
  + macOS client version 5.x or later
  + Linux client for Ubuntu 22.04 version 2024.1 or later, Ubuntu 20.04 version 24.1 or later
  + Web Access

  Other client versions won't be able to connect to WorkSpaces enabled for SAML 2.0 authentication unless fallback is enabled. For more information, see [ Enable SAML 2.0 authentication on the WorkSpaces directory.](https://d1.awsstatic.com/workspaces-saml-guide.pdf)

For step-by-step instructions to integrate SAML 2.0 with WorkSpaces using ADFS, Azure AD, Duo Single Sign-On, Okta, OneLogin, PingFederate and PingOne for Enterprise, review the [Amazon WorkSpaces SAML Authentication Implementation Guide](https://d1.awsstatic.com/workspaces-saml-guide.pdf).

## Prerequisites
<a name="setting-up-saml-prerequisites"></a>

Complete the following prerequisites before configuring your SAML 2.0 identity provider (IdP) connection to a WorkSpaces directory.

1. Configure your IdP to integrate user identities from the Microsoft Active Directory that is used with the WorkSpaces directory. For a user with a WorkSpace, the **sAMAccountName** and **email** attributes for the Active Directory user and the SAML claim values must match for the user to sign in to WorkSpaces using the IdP. For more information about integrating Active Directory with your IdP, consult your IdP documentation.

1. Configure your IdP to establish a trust relationship with AWS.
   + See [Integrating third-party SAML solution providers with AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml_3rd-party.html) for more information on configuring AWS federation. Relevant examples include IdP integration with AWS IAM to access the AWS management console.
   + Use your IdP to generate and download a federation metadata document that describes your organization as an IdP. This signed XML document is used to establish the relying party trust. Save this file to a location that you can access from the IAM console later.

1. Create or register a directory for WorkSpaces by using the WorkSpaces management console. For more information, see [Manage directories for WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/manage-workspaces-directory.html). SAML 2.0 authentication for WorkSpaces is supported for the following directory types:
   + AD Connector
   + AWS Managed Microsoft AD

1. Create a WorkSpace for a user who can sign in to the IdP using a supported directory type. You can create a WorkSpace using the WorkSpaces management console, AWS CLI, or WorkSpaces API. For more information, see [Launch a virtual desktop using WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/launch-workspaces-tutorials.html). 

## Step 1: Create a SAML identity provider in AWS IAM
<a name="create-saml-identity-provider"></a>

First, create a SAML IdP in AWS IAM. This IdP defines your organization's IdP-to-AWS trust relationship using the metadata document generated by the IdP software in your organization. For more information, see [ Creating and managing a SAML identity provider (Amazon Web Services Management Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml.html#idp-manage-identityprovider-console). For information about working with SAML IdPs in AWS GovCloud (US-West)and AWS GovCloud (US-East), see [AWS Identity and Access Management](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-iam.html). 

## Step 2: Create a SAML 2.0 federation IAM role
<a name="create-saml-iam-role"></a>

Next, create a SAML 2.0 federation IAM role. This step establishes a trust relationship between IAM and your organization's IdP, which identifies your IdP as a trusted entity for federation.

To create an IAM role for SAML IdP

1. Open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Roles** > **Create role**.

1.  For **Role type**, choose **SAML 2.0 federation**. 

1.  For **SAML Provider** select the SAML IdP that you created. 
**Important**  
Don't choose either of the two SAML 2.0 access methods, **Allow programmatic access only** or **Allow programmatic and Amazon Web Services Management Console access**.

1. For **Attribute**, choose **SAML:sub\$1type**.

1. For **Value** enter `persistent`. This value restricts role access to SAML user streaming requests that include a SAML subject type assertion with a value of persistent. If the SAML:sub\$1type is persistent, your IdP sends the same unique value for the NameID element in all SAML requests from a particular user. For more information about the SAML:sub\$1type assertion, see the **Uniquely identifying users in SAML-based federation** section in [ Using SAML-based federation for API access to AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html#CreatingSAML-configuring).

1. Review your SAML 2.0 trust information, confirming the correct trusted entity and condition, and then choose **Next: Permissions**. 

1. On the **Attach permissions policies** page, choose **Next: Tags**.

1. (Optional) Enter a key and value for each tag that you want to add. For more information, see [Tagging IAM users and roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html).

1. When you're done, choose **Next: Review**. You'll create and embed an inline policy for this role later.

1. For **Role name**, enter a name that identifies the purpose of this role. Because multiple entities might reference the role, you can't edit the role's name once it is created.

1. (Optional) For **Role description**, enter a description for the new role.

1. Review the role details and choose **Create role**.

1. Add the sts:TagSession permission to your new IAM role's trust policy. For more information, see [Passing session tags in AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html). In your new IAM role's details, choose the **Trust relationships** tab, and then choose **Edit trust relationship\$1**. When Edit Trust Relationship policy editor opens, add the **sts:TagSession\$1** permission, as follows:

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Principal": {
                   "Federated": "arn:aws:iam::111122223333:saml-provider/IDENTITY-PROVIDER"
               },
               "Action": [
                   "sts:AssumeRoleWithSAML",
                   "sts:TagSession"
               ],
               "Condition": {
                   "StringEquals": {
                       "SAML:aud": "https://signin.aws.amazon.com/saml"
                   }
               }
           }
       ]
   }
   ```

------

Replace `IDENTITY-PROVIDER` with the name of the SAML IdP you created in Step 1. Then choose **Update Trust Policy**.

## Step 3: Embed an inline policy for the IAM role
<a name="embed-inline-policy"></a>

Next, embed an inline IAM policy for the role that you created. When you embed an inline policy, the permissions in that policy can't be accidentally attached to the wrong principal entity. The inline policy provides federated users with access to the WorkSpaces directory.

**Important**  
IAM policies to manage access to AWS based on the source IP are not supported for the `workspaces:Stream` action. To manage IP access controls for WorkSpaces, use [IP access control groups](https://docs.aws.amazon.com/workspaces/latest/adminguide/amazon-workspaces-ip-access-control-groups.html). Additionally, when using SAML 2.0 authentication you can use IP access control policies if they are available from your SAML 2.0 IdP.

1. In the details for the IAM role that you created, choose the **Permissions** tab, and then add required permissions to the role's permissions policy. The **Create policy wizard** will start.

1. In **Create policy**, choose the **JSON** tab.

1. Copy and paste the following JSON policy into the JSON window. Then, modify the resource by entering your AWS Region Code, account ID, and directory ID. In the following policy, `"Action": "workspaces:Stream"` is the action that provides your WorkSpaces users with permissions to connect to their desktop sessions in the WorkSpaces directory.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": "workspaces:Stream",
               "Resource": "arn:aws:workspaces:us-east-1:123456789012:directory/DIRECTORY-ID",
               "Condition": {
                   "StringEquals": {
                       "workspaces:userId": "${saml:sub}"
                   }
               }
           }
       ]
   }
   ```

------

   Replace `REGION-CODE` with the AWS Region where your WorkSpaces directory exists. Replace `DIRECTORY-ID` with the WorkSpaces directory ID, which can be found in the WorkSpaces management console. For resources in AWS GovCloud (US-West) or AWS GovCloud (US-East), use the following format for the ARN: `arn:aws-us-gov:workspaces:REGION-CODE:ACCOUNT-ID-WITHOUT-HYPHENS:directory/DIRECTORY-ID`.

1. When you're done, choose **Review policy**. The [Policy Validator](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_policy-validator.html) will report any syntax errors.

## Step 4: Configure your SAML 2.0 identity provider
<a name="configure-saml-id-provider"></a>

Next, depending on your SAML 2.0 IdP, you may need to manually update your IdP to trust AWS as a service provider by uploading the `saml-metadata.xml` file at [https://signin.aws.amazon.com/static/saml-metadata.xml](https://signin.aws.amazon.com/static/saml-metadata.xml) to your IdP. This step updates your IdP’s metadata. For some IdPs, the update may already be configured. If this is the case, proceed to the next step.

If this update isn't already configured in your IdP, review the documentation provided by your IdP for information about how to update the metadata. Some providers give you the option to type the URL, and the IdP obtains and installs the file for you. Others require you to download the file from the URL and then provide it as a local file.

**Important**  
At this time, you can also authorize users in your IdP to access the WorkSpaces application you have configured in your IdP. Users who are authorized to access the WorkSpaces application for your directory don't automatically have a WorkSpace created for them. Likewise, users that have a WorkSpace created for them are not automatically authorized to access the WorkSpaces application. To successfully connect to a WorkSpace using SAML 2.0 authentication, a user must be authorized by the IdP and must have a WorkSpace created.

**Note**  
If your end users will frequently switch between multiple different WorkSpaces user identities while using the same SAML 2.0 identity provider (IdP), ensure that your IdP is configured to force authentication (ForceAuthn) at each login attempt. This prevents your IdP from reusing an existing SSO session, which may otherwise cause authentication failures when your users are switching to another WorkSpace. Refer to your IdP's documentation for guidance on enabling the ForceAuthn (or equivalent) setting.

## Step 5: Create assertions for the SAML authentication response
<a name="create-assertions-saml-auth"></a>

Next, configure the information that your IdP sends to AWS as SAML attributes in its authentication response. Depending on your IdP, this is already configured, skip this step and continue to [ Step 6: Configure the relay state of your federation](https://docs.aws.amazon.com/workspaces/latest/adminguide/setting-up-saml.html#configure-relay-state).

If this information isn't already configured in your IdP, provide the following:
+ **SAML Subject NameID** – The unique identifier for the user who is signing in. The value must match the WorkSpaces user name, and is typically the **sAMAccountName** attribute for the Active Directory user.
+ **SAML Subject Type** (with a value set to `persistent`) – Setting the value to `persistent` ensures that your IdP sends the same unique value for the `NameID` element in all SAML requests from a particular user. Make sure that your IAM policy includes a condition to only allow SAML requests with a SAML sub\$1type set to `persistent`, as described in [ Step 2: Create a SAML 2.0 federation IAM role](https://docs.aws.amazon.com/appstream2/latest/developerguide/external-identity-providers-setting-up-saml.html#external-identity-providers-grantperms).
+ **`Attribute` element with the `Name` attribute set to `https://aws.amazon.com/SAML/Attributes/Role`** – This element contains one or more `AttributeValue` elements that list the IAM role and SAML IdP to which the user is mapped by your IdP. The role and IdP are specified as a comma-delimited pair of ARNs. An example of the expected value is `arn:aws:iam::ACCOUNTNUMBER:role/ROLENAME,arn:aws:iam::ACCOUNTNUMBER:saml-provider/PROVIDERNAME`.
+ **`Attribute` element with the `Name` attribute set to `https://aws.amazon.com/SAML/Attributes/RoleSessionName`** – This element contains one `AttributeValue` element that provides an identifier for the AWS temporary credentials that are issued for SSO. The value in the `AttributeValue` element must be between 2 and 64 characters long, can contain only alphanumeric characters, underscores, and the following characters: **\$1 . : / = \$1 - @**. It can't contain spaces. The value is typically an email address or a user principal name (UPN). It shouldn't be a value that includes a space, such as a user's display name.
+ **`Attribute` element with the `Name` attribute set to `https://aws.amazon.com/SAML/Attributes/PrincipalTag:Email`** – This element contains one `AttributeValue` element that provides the email address of the user. The value must match the WorkSpaces user email address as defined in the WorkSpaces directory. Tag values may include combinations of letters, numbers, spaces, and **\$1 . : / = \$1 - @** characters. For more information, see [Rules for tagging in IAM and AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html#id_tags_rules) in the *IAM User Guide*.
+ **`Attribute` element with the `Name` attribute set to `https://aws.amazon.com/SAML/Attributes/PrincipalTag:UserPrincipalName` (optional)** – This element contains one `AttributeValue` element that provides the Active Directory `userPrincipalName` for the user who is signing in. The value must be provided in the format of `username@domain.com`. This parameter is used with certificate-based authentication as the Subject Alternative Name in the end user certificate. For more information, see Certificate-Based Authentication.
+ **`Attribute` element with the `Name` attribute set to `https://aws.amazon.com/SAML/Attributes/PrincipalTag:ObjectSid` (optional)** – This element contains one `AttributeValue` element that provides the Active Directory security identifier (SID) for the user who is signing in. This parameter is used with certificate-based authentication to enable strong mapping to the Active Directory user. For more information, see Certificate-Based Authentication.
+ **`Attribute` element with the `Name` attribute set to `https://aws.amazon.com/SAML/Attributes/PrincipalTag:ClientUserName` (optional)** – This element contains one `AttributeValue` element that provides an alternative user name format. Use this attribute if you have use cases that require user name formats such as `corp\username`, `corp.example.com\username`, or `username@corp.example.com` to login using the WorkSpaces client. Tag keys and values can include any combination of letters, numbers, spaces, and **\$1 : / . \$1 = @ -** characters. For more information, see [Rules for tagging in IAM and AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html#id_tags_rules) in the *IAM User Guide*. To claim `corp\username` or `corp.example.com\username` formats, replace **\$1** with **/**in the SAML assertion.
+ **`Attribute`element with the `Name` attribute set to https://aws.amazon.com/SAML/Attributes/PrincipalTag:Domain (optional)** – This element contains one `AttributeValue` element that provides the Active Directory DNS fully qualified domain name (FQDN) for users signing in. This parameter is used with certificate-based authentication when the Active Directory `userPrincipalName` for the user contains an alternative suffix. The value must be provided in the `domain.com`, including any subdomains.
+ **`Attribute` element with the `Name` attribute set to https://aws.amazon.com/SAML/Attributes/SessionDuration (optional)** – This element contains one `AttributeValue` element that specifies the maximum amount of time that a federated streaming session for a user can remain active before reauthentication is required. The default value is 3600 seconds (60 minutes). For more information, see the [ SAML `SessionDurationAttribute`](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml_assertions.html#saml_role-session-duration). 
**Note**  
Although `SessionDuration` is an optional attribute, we recommend that you include it in the SAML response. If you don't specify this attribute, the session duration is set to a default value of 3600 seconds (60 minutes). WorkSpaces desktop sessions are disconnected after their session duration expires.

For more information about how to configure these elements, see [ Configuring SAML assertions for the authentication response](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml_assertions.html) in the *IAM User Guide*. For information about specific configuration requirements for your IdP, see your IdP's documentation.

## Step 6: Configure the relay state of your federation
<a name="configure-relay-state"></a>

Next, use your IdP to configure the relay state of your federation to point to the WorkSpaces directory relay state URL. After successful authentication by AWS, the user is directed to the WorkSpaces directory endpoint, defined as the relay state in the SAML authentication response.

The following is the relay state URL format:

```
https://relay-state-region-endpoint/sso-idp?registrationCode=registration-code
```

Construct your relay state URL from your WorkSpaces directory registration code and the relay state endpoint associated with the Region in which your directory is located. The registration code can be found in the WorkSpaces management console.

Optionally, if you are using cross-region redirection for WorkSpaces, you can substitute the registration code with the fully qualified domain name (FQDN) associated with directories in your primary and failover Regions. For more information, see [Cross-region redirection for Amazon WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/cross-region-redirection.html). When using cross-region redirection and SAML 2.0 authentication, both primary and failover directories need to be enabled for SAML 2.0 authentication and independently configured with the IdP, using the relay state endpoint associated with each Region. This will allow the FQDN to be configured correctly when users register their WorkSpaces client applications before signing in, and will allow users to authenticate during a failover event.

The following table lists the relay state endpoints for the Regions where WorkSpaces SAML 2.0 authentication is available.


**Regions where WorkSpaces SAML 2.0 authentication is available**  

| Region | Relay state endpoint | 
| --- | --- | 
| US East (N. Virginia) Region | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/setting-up-saml.html) | 
| US West (Oregon) Region | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/setting-up-saml.html) | 
| Africa (Cape Town) Region | workspaces.euc-sso.af-south-1.aws.amazon.com | 
| Asia Pacific (Mumbai) Region | workspaces.euc-sso.ap-south-1.aws.amazon.com | 
| Asia Pacific (Seoul) Region | workspaces.euc-sso.ap-northeast-2.aws.amazon.com | 
| Asia Pacific (Singapore) Region | workspaces.euc-sso.ap-southeast-1.aws.amazon.com | 
| Asia Pacific (Sydney) Region | workspaces.euc-sso.ap-southeast-2.aws.amazon.com | 
| Asia Pacific (Tokyo) Region | workspaces.euc-sso.ap-northeast-1.aws.amazon.com | 
| Canada (Central) Region | workspaces.euc-sso.ca-central-1.aws.amazon.com | 
| Europe (Frankfurt) Region | workspaces.euc-sso.eu-central-1.aws.amazon.com | 
| Europe (Ireland) Region | workspaces.euc-sso.eu-west-1.aws.amazon.com | 
| Europe (London) Region | workspaces.euc-sso.eu-west-2.aws.amazon.com | 
| South America (São Paulo) Region | workspaces.euc-sso.sa-east-1.aws.amazon.com | 
| Israel (Tel Aviv) Region | workspaces.euc-sso.il-central-1.aws.amazon.com | 
| AWS GovCloud (US-West) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/setting-up-saml.html)  For more information about, see [ Amazon WorkSpaces](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-workspaces.html) in the *AWS GovCloud (US) User Guide*.   | 
| AWS GovCloud (US-East) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/setting-up-saml.html)  For more information about, see [ Amazon WorkSpaces](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-workspaces.html) in the *AWS GovCloud (US) User Guide*.   | 

With an identity provider (IdP)-initiated flow, you can opt to specify the client you want to use for SAML 2.0 federation. To do so, specify either `native` or `web` at end of the relay state URL, after `&client=`. When the parameter is specified in a relay state URL, the corresponding sessions will automatically start in the specified client.

## Step 7: Enable integration with SAML 2.0 on your WorkSpaces directory
<a name="enable-integration-saml"></a>

You can use the WorkSpaces console to enable SAML 2.0 authentication on the WorkSpaces directory.

**To enable integration with SAML 2.0**

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose **Directories**.

1. Choose on the Directory ID for your WorkSpaces.

1. Under **Authentication**, choose **Edit**.

1. Choose **Edit SAML 2.0 Identity Provider**.

1. Check **Enable SAML 2.0 authentication**.

1. For the **User Access URL** and **IdP deep link parameter name**, enter values that are applicable to your IdP and the application you have configured in Step 1. The default value for the IdP deep link parameter name is “RelayState“ if you omit this parameter. The following table lists user access URL and parameter names that are unique to various identity providers for applications.   
**Domains and IP addresses to add to your allow list**    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/setting-up-saml.html)

   The user access URL is usually defined by the provider for unsolicited IdP-initiated SSO. A user can enter this URL in a web browser to federate directly to the SAML application. To test the user access URL and parameter values for your IdP, choose **Test**. Copy and paste the test URL to a private window in your current browser or another browser to test the SAML 2.0 logon without disrupting your current AWS management console session. When IdP-initiated flow opens, you can register your WorkSpaces client. For more information, see [ Identity provider (IdP)-initiated flow](https://docs.aws.amazon.com/workspaces/latest/adminguide/amazon-workspaces-saml.html).

1. Manage fallback settings by checking or unchecking **Allow clients that do not support SAML 2.0 to login**. Enable this setting to continue providing your users access to WorkSpaces using client types or versions that do not support SAML 2.0 or if users need time to upgrade to the latest client version.
**Note**  
This setting allows users to bypass SAML 2.0 and log in using directory authentication using older client versions.

1. To use SAML with the web client, enable Web Access. For more information, see [Enable and configure Amazon WorkSpaces Web Access](https://docs.aws.amazon.com/workspaces/latest/adminguide/web-access.html).
**Note**  
PCoIP with SAML is not supported on Web Access.

1. Choose **Save**. Your WorkSpaces directory is now enabled with SAML 2.0 integration. You can use the IdP-initiated and client application-initiated flows to register WorkSpaces client applications and sign in to WorkSpaces.

# Certificate-based authentication and WorkSpaces Personal
<a name="certificate-based-authentication"></a>

You can use certificate-based authentication with WorkSpaces to remove the user prompt for the Active Directory domain password. 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.
+ Enable 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 CA resources in your AWS account. AWS Private CA enables creation of private certificate authority (CA) hierarchies, including root and subordinate CAs. With AWS Private CA, you can create your own CA hierarchy and issue certificates with it for authenticating internal users. For more information, see the [AWS Private Certificate Authority User Guide](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html).

When using AWS Private CA for certificate-based authentication, WorkSpaces will request certificates for your users automatically during session authentication. Users are authenticated to Active Directory using a virtual smart card provisioned with the certificates.

Certificate-based authentication is supported with Windows WorkSpaces on DCV bundles using the latest WorkSpaces Web Access, Windows, and macOS client applications. Open Amazon WorkSpaces [Client downloads](https://clients.amazonworkspaces.com/) to find the latest versions: 
+ Windows client version 5.5.0 or later
+ macOS client version 5.6.0 or later

For more information on configuring certificate-based authentication with Amazon WorkSpaces, see [ How to configure certificate-based authentication for Amazon WorkSpaces](https://aws.amazon.com/blogs/desktop-and-application-streaming/how-to-configure-certificate-based-authentication-for-amazon-workspaces/) and [ Design considerations in highly regulated environments for Certificate Based Authentication with WorkSpaces Applications and WorkSpaces ](https://aws.amazon.com/blogs/desktop-and-application-streaming/design-considerations-in-highly-regulated-environments-for-certificate-based-authentication-with-appstream-2-0-workspaces/).

## Prerequisites
<a name="cert-based-auth-prerequesites"></a>

Complete the following steps before enabling certificate-based authentication.

1. Configure your WorkSpaces directory with SAML 2.0 integration to use certificate-based authentication. For more information, see [WorkSpaces Integration with SAML 2.0](https://docs.aws.amazon.com/workspaces/latest/adminguide/amazon-workspaces-saml.html).

1. Configure the `userPrincipalName` attribute in your SAML assertion. For more information, see [Create Assertions for the SAML Authentication Response](https://docs.aws.amazon.com/workspaces/latest/adminguide/setting-up-saml.html#create-assertions-saml-auth).

1. Configure the `ObjectSid` attribute in your SAML assertion. This is required to perform strong mapping to the Active Directory user. Certificate-based authentication will fail if the attribute does not match the Active Directory security identifier (SID) for user specified in the SAML\$1Subject `NameID`. For more information, see [Create Assertions for the SAML Authentication Response](https://docs.aws.amazon.com/workspaces/latest/adminguide/setting-up-saml.html#create-assertions-saml-auth).
**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](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html) permission to your IAM role trust policy used with your SAML 2.0 configuration if it is not already present. This permission is required to use certificate-based authentication. For more information, see [Create a SAML 2.0 Federation IAM Role](https://docs.aws.amazon.com/workspaces/latest/adminguide/setting-up-saml.html#create-saml-iam-role).

1. Create a private certificate authority (CA) using AWS Private CA if you do not 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) and follow the guidance to configure a CA for certificate-based authentication. The following AWS Private CA settings are the most common for certificate-based authentication use cases:

   1. CA type options:

      1. Short-lived certificate CA usage mode (recommended if you are only using the CA to issue end user certificates for certificate-based authentication)

      1. Single level hierarchy with a Root CA (alternatively, choose a subordinate CA if you want to integrate with an existing CA hierarchy)

   1. Key algorithm options: RSA 2048

   1. Subject distinguished name options: Use any combination of options to identify the CA in your Active Directory Trusted Root Certification Authorities store.

   1. Certificate revocation options: CRL distribution
**Note**  
Certificate-based authentication requires an online CRL distribution point accessible from desktops and the domain controller. This requires unauthenticated access to the Amazon S3 bucket configured for Private CA CRL entries, or a CloudFront distribution that will have access to the S3 bucket if it is blocking public access. For more information on these options, see [Planning a certificate revocation list (CRL)](https://docs.aws.amazon.com/privateca/latest/userguide/crl-planning.html#s3-bpa).

1. Tag your private CA with a key entitled `euc-private-ca` to designate the CA for use with EUC certificate-based authentication. The key does not require a value. For more information, see [Managing tags for your private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCaTagging.html).

1. Certificate-based authentication utilizes virtual smart cards for logon. Following the [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) in Active Directory, perform the following steps:
   + 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, domain controllers are automatically enrolled with certificates to 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 are using AWS Managed Microsoft AD, you can configure Certificate Services on an EC2 instance to satisfy the requirement for domain controller certificates. See [AWS Launch Wizard](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. AWS Private CA can be configured as a subordinate to the Active Directory Certificate Services CA, or can be configured as its own root when using AWS Managed Microsoft AD.  
An additional configuration task with AWS Managed Microsoft AD and Active Directory Certificate Services is to create outbound rules from the controllers VPC security group to the EC2 instance running Certificate Services allowing TCP ports 135 and 49152-65535 to enable certificate autoenrollment. In addition, the EC2 instance running must allow inbound access on the 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).
   + On the AWS Private CA console or using the SDK or CLI, select your CA and under the CA certificate, export the CA private certificate. For more information, see [Exporting a private certificate](https://docs.aws.amazon.com/acm/latest/userguide/export-private.html).
   + Publish the CA to Active Directory. Logon to a domain controller or a domain-joined machine. Copy the CA private certificate to any `<path>\<file>` and run the following commands as a domain administrator. Alternatively, you can use Group Policy and the Microsoft PKI Health Tool (PKIView) tool 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 <path>\<file> RootCA
     certutil -dspublish -f  <path>\<file> NTAuthCA
     ```

     Ensure that the commands complete successfully, and then remove the private certificate file. Depending on Active Directory replication settings, it can take several minutes for the CA to be published to your domain controllers and desktop instances.
**Note**  
It is required that Active Directory distribute the CA to the Trusted Root Certification Authorities and Enterprise NTAuth stores automatically for WorkSpaces desktops when they are joined to the domain. 

## Enable certificate-based authentication
<a name="enable-cert-based-auth"></a>

Complete the following steps 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. In the navigation pane, choose **Directories**.

1. Choose the Directory ID for your WorkSpaces.

1. Under **Authentication**, click **Edit**.

1. Click **Edit Certificate-Based Authentication**.

1. Check **Enable Certificate-Based Authentication**.

1. Confirm that your private CA ARN is associated in the list. The private CA should be in the same AWS account and AWS Region, and must be tagged with a key entitled euc-private-ca to appear in the list.

1. Click **Save Changes**. Certificate-based authentication is now enabled.

1. Reboot your Windows WorkSpaces on DCV bundles for the changes to take effect. For more information, see [Reboot a WorkSpace](https://docs.aws.amazon.com/workspaces/latest/adminguide/reboot-workspaces.html).

1. After rebooting, when users authenticate via SAML 2.0 using a supported client, they will no longer receive a prompt for the domain password.

**Note**  
When certificate-based authentication is enabled to sign in to WorkSpaces, users are not prompted for multi-factor authentication (MFA) even if enabled on the Directory. When using certificate-based authentication, MFA can be enabled through your SAML 2.0 identity provider. For more information on AWS Directory Service MFA, see [Multi-factor authentication (AD Connector)](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_mfa.html) or [Enable multi-factor authentication for AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_mfa.html#supportedamazonapps). 

## Manage certificate-based authentication
<a name="manage-cert-based-auth"></a>

**CA Certificate**  
In a typical configuration, the private CA certificate has a validity period of 10 years. See [Managing the private CA lifecycle](https://docs.aws.amazon.com/privateca/latest/userguide/ca-lifecycle.html) for more information on replacing a CA with an expired certificate, or reissuing the CA with a new validity period.

**End User Certificates**  
End user certificates issued by AWS Private CA for WorkSpaces certificate-based authentication don't require renewal or revocation. These certificates are short-lived. WorkSpaces automatically issues a new certificate every 24 hours. 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 [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/) to record API calls to AWS Private CA by WorkSpaces. For more information, see [Using CloudTrail](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCtIntro.html). In [CloudTrail Event history](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html) you can view `GetCertificate` and `IssueCertificate` event names from `acm-pca.amazonaws.com` event source made by the WorkSpaces `EcmAssumeRoleSession` user name. These events will be recorded for every EUC certificate-based authentication request.

## Enable cross-account PCA sharing
<a name="enable-pca-sharing"></a>

 When you use Private CA cross-account sharing, you can grant other accounts permissions to use a centralized CA, which removes the needs for a Private CA in every account. The CA can generate and issue certificates by using [AWS Resource Access Manager](https://aws.amazon.com/ram/) to manage permissions. Private CA cross-account sharing can be used with WorkSpaces certificate-based Authentication (CBA) within the same AWS Region. 

**To use a shared Private CA resource with WorkSpaces CBA**

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).

1.  Share the Private CA with the resource AWS accounts where WorkSpaces resources utilize CBA by following 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 don't 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. To share with individual accounts, you need to accept the shared Private CA in your resource account by using the Resource Access Manager (RAM) console or APIs. When configuring the share, confirm that the RAM 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 service role when issuing CBA certificates. 

1. After the share is successful, you should be able to 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 directory properties. At this time, the WorkSpaces console doesn't support selection of shared Private CA ARNs. Example CLI commands:

   ```
   aws workspaces modify-certificate-based-auth-properties —resource-id <value> —certificate-based-auth-properties Status=<value>,CertificateAuthorityArn=<value>
   ```

# Access Microsoft Entra ID-joined WorkSpaces Personal
<a name="access-entra-id"></a>

You can create Windows 10 or 11 BYOL personal WorkSpaces that are Microsoft Entra ID-joined and enrolled to Intune. For more details, see [Create a dedicated Microsoft Entra ID directory with WorkSpaces Personal](launch-entra-id.md). 

## Authentication workflow
<a name="authentication-workflow-entra"></a>

The following sections describe the authentication workflow initiated by WorkSpaces client application, WorkSpaces Web Access, and a SAML 2.0 identity provider (IdP), Microsoft Entra ID:
+ When the flow is initiated by the IdP. For example, when users choose an application in the Entra ID’s user portal in a web browser..
+ When the flow is initiated by the WorkSpaces client. For example, when users open the client application and sign in.
+ When the flow is initiated by WorkSpaces Web Access. For example, when users open Web Access in a browser and sign in.

In these examples, users enter `user@example.onmicrosoft.com`to sign in to the IdP. On Entra ID, an enterprise application is configured to integrate with IAM Identity Center. Users create a WorkSpace for their user names in a directory that uses IAM Identity Center as the identity source to connect to an Entra ID tenant. Additionally, users install the [WorkSpaces client application](https://clients.amazonworkspaces.com/) on their device or the user uses Web Access in a web browser.

**Identity provider (IdP)-initiated flow with client application**

The IdP-initiated flow allows users to automatically register the WorkSpaces client application on their devices without having to enter a WorkSpaces registration code. Users don't sign in to their WorkSpaces using the IdP-initiated flow. WorkSpaces authentication must originate from the client application.

1. Using their web browser, users sign in to the IdP (Microsoft Entra ID).

1. After signing in to the IdP, users choose the AWS IAM Identity Center application from the IdP user portal.

1. Users are redirected to the AWS access portal in the browser. Then, users choose the WorkSpaces icon.

1. Users are redirected to the page below and the WorkSpaces client application is opened automatically. Choose **Open Amazon WorkSpaces app** if the client application doesn't opened automatically.  
![\[Opening WorkSpaces application redirection page\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/images/saml-redir.png)

1. The WorkSpaces client application is now registered and users can continue to sign by clicking **Continue to sign in to WorkSpaces**.

**Identity provider (IdP)-initiated flow with Web Access**

The IdP-initiated Web Access flow allows users to automatically register their WorkSpaces through a web browser without having to enter a WorkSpaces registration code. Users don't sign in to their WorkSpaces using the IdP-initiated flow. WorkSpaces authentication must originate from Web Access.

1. Using their web browser, users sign in to the IdP.

1. After signing in to the IdP, users click the AWS IAM Identity Center application from the IdP user portal.

1. Users are redirected to AWS access portal in the browser. Then, users choose the WorkSpaces icon.

1. Users are redirected to this page in the browser. To open WorkSpaces, choose **Amazon WorkSpaces in the browser**.  
![\[Opening WorkSpaces application redirection page\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/images/saml-redir.png)

1. The WorkSpaces client application is now registered and users can continue to sign in through WorkSpaces Web Access.

**WorkSpaces client-initiated flow**

The client-initiated flow allows users to sign in to their WorkSpaces after signing in to an IdP.

1. Users launch the WorkSpaces client application (if it isn't already running) and clicks **Continue to sign in to WorkSpaces**.

1. Users are redirected to their default web browser to sign in to the IdP. If the users are already signed in to the IdP in their browser, they don't need to sign in again and will skip this step.

1. Once signed in to the IdP, users are redirected to a pop up. Follow the prompts to allow your web browser to open the client application.

1. Users are redirected to the WorkSpaces client application, on Windows login screen.

1. Users complete sign-in to Windows using their Entra ID username and credentials.

**WorkSpaces Web Access-initiated flow**

The Web Access-initiated flow allows users to sign in to their WorkSpaces after signing in to an IdP.

1. Users launch the WorkSpaces Web Access and chooses **Sign in**.

1. In the same browser tab, users are redirected to IdP portal. If the users are already signed in to the IdP in their browser, they don't need to sign in again and can skip this step.

1. Once signed in to the IdP, users redirected to this page in the browser, and clicks **Log in to WorkSpaces**.

1. Users are redirected to the WorkSpaces client application, on the Windows login screen.

1. Users complete sign-in to Windows using their Entra ID username and credentials.

## First-time user experience
<a name="first-time-entra"></a>

If you're logging in for the first time to a Microsoft Entra ID-joined Windows WorkSpaces, you must go through the out-of-box experience (OOBE). During OOBE, the WorkSpaces are joined to Entra ID. You can customize the OOBE experience by configuring the Autopilot profile assigned to the Microsoft Intune device group that you create for your WorkSpaces. For more information, see [Step 3: Configure Windows Autopilot user-driven mode](launch-entra-id.md#entra-step-3).

# Use smart cards for authentication in WorkSpaces Personal
<a name="smart-cards"></a>

Windows and Linux WorkSpaces on DCV bundles allow the use of [Common Access Card (CAC)](https://www.cac.mil/Common-Access-Card) and [Personal Identity Verification (PIV)](https://www.idmanagement.gov/university/piv/) smart cards for authentication.

Amazon WorkSpaces supports the use of smart cards for both *pre-session authentication* and *in-session authentication*. Pre-session authentication refers to smart card authentication that's performed while users are logging in to their WorkSpaces. In-session authentication refers to authentication that's performed after logging in.

For example, users can use smart cards for in-session authentication while working with web browsers and applications. They can also use smart cards for actions that require administrative permissions. For example, if the user has administrative permissions on their Linux WorkSpace, they can use smart cards to authenticate themselves when running `sudo` and `sudo -i` commands. 

**Topics**
+ [Requirements](#smart-cards-requirements)
+ [Limitations](#smart-cards-limitations)
+ [Directory configuration](#smart-cards-directory-config)
+ [Enable smart cards for Windows WorkSpaces](#smart-cards-windows-workspaces)
+ [Enable smart cards for Ubuntu, Rocky Linux, and Red Hat Enterprise Linux WorkSpaces](#smart-cards-linux-workspaces)
+ [Enable smart cards for Amazon Linux 2 WorkSpaces](#smart-cards-amazon-linux-workspaces)

## Requirements
<a name="smart-cards-requirements"></a>
+ An Active Directory Connector (AD Connector) directory is required for pre-session authentication. AD Connector uses certificate-based mutual Transport Layer Security (mutual TLS) authentication to authenticate users to Active Directory using a hardware or software-based smart card certificate. For more information about how to configure your AD Connector and your on-premises directory, see [Directory configuration](#smart-cards-directory-config).
+ To use a smart card with a Windows or Linux WorkSpace, the user must use the Amazon WorkSpaces Windows client version 3.1.1 or later, WorkSpaces macOS client version 3.1.5 or later, or WorkSpaces Ubuntu 22.04 client version 2024.1 or later (smart card authentication is not supported with WorkSpaces Ubuntu 20.04 client). For more information about using smart cards with the Windows and macOS clients, see [ Smart Card Support](https://docs.aws.amazon.com/workspaces/latest/userguide/smart_card_support.html) in the *Amazon WorkSpaces User Guide*. 
+ The root CA and smart card certificates must meet certain requirements. For more information, see [ Enable mTLS authentication in AD Connector for use with smart cards](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_clientauth.html) in the *AWS Directory Service Administration Guide* and [ Certificate Requirements](https://docs.microsoft.com/en-us/windows/security/identity-protection/smart-cards/smart-card-certificate-requirements-and-enumeration#certificate-requirements) in the Microsoft documentation. 

  In addition to those requirements, user certificates employed for smart card authentication to Amazon WorkSpaces must include the following attributes:
  + The AD user's userPrincipalName (UPN) in the subjectAltName (SAN) field of the certificate. We recommend issuing smart card certificates for the user's default UPN.
**Note**  
Amazon Linux 2 WorkSpaces rely on UPN for certificate-to-user mapping. Newer Linux WorkSpaces, like Ubuntu, Rocky Linux, and Red Hat Enterprise Linux WorkSpaces, support more secure [mapping methods](https://www.idmanagement.gov/implement/scl-windows/#step-4---account-linking).
  + The Client Authentication (1.3.6.1.5.5.7.3.2) Extended Key Usage (EKU) attribute.
  + The Smart Card Logon (1.3.6.1.4.1.311.20.2.2) EKU attribute.
+ For pre-session authentication, Online Certificate Status Protocol (OCSP) is required for certificate revocation checking. For in-session authentication, OCSP is recommended, but not required.
**Note**  
Ubuntu WorkSpaces, Rocky Linux WorkSpaces, and Red Hat Enterprise Linux WorkSpaces require OCSP for in-session authentication by default, and OCSP verification in these systems requires the OCSP responder to have NONCE extension enabled to prevent replay attacks. To disable NONCE extension, in-session OCSP verification must be disabled altogether. To disable OCSP verification in Ubuntu, Rocky Linux, and Red Hat Enterprise Linux WorkSpaces, create a new file `/etc/sssd/conf.d/disable-ocsp.conf`with the following content:   

  ```
  [sssd]
  certificate_verification = no_ocsp
  ```

## Limitations
<a name="smart-cards-limitations"></a>
+ Only the WorkSpaces Windows client application version 3.1.1 or later, the WorkSpaces macOS client application version 3.1.5 or later, and WorkSpaces Ubuntu 22.04 client application version 2024.1 or later are currently supported for smart card authentication. WorkSpaces Ubuntu 20.04 or earlier client application is not supported for smart card authentication.
+ The WorkSpaces Windows client application 3.1.1 or later supports smart cards only when the client is running on a 64-bit version of Windows.
+ Only AD Connector directories are currently supported for smart card authentication.
+ In-session authentication is available in all Regions where DCV is supported. Pre-session authentication is available in the following Regions:
  + Asia Pacific (Sydney) Region
  + Asia Pacific (Tokyo) Region
  + Europe (Ireland) Region
  + AWS GovCloud (US-East) Region
  + AWS GovCloud (US-West) Region
  + US East (N. Virginia) Region
  + US West (Oregon) Region
+ For in-session authentication and pre-session authentication on Linux or Windows WorkSpaces, only one smart card is currently allowed at a time. Simultaneous use of multiple cards may work, but is not supported.
+ For pre-session authentication, enabling both smart card authentication and sign-in authentication on the same directory is not currently supported.
+ Only CAC and PIV cards are supported at this time. Other types of hardware or software-based smart cards might also work, but they haven't been fully tested for use with DCV.

## Directory configuration
<a name="smart-cards-directory-config"></a>

To enable smart card authentication, you must configure your AD Connector directory and your on-premises directory in the following manner.

**AD Connector directory configuration**  
Before you begin, make sure your AD Connector directory has been set up as described in [ AD Connector Prerequisites](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/prereq_connector.html) in the *AWS Directory Service Administration Guide*. In particular, make sure that you have opened up the necessary ports in your firewall. 

To finish configuring your AD Connector directory, follow the instructions in [ Enable mTLS authentication in AD Connector for use with smart cards](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_clientauth.html) in the *AWS Directory Service Administration Guide*.

**Note**  
Smart card authentication requires Kerberos Constrained Delegation (KCD) to function properly. KCD requires the username portion of the AD Connector service account to match the sAMAccountName of the same user. A sAMAccountName can't exceed 20 characters.

**On-premises directory configuration**  
In addition to configuring your AD Connector directory:
+ Make sure that the certificates that are issued to the domain controllers for your on-premises directory have the "KDC Authentication" extended key usage (EKU) set. To do this, use the Active Directory Domain Services (AD DS) default Kerberos Authentication certificate template. Do not use a Domain Controller certificate template or a Domain Controller Authentication certificate template because those templates don't contain the necessary settings for smart card authentication.
+ For Linux WorkSpaces, make sure that OCSP responder for the CA issuing smart card certificates has NONCE extension enabled. If it cannot be enabled, in-session OCSP verification will have to be disabled in Ubuntu, Rocky Linux, and Red Hat Enterprise Linux WorkSpaces. To disable OCSP verification, create a new file `/etc/sssd/conf.d/disable-ocsp.conf`with the following content: 

  ```
  [sssd]
  certificate_verification = no_ocsp
  ```

## Enable smart cards for Windows WorkSpaces
<a name="smart-cards-windows-workspaces"></a>

For general guidance on how to enable smart card authentication on Windows, see [ Guidelines for enabling smart card logon with third-party certification authorities](https://docs.microsoft.com/troubleshoot/windows-server/windows-security/enabling-smart-card-logon-third-party-certification-authorities) in the Microsoft documentation.

**To detect the Windows lock screen and disconnect the session**  
To allow users to unlock Windows WorkSpaces that are enabled for smart card pre-session authentication when the screen is locked, you can enable Windows lock screen detection in users' sessions. When the Windows lock screen is detected, the WorkSpace session is disconnected, and the user can reconnect from the WorkSpaces client by using their smart card.

 You can enable disconnecting the session when the Windows lock screen is detected by using Group Policy settings. For more information, see [Configure disconnect session on screen lock for DCV](group_policy.md#gp_lock_screen_in_wsp).

**To enable in-session or pre-session authentication**  
By default, Windows WorkSpaces are not enabled to support the use of smart cards for pre-session or in-session authentication. If needed, you can enable in-session and pre-session authentication for Windows WorkSpaces by using Group Policy settings. For more information, see [Configure smart card redirection for DCV](group_policy.md#gp_smart_cards_in_wsp).

To use pre-session authentication, in addition to updating the Group Policy settings, you must also enable pre-session authentication through your AD Connector directory settings. For more information, follow the instructions in [ Enable mTLS authentication in AD Connector for use in smart cards](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_clientauth.html) in the *AWS Directory Service Administration Guide*.

**To enable users to use smart cards in a browser**  
If your users are using Chrome as their browser, no special configuration is required to use smart cards.

If your users are using Firefox as their browser, you can enable your users to use smart cards in Firefox through Group Policy. You can use these [ Firefox Group Policy templates](https://github.com/mozilla/policy-templates/tree/master/windows) in GitHub.

For example, you can install the 64-bit version of [OpenSC](https://github.com/OpenSC/OpenSC/wiki) for Windows to support PKCS \$111, and then use the following Group Policy setting, where `NAME_OF_DEVICE` is whatever value you want to use to identify PKCS \$111, such as `OpenSC`, and where `PATH_TO_LIBRARY_FOR_DEVICE` is the path to the PKCS \$111 module. This path should point to a library with a .DLL extension, such as `C:\Program Files\OpenSC Project\OpenSC\pkcs11\onepin-opensc-pkcs11.dll`.

```
Software\Policies\Mozilla\Firefox\SecurityDevices\NAME_OF_DEVICE = PATH_TO_LIBRARY_FOR_DEVICE
```

**Tip**  
If you're using OpenSC, you can also load the OpenSC `pkcs11` module into Firefox by running the `pkcs11-register.exe` program. To run this program, either double-click the file at `C:\Program Files\OpenSC Project\OpenSC\tools\pkcs11-register.exe`, or open a Command Prompt window and run the following command:  

```
"C:\Program Files\OpenSC Project\OpenSC\tools\pkcs11-register.exe"
```
To verify that the OpenSC `pkcs11` module has been loaded into Firefox, do the following:  
If Firefox is already running, close it.
Open Firefox. Choose the menu button ![\[Firefox menu button\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/images/firefox-menu-button.png) in the upper-right corner, and then choose **Options**. 
On the **about:preferences** page, in the left navigation pane, choose **Privacy & Security**.
Under **Certificates**, choose **Security Devices**.
In the **Device Manager** dialog box, you should see **OpenSC smartcard framework (0.21)** in the left navigation, and it should have the following values when you select it:  
**Module**: `OpenSC smartcard framework (0.21)`  
**Path**: `C:\Program Files\OpenSC Project\OpenSC\pkcs11\onepin-opensc-pkcs11.dll`

**Troubleshooting**  
For information about troubleshooting smart cards, see [ Certificate and configuration problems](https://docs.microsoft.com/troubleshoot/windows-server/windows-security/enabling-smart-card-logon-third-party-certification-authorities#certificate-and-configuration-problems) in the Microsoft documentation. 

Some common issues that can cause problems:
+ Incorrect mapping of the slots to the certificates.
+ Having multiple certificates on the smart card that can match the user. Certificates are matched using the following criteria:
  + The root CA for the certificate.
  + The `<KU>` and `<EKU>` fields of the certificate.
  + The UPN in the certificate subject.
+ Having multiple certificates that have `<EKU>msScLogin` in their key usage.

In general, it's best to have only one certificate for smart card authentication that is mapped to the very first slot in the smart card.

The tools for managing the certificates and keys on the smart card (such as removing or remapping the certificates and keys) might be manufacturer-specific. For more information, see the documentation provided by the manufacturer of your smart cards.

## Enable smart cards for Ubuntu, Rocky Linux, and Red Hat Enterprise Linux WorkSpaces
<a name="smart-cards-linux-workspaces"></a>

To enable the use of smart cards on Ubuntu, Rocky Linux, and Red Hat Enterprise Linux WorkSpaces, you need to include the root and all intermediate CA certificates in the WorkSpace image for all CAs issuing smart cards, and for all CAs issuing domain controller certificates.

**To obtain your CA certificate:** You can obtain your CA certificate in several ways:
+ You can use a CA certificate bundle of a third-party certification authority. 
+ You can export your own CA certificate by using the Web Enrollment site, which is either `http://ip_address/certsrv` or `http://fqdn/certsrv`, where `ip_address` and `fqdn` are the IP address and the fully qualified domain name (FQDN) of the CA server. For more information about using the Web Enrollment site, see [ How to export a Root Certification Authority Certificate](https://docs.microsoft.com/troubleshoot/windows-server/identity/export-root-certification-authority-certificate) in the Microsoft documentation. 
+ You can use the following procedure to export the CA certificate from a CA server that is running Active Directory Certificate Services (AD CS). For information about installing AD CS, see [ Install the Certification Authority](https://docs.microsoft.com/windows-server/networking/core-network-guide/cncg/server-certs/install-the-certification-authority) in the Microsoft documentation. 

  1. Log into the CA server using an administrator account.

  1. From the Windows **Start** menu, open a command prompt window (**Start** > **Windows System** > **Command Prompt**). 

  1. Use the following command to export the CA certificate to a new file, where `rootca.cer` is the name of the new file:

     ```
     certutil -ca.cert rootca.cer
     ```

     For more information about running certutil, see [ certutil](https://docs.microsoft.com/windows-server/administration/windows-commands/certutil) in the Microsoft documentation.

  1. Use the following OpenSSL command to convert the exported CA certificate from DER format to PEM format, where *rootca* is the name of the certificate. For more information about OpenSSL, see [www.openssl.org](https://www.openssl.org/).

     ```
     openssl x509 -inform der -in rootca.cer -out /tmp/rootca.pem
     ```

**To add your CA certificates to your Linux WorkSpaces**

To assist you with enabling smart cards, we've added the `enable_smartcard` script to our Linux WorkSpaces DCV bundles. This script performs the following actions:
+ Imports your CA certificates into a private PEM bundle that defines the trust root for SSSD on Linux WorkSpaces).
+ Updates SSSD, PAM, and Kerberos configuration, which includes enabling `PKINIT` (Kerberos authentication using certificate instead of password) during WorkSpace provisioning.

The following procedure explains how to use the `enable_smartcard` script to import your CA certificates and to enable smart card authentication for your Linux WorkSpaces.

1. Create a new Linux WorkSpace with the DCV protocol enabled. When launching the WorkSpace in the Amazon WorkSpaces console, on the **Select Bundles** page, be sure to select **DCV** for the protocol, and then select one of the Linux WorkSpaces public bundles.

1. On the newly created WorkSpace, make sure `/etc/skylight.conf` file has `pam_smartcard = true` line in `[features]` section: 

   ```
   [features]
   pam_smartcard = true
   ```
**Note**  
If not all your users are yet configured to use strong `altSecurityIdentities` certificate mapping, you can also add `smartcard_weak_mapping = true` line to the same `[features]` section in `/etc/skylight.conf` to support legacy mapping methods, but we recommend migrating those users to use strong mapping methods as soon as possible instead. 

1. On the WorkSpace, run the following command as root, where `pem-path1`, `pem-path2`, etc., are the paths to files, each containing one of the CA certificates in the trust chain for the smart card and domain controller certificates. All of these files should be in PEM format and contain one certificate per file. Glob patterns can be used (e.g., `*.pem`)

   ```
   /usr/lib/skylight/enable_smartcard --ca-cert pem-path1 pem-path2 pem-path3 ...
   ```
**Note**  
Make sure additional dependency packages are installed on the WorkSpace before running the above command, using following commands as root.  
For Rocky Linux and Red Hat Enterprise Linux WorkSpaces:   

   ```
   dnf install sssd-dbus libsss_simpleifp sssd-tools krb5-pkinit opensc
   ```
 For Ubuntu WorkSpaces:   

   ```
   apt install krb5-pkinit opensc
   ```

1. Perform any additional customizations on the WorkSpace. For example, you might want to add a system-wide policy to [enable users to use smart cards in Firefox](#smart-cards-firefox-linux). (Chrome users must enable smart cards on their clients themselves. For more information, see [ Smart Card Support](https://docs.aws.amazon.com/workspaces/latest/userguide/smart_card_support.html) in the *Amazon WorkSpaces User Guide*.) 

1. [Create a custom WorkSpace image and bundle](create-custom-bundle.md) from the WorkSpace.

1. Use the new custom bundle to launch WorkSpaces for your users.

You can enable your users to use smart cards in Firefox by adding a SecurityDevices policy to your Linux WorkSpace image. For more information about adding system-wide policies to Firefox, see the [Mozilla policy templates](https://github.com/mozilla/policy-templates/releases) on GitHub.

**To enable users to use smart cards in Firefox**

1. On the WorkSpace that you're using to create your WorkSpace image, create a new file named `policies.json` in `PREFIX/firefox/distribution/`, where `PREFIX` is `/usr/lib64` on Fedora-based systems (Amazon Linux 2, Red Hat Enterprise Linux, and Rocky Linux WorkSpaces), and `/usr/lib` on Debian-based systems (Ubuntu WorkSpaces).

1. In the JSON file, add the following SecurityDevices policy, where `NAME_OF_DEVICE` is whatever value you want to use to identify the `pkcs` module. For example, you might want to use a value such as `"OpenSC"`:

   ```
   {
       "policies": {
           "SecurityDevices": {
               "NAME_OF_DEVICE": "PREFIX/opensc-pkcs11.so"
           }
       }
   }
   ```

**Troubleshooting**  
Troubleshooting of smart card authentication is easier when pre-session is set to use password authentication - during session provisioning Linux WorkSpaces automatically switch on-host authentication mode preference to password-based or smartcard-based depending on pre-session authentication method used. If there are any issues with smart card authentication, disconnecting and reconnecting using password pre-session authentication resets the workspace back to password on-host authentication. To manually switch Linux WorkSpaces instance to smart card authentication run `/usr/lib/skylight/resume_smartcard` command as root.

Linux WorkSpaces use OpenSC software for working with smart cards. That software comes with tools like `pkcs11-tool` and `pkcs15-tool` which can be useful in troubleshooting issues with smart cards. These tools can be used for inspecting smart card readers, individual tokens, and PIV slots or certificates on each smart card token.

An `openssl` command-line tool can be helpful in troubleshooting issues with trust chains, OCSP responders, or missing KUs/EKUs (key usage/extended key usage) flags, especially in combination with `pkcs15-tool`'s ability to extract public certificates from a smart card.

Common troubleshooting options:
+ Extract first (usually PIV slot 9A) certificate from the smart card and save it as `card-cert.pem`: `pkcs15-tool --read-certificate 1 > card-cert.pem`
+ Validate the extracted certificate against trust database on the WorkSpace: `openssl verify -verbose -CAfile /etc/sssd/pki/sssd_auth_ca_db.pem -cert card-cert.pem`
+ Get OCSP URL from the extracted smart card certificate: `openssl x509 -noout -ocsp_uri -in card-cert.pem`
+ Verify that OCSP response indicates certificate is valid and includes NONCE: `openssl ocsp -issuer /etc/sssd/pki/sssd_auth_ca_db.pem -CAfile /etc/sssd/pki/sssd_auth_ca_db.pem -cert card-cert.pem -text -url OCSP_URI`, where *OCSP\$1URI* is the OCSP URL from above.
+ Check if domain controller certificate is considered trusted: `openssl s_client -connect DC_HOSTNAME:636 -showcerts | openssl verify -verbose -CAfile /etc/sssd/pki/sssd_auth_ca_db.pem`, where *DC\$1HOSTNAME* is the host name of one of the domain controllers in your Active Directory domain.
+ Confirm domain controller certificate has KDC Authentication EKU (extended key usage) set: `openssl s_client -connect DC_HOSTNAME:636 -showcerts | openssl x509 -noout -text`.
+ Attempt manual PKINIT to see if there are any error codes that can be used to narrow down the problem: `KRB5_TRACE=/dev/stdout kinit -X X509_user_identity=PKCS11:opensc-pkcs11.so:certid=01 -V`, where *01* is the number of one of the four main PIV slots on the card - `01` for `9A`, `02` for `9C`, etc. Most cards will have certificate meant for user authentication in slot 9A.
+ Check if system is able to map smart card certificate to an AD user (execute as root): `dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe/Users org.freedesktop.sssd.infopipe.Users.FindByCertificate string:"$(<card-cert.pem)"`. This can be combined with enabling debug logging for SSSD.

The most common known issues:
+ Incomplete trust chain for the smart card certificate - when importing certificates using `enable_smartcard` script the full list of all root and intermediate CA certificates must to be provided. The `enable_smartcard` tool will show an error if not all imported certificates are trusted because of missing from the list root CA certificate, but it cannot detect when either an entire trust chain or the innermost intermediate CA certificate in one of the trust chains is missing. In that situation it will import certificates without an error, yet either a smart card certificate or domain controller certificates may still be considered untrusted.
+ Missing trust chain for the domain controller certificates - if domain controller certificates are issued by a different CA than smart cards (e.g., in case of [Common Access Card (CAC)](https://www.cac.mil/Common-Access-Card)), that CA trust chain needs to be imported together with the smart card issuing CA certificates.
+ Lack of NONCE extension support in OCSP responder - Linux WorkSpaces require that OCSP responder of the smart card issuer has NONCE extension enabled. If it cannot be enabled, OCSP validation will have to be completely disabled.
+ Domain controller certificates are missing `KDC Authentication` EKU (OID 1.3.6.1.5.2.3.1) - for smart card authentication to work domain controller certificates need to be re-issued to include KDC Authentication EKU.
+ Domain controller certificates are expired - for smart card authentication to work domain controller certificates must remain up-to-date.
+ Smart card certificates are mapped to users in AD using weak mapping methods - traditionally, UPN field in subjectAltName attribute was used to map a certificate to a user in AD, being expected to match userPrincipalName attribute. This is no longer considered a secure mapping method and is disallowed by default. It is possible to re-enable it by passing `--allow-weak-mapping` argument to `enable_smartcard` command and adding `smartcard_weak_mapping = true` line to the `[features]` section in `/etc/skylight.conf` file, but a better solution is to use one of the strong mapping methods. See [Account Linking](https://www.idmanagement.gov/implement/scl-windows/#step-4---account-linking) documentation for more details.

The tools for managing the certificates and keys on the smart card (such as removing or remapping the certificates and keys) might be manufacturer-specific. Additional tools that you can use to work with smart cards are:
+ `opensc-explorer`
+ `opensc-tool`
+ `pkcs11_inspect`
+ `pkcs11_listcerts`
+ `pkcs15-tool`

**To enable debug logging**
+ Add `debug_level = LEVEL` line in `/etc/sssd/sssd.conf` for each individual section, where *LEVEL* is the desired verbosity level, from 1 to 10. The logs for each corresponding section can then be found in `/var/log/sssd/` directory. See SSSD documentation [here](https://docs.pagure.org/sssd.sssd/users/troubleshooting.html#sssd-debug-logs) and [here](https://sssd.io/troubleshooting/basics.html#sssd-debug-logs) for more details.

## Enable smart cards for Amazon Linux 2 WorkSpaces
<a name="smart-cards-amazon-linux-workspaces"></a>

**Note**  
Amazon Linux 2 WorkSpaces on DCV currently have the following limitations:  
Clipboard, audio-in, video-in, and time zone redirection aren't supported.
Multiple monitors aren't supported.

To enable the use of smart cards on Amazon Linux 2 WorkSpaces, you need to include a root CA certificate file in the PEM format in the WorkSpace image.

**To obtain your root CA certificate:** You can obtain your root CA certificate in several ways:
+ You can use a root CA certificate operated by a third-party certification authority. 
+ You can export your own root CA certificate by using the Web Enrollment site, which is either `http://ip_address/certsrv` or `http://fqdn/certsrv`, where `ip_address` and `fqdn` are the IP address and the fully qualified domain name (FQDN) of the root certification CA server. For more information about using the Web Enrollment site, see [ How to export a Root Certification Authority Certificate](https://docs.microsoft.com/troubleshoot/windows-server/identity/export-root-certification-authority-certificate) in the Microsoft documentation. 
+ You can use the following procedure to export the root CA certificate from a root CA certification server that is running Active Directory Certificate Services (AD CS). For information about installing AD CS, see [ Install the Certification Authority](https://docs.microsoft.com/windows-server/networking/core-network-guide/cncg/server-certs/install-the-certification-authority) in the Microsoft documentation. 

  1. Log into the root CA server using an administrator account.

  1. From the Windows **Start** menu, open a command prompt window (**Start** > **Windows System** > **Command Prompt**). 

  1. Use the following command to export the root CA certificate to a new file, where `rootca.cer` is the name of the new file:

     ```
     certutil -ca.cert rootca.cer
     ```

     For more information about running certutil, see [ certutil](https://docs.microsoft.com/windows-server/administration/windows-commands/certutil) in the Microsoft documentation.

  1. Use the following OpenSSL command to convert the exported root CA certificate from DER format to PEM format, where *rootca* is the name of the certificate. For more information about OpenSSL, see [www.openssl.org](https://www.openssl.org/).

     ```
     openssl x509 -inform der -in rootca.cer -out /tmp/rootca.pem
     ```

**To add your root CA certificate to your Amazon Linux 2 WorkSpaces**

To assist you with enabling smart cards, we've added the `enable_smartcard` script to our Amazon Linux DCV bundles. This script performs the following actions:
+ Imports your root CA certificate into the [ Network Security Services (NSS)](https://developer.mozilla.org/docs/Mozilla/Projects/NSS) database. 
+ Installs the `pam_pkcs11` module for Pluggable Authentication Module (PAM) authentication.
+ Performs a default configuration, which includes enabling `pkinit` during WorkSpace provisioning.

The following procedure explains how to use the `enable_smartcard` script to add your root CA certificate to your Amazon Linux 2 WorkSpaces and to enable smart cards for your Amazon Linux 2 WorkSpaces.

1. Create a new Amazon Linux 2 WorkSpace with the DCV protocol enabled. When launching the WorkSpace in the Amazon WorkSpaces console, on the **Select Bundles** page, be sure to select **DCV** for the protocol, and then select one of the Amazon Linux 2 public bundles.

1. On the new WorkSpace, run the following command as root, where `pem-path` is the path to the root CA certificate file in PEM format.

   ```
   /usr/lib/skylight/enable_smartcard --ca-cert pem-path
   ```
**Note**  
Amazon Linux 2 WorkSpaces assume that the certificates on the smart cards are issued for the user's default user principal name (UPN), such as `sAMAccountName@domain`, where `domain` is a fully qualified domain name (FQDN).   
To use alternate UPN suffixes, `run /usr/lib/skylight/enable_smartcard --help` for more information. The mapping for alternate UPN suffixes is unique to each user. Therefore, that mapping must be performed individually on each user's WorkSpace.

1. (Optional) By default, all services are enabled to use smart card authentication on Amazon Linux 2 WorkSpaces. To limit smart card authentication to only specific services, you must edit `/etc/pam.d/system-auth`. Uncomment the `auth` line for `pam_succeed_if.so` and edit the list of services as needed.

   After the `auth` line is uncommented, to allow a service to use smart card authentication, you must add it to the list. To make a service use only password authentication, you must remove it from the list.

1. Perform any additional customizations to the WorkSpace. For example, you might want to add a system-wide policy to [enable users to use smart cards in Firefox](#smart-cards-firefox-amazon-linux). (Chrome users must enable smart cards on their clients themselves. For more information, see [ Smart Card Support](https://docs.aws.amazon.com/workspaces/latest/userguide/smart_card_support.html) in the *Amazon WorkSpaces User Guide*.) 

1. [Create a custom WorkSpace image and bundle](create-custom-bundle.md) from the WorkSpace.

1. Use the new custom bundle to launch WorkSpaces for your users.

You can enable your users to use smart cards in Firefox by adding a SecurityDevices policy to your Amazon Linux 2 WorkSpace image. For more information about adding system-wide policies to Firefox, see the [Mozilla policy templates](https://github.com/mozilla/policy-templates/releases) on GitHub.

**To enable users to use smart cards in Firefox**

1. On the WorkSpace that you're using to create your WorkSpace image, create a new file named `policies.json` in `/usr/lib64/firefox/distribution/`.

1. In the JSON file, add the following SecurityDevices policy, where `NAME_OF_DEVICE` is whatever value you want to use to identify the `pkcs` module. For example, you might want to use a value such as `"OpenSC"`:

   ```
   {
       "policies": {
           "SecurityDevices": {
               "NAME_OF_DEVICE": "/usr/lib64/opensc-pkcs11.so"
           }
       }
   }
   ```

**Troubleshooting:** For troubleshooting, we recommend adding the `pkcs11-tools` utility. This utility allows you to perform the following actions:
+ List each smart card.
+ List the slots on each smart card.
+ List the certificates on each smart card.

Some common issues that can cause problems:
+ Incorrect mapping of the slots to the certificates.
+ Having multiple certificates on the smart card that can match the user. Certificates are matched using the following criteria:
  + The root CA for the certificate.
  + The `<KU>` and `<EKU>` fields of the certificate.
  + The UPN in the certificate subject.
+ Having multiple certificates that have `<EKU>msScLogin` in their key usage.

In general, it's best to have only one certificate for smart card authentication that is mapped to the very first slot in the smart card.

The tools for managing the certificates and keys on the smart card (such as removing or remapping the certificates and keys) might be manufacturer-specific. Additional tools that you can use to work with smart cards are:
+ `opensc-explorer`
+ `opensc-tool`
+ `pkcs11_inspect`
+ `pkcs11_listcerts`
+ `pkcs15-tool`

**To enable debug logging**

To troubleshoot your `pam_pkcs11` and `pam-krb5` configuration, you can enable debug logging.

1. In the `/etc/pam.d/system-auth-ac` file, edit the `auth` action and change the `nodebug` parameter of `pam_pksc11.so` to `debug`. 

1. In the `/etc/pam_pkcs11/pam_pkcs11.conf` file, change `debug = false;` to `debug = true;`. The `debug` option applies separately to each mapper module, so you might need to change it both directly under the `pam_pkcs11` section and also under the appropriate mapper section (by default, this is `mapper generic`).

1. In the `/etc/pam.d/system-auth-ac` file, edit the `auth` action and add the `debug` or the `debug_sensitive` parameter to `pam_krb5.so`. 

After you've enabled debug logging, the system prints out `pam_pkcs11` debug messages directly in the active terminal. Messages from `pam_krb5` are logged in `/var/log/secure`. 

To check which username a smart card certificate maps to, use the following `pklogin_finder` command:

```
sudo pklogin_finder debug config_file=/etc/pam_pkcs11/pam_pkcs11.conf
```

When prompted, enter the smart card PIN. `pklogin_finder` outputs on `stdout` the username on the smart card certificate in the form `NETBIOS\username`. This username should match the WorkSpace username.

In Active Directory Domain Services (AD DS), the NetBIOS domain name is the pre-Windows 2000 domain name. Typically (but not always), the NetBIOS domain name is the subdomain of the Domain Name System (DNS) domain name. For example, if the DNS domain name is `example.com`, the NetBIOS domain name is usually `EXAMPLE`. If the DNS domain name is `corp.example.com`, the NetBIOS domain name is usually `CORP`. 

For example, for the user `mmajor` in the domain `corp.example.com`, the output from `pklogin_finder` is `CORP\mmajor`.

**Note**  
If you receive the message `"ERROR:pam_pkcs11.c:504: verify_certificate() failed"`, this message indicates that `pam_pkcs11` has found a certificate on the smart card that matches the username criteria but that doesn't chain up to a root CA certificate that is recognized by the machine. When that happens, `pam_pkcs11` outputs the above message and then tries the next certificate. It allows authentication only if it finds a certificate that both matches the username and chains up to a recognized root CA certificate.

To troubleshoot your `pam_krb5` configuration, you can manually invoke `kinit` in debug mode with the following command:

```
KRB5_TRACE=/dev/stdout kinit -V
```

This command should successfully obtain a Kerberos Ticket Granting Ticket (TGT). If it fails, try adding the correct Kerberos principal name explicitly to the command. For example, for the user `mmajor` in the domain `corp.example.com`, use this command: 

```
KRB5_TRACE=/dev/stdout kinit -V mmajor
```

If this command succeeds, the issue is most likely in the mapping from the WorkSpace username to the Kerberos principal name. Check the `[appdefaults]/pam/mappings` section in the `/etc/krb5.conf` file. 

If this command doesn't succeed, but a password-based `kinit` command does succeed, check the `pkinit_`-related configurations in the `/etc/krb5.conf` file. For example, if the smart card contains more than one certificate, you might need to make changes to `pkinit_cert_match`.

# Provide internet access for WorkSpaces Personal
<a name="amazon-workspaces-internet-access"></a>

Your WorkSpaces must have access to the internet so that you can install updates to the operating system and deploy applications. You can use one of the following options to allow your WorkSpaces in a virtual private cloud (VPC) to access the internet.

**Options**
+ Launch your WorkSpaces in private subnets and configure a NAT gateway in a public subnet in your VPC.
+ Launch your WorkSpaces in public subnets and automatically or manually assign public IP addresses to your WorkSpaces.

For more information about these options, see the corresponding sections in [Configure a VPC for WorkSpaces Personal](amazon-workspaces-vpc.md).

With any of these options, you must ensure that the security group for your WorkSpaces allows outbound traffic on ports 80 (HTTP) and 443 (HTTPS) to all destinations (`0.0.0.0/0`).

**Amazon Linux extras library**  
If you are using the Amazon Linux repository, your Amazon Linux WorkSpaces must either have internet access or you must configure VPC endpoints to this repository and to the main Amazon Linux repository. For more information, see the *Example: Enabling Access to the Amazon Linux AMI Repositories* section in [Endpoints for Amazon S3](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-s3.html). The Amazon Linux AMI repositories are Amazon S3 buckets in each Region. If you want instances in your VPC to access the repositories through an endpoint, create an endpoint policy that enables access to these buckets. The following policy allows access to the Amazon Linux repositories.

```
{
  "Statement": [
    {
        "Sid": "AmazonLinux2AMIRepositoryAccess",
        "Principal": "*",
        "Action": [
            "s3:GetObject"
        ],
        "Effect": "Allow",
        "Resource": [
            "arn:aws:s3:::amazonlinux.*.amazonaws.com/*"
        ]
    }
  ]
}
```

# Security groups for WorkSpaces Personal
<a name="amazon-workspaces-security-groups"></a>

When you register a directory with WorkSpaces, it creates two security groups, one for directory controllers and another for WorkSpaces in the directory. The security group for directory controllers has a name that consists of the directory identifier followed by **\$1controllers** (for example, d-12345678e1\$1controllers). The security group for WorkSpaces has a name that consists of the directory identifier followed by **\$1workspacesMembers** (for example, d-123456fc11\$1workspacesMembers).

**Warning**  
Avoid modifying, deleting, or detaching the **\$1controllers** and the **\$1workspacesMembers** security groups. Be cautious when modifying or deleting these security groups, because you will not be able to recreate these groups and add them back after they have been modified or deleted. For more information, see [ Amazon EC2 security groups for Linux instance](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/ec2-security-groups.html) or [ Amazon EC2 security groups for Windows instances](https://docs.aws.amazon.com//AWSEC2/latest/WindowsGuide/ec2-security-groups.html).

You can add a default WorkSpaces security group to a directory. After you associate a new security group with a WorkSpaces directory, new WorkSpaces that you launch or existing WorkSpaces that you rebuild will have the new security group. You can also [add this new default security group to existing WorkSpaces without rebuilding them](#security_group_existing_workspace), as explained later in this topic.

When you associate multiple security groups with a WorkSpaces directory, the rules from each security group are effectively aggregated to create one set of rules. We recommend condensing your security group rules as much as possible.

For more information about security groups, see [ Security Groups for Your VPC](https://docs.aws.amazon.com//vpc/latest/userguide/VPC_SecurityGroups.html) in the *Amazon VPC User Guide*.

**To add a security group to a WorkSpaces directory**

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose **Directories**.

1. Select the directory and choose **Actions**, **Update Details**.

1. Expand **Security Group** and select a security group.

1. Choose **Update and Exit**.

To add a security group to an existing WorkSpace without rebuilding it, you assign the new security group to the elastic network interface (ENI) of the WorkSpace.

**To add a security group to an existing WorkSpace**

1. Find the IP address for each WorkSpace that needs to be updated.

   1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

   1. Expand each WorkSpace and record its WorkSpace IP address.

1. Find the ENI for each WorkSpace and update its security group assignment.

   1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

   1. Under **Network & Security**, choose **Network Interfaces**.

   1. Search for the first IP address that you recorded in Step 1.

   1. Select the ENI associated with the IP address, choose **Actions**, and then choose **Change Security Groups**.

   1. Select the new security group, and choose **Save**.

   1. Repeat this process as needed for any other WorkSpaces. 

# IP access control groups for WorkSpaces Personal
<a name="amazon-workspaces-ip-access-control-groups"></a>

Amazon WorkSpaces allows you to control which IP addresses your WorkSpaces can be accessed from. By using IP address-based control groups, you can define and manage groups of trusted IP addresses, and only allow users to access their WorkSpaces when they're connected to a trusted network.

An *IP access control group* acts as a virtual firewall that controls the IP addresses from which users are allowed to access their WorkSpaces. To specify the CIDR address ranges, add rules to your IP access control group, and then associate the group with your directory. You can add up to 30 rules per IP access control group and can associate each IP access control group with one or more directories. You can create up to 140 IP access control groups per Region per AWS account. However, you can only associate up to 35 IP access control groups with a single directory.

A default IP access control group is associated with each directory. This default group includes a default rule that allows users to access their WorkSpaces from anywhere. You cannot modify the default IP access control group for your directory. If you don't associate an IP access control group with your directory, the default group is used. If you associate an IP access control group with a directory, the default IP access control group is disassociated.

To specify the public IP addresses and ranges of IP addresses for your trusted networks, add rules to your IP access control groups. If your users access their WorkSpaces through a NAT gateway or VPN, you must create rules that allow traffic from the public IP addresses for the NAT gateway or VPN.

**Note**  
IP access control groups do not allow the use of dynamic IP addresses for NATs. If you're using a NAT, configure it to use a static IP address instead of a dynamic IP address. Make sure the NAT routes all the UDP traffic through the same static IP address for the duration of the WorkSpaces session.
IP access control groups control the IP addresses from which users can connect their streaming sessions to WorkSpaces. Users can still execute functionalities, such as restart, rebuild, shutdown, from any IP address using Amazon WorkSpaces public APIs.
IP access control groups do not apply when VPC endpoint for streaming is configured for a directory.
When you change an IP access control, active sessions are not immediately interrupted; changes will be applied for new sessions only.

You can use this feature with Web Access, PCoIP zero clients, and the client applications for macOS, iPad, Windows, Chromebook, and Android.

## Create an IP access control group
<a name="create-ip-access-control-group"></a>

You can create an IP access control group as follows. Each IP access control group can contain up to 30 rules.

**To create an IP access control group**

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose **IP Access Controls**.

1. Choose **Create IP Group**.

1. In the **Create IP Group** dialog box, enter a name and description for the group and choose **Create**.

1. Select the group and choose **Edit**.

1. For each IP address, choose **Add Rule**. For **Source**, enter the IP address or IP address range. For **Description**, enter a description. When you are done adding rules, choose **Save**.

## Associate an IP access control group with a directory
<a name="associate-ip-access-control-group"></a>

You can associate an IP access control group with a directory to ensure that WorkSpaces are accessed only from trusted networks.

If you associate an IP access control group that has no rules with a directory, this blocks all access to all WorkSpaces.

**To associate an IP access control group with a directory**

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose **Directories**.

1. Select the directory and choose **Actions**, **Update Details**.

1. Expand **IP Access Control Groups** and select one or more IP access control groups.

1. Choose **Update and Exit**.

## Copy an IP access control group
<a name="copy-ip-access-control-group"></a>

You can use an existing IP access control group as a base for creating a new IP access control group.

**To create an IP access control group from an existing one**

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose **IP Access Controls**.

1. Select the group and choose **Actions**, **Copy to New**.

1. In the **Copy IP Group** dialog box, enter a name and description for the new group and choose **Copy Group**.

1. (Optional) To modify the rules copied from the original group, select the new group and choose **Edit**. Add, update, or remove rules as needed. Choose **Save**.

## Delete an IP access control group
<a name="delete-ip-access-control-group"></a>

You can delete a rule from an IP access control group at any time. If you remove a rule that was used to allow a connection to a WorkSpace, the user is disconnected from the WorkSpace.

Before you can delete an IP access control group, you must disassociate it from any directories.

**To delete an IP access control group**

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose **Directories**.

1. For each directory that is associated with the IP access control group, select the directory and choose **Actions**, **Update Details**. Expand **IP Access Control Groups**, clear the check box for the IP access control group, and choose **Update and Exit**.

1. In the navigation pane, choose **IP Access Controls**.

1. Select the group and choose **Actions**, **Delete IP Group**.

# Set up PCoIP zero clients for WorkSpaces Personal
<a name="set-up-pcoip-zero-client"></a>

PCoIP zero clients are compatible only with WorkSpaces bundles that are using the PCoIP protocol.

If your zero client device has firmware version 6.0.0 or later, your users can connect to their WorkSpaces directly. When your users are connecting directly to their WorkSpaces using a zero client device, we recommend using multi-factor authentication (MFA) with your WorkSpaces directory. For more information about using MFA with your directory, see the following documentation:
+ **AWS Managed Microsoft AD** — [ Enable multi-factor authentication for AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_mfa.html) in the *AWS Directory Service Administration Guide*
+ **AD Connector** — [ Enable multi-factor authentication for AD Connector](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_mfa.html) in the *AWS Directory Service Administration Guide* and [Multi-factor authentication (AD Connector) for WorkSpaces Personal](connect-mfa.md)
+ **Trusted domains** — [ Enable multi-factor authentication for AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_mfa.html) in the *AWS Directory Service Administration Guide*
+ **Simple AD** — Multi-factor authentication is not available for Simple AD.

As of April 13, 2021, PCoIP Connection Manager is no longer supported for use with zero client device firmware versions between 4.6.0 and 6.0.0. If your zero client firmware is not version 6.0.0 or later, you can get the latest firmware through a Desktop Access subscription at [https://www.teradici.com/desktop-access](https://www.teradici.com/desktop-access).

**Important**  
In the Teradici PCoIP Administrative Web Interface (AWI) or the Teradici PCoIP Management Console (MC), make sure you enable Network Time Protocol (NTP). For the NTP host DNS name, use **pool.ntp.org**, and set the NTP host port to **123**. If NTP isn't enabled, your PCoIP zero client users might receive certificate failure errors, such as "The supplied certificate is invalid due to timestamp."
Starting with version 20.10.4 of the PCoIP agent, Amazon WorkSpaces disables USB redirection by default through the Windows registry. This registry setting affects the behavior of USB peripherals when your users are using PCoIP zero client devices to connect to their WorkSpaces. For more information, see [USB printers and other USB peripherals aren't working for PCoIP zero clients](amazon-workspaces-troubleshooting.md#pcoip_zero_client_usb).

For information about setting up and connecting with a PCoIP zero client device, see [PCoIP Zero Client](https://docs.aws.amazon.com/workspaces/latest/userguide/amazon-workspaces-pcoip-zero-client.html) in the *Amazon WorkSpaces User Guide*. For a list of approved PCoIP zero client devices, see [PCoIP Zero Clients](https://www.teradici.com/resource-center/product-service-finder/pcoip-zero-clients) on the Teradici website.

# Set up Android for Chromebook for WorkSpaces Personal
<a name="set-up-android-chromebook"></a>

Version 2.4.13 is the final release of the Amazon WorkSpaces Chromebook client application. Because [ Google is phasing out support for Chrome Apps](https://blog.chromium.org/2020/01/moving-forward-from-chrome-apps.html), there will be no further updates to the WorkSpaces Chromebook client application, and its use is unsupported.

For [ Chromebooks that support installing Android applications](https://www.chromium.org/chromium-os/chrome-os-systems-supporting-android-apps/), we recommend using the [ WorkSpaces Android client application](https://docs.aws.amazon.com/workspaces/latest/userguide/amazon-workspaces-android-client.html) instead.

Some Chromebooks launched before 2019 must be enabled to [ install Android apps](https://support.google.com/chromebook/answer/7021273) before users can install the Amazon WorkSpaces Android client application. For more information, see [ Chrome OS Systems Supporting Android Apps](https://sites.google.com/a/chromium.org/dev/chromium-os/chrome-os-systems-supporting-android-apps).

To remotely manage enabling your users' Chromebooks to install Android apps, see [Set up Android on Chrome devices](https://support.google.com/chrome/a/topic/9042368).

# Enable and configure WorkSpaces Web Access for WorkSpaces Personal
<a name="web-access"></a>

Most WorkSpaces bundles support Amazon WorkSpaces Web Access. For a list of WorkSpaces that support web browser access, see "Which Amazon WorkSpaces bundles support Web Access?" in [ Client Access, Web Access, and User Experience](https://aws.amazon.com/workspaces/faqs/#Client_Access.2C_Web_Access.2C_and_User_Experience).

**Note**  
As of November 7, 2025, Amazon WorkSpaces PCoIP Web Access is no longer open to new customers. The feature will only receive critical functional and security updates going forward. For more information, see the [Amazon WorkSpaces User Guide](https://docs.aws.amazon.com/workspaces/latest/userguide/amazon-workspaces-web-access.html).
Web Access with DCV for Windows and Ubuntu WorkSpaces is supported in all Regions where DCV WorkSpaces are available. DCV for Amazon Linux WorkSpaces is only available in AWS GovCloud (US-West).
We strongly recommend using Web Access with DCV WorkSpaces for best streaming quality and user experience. The following are limitations when using Web Access with PCoIP WorkSpaces:  
Web Access with PCoIP is not supported in the AWS GovCloud (US) Regions, Asia Pacific (Mumbai), Africa (Cape Town), Europe (Frankfurt), and Israel (Tel Aviv)
Web Access with PCoIP is only supported for Windows WorkSpaces, not with Amazon Linux or Ubuntu WorkSpaces.
Web Access is not available for some Windows 10 WorkSpaces that are using the PCoIP protocol. If your PCoIP WorkSpaces are powered by Windows Server 2019 or 2022, Web Access is not available.
Web Access with PCoIP is limited in feature functionality. It supports video-out, audio-out, keyboard and mouse. It does not support many features, including video-in, audio-in, clipboard redirection, and web cams.
If you are using macOS on VPN and using the Firefox web browser, the web browser will not support streaming PCoIP WorkSpaces using WorkSpaces Web Access. This is due to a limitation in Firefox implementation of the WebRTC protocol.

**Important**  
Beginning October 1, 2020, customers will no longer be able to use the Amazon WorkSpaces Web Access client to connect to Windows 7 custom WorkSpaces or to Windows 7 Bring Your Own License (BYOL) WorkSpaces.

## Step 1: Enable Web Access to your WorkSpaces
<a name="enable-web-access"></a>

You control Web Access to your WorkSpaces at the directory level. For each directory containing WorkSpaces that you want to allow users to access through the Web Access client, do the following steps.

**To enable Web Access to your WorkSpaces**

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose **Directories**.

1. Under the **Directory ID** column, choose the directory ID of the directory you want to enable Web Access for.

1. On the **Directory Details** page, scroll down to the **Other platforms** section and choose **Edit**.

1. Choose **Web Access**.

1. Choose **Save**.

**Note**  
After you enable Web Access, reboot your WorkSpace for the change to apply.

## Step 2: Configure inbound and outbound access to ports for Web Access
<a name="configure_inbound_outbound"></a>

Amazon WorkSpaces Web Access requires inbound and outbound access for certain ports. For more information, see [Ports for Web Access](workspaces-port-requirements.md#web-access-ports).

## Step 3: Configure Group Policy and security policy settings to enable users to log on
<a name="configure_group_policy"></a>

Amazon WorkSpaces relies on a specific logon screen configuration to enable users to successfully log on from their Web Access client.

To enable Web Access users to log on to their WorkSpaces, you must configure a Group Policy setting and three Security Policy settings. If these settings are not correctly configured, users might experience long logon times or black screens when they try to log on to their WorkSpaces. To configure these settings, use the following procedures. 

You can use Group Policy Objects (GPOs) to apply settings to manage Windows WorkSpaces or users that are part of your Windows WorkSpaces directory. We recommend that you create an organizational unit for your WorkSpaces Computer Objects and an organizational unit for your WorkSpaces User Objects.

For information about using the Active Directory administration tools to work with GPOs, see [ Installing the Active Directory Administration Tools](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_install_ad_tools.html) in the *AWS Directory Service Administration Guide*.

**To enable the WorkSpaces logon agent to switch users**

In most cases, when a user attempts to log on to a WorkSpace, the user name field is prepopulated with the name of that user. However, if an administrator has established an RDP connection to the WorkSpace to perform maintenance tasks, the user name field is populated with the name of the administrator instead.

To avoid this issue, disable the **Hide entry points for Fast User Switching** Group Policy setting. When you disable this setting, the WorkSpaces logon agent can use the **Switch User** button to populate the user name field with the correct name.

1. Open the Group Policy Management tool (**gpmc.msc**) and navigate to and select a GPO at the domain or domain controller level of the directory that you use for your WorkSpaces. (If you have the [ WorkSpaces Group Policy administrative template](group_policy.md#gp_install_template) installed in your domain, you can use the WorkSpaces GPO for your WorkSpaces machine accounts.)

1. Choose **Action**, **Edit** in the main menu.

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Policies**, **Administrative Templates**, **System**, and **Logon**. 

1. Open the **Hide entry points for Fast User Switching** setting.

1. In the **Hide entry points for Fast User Switching** dialog box, choose **Disabled**, and then choose **OK**.

By default, the list of last logged on users is displayed instead of the **Switch User** button. Depending on the configuration of the WorkSpace, the list might not display the **Other User** tile. When this situation occurs, if the prepopulated user name isn't correct, the WorkSpaces logon agent can't populate the field with the correct name.

To avoid this issue, enable the Security Policy setting **Interactive logon: Don't display last signed-in** or **Interactive logon: Do not display last user name** (depending on which version of Windows you're using).

**To hide the last logged on user name**

1. Open the Group Policy Management tool (**gpmc.msc**) and navigate to and select a GPO at the domain or domain controller level of the directory that you use for your WorkSpaces. (If you have the [ WorkSpaces Group Policy administrative template](group_policy.md#gp_install_template) installed in your domain, you can use the WorkSpaces GPO for your WorkSpaces machine accounts.)

1. Choose **Action**, **Edit** in the main menu.

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Windows Settings**, **Security Settings**, **Local Policies**, and **Security Options**. 

1. Open one of the following settings:
   + For Windows 7 — **Interactive logon: Don't display last signed-in**
   + For Windows 10 — **Interactive logon: Do not display last user name**

1. In the **Properties** dialog box for the setting, choose **Enabled**, and then choose **OK**.

**To require pressing CTRL\$1ALT\$1DEL before users can log on**

For WorkSpaces Web Access, you need to require that users press CTRL\$1ALT\$1DEL before they can log on. Requiring users to press CTRL\$1ALT\$1DEL before they log on ensures that users are using a trusted path when they're entering their passwords.

1. Open the Group Policy Management tool (**gpmc.msc**) and navigate to and select a GPO at the domain or domain controller level of the directory that you use for your WorkSpaces. (If you have the [ WorkSpaces Group Policy administrative template](group_policy.md#gp_install_template) installed in your domain, you can use the WorkSpaces GPO for your WorkSpaces machine accounts.)

1. Choose **Action**, **Edit** in the main menu.

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Windows Settings**, **Security Settings**, **Local Policies**, and **Security Options**. 

1. Open the **Interactive logon: Do not require CTRL\$1ALT\$1DEL** setting.

1. On the **Local Security Setting** tab, choose **Disabled**, and then choose **OK**.

**To display the domain and user information when the session is locked**

The WorkSpaces logon agent looks for the user's name and domain. After this setting is configured, the lock screen will display the user's full name (if it is specified in Active Directory), their domain name, and their user name.

1. Open the Group Policy Management tool (**gpmc.msc**) and navigate to and select a GPO at the domain or domain controller level of the directory that you use for your WorkSpaces. (If you have the [ WorkSpaces Group Policy administrative template](group_policy.md#gp_install_template) installed in your domain, you can use the WorkSpaces GPO for your WorkSpaces machine accounts.)

1. Choose **Action**, **Edit** in the main menu.

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Windows Settings**, **Security Settings**, **Local Policies**, and **Security Options**. 

1. Open the **Interactive logon: Display user information when the session is locked** setting.

1. On the **Local Security Setting** tab, choose **User display name, domain and user names**, and then choose **OK**.

**To apply the Group Policy and Security Policy settings changes**  
Group Policy and Security Policy settings changes take effect after the next Group Policy update for the WorkSpace and after the WorkSpace session is restarted. To apply the Group Policy and Security Policy changes in the prior procedures, do one of the following:
+ Reboot the WorkSpace (in the Amazon WorkSpaces console, select the WorkSpace, then choose **Actions**, **Reboot WorkSpaces**).
+ From an administrative command prompt, enter **gpupdate /force**.

# Configure WorkSpaces Thin Client
<a name="access-control-awstc"></a>

Most WorkSpaces bundles support Amazon WorkSpaces Thin Client Access. For a list of WorkSpaces that support web browser access, see "Which Amazon WorkSpaces bundles support Thin Client Access?" in [ Client Access, Web Access, and User Experience](https://aws.amazon.com/workspaces/faqs/#Client_Access.2C_Web_Access.2C_and_User_Experience).

## Step 1: Enable Access Control to your Amazon WorkSpaces Thin Client
<a name="enable-access-control-awstc"></a>

You control Thin Client Access to your WorkSpaces at the directory level with user-agent based access control. For each directory containing WorkSpaces that you want to allow users to access through the Thin Client Access client, do the following steps.

**To enable Thin Client Access to your WorkSpaces**

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose **Directories**.

1. Under the **Directory ID** column, choose the directory ID of the directory you want to enable Thin Client Access for.

1. On the **Directory Details** page, scroll down to the **Other platforms** section and choose **Edit**.

1. Select **WorkSpaces Thin Client**.

1. Choose **Save**.

## Step 2: Configure inbound and outbound access to ports for Thin Client Access
<a name="configure_inbound_outbound_awstc"></a>

Amazon WorkSpaces Thin Client Access requires inbound and outbound access for certain ports. For more information, see [Ports for Web Access](workspaces-port-requirements.md#web-access-ports).

## Step 3: Configure Group Policy and security policy settings to enable users to log on
<a name="configure_group_policy-awstc"></a>

Amazon WorkSpaces relies on a specific logon screen configuration to enable users to successfully log on from their Thin Client Access client.

1. To enable Thin Client Access users to log on to their WorkSpaces, you must configure a Group Policy setting and three Security Policy settings. If these settings are not correctly configured, users might experience long logon times or black screens when they try to log on to their WorkSpaces. To configure these settings, use the following procedures. 

1. You can use Group Policy Objects (GPOs) to apply settings to manage Windows WorkSpaces or users that are part of your Windows WorkSpaces directory. We recommend that you create an organizational unit for your WorkSpaces Computer Objects and an organizational unit for your WorkSpaces User Objects.

1. For information about using the Active Directory administration tools to work with GPOs, see [ Installing the Active Directory Administration Tools](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_install_ad_tools.html) in the *AWS Directory Service Administration Guide*.

1. In most cases, when a user attempts to log on to a WorkSpace, the user name field is prepopulated with the name of that user. However, if an administrator has established an RDP connection to the WorkSpace to perform maintenance tasks, the user name field is populated with the name of the administrator instead.

1. To avoid this issue, disable the **Hide entry points for Fast User Switching** Group Policy setting. When you disable this setting, the WorkSpaces logon agent can use the **Switch User** button to populate the user name field with the correct name.

**To enable the WorkSpaces logon agent to switch users**

1. Open the Group Policy Management tool (**gpmc.msc**) and navigate to and select a GPO at the domain or domain controller level of the directory that you use for your WorkSpaces. (If you have the [ WorkSpaces Group Policy administrative template](group_policy.md#gp_install_template) installed in your domain, you can use the WorkSpaces GPO for your WorkSpaces machine accounts.)

1. Choose **Action**, **Edit** in the main menu.

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Policies**, **Administrative Templates**, **System**, and **Logon**. 

1. Open the **Hide entry points for Fast User Switching** setting.

1. In the **Hide entry points for Fast User Switching** dialog box, choose **Disabled**, and then choose **OK**.

By default, the list of last logged on users is displayed instead of the **Switch User** button. Depending on the configuration of the WorkSpace, the list might not display the **Other User** tile. When this situation occurs, if the prepopulated user name isn't correct, the WorkSpaces logon agent can't populate the field with the correct name.

To avoid this issue, enable the Security Policy setting **Interactive logon: Don't display last signed-in** or **Interactive logon: Do not display last user name** (depending on which version of Windows you're using).

**To hide the last logged on user name**

1. Open the Group Policy Management tool (**gpmc.msc**) and navigate to and select a GPO at the domain or domain controller level of the directory that you use for your WorkSpaces. (If you have the [ WorkSpaces Group Policy administrative template](group_policy.md#gp_install_template) installed in your domain, you can use the WorkSpaces GPO for your WorkSpaces machine accounts.)

1. Choose **Action**, **Edit** in the main menu.

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Windows Settings**, **Security Settings**, **Local Policies**, and **Security Options**. 

1. Open one of the following settings:
   + For Windows 7 — **Interactive logon: Don't display last signed-in**
   + For Windows 10 — **Interactive logon: Do not display last user name**

1. In the **Properties** dialog box for the setting, choose **Enabled**, and then choose **OK**.

For WorkSpaces Thin Client Access, you need to require that users press CTRL\$1ALT\$1DEL before they can log on. Requiring users to press CTRL\$1ALT\$1DEL before they log on ensures that users are using a trusted path when they're entering their passwords.

**To require pressing CTRL\$1ALT\$1DEL before users can log on**

1. Open the Group Policy Management tool (**gpmc.msc**) and navigate to and select a GPO at the domain or domain controller level of the directory that you use for your WorkSpaces. (If you have the [ WorkSpaces Group Policy administrative template](group_policy.md#gp_install_template) installed in your domain, you can use the WorkSpaces GPO for your WorkSpaces machine accounts.)

1. Choose **Action**, **Edit** in the main menu.

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Windows Settings**, **Security Settings**, **Local Policies**, and **Security Options**. 

1. Open the **Interactive logon: Do not require CTRL\$1ALT\$1DEL** setting.

1. On the **Local Security Setting** tab, choose **Disabled**, and then choose **OK**.

The WorkSpaces logon agent looks for the user's name and domain. After this setting is configured, the lock screen will display the user's full name (if it is specified in Active Directory), their domain name, and their user name.

**To display the domain and user information when the session is locked**

1. Open the Group Policy Management tool (**gpmc.msc**) and navigate to and select a GPO at the domain or domain controller level of the directory that you use for your WorkSpaces. (If you have the [ WorkSpaces Group Policy administrative template](group_policy.md#gp_install_template) installed in your domain, you can use the WorkSpaces GPO for your WorkSpaces machine accounts.)

1. Choose **Action**, **Edit** in the main menu.

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Windows Settings**, **Security Settings**, **Local Policies**, and **Security Options**. 

1. Open the **Interactive logon: Display user information when the session is locked** setting.

1. On the **Local Security Setting** tab, choose **User display name, domain and user names**, and then choose **OK**.

Group Policy and Security Policy settings changes take effect after the next Group Policy update for the WorkSpace and after the WorkSpace session is restarted. To apply the Group Policy and Security Policy changes in the prior procedures, do one of the following:

**To apply the Group Policy and Security Policy settings changes**

1. Reboot the WorkSpace (in the Amazon WorkSpaces console, select the WorkSpace, then choose **Actions**, **Reboot WorkSpaces**).

1. From an administrative command prompt, enter **gpupdate /force**.

# Configure FedRAMP authorization or DoD SRG compliance for WorkSpaces Personal
<a name="fips-encryption"></a>

To comply with the [Federal Risk and Authorization Management Program (FedRAMP)](https://aws.amazon.com/compliance/fedramp/) or the [Department of Defense (DoD) Cloud Computing Security Requirements Guide (SRG)](https://aws.amazon.com/compliance/dod/), you must configure Amazon WorkSpaces to use Federal Information Processing Standards (FIPS) endpoint encryption at the directory level. You must also use a US AWS Region that has FedRAMP authorization or is DoD SRG compliant.

The level of FedRAMP authorization (Moderate or High) or DoD SRG Impact Level (2, 4, or 5) depends on the US AWS Region in which Amazon WorkSpaces is being used.

For the levels of FedRAMP authorization and DoD SRG compliance that apply to each Region, see [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/).

**Note**  
In addition to using FIPS endpoint encryption, you can also encrypt your WorkSpaces. For more information, see [Encrypted WorkSpaces in WorkSpaces Personal](encrypt-workspaces.md).

**Requirements**
+ You must create your WorkSpaces in a [US AWS Region that has FedRAMP authorization or is DoD SRG-compliant](https://aws.amazon.com/compliance/services-in-scope/).
+ The WorkSpaces directory must be configured to use **FIPS 140-2 Validated Mode** for endpoint encryption.
**Note**  
To use the **FIPS 140-2 Validated Mode** setting, the WorkSpaces directory must either be new, or all existing WorkSpaces in the directory must be using **FIPS 140-2 Validated Mode** for endpoint encryption. Otherwise, you cannot use this setting, and therefore the WorkSpaces that you create will not comply with FedRAMP or DoD security requirements.  
Refer to [step 3](#step3-fips) below for details on how to verify the directory.
+ Users must access their WorkSpaces from one of the following WorkSpaces client applications:
  + Windows: 2.4.3 or later
  + macOS: 2.4.3 or later for PCoIP WorkSpaces, and 5.21.0 or later for DCV WorkSpaces
  + Linux: 3.0.0 or later
  + iOS: 2.4.1 or later
  + Android: 2.4.1 or later
  + Fire Tablet: 2.4.1 or later
  + ChromeOS: 2.4.1 or later
  + Web Access

**To use FIPS endpoint encryption**

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose **Directories**.

1. Verify that the directory where you want to create FedRAMP-authorized and DoD SRG-compliant WorkSpaces does not have any existing WorkSpaces associated with it. If there are WorkSpaces associated with the directory and the directory is not already enabled to use FIPS 140-2 Validated Mode, either terminate the WorkSpaces or create a new directory.

1. Choose the directory that meets the above criteria, and then choose **Actions**, **Update Details**.

1. <a name="step3-fips"></a>On the **Update Directory Details** page, choose the arrow to expand the **Access Control Options** section.

1. For **Endpoint Encryption**, choose **FIPS 140-2 Validated Mode** instead of **TLS Encryption Mode (Standard)**.

1. Choose **Update and Exit**.

1. You can now create WorkSpaces from this directory that are FedRAMP authorized and DoD SRG compliant. To access these WorkSpaces, users must use one of the WorkSpaces client applications listed earlier in the [Requirements](#fedramp-requirements) section.

# Enable SSH connections for your Linux WorkSpaces in WorkSpaces Personal
<a name="connect-to-linux-workspaces-with-ssh"></a>

If you or your users want to connect to your Linux WorkSpaces by using the command line, you can enable SSH connections. You can enable SSH connections to all WorkSpaces in a directory or to individual WorkSpaces in a directory. 

To enable SSH connections, you create a new security group or update an existing security group and add a rule to allow inbound traffic for this purpose. Security groups act as a firewall for associated instances, controlling both inbound and outbound traffic at the instance level. After you create or update your security group, your users and others can use PuTTY or other terminals to connect from their devices to your Linux WorkSpaces. For more information, see [Security groups for WorkSpaces Personal](amazon-workspaces-security-groups.md).

For a video tutorial, see [ How can I connect to my Linux Amazon WorkSpaces using SSH?](https://aws.amazon.com/premiumsupport/knowledge-center/linux-workspace-ssh/) on the AWS Knowledge Center. This tutorial is for Amazon Linux 2 WorkSpaces only.

**Topics**
+ [Prerequisites for SSH connections to Linux WorkSpaces](#before-you-begin-enable-ssh-linux-workspaces)
+ [Enable SSH connections to all Linux WorkSpaces in a directory](#enable-ssh-directory-level-access-linux-workspaces)
+ [Password-based authentication in WorkSpaces](#enable-ssh-access-old-version)
+ [Enable SSH connections to a specific Linux WorkSpace](#enable-ssh-access-specific-linux-workspace)
+ [Connect to a Linux WorkSpace using Linux or PuTTY](#ssh-connection-linux-workspace-using-linux-or-putty)

## Prerequisites for SSH connections to Linux WorkSpaces
<a name="before-you-begin-enable-ssh-linux-workspaces"></a>
+ Enabling inbound SSH traffic to a WorkSpace — To add a rule to allow inbound SSH traffic to one or more Linux WorkSpaces, make sure that you have the public or private IP addresses of the devices that require SSH connections to your WorkSpaces. For example, you can specify the public IP addresses of devices outside your virtual private cloud (VPC) or the private IP address of another EC2 instance in the same VPC as your WorkSpace. 

  If you plan to connect to a WorkSpace from your local device, you can use the search phrase "what is my IP address" in an internet browser or use the following service: [Check IP](https://checkip.amazonaws.com/). 
+ Connecting to a WorkSpace — The following information is required to initiate an SSH connection from a device to a Linux WorkSpace.
  + The NetBIOS name of the Active Directory domain that you are connected to.
  + Your WorkSpace user name.
  + The public or private IP address of the WorkSpace that you want to connect to.

    Private: If your VPC is attached to a corporate network and you have access to that network, you can specify the private IP address of the WorkSpace.

    Public: If your WorkSpace has a public IP address, you can use the WorkSpaces console to find the public IP address, as described in the following procedure.

**To find the IP addresses for the Linux WorkSpace you want to connect to and your user name**

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose **WorkSpaces**.

1. In the list of WorkSpaces, choose the WorkSpace that you want to enable SSH connections to.

1. In the **Running mode** column, confirm that the WorkSpace status is **Available**.

1. Click the arrow to the left of the WorkSpace name to display the inline summary, and note the following information:
   + The **WorkSpace IP**. This is the private IP address of the WorkSpace.

     The private IP address is required for obtaining the elastic network interface associated with the WorkSpace. The network interface is required to retrieve information such as the security group or public IP address associated with the WorkSpace.
   + The WorkSpace **Username**. This is the user name that you specify to connect to the WorkSpace.

1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. In the navigation pane, choose **Network Interfaces**.

1. In the search box, type the **WorkSpace IP** that you noted in Step 5. 

1. Select the network interface associated with the **WorkSpace IP**. 

1. If your WorkSpace has a public IP address, it is displayed in the **IPv4 Public IP** column. Make a note of this address, if applicable.

**To find the NetBIOS name of the Active Directory domain that you are connected to**

1. Open the Directory Service console at [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/).

1. In the list of directories, click the **Directory ID** link of the directory for the WorkSpace.

1. In the **Directory details** section, note the **Directory NetBIOS name**.

## Enable SSH connections to all Linux WorkSpaces in a directory
<a name="enable-ssh-directory-level-access-linux-workspaces"></a>

To enable SSH connections to all Linux WorkSpaces in a directory, do the following.

**To create a security group with a rule to allow inbound SSH traffic to all Linux WorkSpaces in a directory**

1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. In the navigation pane, choose **Security Groups**.

1. Choose **Create Security Group**.

1. Type a name and optionally, a description for your security group.

1. For **VPC**, choose the VPC that contains the WorkSpaces that you want to enable SSH connections to.

1. On the **Inbound **tab, choose **Add Rule**, and do the following:
   + For **Type**, choose **SSH**.
   + For **Protocol**, TCP is automatically specified when you choose **SSH**.
   + For **Port Range**, 22 is automatically specified when you choose **SSH**.
   + For **Source**, specify the CIDR range of the public IP addresses for the computers that users will use to connect to their WorkSpaces. For example, a corporate network or a home network.
   + For **Description** (optional), type a description for the rule.

1. Choose **Create**.

1. Attach this security group to your WorkSpaces. For more information on adding this security group to your WorkSpaces, see [Security groups for WorkSpaces Personal](amazon-workspaces-security-groups.md). If you want to automatically attach additional security groups to your WorkSpaces, refer to this [ blog post](https://aws.amazon.com/blogs/desktop-and-application-streaming/automatically-attach-additional-security-groups-to-amazon-appstream-2-0-and-amazon-workspaces/).

## Password-based authentication in WorkSpaces
<a name="enable-ssh-access-old-version"></a>

**To enable password authentication in newly created Linux WorkSpaces**

1. Launch the WorkSpaces client and login to your WorkSpace.

1. Open the Terminal window.

1. In the Terminal window, run the following command to enable SSH Password Authentication in cloud-init.

   ```
   sudo bash -c 'touch /etc/cloud/cloud.cfg.d/15_sshpwauth.cfg && echo "ssh_pwauth: true" > /etc/cloud/cloud.cfg.d/15_sshpwauth.cfg && sudo rm /var/lib/cloud/instance/sem/config_set_passwords && sudo cloud-init single --name set-passwords'
   ```

   This script will do the following:
   + Create a configuration file in the cloud-init directory `/etc/cloud/cloud.cfg.d/`.
   + Modify the configuration file to tell cloud-init to enable SSH password authentication.
   + Reset the `set-passwords` cloud-init module so that it can be run again.
   + Run the `set-passwords` cloud-init module by itself. This will write a file that enables SSH password authentication to the SSH configuration directory, `/etc/ssh/sshd_config.d/`, and restart SSHD so that the setting will take place immediately.

 This enables SSH password authentication on your WorkSpace and will persist through custom images. If you enable SSH password authentication only in the SSHD configuration file, without configuring cloud-init, the setting will not persist through imaging on some Linux WorkSpaces. For more information, see [Set Passwords]() in the cloud-init module documentation.

**To disable password authentication in existing Linux WorkSpaces**

1. Launch the WorkSpaces client and login to your WorkSpace.

1. Open the Terminal window.

1. In the Terminal window, run the following command to disable SSH Password Authentication in cloud-init.

   ```
   sudo bash -c 'touch /etc/cloud/cloud.cfg.d/15_sshpwauth.cfg && echo "ssh_pwauth: false" > /etc/cloud/cloud.cfg.d/15_sshpwauth.cfg && sudo rm /var/lib/cloud/instance/sem/config_set_passwords && sudo cloud-init single —name set-passwords'
   ```

   This script will do the following:
   + Create a configuration file in the cloud-init directory `/etc/cloud/cloud.cfg.d/`.
   + Modify the configuration file to tell cloud-init to disable SSH password authentication.
   + Reset the `set-passwords` cloud-init module so that it can be run again.
   + Run the `set-passwords` cloud-init module by itself. This will write a file that enables SSH password authentication to the SSH configuration directory, `/etc/ssh/sshd_config.d/`, and restart SSHD so that the setting will take place immediately.

This immediately disables SSH in the WorkSpace and will persist through custom images.

## Enable SSH connections to a specific Linux WorkSpace
<a name="enable-ssh-access-specific-linux-workspace"></a>

To enable SSH connections to a specific Linux WorkSpace, do the following.

**To add a rule to an existing security group to allow inbound SSH traffic to a specific Linux WorkSpace**

1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. In the navigation pane, under **Network & Security**, choose **Network Interfaces**.

1. In the search bar, type the private IP address of the WorkSpace that you want to enable SSH connections to.

1. In the **Security groups** column, click the link for the security group.

1. On the **Inbound **tab, choose **Edit**.

1. Choose** Add Rule**, and then do the following:
   + For **Type**, choose **SSH**.
   + For **Protocol**, TCP is automatically specified when you choose **SSH**.
   + For **Port Range**, 22 is automatically specified when you choose **SSH**.
   + For **Source**, choose **My IP** or **Custom**, and specify a single IP address or an IP address range in CIDR notation. For example, if your IPv4 address is `203.0.113.25`, specify `203.0.113.25/32` to list this single IPv4 address in CIDR notation. If your company allocates addresses from a range, specify the entire range, such as `203.0.113.0/24`.
   + For **Description** (optional), type a description for the rule.

1. Choose **Save**.

## Connect to a Linux WorkSpace using Linux or PuTTY
<a name="ssh-connection-linux-workspace-using-linux-or-putty"></a>

After you create or update your security group and add the required rule, your users and others can use Linux or PuTTY to connect from their devices to your WorkSpaces. 

**Note**  
Before completing either of the following procedures, make sure that you have the following:  
The NetBIOS name of the Active Directory domain that you are connected to.
The username that you use to connect to the WorkSpace.
The public or private IP address of the WorkSpace that you want to connect to.
For instructions on how to obtain this information, see "Prerequisites for SSH Connections to Linux WorkSpaces" earlier in this topic.

**To connect to an Linux WorkSpace using Linux**

1. Open the command prompt as an administrator and enter the following command. For *NetBIOS name*, *Username*, and *WorkSpace IP*, enter the applicable values. 

   ```
   ssh "NetBIOS_NAME\Username"@WorkSpaceIP
   ```

   The following is an example of the SSH command where:
   + The *NetBIOS\$1NAME* is anycompany
   + The *Username *is janedoe
   + The *WorkSpace IP* is 203.0.113.25

   ```
   ssh "anycompany\janedoe"@203.0.113.25
   ```

1. When prompted, enter the same password that you use when authenticating with the WorkSpaces client (your Active Directory password).

**To connect to an Linux WorkSpace using PuTTY**

1. Open PuTTY.

1. In the **PuTTY Configuration** dialog box, do the following:
   + For **Host Name (or IP address)**, enter the following command. Replace the values with the NetBIOS name of the Active Directory domain that you are connected to, the user name that you use to connect to the WorkSpace, and the IP address of the WorkSpace that you want to connect to.

     ```
     NetBIOS_NAME\Username@WorkSpaceIP
     ```
   + For **Port**, enter **22**.
   + For **Connection type**, choose **SSH**.

   For an example of the SSH command, see step 1 in the previous procedure.

1.  Choose **Open**.

1. When prompted, enter the same password that you use when authenticating with the WorkSpaces client (your Active Directory password).

# Required configuration and service components for WorkSpaces Personal
<a name="required-service-components"></a>

As a WorkSpace administrator, you must understand the following about required configuration and service components.
+ [Required routing table configuration](#routing-table-configuration)
+ [Required service components for Windows](#required-service-components-windows)
+ [Required service components for Linux](#required-service-components-linux)
+ [Required service components for Ubuntu](#required-service-components-ubuntu)
+ [Required service components for Rocky Linux](#required-service-components-rocky)
+ [Required service components for Red Hat Enterprise Linux](#required-service-components-red-hat)

## Required routing table configuration
<a name="routing-table-configuration"></a>

We recommend that you not modify the operating system-level routing table for a WorkSpace. The WorkSpaces service requires the preconfigured routes in this table to monitor the system state and update system components. If routing table changes are required for your organization, contact AWS Support or your AWS account team before applying any changes. 

## Required service components for Windows
<a name="required-service-components-windows"></a>

On Windows WorkSpaces, the service components are installed in the following locations. Do not delete, change, block, or quarantine these objects. If you do so, the WorkSpace will not function correctly.

If antivirus software is installed on the WorkSpace, make sure it does not interfere with the service components installed in the following locations.
+ `C:\Program Files\Amazon`
+ `C:\Program Files\NICE`
+ `C:\Program Files\Teradici`
+ `C:\Program Files (x86)\Teradici`
+ `C:\ProgramData\Amazon`
+ `C:\ProgramData\NICE`
+ `C:\ProgramData\Teradici`

If antivirus software is installed on the WorkSpaces Core, make sure it does not interfere with the service components installed in the following locations.
+ C:\$1Program Files\$1Amazon
+ C:\$1ProgramData\$1Amazon

### 32-bit PCoIP agent
<a name="pcoip-agent-32-bit-to-64-bit"></a>

As of March 29, 2021, we updated the PCoIP agent from 32-bit to 64-bit. For Windows WorkSpaces that are using the PCoIP protocol, this means that the location of the Teradici files changed from `C:\Program Files (x86)\Teradici` to `C:\Program Files\Teradici`. Because we updated PCoIP agents during regular maintenance windows, some of your WorkSpaces might have used the 32-bit agent longer than others during the transition.

If you've configured firewall rules, antivirus software exclusions (on the client side and host side), Group Policy Object (GPO) settings, or settings for Microsoft System Center Configuration Manager (SCCM), Microsoft Endpoint Configuration Manager, or similar configuration management tools based on the full path to the 32-bit agent, you must also add the full path to the 64-bit agent to those settings.

**If you're filtering on the paths to any 32-bit PCoIP components, be sure to add the paths to the 64-bit versions of the components. Because your WorkSpaces might not all be updated at the same time, do not replace the 32-bit path with the 64-bit path, or some of your WorkSpaces might not work.** For example, if you're basing your exclusions or communication filters on `C:\Program Files (x86)\Teradici\PCoIP Agent\bin\pcoip_server_win32.exe`, you must also add `C:\Program Files\Teradici\PCoIP Agent\bin\pcoip_server.exe`. Likewise, if you're basing your exclusions or communications filters on `C:\Program Files (x86)\Teradici\PCoIP Agent\bin\pcoip_agent.exe`, you must also add `C:\Program Files\Teradici\PCoIP Agent\bin\pcoip_agent.exe`.

**PCoIP arbiter service change** — Be aware that the PCoIP arbiter service (`C:\Program Files (x86)\Teradici\PCoIP Agent\bin\pcoip_arbiter_win32.exe`) is removed when your WorkSpaces are updated to use the 64-bit agent.

**PCoIP zero clients and USB devices** — Starting with version 20.10.4 of the PCoIP agent, Amazon WorkSpaces disables USB redirection by default through the Windows registry. This registry setting affects the behavior of USB peripherals when your users are using PCoIP zero client devices to connect to their WorkSpaces. For more information, see [USB printers and other USB peripherals aren't working for PCoIP zero clients](amazon-workspaces-troubleshooting.md#pcoip_zero_client_usb).

## Required service components for Linux
<a name="required-service-components-linux"></a>

On Amazon Linux WorkSpaces, the service components are installed in the following locations. Do not delete, change, block, or quarantine these objects. If you do so, the WorkSpace will not function correctly.

**Note**  
Making changes to files other than `/etc/pcoip-agent/pcoip-agent.conf` might cause your WorkSpaces to stop working and might require you to rebuild them. For information about modifying `/etc/pcoip-agent/pcoip-agent.conf`, see [Manage your Amazon Linux 2 WorkSpaces in WorkSpaces Personal](manage_linux_workspace.md).
+ `/etc/dhcp/dhclient.conf`
+ `/etc/logrotate.d/pcoip-agent`
+ `/etc/logrotate.d/pcoip-server`
+ `/etc/os-release`
+ `/etc/pam.d/pcoip`
+ `/etc/pam.d/pcoip-session`
+ `/etc/pcoip-agent`
+ `/etc/profile.d/system-restart-check.sh`
+ `/etc/X11/default-display-manager`
+ `/etc/yum/pluginconf.d/halt_os_update_check.conf`
+ `/etc/systemd/system/euc-analytic-agent.service`
+ `/lib/systemd/system/pcoip.service`
+ `/lib/systemd/system/pcoip-agent.service`
+ `/lib64/security/pam_self.so`
+ `/usr/bin/pcoip-fne-view-license`
+ `/usr/bin/pcoip-list-licenses`
+ `/usr/bin/pcoip-validate-license`
+ `/usr/bin/euc-analytics-agent`
+ `/usr/lib/firewalld/services/pcoip-agent.xml`
+ `/usr/lib/modules-load.d/usb-vhci.conf`
+ `/usr/lib/pcoip-agent`
+ `/usr/lib/skylight`
+ `/usr/lib/systemd/system/pcoip.service`
+ `/usr/lib/systemd/system/pcoip.service.d/`
+ `/usr/lib/systemd/system/skylight-agent.service`
+ `/usr/lib/tmpfiles.d/pcoip-agent.conf`
+ `/usr/lib/yum-plugins/halt_os_update_check.py`
+ `/usr/sbin/pcoip-agent`
+ `/usr/sbin/pcoip-register-host`
+ `/usr/sbin/pcoip-support-bundler`
+ `/usr/share/doc/pcoip-agent`
+ `/usr/share/pcoip-agent`
+ `/usr/share/selinux/packages/pcoip-agent.pp`
+ `/usr/share/X11`
+ `/var/crash/pcoip-agent`
+ `/var/lib/pcoip-agent`
+ `/var/lib/skylight`
+ `/var/log/pcoip-agent` 
+ `/var/log/skylight`
+ `/var/logs/wsp`
+ `/var/log/eucanalytics` 

## Required service components for Ubuntu
<a name="required-service-components-ubuntu"></a>

On Ubuntu WorkSpaces, the service components are installed in the following locations. Do not delete, change, block, or quarantine these objects. If you do so, the WorkSpace will not function correctly.
+ `/etc/X11/default-display-manager`
+ `/etc/dcv`
+ `/etc/default/grub.d/zz-hibernation.cfg`
+ `/etc/netplan`
+ `/etc/os-release`
+ `/etc/pam.d/dcv`
+ `/etc/pam.d/dcv-graphical-sso`
+ `/etc/sssd/sssd.conf`
+ `/etc/wsp`
+ `/etc/systemd/system/euc-analytic-agent.service` 
+ `/lib64/security/pam_self.so`
+ `/usr/lib/skylight`
+ `/usr/lib/systemd/system/dcvserver.service`
+ `/usr/lib/systemd/system/dcvsessionlauncher.service`
+ `/usr/lib/systemd/system/skylight-agent.service`
+ `/usr/lib/systemd/system/wspdcvhostadapter.service`
+ `/usr/share/X11`
+ `/usr/bin/euc-analytics-agent`
+ `/var/lib/skylight`
+ `/var/log/skylight`
+ `/var/log/eucanalytics` 

## Required service components for Rocky Linux
<a name="required-service-components-rocky"></a>

On Red Hat Enterprise Linux WorkSpaces, the service components are installed in the following locations. Do not delete, change, block, or quarantine these objects. If you do so, the WorkSpace will not function correctly.
+ `/etc/dcv`
+ `/etc/os-release`
+ `/etc/pam.d/dcv-graphical-sso`
+ `/etc/pam.d/dcv`
+ `/etc/systemd/system/euc-analytic-agent.service`
+ `/etc/wsp`
+ `/usr/bin/euc-analytics-agent`
+ `/usr/lib/skylight`
+ `/usr/lib/systemd/system/dcvserver.service`
+ `/usr/lib/systemd/system/dcvsessionlauncher.service`
+ `/usr/lib/systemd/system/skylight-agent.service`
+ `/usr/lib/systemd/system/wspdcvhostadapter.service`
+ `/usr/lib/systemd/system/xdcv-console.path`
+ `/usr/lib/systemd/system/xdcv-console.service`
+ `/usr/lib/systemd/system/xdcv-console-update.service`
+ `/usr/share/X11`
+ `/var/lib/skylight`
+ `/var/log/eucanalytics`
+ `/var/log/skylight`

## Required service components for Red Hat Enterprise Linux
<a name="required-service-components-red-hat"></a>

On Red Hat Enterprise Linux WorkSpaces, the service components are installed in the following locations. Do not delete, change, block, or quarantine these objects. If you do so, the WorkSpace will not function correctly.
+ `/etc/dcv`
+ `/etc/os-release`
+ `/etc/pam.d/dcv-graphical-sso`
+ `/etc/pam.d/dcv`
+ `/etc/systemd/system/euc-analytic-agent.service`
+ `/etc/wsp`
+ `/usr/bin/euc-analytics-agent`
+ `/usr/lib/skylight`
+ `/usr/lib/systemd/system/dcvserver.service`
+ `/usr/lib/systemd/system/dcvsessionlauncher.service`
+ `/usr/lib/systemd/system/skylight-agent.service`
+ `/usr/lib/systemd/system/wspdcvhostadapter.service`
+ `/usr/lib/systemd/system/xdcv-console.path`
+ `/usr/lib/systemd/system/xdcv-console.service`
+ `/usr/lib/systemd/system/xdcv-console-update.service`
+ `/usr/share/X11`
+ `/var/log/eucanalytics`
+ `/var/log/skylight`