About 8 months ago, I published an article about creating a Citrix desktop delivery environment in a lab environment and installing YubiOn Portal there. I haven't been able to experiment with this kind of virtual desktop environment for a while due to other development work. But this time, I had an opportunity to touch AWS WorkSpaces, so I would like to introduce YubiOn Portal there.
■ Configuration
As for the configuration, I think it can be said that it is a very general environment where you can say "I tried Amazon WorkSpaces".
Last time, I built everything necessary for the lab environment, so you may have the impression that there were more things to do than the contents of the article. But cloud services are convenient in such cases. On the other hand, I'm also nervous that it might end up with a high bill. This time, I tried to do it for free as much as possible. But I will explain the story of the price at the end.
■ Build your WorkSpaces
If you just want to try out Amazon WorkSpaces, you should be able to make the necessary settings according to the instructions provided by AWS.
① Build a directory
First, create a "Directory" to place WorkSpaces. This is the part corresponding to Active Directory in Windows.
If it is just a trial, I think there is no problem with the "Simple AD" type. It seems that a compatible server called "Samba 4 Active Directory Compatible Server" is used instead of pure Microsoft AD.
"AWS Managed Microsoft AD" runs using pure Microsoft Windows Server 2019, so if you want to fully use the functions provided by Microsoft, you should use this.
"AD Connector" is a bit different, and is an option for linking with AD in the existing intranet. I think that it will be used for purposes such as migrating things that were used locally in the company to the cloud.
Next, enter the directory information.
It's a trial, so the size is small. Don't think too much about the organization name, DNS name, NetBIOS name, etc., end st them in the same way as a normal AD construction. If you forget the administrator password, you will not be able to manage it as AD, so please handle it strictly.
Next, we will configure the network settings.
Here too, there is no problem if you follow the instructions on the screen to create a virtual network that uses WorkSpaces. However, if you create a subnet as a private subnet, and you just create a VPC and 2 subnets according to the instructions on this screen, you will not be able to access the Internet from that space. I will explain this later, so for now I will create a VPC and 2 private subnets and allocate them.
(We will cut the public subnet later, so please leave room for additional subnets in the VPC.)
After setting up here, check the contents on the "Review & create" screen and create the directory.
As is often the case with AWS, after you click "Create", you have to wait for a while as it will be created in the background.
When the status becomes "Active", creation is complete. Finally, to use this directory with WorkSpaces, we need to "Register" it. (Select the directory → "Action" → "Register")
Specify the subnet you set earlier and register it.
② Create WorkSpaces
Next, we will create WorkSpaces. Although it is called "WorkSpaces", as far as the behavior is concerned, I think that one WorkSpace can be considered as one virtual machine. Not limited to this point, when using AWS, I think it is important to understand in your way what the specific terms of AWS refer to.
Create WorkSpaces with the "Create WorkSpaces" button on the above screen.
Select the created directory and click "Next".
To create a new user, click "Create additional user" to move to the create screen. If you want to assign a user that already exists in the directory (such as deleting the previously created WorkSpaces and recreating it with the same user), you do not need to create a user here.
Enter your user information. You can create up to 5 people, but here I set only 1 person and click "Next".
Once the user has been created, you will automatically proceed to the "Identify Users" screen. This screen is a little confusing. It means that WorkSpaces will be created for the specified number of users, rather than allowing the specified user to log in to 1 newly created WorkSpace. Since I want to create only 1 this time, select only the user created earlier and click " Next".
Then proceed to the step "Select Bundle". The "bundle" here is something like a template that is the base of WorkSpaces. The biggest difference is the OS, but there are other differences such as the presence or absence of Office and client protocol (communication protocol for actual remote operation).
This time, select "Standard with Windows 10 (Server 2019 based)" with "WSP" as the client protocol. We will discuss the client protocol later.
Next, set the running mode, etc. As explained on the screen, the power is always on as a virtual machine (AlwaysOn), or it automatically stops when not in use (AutoStop). If it is for the experiment, I think that there is no problem with AutoStop. For tags, make settings as necessary.
Then there are the customization options. In actual operation, encryption should be properly performed, and the user volume should be selected appropriately according to the usage, but since it is an experiment, I will leave it as the default.
Finally, review the settings. If there seems to be no problem, click "Create WorkSpaces".
Creating will start a background process as usual. It will take several tens of minutes to create these WorkSpaces, so please be patient. When creation is completed, an email saying "WorkSpaces for you has been created" will fly to the email address specified when creating an additional user.
According to the contents of the email, set the user password, install the client application, and try to connect.
If you can connect to WorkSpaces as in the above image, first of all, I think that it is over to the point of "trying to run WorkSpaces".
■ Network settings
For now, I can access the virtual PC set up in WorkSpaces, but even if start the pre-installed Firefox on WorkSpaces, I can't connect to the Internet. Currently, the private part on the left side of the schematic diagram has been completed, and if you think about it in terms of a home LAN, it is in the stage of "I tried building a LAN in my house". So, next, we will create the public part on the right, which is the part that corresponds to the Internet connection router in the image of the home LAN.
(A typical home internet router includes a LAN side gateway and DHCP server, so it's a little different from the image,...)
Everything is created on the "VPC" screen of the AWS management console.
③ Create an Internet gateway and attach it to VPC
First, create an Internet gateway. There is nothing too difficult here, just choose a name and create it.
Once created, link it to an existing VPC. Select "Attach to a VPC" from the action menu to attach.
④ Create a public subnet
Create a subnet for access from the Internet side. Place the NAT gateway within this subnet. Public subnets are created in the same way as private subnets. Create by specifying an IPv4 CIDR block that is different from the existing private subnet within the range of your VPC.
⑤ Create a NAT gateway
From the NAT gateway management screen, click "Create NAT gateway" to display the creation screen. As the subnet, specify the public subnet created earlier, set the connectivity type to the public, and assign an Elastic IP.
⑥ Create a public route table
A set of virtual devices has been prepared, but as it stands, information about what route to take to get to the Internet is not set. Currently, I think that the same route table created by default is used for the 3 subnets, but it is necessary to specify different route information for the private side and the public side, so I will create 1 public route table. Select "Create route table" from the route table management screen.
Name it whatever you like and specify the VPC you're currently using.
⑦ Set route table association for the public subnet
Select the public subnet from the subnet management screen and open the "Route table" tab.
Click "Edit rote table association", select the route table ID, set the public route table created earlier, and click "Save".
⑧ Configure routing for the public route table
From the route table management screen, select the created public route table, open the "Routes" tab, and click "Edit routes".
By default, I think that the routing is set to go to local if it is within the VPC subnet range, but I will add a route that goes to the Internet gateway if it is "0.0.0.0/0" and click "Save changes".
⑨ Set the routing of the private route table
As in the previous section, edit the default route table route associated with the private subnet.
Here, add a route that goes to the NAT gateway if it is "0.0.0.0/0".
With the settings up to this point, I think you will be able to access the Internet from WorkSpaces. Connect to your WorkSpaces again and try accessing the Internet with Firefox.
■ YubiOn Portal introduction and use in the logon section
Now I will install YubiOn Portal to the created WorkSpaces. Regarding the reuse of the main points when introducing Citrix products, the following points are almost common in virtual environments, especially in virtual environments with automatic logon to Windows.
Installation must be done for each WorkSpace.
Currently, account and YubiKey assignments also need to be done for each WorkSpace.
Forced YubiKey logon must be enabled in the policy.
If not enabled, the WorkSpaces authentication mechanism will skip the Windows logon part.
Cache logon, screen lock when YubiKey is removed, etc. cannot be used.
Both require YubiKey and USB communication, so they cannot be used in environments where USB is not directly connected.
If you have multiple WorkSpaces, those machines must have different SIDs.
YubiOn Portal identifies each terminal based on SID and does not support situations where there are multiple terminals with the same SID.
After completing the setup, access from the WorkSpaces client.
After entering your WorkSpaces login information and signing in, the YubiOn Portal Windows logon screen will be displayed on the WorkSpaces screen.
Here, you will be able to log on by entering your password + YubiKey. With WorkSpaces alone, the Windows logon part was omitted, but by introducing YubiOn Portal, it will be possible to enforce two-factor authentication when displaying the desktop.
■ Summary
The above is how to install YubiOn Portal for the Amazon WorkSpaces environment.
As same as the previous introduction to Citrix products, I think there will be issues in terms of setup for large-scale use. Currently, I think that the method is to list the SIDs of the created WorkSpaces and install them using the kitting installation option, etc. However, we are looking for a way to automatically register from the created WorkSpaces with YubiOn Portal installed.
There are 3 digressions below so I will write them together.
■ Digression ①: WorkSpaces client protocol
WorkSpaces has "PCoIP" and "WSP" as client protocols. Both are protocols for transferring input and output (video, audio, mouse operation, key input, etc.) of WorkSpaces terminals, but their origins are very different.
① PCoIP (PC over IP)
A protocol developed by Teradici Co. of Canada (acquired by HP Co. in 2021). In addition to Amazon WorkSpaces, it is also used by VMware's VMware Horizon.
② WSP
A protocol originally developed by Amazon, an abbreviation for "WorkSpaces Streaming Protocol".
The comparison between the two is detailed in AWS help.
The reason why WorkSpaces supports two protocols is speculation. At first, PCoIP was adopted, but to deal with an unstable network environment and support cameras, it was necessary to reconsider the protocol itself and develop a separate WSP. Assuming such circumstances, I think that WSP will become mainstream in WorkSpaces in the future.
In this procedure, I used WSP, but YubiOn Portal itself works normally even if PCoIP is used. However, when using PCoIP, there is a problem after entering the authentication information in the WorkSpaces client, we have to wait about 1 minute until the Windows logon screen is displayed. Presumably, in the case of PCoIP connections, I suspect there is a mechanism to wait for Windows to log on properly (or time to) using the credentials sent by the WorkSpaces client.
■ Digression ②: How FIDO Logon works in WorkSpaces
It is related to digression ①. When using the PCoIP protocol, a mechanism called USB transfer can be used.
In addition to the contents of the above help, in the other to use it, it is necessary to set USB transfer permission in the AD group policy. (I will omit that part this time.)
I also experimented to see if FIDO Logon can be used. In conclusion, it is possible. However, there are some problems, and I think that it is not practical at the moment.
As the problem mentioned in digression ① (waiting for about 1 minute until connection) is the same for FIDO Logon.
YubiKey is the only device officially supported by Amazon and the flexibility of key selection for FIDO2 authentication is lost.
It seems to be dependent on the environment, but when I tried it, there was a phenomenon that the WorkSpaces client could not recognize the device after removing and reinserting the device or reconnecting to WorkSpaces. (including supposed YubiKeys)
Technically speaking, it may be quite difficult to transfer USB device communication, which is usually exchanged in milliseconds, over the Internet in 100 milliseconds. In addition, there is also the idea that the FIDO mechanism itself is a requirement from the security point of view that the related devices are in the hands of the user. None of the USB/NFC/BLE supported by FIDO2 are originally designed to send communications to remote locations. DaaS authentication, including the pros and cons of transferring USB devices, may be an issue that the industry should continue to consider in the future.
■ Digression ③: Billing for AWS charges
The truth is that since it's just a trial, so if possible, I want to use it for free. However, the charges are as follows.
In the "Bundle" settings, I chose the item "Free tier eligible", so the "Software" portion is free. However, it seems that the operation of the instance and the user registration of the directory are not free. And, although it is not described in the above image, I think that parts other than WorkSpaces (such as VPC) are also charged.