Getting an Organization started on AWS Part 5: WorkSpaces & WorkMail — workforce style users
Part 1: Introduction, AWS Accounts, IAM & AWS Organizations
Part 2: Multi-Account, Landing Zones & AWS Control Tower
Part 3: Domains, DNS & Route53
Part 4: Identity Center, Single-Sign-On & Directory Service
Part 5: WorkSpaces & WorkMail — workforce style users
Part 6: WordPress & Workloads
Welcome back to part 5 of this course! So far, we have our multi-account AWS environment configured, we can invite users to AWS accounts with differing levels of access, and grant the same users access to third-party SAML-enabled apps.
We still need a way to create workforce-style users with custom email addresses, grant them access to their mail — and potentially grant them access to a virtual desktop environment.
In this course, we’ll learn about WorkMail + WorkSpaces, how to configure WorkMail for our custom domain name, as well as creating shared network infrastructure that we can reuse for future AWS workloads.
Let’s get stuck into some quick theory, and then we can continue with a walkthrough.
Theory:
Amazon WorkSpaces is a desktop-as-a-service solution, which allows us to provide Windows & Linux desktops for our workforce users to remote to from their machine (using Amazon’s client application for WorkSpaces), to use as a work environment. Similar to other services such as Citrix.
AWS hosts the actual workspaces themselves in an Amazon-managed VPC. We provide public subnets when configuring WorkSpaces, and then inject the workspaces into those subnets.
WorkSpaces uses an AWS Directory Service directory to store its users. It can pull users from a directory registered with AWS WorkSpaces.
Directory service, Workmail & WorkSpaces are all chargeable products. They cost money to use. WorkSpaces can either bill hourly or monthly, and also has an AutoStop mode whereby the WorkSpaces are automatically stopped after a specified period, to reduce costs.
WorkMail is a secure, managed business email and calendar service. A web portal is provided where users can log in and access their mail, alternatively, you can configure a desktop and/or mobile app to use WorkMail, such as the Windows 10 Mail app.
WorkMail is managed in what is called an ‘organization’, not to be confused with AWS Organizations. WorkMail can be configured to use an alternate domain name to the one they provide to you, and the set-up page for custom domains provides all the DNS records needed to configure it for your custom domain.
A WorkMail organization can be configured to use a directory from Directory Service, whereby you can ‘Enroll’ users from the directory into the WorkMail organization.
Directory Service provides no AWS portal to manage the directory users. Instead, you must “join” a computer ( Ec2 instance) to the directory domain, and then you can install the AD tools onto the computer. The computer could be Linux or Windows for Simple AD, but for simplicity’s sake — we’ll use Windows. This server is referred to as the ‘Domain Controler’.
From here, IT administrators can remotely connect (using RDP) to the machine, and use the Active Directory Administrator tools to add users/groups to the directory.
A directory in directory service is technically two directories, as per AWS’s preferred high-availability approach. When you create the directory, you must provide two subnets in different availability zones. These subnets must have outbound access to the internet.
For simplicity’s sake again, we’ll deploy the Domain Controller to one of the two subnets. Since IT administrators will be remotely connecting to the machine through RDP, the subnet must be public (have a route to an internet gateway).
Architecturally, the relationship between the products looks like the below:
In terms of networking and account structure, our approach will look like this:
WorkSpaces, the Domain Controller, and the directory will all be deployed to public subnets from a shared VPC in a separate network account. That way, we can reuse cost-incurring resources such as NAT gateways across many accounts, including future workload accounts.
WorkMail does not live within a VPC, it is fully managed by AWS.
Once the technical infrastructure is in place, the end-to-end journey for creating a workforce-style user will be the following:
- IT admin remotes to the DC to create a new user in the AD
- IT admin imports the newly created user into the WorkMail organization, creating that user an email address.
- The user can now log into the mail portal to access their mail, or the IT admin can configure it with their mail app on the user’s device.
- (Optionally) IT admin imports the user into WorkSpaces and creates a desktop instance for the user
- (Optionally) IT admin can create the user in Identity Center, specifying their new email. IT admin could add the user to a role-specific group. IT admin can grant this user access to the AWS Accounts and third-party apps that the user needs if the group does not already have that configured.
- The user can accept the invite to Identity Center through their email, open the SSO portal, and then reset their password, add an MFA device, and access the accounts and apps provided.
- IT admin creates the user account in any third-party apps needed, using the user’s email address.
So just to recap the technical side one more time, what we’ll be doing is:
- Create a network account and share the VPC
- Create a directory in the directories account
- Join a domain controller to the directory & install AD tools
- Create a WorkMail org & configure DNS
- Configure WorkSpaces for the directory
- Demo end-to-end user sign-up journey
I hope that’s been enough theory, feel free to research any individual product or technology separately. Let’s get stuck in with the walkthrough!
Walkthrough Part 1: Network account & Shared VPC
So since we need a directory, we need two subnets which can make outbound requests to the internet. If you recall, in part 2 of the course we created the directories account with private-only subnets, with no NAT gateways created.
So we could destroy and recreate the account, and change the account factory settings to create a public VPC. Alternatively, we could just create the infrastructure in the directories account.
However, NAT gateways are expensive. And we’re going to need VPC with internet access for any future accounts we create for the workloads we need to run…
What we’ll do instead is create a ‘Network’ account, and share the newly created VPC’s subnets with the rest of the organization.
So step 1, go to the management account and go to AWS Control tower
2. Go to Control Tower => Account Factory => Network configuration and edit the settings. Enable Internet-accessible subnet, specify 1 maximum number of subnets (this is per Availability Zone). Feel free to edit the CIDR range if you want, and select the region (you just need one) where you want to deploy your VPC to. Hit Save.
3. Go to Control Tower => Account Factory => Create account. Specify the details of the account, and in the name, I make it clear that the account is for networking. I chose ‘SharedServices’ as the OU since it is for shared (VPC) services. Create the account.
4. Whilst the account is provisioning, go to Identity Center. From there, either create a user or grant an existing user, permissions to the new network account. You can also grant access to the directories account since that will make things easier.
If creating a new user, feel free to use an email alias or a different email, but make sure you can access the email since you’ll need to accept the SSO invite. Make sure the permissions of the user allow for creating a resource share in Resource Access Manager, and for creating VPCs. PowerUserAccess would do the trick. Don’t log in as this user yet.
5. Log in to the management account as the root user. Go to AWS Organizations => Settings. Copy the Organization ID and make note of it somewhere, you’ll need it soon.
6. Go to AWS Resource Access Manager => Settings => Tick “Enable sharing with AWS Organizations”.
7. Go to AWS Identity Center => Open the SSO portal link at the bottom right. Log in as the new user you created. Log in to the Network account management console.
8. Go to VPC.
9. You should see the below, only without the extra (was a play-around of mine)
10. Go to VPC => Subnets and select one of the subnets names public
11. Go to Sharing => Share subnet
12. Create a resource share
13. Name the share and select the two public subnets
14. Untick this and click ‘Create resource share’
15. Once created, select the subnet share and click modify
16. On the right navbar, select ‘Grant access to principles’. Select “Allow sharing only within your organization”. Change the dropdown to “Organization”. Paste in the organization ID you made note of earlier. Click “Add”. Then, once added in the ‘Selected principals’ section, click ‘Next’. Then, on the next page, click ‘Update resource share’ at the bottom right.
Walkthrough Part 2: Creating your directory
1. Leave the network account and log back into the directories account. Now we can create our directory. Go to Directories Service. Make sure you’re still in the Ireland region, or whichever region you’ve deployed your VPC to. Click Set up directory.
2. Select Simple AD.
3. Choose your directory size. Then, enter a DNS name for your directory. The domain name does not have to be a real, publicly addressable domain name. We’re going to edit the VPC DHCP settings so that the DNS name is resolvable within the VPC. Enter a domain name (e.g corp.yourdomain.tld) and enter a shorthand nickname for the directory in the Directory NetBIOS name field.
When the directory is created, it will create an administrator user within AD. Provide a strong password for that user and note it down.
Optionally enter a description for the directory and click Next.
4. Select the shared VPC. Then you can specify the subnets or leave them as “no preference”.
5. Review then click “Create directory”.
6. Wait for the status to be “Active”
7. Click into the directory, go to “Networking & security” and copy the DNS addresses of the directory
Walkthrough Part 3: Configure the DHCP options for the shared VPC
- Now we need to make our directory DNS name internally resolvable within the VPC. Log back into the Network account and go to VPC. Navigate to VPC => DHCP Option sets
2. Create a DHCP option set
3. Optionally specify a name for the new DHCP options set. Specify the domain name of the directory you created, paste in the IP addresses you copied and separate them with a comma. Scroll down and click “Create DHCP option set”.
4. Go back to VPC => Your VPCs => select your VPC. Drop down “Actions” and select “Edit DHCP option set”
5. Change to your new options set and click “Save changes”
Walkthrough Part 4: Create a domain controller & install AD tools
- Log out of the network account and go back to the directories account
2. Make sure you’re still in the correct region, and navigate to Ec2.
3. Launch a new instance.
4. Give the server a name, select Windows, and choose the appropriate image. I’m using the free tier eligible Windows Server 2022 base. For the instance type, choose the correct size (I chose t2.micro, which is free tier eligible).
5. For “Key pair”, choose “Proceed without a key pair”. Click “Edit” next to Network settings and select the shared VPC, and one of the shared subnets. For “auto-assign public IP”, select “Enable”.
6. Create a security group, then name and describe the security group appropriately. I adjusted the inbound rule to only allow my IP address to connect, if you want other IT members to remote to this server from somewhere other than your home network, then select “Anywhere”.
7. Scroll down to “Advanced Details” and change the domain join directory to your directory. Ensure “Enable resource-based IPv4 (A record) DNS requests” is selected. Then, go to “Create new IAM profile” and open in a new tab.
8. Select “Create role”.
9. Select “EC2” then click next
10. Search for “AmazonSSMManagedInstanceCore” and then tick the box for it. Clear the search bar and search for “AmazonSSMDirectoryServiceAccess”. Select that. When you have both permissions policies selected, click next.
11. Name the role and create it. Then return to the EC2 journey. Refresh the dropdown box and select your new role
12. Review your configuration and click “Launch instance” when ready.
13. Wait for the instance state to be “Running” and “Status check” to have 2/2 checks passed. When ready, click Connect.
14. Go to RDP client. Either download the remote desktop file or open RDP from windows. For the computer name, copy the public DNS of the Ec2 instance.
The username would be yourdomainaddress\Administrator. For example, corp.acompanymakingeverything.co.uk\Administrator. The password is what you provided when creating the directory.
15. Connect to that and the server session should start.
16. From the windows start menu, find “Server Manager” and open it. From there, click “Add roles and features” and wait for the menu to open.
17. Click “Next” through “Before You Begin” and “Installation Type” without changing anything. When you get to “Server Selection”, ensure that your server is there in the server pool. You shouldn’t have to change anything at this point.
18. Click “Next” through “Server Roles” without changing anything. When you get to “Features”, Select Remote Server Administration Tools => Role Administration Tools => and select “AD DS and AD LDS Tools”, as well as “DNS Server Tools”. Click Next and await installation.
19. When done, close the server session, go back to EC2, and stop the instance. Once in the stopped state, start the instance again and await for the “Running” instance state and 2/2 status checks.
20. Now the server has been rebooted, reconnect to the server through RDP. Once connected, through the Windows start menu, find “Active Directory users and computers”. Drop down your directory on the left, right-click “Users” and add a new user. Fill in the user details and click “Next”.
21. Hit finish. Now, we have our user in AD. If we wanted to, we could add this user as an RDP user and remote to the server through this new user. This is optional.
Walkthrough Part 5: WorkMail configuration
- Ensuring you’re still in the directories account, as well as in the region you want to be in, search for WorkMail and open it. Click Create Organization.
You may have purchased your domain through Route53 in the Domains account, or you may have purchased it through a different vendor. In this example, I have a domain through GoDaddy. Either way, navigate to the DNS settings page for your domain. If in Route53, you can see that in the hosted zone.
Or, if you don’t want a domain, you can use a free test domain from WorkMail (exampledomain.awsapps.com).
Either way, WorkMail provides DNS records you can add to the DNS settings of your domain, which will allow you to use your domain for email services wherever you like. WorkMail offers a web portal for viewing mail, but you can configure it for a mail app also, such as the Windows 10 Mail app.
2. Select “External domain”. Enter your domain name, as well as an alias that WorkMail uses for your organization.
3. Under “Advanced settings”, select “Use existing directory” and select your directory. For encryption, select “Use Amazon WorkMail managed key”. Click “Create Organization”.
4. Wait for the organization’s state to be “Active”. Once Active, click on the organization.
5. Go to WorkMail => YourOrganization => Domains and click your domain.
6. You will have a bunch of records. Copy these records into your DNS settings for your domain, wherever you manage your domain (Route53, GoDaddy, 123Reg…). Ensure to make note of the type, name, and value of each. See the video at the top of this post for to see me doing this on GoDaddy.
7. Once you’ve done a few, come back to the page and refresh. You’ll notice they’ve changed from red to green.
8. At the bottom, you’ll notice “Improved email delivery — recommended”. This is to configure a custom “MAIL FROM” domain. Click the SES link included.
9. In the SES console, ensure you’re on the “Verified identities” page, scroll to the bottom, and edit the Custom “MAIL FROM” domain.
10. Tick “Use a custom MAIL FROM domain” and enter a default “MAIL FROM” subdomain. I use “mail”. When done, hit “Save changes” and return to WorkMail.
11. Refresh the page on WorkMail and you’ll see new DNS records to add. Apply those to the DNS settings for your domain.
12. Go to WorkMail => YourOrganization => Domains. You’ll see your two domains (your custom and the free test domain). Select your custom domain and click “Set as default”.
13. Click into your domain. You’ll notice all DNS settings are healthy.
14. Go to WorkMail => YourOrganization => Users. You’ll notice that our WorkMail organization has already pulled the user we created through Active Directory
15. Select the user and click “Enable”. This enrols the user into our WorkMail organization. This will allow us to set a primary email address for this user.
16. You can now see the state of the user is enabled. You can click the display name hyperlink to view the details of the user if you wish.
17. Go to WorkMail => YourOrganization. You can see a WorkMail link to access the WorkMailweb application. Here, you can log in with the AD user’s username and password. If you don’t know the user’s password, you could always remote into the server again and reset it.
Once logged in, you could send and receive emails. You could also look at online guides for configuring WorkMail to different mail applications.
Walkthrough Part 6: WorkSpaces
Go to AWS Workspaces. For Ireland, that would be “eu-west-1.console.aws.amazon.com/workspaces/v2/workspaces”.
- At the time of recording, the UI for workspaces was a bit glitchy and wouldn’t let me go to the navigation page for WorkSpaces. A trick I used was to go to “WorkSpaces Web” and then go to “WorkSpaces => Directories” from the side nav bar.
2. Click “Create Workspaces”
3. Select your directory and click “Register”
4. Select both subnets (these are shared from your network VPC). If you want, you could also click “Enable self-service permissions” and/or “Enable Amazon WorkDocs”. I chose not to. Click Register.
5. Click Next
6. Click Next through Create users, you don’t need to do this since we’re creating our users through AD directly. For “Step 3 — Identify Users”, select your user
7. Choose your bundle. I chose the cheapest Windows 10 bundle.
The bundle is the environment you’re providing to your users through WorkSpaces. Free-tier-elibigle workloads are offered for both Linux and Windows.
8. Choose your “Running Mode”. AlwaysOn bills monthly, and AutoStop bills hourly. AutoStop deactivates the instance after n number of hours of inactivity. Continue to click Next and then “Create WorkSpaces”.
9. Wait for the workspace to transition from “Pending” to “Available”. Once avaialble, click on the available workspace.
10. Download the client for your operating system. Once downloaded, go through the installation wizard.
11. In WorkSpaces => YourUsersWorkSpace, copy the registration code. Open the client app on your device if not already open and paste the registration code
12. Sign in
And that’s everything for WorkSpaces! Now you can create a user in Active Directory, grant them an email, and grant them a virtual desktop environment!
Walkthrough Part 7: Reviewing our user process
Here is the process we drew up at the beginning of this chapter:
“
Once the technical infrastructure is in place, the end-to-end journey for creating a workforce-style user will be the following:
- IT admin remotes to the DC to create a new user in the AD
- IT admin imports the newly created user into the WorkMail organization, creating that user an email address. The user can now log into the mail portal to access their mail, or the IT admin can configure it with their mail app on the user’s device.
- (Optionally) IT admin imports the user into WorkSpaces and creates a desktop instance for the user
- (Optionally) IT admin can create the user in Identity Center, specifying their new email. IT admin could add the user to a role-specific group. IT admin can grant this user access to the AWS Accounts and third-party apps that the user needs if the group does not already have that configured.
- The user can accept the invite to Identity Center through their email, open the SSO portal, and then reset their password, add an MFA device, and access the accounts and apps provided.
- IT admin creates the user account in any third-party apps needed, using the user’s email address.
”
- IT admin remotes to the DC and adds a new user:
2. IT admin imports the newly created user into the WorkMail organization, creating that user an email address :
3. IT admin imports the user into WorkSpaces and creates a desktop instance for the use:
4. IT admin can create the user in Identity Center, specifying their new email:
Walkthrough Part 8: Clean-up
Well done for getting so far! This has been a big walkthrough and we’re now finished with the workforce federation side of this course. We can now set up users in our organisation, provide email addresses and virtual desktops, and give technical users security limited access to AWS itself. We can also give our users access to a single sign-on page for third-party apps!
We’ve reviewed different technical concepts and outlined alternative technical architectures for workforce-style user federation.
A lot of the components in this part of the course though incur hourly charges and can get quite expensive if left running.
In the next part of the course, we cover setting up a WordPress site on AWS. We don’t need the user directory or workspaces or mail services for that, so we’ll cover deleting our directory, our workspaces and our WorkMail organization.
- Go to workspaces. Select your workspace and click Delete, and then Delete
It will now transition to the terminating state.
2. Go to WorkSpaces => Directories. Select your directory, drop-down “Actions” and click “Deregister”. The workspace needs to be terminated before this will work.
3. Go to WorkMail, select your organization and click delete. Enter the alias of your org, in my case, acmecorpuk
4. Go to EC2, and click your instance. Drop-down “instance state” and click terminate.
5. Go to directory service and click your directory. Drop-down “Actions” and click “Delete”. Type your directory domain and then click “Delete”.
Okay! So now the only thing left that has some costs is the shared subnets from the VPC. We’ll be using those in part 6. If you’re not bothered about part 6, then you could always just start closing your AWS accounts.
Conclusion
I hope this has been useful! In part 6 we’ll be setting up some workloads accounts, as to demonstrate the actual uses of AWS as a platform for hosting our applications.
