Page History

...

• • 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.We have not tested this out, but we assume that if you
    • Please work with IdM and ITSO, enabling MFA should be as straightforward as filling this form out with the Cornell RADIUS server informationto 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.
        Image Added
      • 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.

...