Amazon Workspace App

Overview

AWS Workspaces (AWSW) supports RADIUS for MFA authentication.

The Amazon Workspace app allows use of the Okta RADIUS agent for multi-factor authentication on Amazon Workspaces. End-users can sign into Amazon Workspaces using factors registered with Okta. This integration shows how to configure AWS Workspaces using Active Directory to support authentication using Okta MFA and Okta Verify Push..

Amazon Workspaces and Okta MFA over RADIUS architecture
Amazon Workspace and Okta MFA over RADIUS architecture

Prerequisites

  • Amazon Web Services instances, configured as:
    • Instance A - represents the Amazon Directory Service virtual machine instance.
    • Instance B - represents the Windows 2012r2 host where the Okta RADIUS agent will be installed.
      The AWS Directory Service will require the private IP address of Instance B to delegate the MFA challenge over RADIUS..
  • AWS Directory Service instance, configured and pointing to Instance A, running Active Directory.
    Note: You must have the Directory ID of the AWS Directory Service. The Directory ID is used to determine the name of the Security Group.

Note: The AWS Directory service will require the private IP address of Instance B to delegate the MFA challenge over RADIUS. If that private IP changes the AWS Directory MFA configuration must be updated to reflect the new private IP.

The following steps prepare an existing EC2 instance for use with Active Directory, create an AWS Directory service as a connector that points to Active Directory, and launches an associated workspace.

  1. In your browser, navigate to Amazon Web Services console and login as an administrator.

  2. Select Services > EC2.

  3. In the left pane select INSTANCES > Instances.

  4. Locate the Active Directory instance (referred to as Instance A), and select it.

  5. In the Description tab, Note the Private IP address of the instance.

  6. In the lower right, click the VPC ID value.

  7. In the associated VPC page, note the IPv4 CIDR value.

  8. Navigate to NETWORK & SECURITY > Security Groups.

  9. Open the Instance A security group and click Add to add inbound rules to enable UDP/TCP for ports 53, 88. and 389 against the IPv4 CIDR.

  1. Return to the Services tab of the AWS Console.

  2. Enter Directory Service into the search bar and click Directory Service.

  3. Click Set up directory.

  4. Select AD Connector as Directory type and click Next.

  5. Choose an appropriate size and click Next.

  6. Choose the Instance A VPC, subsets if reuqired, and choose Next.

  7. In the Active Directory information step enter:

    Field Value
    Connected Directory DNS Required: Your domain.
    For example: biz.nicopowered.com
    Connected NetBIOS Name Option. Anything appropriate.
    For example: biz.
    DNS Address The private IP address of instance A, previously captured.
    Service Account username Username of the active directory account previously created.
    Service Account password Associated password.

    Click Next when complete.

  8. Review the values and click Create directory.
    When complete the connector should resemble:

  1. Navigate to Workspaces.

  2. If required,create a workspace, otherwise select a workspace and click Launch Workspaces.

  3. From the Directory dropdown list select a directory to authenticate against and click Next Step.

  4. Select an appropriate user from the directory service and click Add Selected.

  5. Select a bundle, review your configure and .click Launch Workspace.

The Amazon Workspace is now ready for use.

The RADIUS Agent must be installed and configured on Instance B.

Installation notes:

Shared Secret During the install of the RADIUS agent you will be required to enter a shared secret. The shared secret value will be required later in the procedure.
Port The RADIUS agent requires a port. Any available port can be used. For the remainder of this procedure the value: 1899 will be used.

Caution

Caution

When installing the RADIUS Agent you must be logged in to an account which has all three of Read-only Admin, Mobile Admin, and App admin roles, or Super admin role.
In addition, Okta recommends the use of dedicated service account to authorize RADIUS agents. A dedicated account ensures that the API token used by the RADIUS agent is not tied to the life-cycle of a specific user account which could be deactivated when the user is deactivated. In addition, service accounts used for RADIUS agents must be given appropriate admin permissions.

