Page History

...

Amazon WorkSpaces is a fully managed VDI service from AWS that allows admins to assign remote Windows PC instances remote Amazon Linux WorkSpaces built on Amazon Linux 2 LTS, or Windows 10 desktop experience instances to individual users.

Users can connect to the WorkSpace from their own device whether they are using Windows, Mac, Chromebook, Tablets or even a supported web browser. 

...

Admins create an image using the Windows 7 the Amazon Linux WorkSpaces built on Amazon Linux 2 LTS, or Windows 10 base desktop experience base image provided by AWS with the software and updates they desire and then deploy to users.  Traditional desktop management tools can be installed like any other computer TSPs are administering.

...

Amazon WorkSpaces requires an Active Directory domain as a base for assigning WorkSpaces to individual users. AWS Directory Service allows admins to create an AD Connector in order to integrate with CornellAD. The AD Connector acts as a proxy to CornellAD and has a Cornell HoldingID assigned to it. This special HoldingID is given permission to look up users and groups as well as create Computer Objects in a specific OU. If you are ready to create your AD Connector, send your request to cloud-support@cornell.edu and the IT@Cornell Cloud Team will create your WorkSpaces HoldingID and OrganizationalUnit (OU). You will be given the ability to manage your OU and apply Group Policy ObjectObjects (GPOGPOs) s  as as desired; WorkSpaces respect GPOs the same as any other computer would.

...

To create your AD Connector, log into your Cornell AWS Account, navigate to the WorkSpaces Directories Console, click the "Set up Directory" button and choose AD Connector as the directory type. The settings for the AD Connector are straightforward and an example configuration is outlined in the screenshot below. Be sure to place your AD Connector within your Cornell Standard VPC and your private subnets. All WorkSpaces you create within this directory will be created within the same subnets as the AD Connector. You will need to plan network space according to the number of users you plan to support.

...

• • Target Domain and Organizational Unit
    • Place the Distinguished Name for the OU assigned to you by the IT@Cornell Cloud Team
    • Only the OU that is assigned to you will work, if you place any other OU here, your computer objects will fail to create. This is because they are named by AWS and will not conform to your object naming restrictions.
    • You can create sub-OUs under the OU assigned to you. As long as the OU you designate here is underneath your assigned WorkSpaces OU, it will work fine.
  
  
  • Security Group
    
    • Assigning a Security Group to your WorkSpaces is optional. 
    • This would come in handy if you need to restrict WorkSpaces network access to other resources in your VPC. For example, an RDS database, file share or EC2 Instance.
      
      
  • Access to Internet
    
    • Although it seems counterintuitive, in almost all cases you want to disable this setting. 
    • Enabling this setting simply assigns each WorkSpace a public IP address. In the previous section, we recommended to place your WorkSpaces Directory within private subnets, so public IP addresses are not required.
    • The advantage here is that all WorkSpaces will be behind a NAT Gateway and all traffic will come from a single public IP, that of the NAT Gateway itself. This benefits security and also makes it easier to open firewall rules to allow WorkSpaces to connect to publicly routed resources.
    • There may be edge cases where your WorkSpaces need to be placed in public subnets and assigned public IP addresses. This is up to the discretion of the admins.
      
      
  • Web Access
    
    • Enable this setting unless you want to disable access to WorkSpaces via Web Browser. As of the time that this wiki is being written, Web Browser Access to WorkSpaces is not working. Users must use a WorkSpaces fat client to connect.
      
      
  • Local Administrator Setting
    
    • We recommend setting this to disabled for user directories and enabled for admin directories. However, this is up to the discretion of the admins.
    • This setting controls user write privileges to the OS drive on the WorkSpaces. Users always have write privileges to their persistent User Profile.
    • Keep in mind that if a WorkSpace is rebuilt, any changes to the OS drive will be overwritten by the new WorkSpaces Image. Only the User Profile persists between rebuilds. 
    • Admins can also control local administrator access on WorkSpaces via GPO instead of enabling this setting.
      
      
  • Update AD Connector Account
    
    • If you ever need to update the password on your assigned HoldingID, here is where you do it.
      
      
  • Multi-Factor Authentication
    
    • This allows you to configure MFA for your WorkSpaces via RADIUS.
    • Please work with IdM to setup a RADIUS integration as they will need to provide a shared secret, IP addresses and any custom ports. Reference doc.
      • Setup an AD Connector Directory within the Workspaces console.
      • Provide IdM with the Directory IP addresses for firewall allows.
      • Enter RADIUS server IP addresses to the security group attached to the Directory.
        
      • In MFA field in the Workspaces application, enter DUO code, 'push,' 'phone' or 'sms' for MFA authentication.
        
        
  • Maintenance Mode
    
    • We recommend always enabling this setting.
    • This ensures that Auto-Stop WorkSpaces start up at least once per month to apply updates.

...

• • WorkSpaces Images
    • The first step to creating WorkSpaces for your users is to create a WorkSpaces Image.
    • This should have the latest Windows Updates and any management software and applications you want to maintain within the base image.
    • We recommend creating a "Golden Image" as your base and using existing management tools to manage WorkSpaces like any other Desktop / Laptop on campus.
    • WorkSpaces, and the images and applications that make them up, should adhere to CU Policy 5.10.
      
      
  • WorkSpaces Bundles
    • A bundle decides the OS Version, CPU, RAM, SSD and GPU resources available to a set of WorkSpaces.
    • One Image is assigned to a Bundle, but the Image can be updated / swapped out with any other Image you create, at any time.
    • Once a WorkSpace is created, its bundle cannot change, but you can update the Image within the Bundle and then Rebuild the WorkSpace to apply the updated Image.
    • Rebuilding a WorkSpace with a new Image has a few caveats and is analogous to "re-imaging" a physical computer. Technically, the User Profile will persist, but file integrity is only guaranteed if a Rebuild is performed within a certain maintenance window. For this reason, we recommend using traditional management tools to administer WorkSpaces as if they were a physical computer.
      
      
  • WorkSpace
    • A WorkSpace is a single VM assigned to a single user. 
    • WorkSpaces have a "Registration Code" that is unique to each directory. Users will need this Registration Code to configure their client to connect to their assigned WorkSpace.
    • When WorkSpaces are set up to use CornellAD, as outlined in this wiki, the user logs in with their Cornell NetID & Password.
    • Only one WorkSpace can be assigned per user, per directory.
    • You cannot change the user assigned to a WorkSpace, it is forever assigned to that user.
    • WorkSpaces can be set to Always-On or Auto-Stop. We recommend using Auto-Stop in the majority of cases. The cost savings are phenomenal significant and it only adds ~30-60 seconds a minimal amount of time to resume a WorkSpace when a user connects.
    • WorkSpaces can optionally have the OS Drive and / or User Profile encrypted at rest (full disk encryption). We recommend enabling full disk encryption, as it is a requirement for CU Policy 5.10.

...