Enterprise tips for AWS Workspaces and AWS Managed AD

::: note ::: title Note :::

fjleon of Reddit has pointed out that today many of the limitations I have written about have been solved. see the discussion on Reddit Or check the documentation for the latest. :::

This is some learning and pointers after setting up a secure enterprise AWS workspace and Managed AD. My biggest issue with this product is the difficulty in managing user passwords since some of the normal windows features like warning about password resets or on logon prompt to update an soon to expire password do not work. This causes a big overhead when managing user passwords and means you have to write some tooling to manage this and get users to reset their passwords. Related to this is that you can not reset a password over LDAP unless using TLS. Which means you have to spin up your own CA before you can have this tooling working. Otherwise latency and experience is really good.

Workspaces

  • There is one workspaces security group created per directory so a rule for one workspace must apply to all.

  • Workspaces client does not support proxy, if you need to guarantee you clients only can connect to workspaces your organization owns, you need to punch holes in firewall straight from users desktop to the internet.

  • To prevent people connecting to Workspaces not owned by your org you can block out the all http requests via proxy except your directory ID auth endpoint.

  • Workspaces does not support the Interactive logon: Message text for users attempting to log on policy that shows users a MOTD or legal statement.

  • Workspaces does not support warning users to change the password when logging in with a password which is about to expire.

Instances are not shutdown unless the workspace client is disconnected (so an open connection for 11 months will be 11 months of billing)

However, you can use the below workaround to trigger autostop in such cases. You can configure below policies in Windows OS using GPO to log off the user if the idle session timeout is fired. Along with logoff, set up a scheduled task at logoff that whenever a logoff is triggered, system is shut down.

  • Disconnected Session Timer: Enables or disables a timer to determine how long a disconnected, locked workstation can remain locked before the session is logged off. By default, this timer is disabled, and disconnected sessions are not logged off.

  • Disconnected Session Timer Interval: Determines how long, in minutes, a disconnected, locked workstation can remain locked before the session is logged off. By default, the time period is 1440 minutes (24 hours).

  • Session Idle Timer: Enables or disables a timer to determine how long an uninterrupted user device connection to a workstation will be maintained if there is no input from the user. By default, this timer is enabled.

  • Session Idle Timer Interval: Determines, in minutes, how long an uninterrupted user device connection to a workstation will be maintained if there is no input from the user. By default, idle connections are maintained for 1440 minutes (24 hours).

  • The Legal notice / MOTD prompt you can get when you login to a Windows session is not support.

  • AWS can inject a legal notice into the AWS client authentication screen but this is a backend operation you need to supply the text to AWS support.

PS D:\Users\brentcetinich> Set-ADDefaultDomainPasswordPolicy -MaxPasswordAge 52.0:0:0.0 -Identity $domain
Set-ADDefaultDomainPasswordPolicy : Insufficient access rights to perform the operation

Managed AD

  • No TLS support for LDAP out of the box, if you want that, you need to spin up ~2 windows servers to roll your own PKI to generate a certificate. See internal PKI CA

  • AWS Managed Microsoft AD is powered by Windows Server 2012 R2. (Workspaces is Windows 2016 Server)

  • The default password expiration is 42 days and this includes the Admin user AWS gives you.

  • Default password expiry is 45 days (Un-Tick the password never expires in msad.msc or ADUC for Admin) Otherwise you can reset it from the AWS API.

Disable TLS Enforcement for LDAP

To roll back the policy the blocks password operations over insecure channel

Get the events for a certain ID from the remote DC:

get-winevent -computername <dc name> -logname "Directory Service" | where {$_.id -eq '2889'} | select -expand Message

Secret workspace APIs

There are a few undocumented API that workspaces uses which is a concern because now I worry about what other actions can be done against the directory without explicit IAM permissions to do them. From my testing you must be authenticated to use this one.

It is nice that it is authenticated, but from my experience undocumented API could mean it was not subject to pentesting, security review, or included in the threat model.. Who knows what other APIs are there and what exploits they may be vulnerable to.

Creating a new user via awscli is not available. This would be very convenient, this API is very different to the usual API I am used to from AWS.

  • They provide a search directory function via the console. By intercepting the request the console sends, I can see a HTTP to “SearchForDirectoryUsers” endpoint

They send the following payload to this endpoint https://ap-southeast-1.console.aws.amazon.com/workspaces/workspaces/WorkspacesConsoleService