Please refer to the Administrators permission table (MFA section) for specific permissions required.

  1. From your Administrator Dashboard, select Settings > Downloads > Okta RADIUS Server Agent.

  2. Click the Download button and run the Okta RADIUS installer.

  3. Proceed through the installation wizard to the "Important Information" and "License Information" screens.

  4. Choose the Installation folder and click the Install button.

  5. On the Okta RADIUS Agent Configuration screen, enter your RADIUS Shared Secret key and RADIUS Port number. If you are using the RADIUS application, these elements are not required.

    Info

    Note

    As of EA version 2.9.6 EA RADIUS Shared Secret and Port are not required. When installing the RADIUS Agent v2.9.6 EA or later these screens will be not be displayed.

    Info

    Note

    Avoid the use of special characters when entering the shared secret. Certain special characters can cause the installation to fail with Error Code: 3.

  6. On the Okta RADIUS Agent Proxy Configuration screen, you can optionally enter your proxy information. Click the Next button.

  7. On the Register Okta RADIUS Agent screen, enter the following: Choose your org version.

  8. If setting this up to test on your Okta Preview Sandbox org, you'll need to enter the complete URL for your org. For example: https://mycompany.oktapreview.com

    • Enter Subdomain – For example, if you access Okta using https://mycompany.okta.com, enter "mycompany", as described below.
      • Production - Select Production and enter a production domain.
        For example: mycompany.okta.com.
      • Preview- Select preview and enter a preview domain.
        For example: mycompany.oktapreview.com.
      • Custom- Select custom and enter a custom domain.
        For example: mycompany.mydomain.com[:port].

  9. For Windows Server 2008 R2 Core only: Open a browser and add the provided URL into the address field. This authorizes the installer to use Okta.

  10. Click the Next button to continue on to an Okta Sign In page.
  11. Sign into the service specific Okta account on the Sign In screen.
  12. Click the Allow Access button.

    13. Radius_7.jpg

  13. The confirmation screen appears. Click the Finish button to complete the installation.
    Info

    Note

    If during the agent installation you encounter Error code 12: Could not establish trust relationship for the SSL/TLS service channel, ensure that you are running the latest version of the agent as older agent versions do not support TLS 1.2.

  14. Configure a RADIUS app in Okta to configure the RADIUS agent port, shared secret, and advanced RADIUS settings .
    For more information about configuring the RADIUS App in your okta tenant please see RADIUS applications in Okta

Additional Property Configurations

You can override the defaults on the following properties, if desired.

Important Note

Important

Changes to the RADIUS Agent config.properties are only loaded on agent restart.
Always restart your agent after changing config.properties.

  1. Open the folder where the Okta RADIUS agent resides. The default installation folder is C:\Program Files (x86)\Okta\Okta RADIUS Agent\.
  2. From this folder, navigate to current\user\config\radius\config.properties. Before making changes, we recommend creating a back up of this file. Using a text application such a Notepad, open the file current\user\config\radius\config.properties residing in the Okta RADIUS agent installation folder.
  3. Configure any of the properties shown below, as required.
  4. When done, save the file.
  5. Any changes are effective after restarting the Okta RADIUS Agent service using the available Windows administrative tools.
Property Description Default
ragent.num_max_http_connection The maximum number of HTTP connections in the connection pool. 20
ragent.num_request_threads The number of authentication worker threads available for processing requests. 15
ragent.total.request.timeout.millisecond

The maximum time the RADIUS agent is allowed to process a UDP packet after it has arrived from the RADIUS client.

 

For the Okta Verify with Push factor the actual value is interpreted by the RADIUS agent as one half (1/2) of the configured value.
For example: 60000 =60 seconds, divided in half =30 seconds.

For all other factors the value is used as specified.


60000
ragent.request.timeout.millisecond The maximum time the RADIUS agent is allowed to process a UDP packet after it has arrived from the RADIUS client.

If specified, ragent.total.request.timeout.millisecond is ignored.
If not specified, default is to use ragent.total.request.timeout.millisecond.

Available since version 2.9.4.		 N/A defaults to value specified by ragent.total.request.timeout.millisecond
ragent.okta.request.max.timeout.millisecond

