Working with on-premises directories
During this course we will explore the enterprise applications that AWS provides, including Amazon WorkSpaces, Amazon WorkDocs and Amazon WorkMail. We will start with a basic overview of each service, one by one, then move on to a more practical experience by demonstrating an integration of all these services with an on-premises network, and a discussion of the available options to configure these services to make them suit your company's needs.
We assume you have some pre-requisites for this course. You need to have some general IT understanding plus some AWS knowledge, including the core AWS services such as EC2, IAM, and VPC. In addition, because all the services in the enterprise applications category make use of the Directory Service, you will also need to be familiar with this service.
This course is for anyone getting started with the AWS cloud, but is particularly geared toward systems engineers and windows administrators.
Hi, and welcome to this lecture. This lecture is all about integration of the Enterprise applications with your on-premises network. So in the first part of this lecture, we'll talk about the plan. I will show you the architecture, and we will also talk about the main considerations that we need to be aware of prior going ahead and deploying the solutions. Then we'll have a demonstration on how to deploy the solution.
So in here we can see these two squares, the corporation, our business, and AWS. And inside our corporation, we have our customer network and inside of this network we will have our desktops, we will have some servers, could be file servers. We would have our domain controllers. Because we don't want to save our company data in the cloud, so we had to have our domain controllers with our users and passwords and our file servers on premises. That's okay, and that is a very common scenario out there.
Our users would access our desktops. They would go through the internet and access WorkDocs, WorkMail, and WorkSpaces, and would have access to the internal service within the network. On the other hand, we would have some users outside the company accessing our resources such as WorkDocs, WorkMail, and WorkSpaces, and they would be connecting via mobile devices or even working from home with their personal computers. And we can see here that we have a VPN connection between our customer network and our VPC, so from my WorkSpace machine for example, I would be able if I want to, if I'll allow to to ping my file servers, so you could also grant access from your WorkSpaces machines to your file servers. That's also common. And to do all that, to have our domain only on premises we would have to configure an AD connector here. So we can't deploy everything. I would love to have a very similar deployment to show you right now. What we'll do is, I will create two VPCs and I will integrate them to simulate a VPN connection. And one VPC will have only a couple of domain controllers to simulate our on-premises network. Our domain will live inside this network and the other network will have a couple of private sub-nets and a couple of public sub-nets where we'll launch our directory service and also launch our WorkSpaces machines.
So let's go ahead on the AWS console and see how we can deploy this solution. I don't want to deploy everything by hand, so the first thing that I will use is this quick start guide from AWS, in our case we are going to use the Microsoft AD domain services. And if we click here we can see the architecture. We can see what we are going to deploy with this template. We are going to deploy a VPC with a couple of sub-nets. For high availability, we will deploy a couple of net instances and some remote desktop gateways. So let's click here on quick launch and we are going to be forwarded to the cloud formation page. And we can see here that we already have the URL for the templates, so what you need to do here is just click next and insert the information of our domain. In this case, I will change the stack name, put "Customer Network," and I will change the password. So click next, next again, and create.
Also to simulate our cloud VPC, I will launch another cloud formation template. I will launch a template that is available on the GitHub repository that I show you in the first lecture. So what we need to do is download the repository, choose the file and in here we will deploy this template, public, private, VPC. And what this template will do is basically create a couple of private and a couple of public sub-nets inside the VPC. So I will call it our "cloud VPC." Create. Now we need to wait of course until our stacks get deployed. So I will stop the recording and come back once it's done.
So our stacks were finally created. We can see in here the results. There is really nothing to see in the cloud VPC stack. What is important in here to see is the customer network stack. We have some useful output. We have in here the elastic IP from the remote desktop gateway which we are going to use.
So what a gateway does is to function as a step into the connection. So I really want to connect to the domain controller in the first availability zone which is DC1, but instead of opening the connection directly to this domain controller, we're choosing a private sub-net. I can either create a Bastion host to function as a host that I will connect, and inside this host I will open another connection or I can use it directly as a gateway. So I won't use the gateway as a jump host. I will be connecting to this host but I will only be using this connection to get a connection to the domain controller which is the machine that I want to use.
To do that we need to connect first via HTTPS to the server. Unfortunately, AWS has a problem in this template and we need to manually allow us to connect via HTTPS to this address. So let's do so very quickly. I'll go on VPC, and in here we can see the security groups and this is the security group that we need to change. It's the remote desktop gateway security group. We just need to quick add another rule. So I will add the HTTPS, and allow it to everybody. Okay, it's done. It's configured.
Now, let's connect to our machine. I'll create a new connection to a DC1. We want to connect to DC1. This is the default user name, the default password which is Password123 with a capital P and we need to configure in here a gateway. So add a gateway. So it will be my remote desktop gateway one. This is the elastic IP. And I will not provide a user name or password in here because it will be the same. So I can close and, wait a sec. Change the resolution, and we are ready to go. I apparently...ah, I didn't select the gateway. My bad, and start. We have to click on continue because it will bark at us because of a field self-signed certificate. But anyway, we'll have access to our domain controller and that's what we want.
Okay, we have access. And let's take a quick look in our domain, in the objects that we have created in here. I will go to users and computers real quick. Example.com is our domain, and in users, we have a few pre-populated users. These users were created during the creation of this domain. So they are here for us to test but yeah, I miss my Josef Kimber user, so I will create him. Set a password. What I also want to do is give my user domain admin permission. This is not needed but that will help me a lot. So right now Josef Klimber is a domain admin.
So we have our domain. This domain is entirely hosted in the EC2 service inside our instances. It's similar to what you have in your on-premises network. So let's now connect both VPCs together, and we can do that by going here in peering connections, create VPC peering connection, let's tag it CA Cloud Academy. And we need to select a local VPC, in this case, it's this one is the VPC10, and we want to connect with another VPC in our account and is the Cloud VPC. So right now basically, the behave like they were in the same VPC as they would behave if they were in a VPN connection. Let me click in here a set, and our connection is active.
Now we need to create some routes to the other network and we do that by going on route tables. We have these route tables from the 192 network which we are going to also edit. We click in here, we need to add another route, and the route is that we are going to forward everything that is going to the same network through the peering connection. We do that for the public as well. And now we have also to change things for the same network.
Okay, so let's now configure directory service to connect to our domain. This time, we are going to create an AD connector and the process is slightly the same. We have to put the DNS name of the domain, NetBIOS name, and in here we have to provide an account, a privileged account. This account basically needs to have permission to join computers to the domain and also read the entire domain. It doesn't necessarily need to be a domain admin, but in this case, I will use the JKlimber account to make things easier for us. I will put the DNS address from our service, in this case, will be the DC service. We can grab the address in here. And another thing that we need to do is, since we have security groups associated with these domain controllers, we have to grant access to the directory service. I will do it by creating kind of a general rule allowing all the connections coming from the 192 network. Let me put in here, all traffic. And I have to do the same for the domain controller too because we have two distinct security groups for them. That's not what we would have in a production environment, but that will work for us in this lab.
So now we have to select the VPC which we are going to use to launch the directory service and AD connector will be our cloud VPC and we have to select the subnets. Create AD connector. It will take a while so I will stop the recording and come back once it's done.
So our domain is active. We can see in here it's connected to our kind of on-premises domain, let's say that. So now let's go to the enterprise applications and start launching new things. I will start by the workspace service. Click on Get Started. We can go on advanced setup and we would have to create a new directory or AD connector, but hey, we already have that. So we can just simply click on cancel and we will be forwarded to this page. And in here we could simply click in here and register our domain as we did in the WorkSpaces lecture, but I will do it differently this time.
This time, I will go on the directory service. I will select our domain, and remember that we talked about an access URL, here is where we can define it. So I really don't like of our domain name example. It's too simple, so let's create something more expressive. I will use Cloud Enterprise and create the access URL. And we can just create it once. We can't modify it afterwards. And right now if we go back to the WorkSpaces service, we can click in here, register, and enable Amazon WorkDocs as we did in the last time. And in here we won't see much of a change. We can go here, launch WorkSpaces, select our directory. And here we now have users, actually users. I will use the JKlimber user just because I like him. And click on next. We need to select the value package, not need to select the value package, sorry. I will select the value package because it's the cheapest one. I won't encrypt anything and launch WorkSpaces.
While it's launching I will also go to WorkDocs and it can see in this time that we are using Cloud Enterprise, not Example as it would be if we just registered the domain on the WorkSpaces service, because we defined the access URL in here so that's why we have this time kind of a custom URL. What I'll do is click here, and I will set again an administrator, our JKlimber user, and go to the URL, put my password. Notice that this time I didn't have to configure my email or something in order to create a password because I will have already the final password in my domain inside the domain controller. So it's all integrated in here. And we have Amazon WorkDocs as we would expect.
Let's now go to WorkMail. Let's create our organization on WorkMail. Get started, again custom setup. Select our directory, the inscription key, and we have to wait a few minutes. So I will stop the video and come back once it's done.
So we created our organization on WorkMail. I'll click here and quickly add a new user. Again, guess what user? JKlimber. Enable email for him. Well, nothing new here. What is new is on groups. If we click in here add group, you'll see that these groups are the groups that we have on our domain. We can't create groups in here anymore. So to create a developers group, for example, as we did on the WorkMail lecture, we would have to create first the group on the domain.
So let's do this. I'm here with my domain controller. I will again go to users and computers and let's create a new group in here. Let's create group Dev. Okay, it's created. Let me now go back. So okay, now we have Dev. We can select, next, again, Dev, and enable. And just notice that in here we don't have anything different.
To finish our lecture, let's just connect to our WorkSpaces machine. Again, we have to copy the registration code, open the app, register our machine, put our username, password, and we are set. And real quick, just to show you what we have here, first, we won't have any internet connection, because remember that we launched our directory in a private sub-net. That's right. We have a private sub-net and we don't have any net gateways or net instances in order to forward our connections to the internet. I did that just because we won't need it. You just have to configure it if you want, and also you could configure it forwarding all the connections, all the internet requests to your on-premises network. So you could monitor all the internet requests on your on-premises network using the same firewall rules that you are applying to your on-premises network.
So close here and quickly show you that we can, for example, make a ping to the DC1 or DC2 because again, we are in a different network. We are in the 192 network, but we have configured the route tables accordingly and we have configured our peering connection. So we have access to the other network as we would have access if the domain controller was in the on-premises network.
I hope you enjoyed this course, and I encourage you to leave us a comment below telling about what you think about this course. Thank you, and see you in the next course.
About the Author
Eric Magalhães has a strong background as a Systems Engineer for both Windows and Linux systems and, currently, work as a DevOps Consultant for Embratel. Lazy by nature, he is passionate about automation and anything that can make his job painless, thus his interest in topics like coding, configuration management, containers, CI/CD and cloud computing went from a hobby to an obsession. Currently, he holds multiple AWS certifications and, as a DevOps Consultant, helps clients to understand and implement the DevOps culture in their environments, besides that, he play a key role in the company developing pieces of automation using tools such as Ansible, Chef, Packer, Jenkins and Docker.