7|2|11|https://d28l4465vaf89b.cloudfront.net/xxx/workspaces/|8888888877F264742C8888888A|com.google.gwt.user.client.rpc.XsrfToken/4254043109|86E59D5185C9AA4397F9B9C9317AFB95|com.amazonaws.workspacesmanagementconsole.client.WorkspacesConsoleService|SearchForDirectoryUsers|com.amazonaws.workspacesmanagementconsole.shared.directories.SearchForDirectoryUsersRequest/938585377|d-96671d5762|java.lang.Integer/3438268394|corp.internal||1|2|3|4|5|6|1|7|7|0|8|9|25|10|11|

The response is this crazy structure:

//OK[114,113,9,112,111,110,5,109,108,9,0,0,0,5,107,106,9,14,105,104,5,103,
102,9,101,100,99,5,98,97,9,96,95,94,5,93,92,9,91,90,89,5,88,87,9,86,85,84,5,
83,82,9,81,80,79,5,78,77,9,76,75,74,5,73,72,9,71,70,69,5,68,67,9,23,66,65,5,
64,63,9,62,61,60,5,59,58,9,57,56,55,5,54,53,9,52,51,50,5,47,49,9,48,47,46,5,
45,44,9,0,0,0,5,41,43,9,42,41,0,5,40,39,9,38,37,36,5,35,34,9,33,32,31,5,30,
29,9,28,27,26,5,25,24,9,0,0,0,5,23,22,9,0,0,0,5,21,20,9,19,18,17,5,16,15,9,
14,13,12,5,11,10,9,8,7,6,5,25,4,82,3,2,1,
[
  "com.amazonaws.workspacesmanagementconsole.shared.directories.SearchForDirectoryUsersResponse/973973743",
  "f63e54d0-39af-479e-b550-9ed1fd93f45e",
  "java.lang.Integer/3438268394",
  "java.util.ArrayList/4159755760",
  "com.amazonaws.workspacesmanagementconsole.shared.User/210721608",

  "XXXXXX@gmail.com",
  "cetinic",
  "cetinich1",
  "S-1-5-21-555326939-1375677655-1791692927-1143",
  "brentcetinich",
  "cXXXXX@gmail.com",
  "CA",
  "S-1-5-21-555326939-1375677655-1791692927-1149",
  "CAAdmin",

]
,2,7]o

Create directory users

There is also a way to create a new user in the Managed AD, since out of the box managed AD does not enable TLS and for a long time, Windows do not allow password setting over insecure channel they must run some agent on the Domain Controller.

Same WorkspacesConsoleService endpoint as above:

Request:

7|2|13|https://d28l4465vaf89b.cloudfront.net/342e4212567c64bf2bc6004afce9754db4d434fc/workspaces/|8A2E7AC5A3C1A877F264742C374DAC8A|com.google.gwt.user.client.rpc.XsrfToken/4254043109|86E59D5185C9AA4397F9B9C9317AFB95|com.amazonaws.workspacesmanagementconsole.client.WorkspacesConsoleService|CreateDirectoryUsers|com.amazonaws.workspacesmanagementconsole.shared.directories.CreateDirectoryUsersRequest/1479783708|d-96671d5762|java.util.ArrayList/4159755760|com.amazonaws.workspacesmanagementconsole.shared.users.NewUserInfo/3031892526|cetinich+testbc@gmail.com|TESTBC|TEST|1|2|3|4|5|6|1|7|7|8|9|1|10|11|12|12|13|

Response:

//OK[8,7,6,5,5,4,3,1,2,1,
["com.amazonaws.workspacesmanagementconsole.shared.directories.CreateDirectoryUsersResponse/3237473026",
"java.util.ArrayList/4159755760",
"com.amazonaws.workspacesmanagementconsole.shared.User/210721608",
"cetinich+testbc@gmail.com",
"TESTBC",
"corp.internal","S-1-5-21-555326939-1375677655-1791692927-1264","TEST"],2,7]

How to run ADUC / dsa.msc as the Administrator user

I have not tried launching a Workspace with the Admin user, but once you have the Admin users credential you can use the following command from your non administrator account in your own workspace to launch ADUC as another account and then manage the directory.

runas /netonly /user:Admin@corp.internal "mmc %SystemRoot%\system32\dsa.msc"

Some other management consoles you can use the same method:

  • Group Policy: gpmc.msc

  • DNS Management: dnsmgmt.msc

  • DHCP: dhcpmgmt.msc

  • AD Domains and Trusts: domain.msc

Comments

comments powered by Disqus