The socket timeout to set on the Okta API request. This property only applies if configured; otherwise, it is computed dynamically based on the total request timeout setting.

 Dynamic, based on remaining TTL for request
ragent.request.timeout.response.mode

The timeout response mode. Possible values include:

  • SEND_REJECT_ALWAYS - agent sends a reject message to the client after any timeout..
  • SEND_REJECT_ON_POLL_MFA- agent sends a reject message to the client if a timeout occurs during the MFA polling loop only (i.e. while the agent is polling Okta to determine if the user has correctly responded to an MFA challenge such as a push notification). If a timeout occurs at any other time, no response will be sent to the client.
  • NO_RESPONSE - no response will be sent to the client when the agent times out.
 SEND_REJECT_ON_POLL_MFA
ragent.mfa.timeout.seconds Time, in seconds, that the agent will wait for the client to respond to an MFA challenge such as factor selection. 60
Important Note

Important

When using the RADIUS agent with a VPN such as Cisco ASA VPN the following timeout values should be configured on both RADIUS Agent and VPN settings:

RADIUS agent v2.9.3 and earlier with out Okta Verify Push. ragent.total.request.timeout.millisecond = VPN retry count * (VPN timeout + VPN wait between retries) - VPN wait between retries

 
RADIUS agent v2.9.3 with Okta Verify Push. ragent.total.request.timeout.millisecond = 2 * (VPN retry count * (VPN timeout + VPN wait between retries) - VPN wait between retries)

 
RADIUS agent v 2.9.4 and later. ragent.request.timeout.millisecond = VPN retry count * (VPN timeout + VPN wait between retries) - VPN wait between retries

Note:

  • VPN retry count should be between 3-5.
  • VPN request timeout should be 15-60s, (60-120s when using Okta Verify Push).

For example, where:

  • VPN retry = 5x
  • VPN request timeout = 60s
  • VPN wait between retry = 5s

Then, VPN authentication timeout = 5 * (60 + 5) + 5 = 320s, or 320000ms
RADIUS agent v2.9.3 and earlier with Okta Verify Push: ragent.total.request.timeout.millisecond = 320000.

RADIUS agent v 2.9.4 and later: ragent.request.timeout.millisecond =320000.

The following properties apply to proxy configuration only.

Property Description Default
ragent.proxy.enabled Indicates that the RADIUS agent should use a proxy. Must be set to true.
Example: ragent.proxy.enabled = true. 		Default: Not present must be added to config.properties.
ragent.proxy.address The IP address and port( if required) of the proxy. If ragent.proxy.enabled is set to true this property must exist.
Example: ragent.proxy.address = 127.0.0.1:8888

Default: Not present must be added to config.properties.
ragent.ssl.pinning If the proxy terminates the SSL connection, then SSL pinning must be disabled.
Example:
ragent.ssl.pinning = false		 Default: true.
ragent.proxy.user
ragent.proxy.password 		Proxy credentials, if required.
Encrypted on agent restart.
ragent.proxy.user = admin
ragent.proxy.password = password		 Default: Not present must be added to config.properties.

For a complete list of all steps as well as detained steps for installing the Okta RADIUS agent see:

Instance B must be able to communicate with the AWS Directory Service. Inbound rules are used to configure the required ports/protocol to grant the required access.

  1. In your browser, navigate to your AWS Workspace and login as an administrator.

  2. In a browser Navigate to the AWS Workspace.

  3. Select the Directories tab.

  4. In the Details section for the selected directory note the Directory ID
    . .

  5. Navigate to the security groups page and determine the group ID for the associated group name.

  6. Using the Group ID, navigate to the security group.

  7. Create an inbound rule with values:

    FieldValue
    ProtocolUDP
    Port Range1899

    When complete the new inbound rule will resemble:

    8. Note: You may be required to create a Windows firewall rule to allow UDP traffic on the required port.

  1. In your browser, Navigate to your Okta Org and Login as an Administrator.

  2. From Applications menu, choose Applications.

  3. On the Applications page, click Add Application.

  4. In the left-side search field, enter the keyword Amazon Workspaces.

  5. From the resulting list, choose Amazon Workspace by clicking the Add button.

  1. In the Sign-On Options page enter:

    OptionValue
    Authentication check boxEnsure that Okta performs primary authentication remains unchecked.
    Port1899. The port used for RADIUS agent integration.
    Secret KeyValue used when installing RADIUS agent
    Application Username FormatUse this drop down to specify the username format for users authenticating to Amazon Workspaces.

  2. Click Save.

Note: Once the application has been added you must assign it to appropriate users or groups within the Active Directory instance.

Amazon Workspaces must be configured for MFA.

Info

Caution

DUO MFA with Push/SMS/Call is not supported for Amazon Workspaces with RADIUS. When an end user, enrolled in Okta with DUO MFA, attempts to access Amazon Workspaces configured with RADIUS, they must provide the six digit MFA passcode displayed on the DUO mobile app in addition to their primary password.

  1. Return to the browser open to the Amazon Workspace.

  2. Open the directory configuration.

  3. Select enable Multi-Factor authenticationn.

  4. Specify the following values:

    Field Value
    RADIUS Server IP Instance B's private IP address
    Port 1899
    Shared Secret Value used when installing the Okta RADIUS agent.
    Protocol PAP
  5. Save the updated configuration.
    6. When complete the updates should resemble:

To configure factors used for MFA:

  1. In a browser, Navigate to your Okta Org and Login as an Administrator.

  2. Click Security > Multifactor.

  3. Select Factor Types tab.

  4. For each factor being enabled,

    1. Select the factor, for example Okta Verify.
    2. Select Activate in the Inactive/Activate drop down.
      Note: For active factors this drop down includes Active/deactivate values.
    3. Configure factor specific settings as appropriate.

  5. Note; Okta recommends that at a Minimum Okta Verify be specified.

  6. Select the Multifactor tab.

    1. Click Add Multifactor Policy.
    2. Name the policy appropriately.
    3. In Assign to Groups, enter everyone and then click Add.
    4. For Okta Verify select Required.
    5. Click Create Policy.

    7. After adding a policy you are directed to Add Rule automatically. You need not add a rule at this time.

Note: For more information on Multifactor Authentication see Multifactor Authentication .

AWS Workspace users are already managed in Active Directory. In live configurations configure Okta to pull users from Active directory as follows:

  1. In a browser, Navigate to your Okta Org and Login as an Administrator.

  2. Click Directory > Directory Integrations.

  3. Click Add Active Directory.

  4. Click Setup Active Directory.

  5. Complete the wizard as required.

    6. Note: For more information about integrating Active Directory with your Okta tenant see Manage your Active Directory integration.

The following describes the user experience once complete.

  1. End user receives an activation link in the inbox.
    MFA Enrollment welcome email.

    2. Note: you can fully customize the email template from Okta admin console.

  2. When a user clicks on the activation link they are directed to the onboarding page:
    MFA Onboarding page

  3. When a user clicks on the activation link they are directed to the onboarding page:
    MFA Onboarding page

  4. User can click on Configure factor and select a mobile OS::
    MFA Onboarding page

  5. User downloads Okta Verify app on their mobile device. Opens the app and scans the barcode displayed on the laptop:
    MFA Onboarding pageMFA Onboarding page

  6. Okta Verify self-enrollment is complete when user clicks on Finish
    User may choose to configure additional factors.
    MFA Onboarding page

    7. Note: When complete the user is redirected to the Okta dashboard.

  1. Once Okta MFA is enabled within the AWS Workspace, end users will see a MFA field on their workspace sign in page similar to:
    AWS MFA

  2. The MFA code can be used in 2 ways:

    1. You can enter the Okta Verify OTP that is displayed on your enrolled mobile phone in Okta Verify App.
      Click on your username in the mobile app to display the OTP. If you enter username+password and Okta Verify OTP as MFA code, you'll be signed in automatically.
      AWS MFA

    2. You can enter push as value.
      If you enter username+password and push as MFA code: you will receive a push notification on your enrolled mobile phone. Once you approve, you'll be signed in automatically in your workspace instance.
      AWS MFA
      AWS MFA
      AWS MFA