3. Connect Identity infrastructure to Azure AD
Right now, if I go to my Azure Portal, to the Azure Active Directory, and then to users, I will see that I only have this particular user and another user. But where are the other users that I have on the domain controller? This is my domain controller. This is the virtual machine on Azure, and these are the test users I have. How can I see them in my Azure portal? There is also the user I created who is the domain administrator, or WVD administrator, as I refer to them. So in this lecture, I will walk you through the process to synchronize the users with the Azure Active Directory. So we can see the users in the Azure Active Directory. And then, once we can see them there, we can actually start using these user names that we have in this domain controller for the WVD authentication. Of course, there are different scenarios for using Azure Ad Connect.
For example, for us, we do not use an actual domain. We use a local one that is not verified in the Azure Portal. So this is a specific scenario. If you are using an actual domain, you can add the domain to the Azure Portal. But for the sake of this demonstration, I’m assuming that local domain, and thus I will follow the steps for that scenario. So you can agree to the terms and conditions and click Continue. And after that, it says, “Would you like to use the Express settings or just customize it?” I will go with the Express setting, and it will install any required components if needed. Then it will ask me for my Azure AD username and password. It needs the global admin username and password. And then it will ask me in the next step for the Active Directory domain service admin as well: who is the admin of this Azure virtual machine?
So I will input the username and password for my Azure subscription, and then we can go to the next step. And now the username and password for the Active Directory domain service So let me input my admin username and password and click Next as well. So let’s say this is the configuration and this is the Azure Active Directory UPN suffix, and it detected that I have Kelly clouds local and I have a custom UBN suffix as well, which I will use for the login of the users at a later point once they want to log into their desktops. But for now, it says I have this option, “Continue without matching all up and suffixes to verified domains,” because I don’t have any actual domains. It’s a dot local followed by a custom up and suffix.
So I will mark this option and I will click on Next, and after that, it says, “Ready to be configured.” And I will keep this marked: start the synchronization process once the configuration is complete. So once I click Install, it’s going to install the synchronisation engine and configure the Azure AD connector between this domain controller and the Azure Active Directory. It’s going to configure the connector for Kelly cloud’s local enable. The password is synchronized, which is a feature of the Express settings. You can customize them if you click “Customize” on the first step. And it’s going to enable auto-upgrade and configure the synchronisation services on this machine. So I will click Install, and we will check in the next lecture once the usernames are synchronized with the Azure Active Directory. Let’s give it some time. and I will pause this video until it’s completed and come back.
4. Check the Identity Sync
It says the configuration was completed successfully right now, and I lifted for a couple of minutes, so the user should be synchronized with my Azure Portal if I go check. So let’s log out of Microsoft-Azure Active Directory Connect. But, before I go to the Azure Portal, there are a few tools and services you should look into. If you go to the start menu and select “Azure AD Connect,” you will find some services and applications that will help you to control the synchronisation rules, edit the rules, and see and manage the synchronisation services. It is well worth your time to watch these series. Now, if we return to our portal and to the Azure Active Directory and users, we will see that the users have been synchronized. And yes, here are our friends Belle, Pop, Jack, Julia, Mary, Sue, and even the WVD admin that we have created. So this is how we have made the synchronisation between the domain controller we have and the Azure Active Directory.
5. Create Azure AD groups for Azure Virtual Desktop
Now that we can see the company users in our Azure Active Directory, we can start using these user names in our security groups. So at a later stage, we can assign these groups to the hospitals. So I will go to the Azure Active Directory and then to Groups, and I will create some new groups. So the first one will be for Pulled Desktop users. So these are the users who are going to use one virtual machine. As a result, desktop users were dragged. I will call it So this is the group, and I will create this one.
I’ll make another group for personal users at the same time. So personal desktop users mean one user pair and one virtual machine. So we can use it for another hospital just to experiment and try things together and to see how the hospitals will actually have a different type of management and look. So I will create this group and also create another group for the remote apps.
So it’s going to be the remote app users, and I will create this group as well. So now I have the three groups: remote apps, personal desktops, and pull desktops. Let’s assign users to each one of these. So for the pool, I will go to Members and add some of the users we have. So I will add “bell.” You are aware of the users we have. If I go to my domain controller and go to the users, I have these users in my domain controller for the company for our scenario. So I will use Bell and Bob for the pool. So this is Bill and select, and I will also add Bob as well. As a result, I added these two users to the Pole Desktop Users group. Now I will also go to the Personal group for Members and add some other users.
Let’s go with Mary, and let’s also add: whom shall we add? Let’s add Jack. So this is Jack Select, and the third group is the one for the remote apps. Let’s go back to Members and just assign a couple of users there so we can use it for testing. So if I select this time, let’s go with Bell, and let’s also go with Bell first and then with Julia. And perhaps we can include Sue so she is not alone. So hi. There are two options: sue and select. So this group has three users right now. These are the emails that they can use to access their desktop and their remote applications. As if we went to the personal desktops and members right now. So these are the users, and these are the emails they can use once they want to sign in to the machines. So we have created in this lecture three groups, the Personal Desktop users, the Poll desktop users, and the remote apps so we can use them later to assign these groups to the hospitals and application groups.
6. *NEW* – Alternative Identity Option: Azure Active Directory Domain Services
In this lecture, we will discuss the second identity option for WVD. Just a small recap. In our previous lectures, we discussed the WVD identity deployment options, and we had two for the cloud and one hybrid. And these were the three. I will not go into too many details because this has been explained before, but the hybrid one, the one on the Must right, is where you have an Active Directory or a domain controller deployed on your on-premises infrastructure. And then you connect your on-premises network to the virtual network of Azure, and you use the on-premises domain controller for the authentication. This has its own limitations, its own pros and cons.
But the latency is the main thing to consider the two cloud options. The first one on the left is to deploy a domain controller in a hosted Windows Server VM running on Azure, which is actually the scenario we have deployed as our main identity option. The second one, however, is the alternative option, and this one is relatively easy to deploy for your own use of the WVD infrastructure: provision Azure Active Directory Domain Services. So, as you can see, you don’t have to maintain any domain controllers or VMs. You can connect the Azure Active Directory domain services to the same virtual network as your Windows virtual desktop environment. So you can use it, and the VMs can connect to it directly. And it doesn’t need a local Active Directory. It acts on its own. It’s like you are deploying your own domain controller in an Azure virtual machine. Windows virtual machine But the difference is that this is a platform as a service. You don’t actually have access to the VM.
You don’t manage anything. You don’t manage patching updates and so on. It is taken care of for you. So let’s just dig in a little bit to Microsoft before we start the implementation, and I will show you how to provision the services and how to use them. But let’s just see in one paragraph what Microsoft Azure says about the Azure Active Directory domain services.
So, as you can see in the highlighted paragraph, it says it provides managed domain services such as Domain Join, Group Policy, Lightweight Directory Access Protocol (LDAP), and Carper Sentinel authentication, where you can use these domain services without the need to deploy, manage, and patch domain controllers in the cloud. So you can, of course, refer to this documentation yourself. For further reading, just go to Google and search for Azure Active Directory Domain Services. It is going to be the first or second one that pops up for you.
So now that we know the second option, we have had a small recap and have seen the Microsoft definition, or the use cases for the Active Directory Domain Services, which is the second option. So let’s jump into the deployment. What do you need to have set up, and what can you do? What shall you do? The first thing is networking. You need to know that the Azure Active Directory Domain Services require a special subnet. It requires a subnet of its own.
So I will show you the virtual network setup I have already. Of course, you can go to New Services, create a virtual network, and create the subnets. But the structure is going to be the following: I have this WVD network, which I called it, and I have these subnets. You will find three subnets with different IP ranges, so they can, of course, communicate with each other. One of them is the adds subnet, which is the one I will use to deploy the Azure Active Directory Domain Services Service. It needs its own subnet so it can join the VMs to it.
Another one will be a management VM. So I will use it later, as we will see in the lecture, to provision a standalone VM that will be used to manage the domain services. So you will get the familiar interface of users, groups, computers, and so on. the one, the one, the one, the one, the one, the one, the one So the main one for us now is going to be this one, where we are going to deploy the Azure Active Directory Domain Services. So now, let’s start and deploy, actually. The Azure Active Directory Domain Services It is easy, and I will show you and walk you through the steps. We will see them together. The first thing you can do is go to the search page for Azure Active Directory Domain Services and click on it. And because I have already done it, you can see it right here. Let me show you what you will see. So for the service provisioning, you will see you don’t have any Azure Active Directed Domain Services created. So I will click on “New,” and then it’s just a straightforward provisioning where we will see some of the interesting stuff.
So this is for the basics. You can see some information. I would encourage you to read it, and then it’s going to ask you to select a subscription, a resource group. And I have created one already. I called it Azure Active Directory Domain Services Resource Group, or RG. And this is one interesting part where you actually specify the DNS domain name. You can use any name, actually. So let me use this one adds WVD net. So this is the domain name I will use. You can use anyone for your own testing and experimenting. And the reason I’ll limit it to the west-central United States is because SQL is the standard. But for our demonstration, this is more than enough. It provides you with a large number (actually, a large number) of virtual machines to join and so on. And I’ll leave everything else alone; the second caboose is that if we go next, it’ll be the networking.
And you can see that it has selected the Active Directory Domain Services Virtual Network because it is in the same region and the same resource group. And it has selected the subnet with the name that seems to be closest to the Active Directory Domain Services. and I will go next. and this is a very important step for you. It clearly says administration. And it asks you to specify the Azure Active Directory. domain services administrators. So actually here, you specify the user or users who will have admin privileges to do whatever the admin can do on the domain controller that will be provisioned by this platform as a service service. So you simply click on Manage Group Membership, and you can add users easily.
So if I have already created a user beforehand, just a simple creation of a user, I will say “add a member.” So this is a group, and I can add as many members as I want. And I will go and search for Edds. For example, I believe I called it Eds Admin, and I will select it, and I will say select, and that’s it. So the member has been added successfully. Okay, I will go back. So I’ve specified who will be the administrator and who will have administrative privileges. And you can see that you can also explore this for deniability. So we’ll get them, and so on. Let’s go next. And now comes the synchronization. You basically specify if you want the synchronisation to be for everything or scoped, where you can actually narrow down the synchronisation between the Domain Services and the Azure Active Directory. Again, it acts as your domain controller on the Windows Virtual Machine.
So this is why we have synchronization. If we move to Next, it gives you the security settings where you can enable and disable as well as pair your needs with your company’s needs and then tag, review, and create. So once you click on it, it is validating. Everything will be checked for me. Once it’s good, it gives you a green highlight, and then you can create it. To save you time, I’ve already created one for you; allow me to show you. So this is another annual subscription where I have already created one for you with the same name, and we can explore it together. So I went to Active Directory Domain Services. You can see it says I have one provision already. and this is what you will see. Most probably, it will give you a notification about some mismatches in the DNS records. You can just say “detect and fix” and fix it in an automated fashion. It’s very easy. So actually, this is how you provision the service. This indicates that you have a domain controller with the domainEdds WVD net or whatever you entered.
Now, one other important note for you if you want to try this yourself: this will not work properly. Unless you have one of your cloud users, you cannot use the user names and adminusers that you have added to the administration group. And by “cloud users,” I mean a user that has been created in the Azure Portal to log in and change the password. This will actually initiate the synchronisation of the password hashes, which means, in other words, that you can start using the Azure Active Directory domain services properly because all of the passwords will be copied properly between the domain services and the Active Directory. So just remember one of the users—cloud users—and use the one that you have created. It could be the admin that you have created for the Domain Control Administration. Just have them go and actually log into the Microsoft Portal or Portal Office, change their password, and so on.
Then you will have everything ready. Once you have it ready, you can actually use it at a later stage to create VMs and join the VMs to it. One last tip I will give you will be very useful to you. Maybe you will have the question in your mind: “What if I want to control things?” What if I want to change things just as I do in a domain controller that is installed on a Windows virtual machine or on premises? What if I want to have the interface of computers and users and so on? Can I have that? And, yes, it is possible. And this is what I will show you how to do. You can simply create a virtual machine. As a result, I made one for you. The creation of the virtual machine, on the other hand, will be straightforward. Go create a new resource, and you create the virtual machine. You specify a local admin username and password, and then you can use the connect command so you can connect via the RDB to that Windows virtual machine.
Again, this machine is going to be deployed in the same virtual network. But I used a different subnet. If you remember the subnets we had, one was for the management virtual machine, and the first time you look, you will log in using the local user. Why? It’s because you need to join this new virtual machine to the domain so you can later use your admin account to control it. So I have already connected using RDB to the management virtual machine. This is a machine just created to help me actually manage the user’s computers and so on. The first thing you’ll need to do is connect your virtual machine to your domain. So, just as you would with any virtual machine to join any domain, you go to properties here and say this is the computer name and so on and domain, and you can say change settings; it’s a standard procedure. And next to the domain, you can say “change.” And you will use the admin user that you added to the group of administrators for the domain services while you were provisioning that service.
And you just pop it in and say, “Okay,” and it will be joined. Of course, you can see that I have already done that for you for the purpose of the demonstration for this alternative identity option. So once it is added, you logout and log in again. But, mark my words, this time you’ll be using the admin user you added to the Administrators group. Why? So you can install the necessary tools and use them as the domain controller’s administrator. So a very small recap What we have done up to this point is prepare the virtual network using three subnets. We have provisioned the Azure Active Directory Domain Services using a domain name, and we have specified an admin user. Then we wanted to make things even simpler and give you the familiar tools that you usually use by provisioning a standalone virtual machine in the same virtual network where I have provisioned the Active Directory Domain Services. And now I have joined that VM to the domain. So again, this is the management virtual machine. And if I go here, I’m right now locked in as the admin user I specified while provisioning the service. And if you go to Manage and then Add Roles and Features, you know, it’s the same step as you would do with any Windows server. Next, I will not go to the server roles; I will go to the features.
And if you scroll down, there is something called Remote Server Administration Tools, where you can actually install the remote administration tools. And this is the one to choose; simply press market and OK. The next edit will be installed. Why this last step? Simply put, I can show you how to get to Tools. We have done this step so you can go to Tools and you can actually see these, which are familiar to you, I believe, right?
These are the tools and services that you use to administer and manage your domain controller. And this is due to the fact that this management VM is connected to the Domain Controller Services or the Azure Active Directory Domain Services, which is essentially your domain controller in the cloud as a platform and as a service. And because this machine is connected to it using the admin user, it will actually control those Azure Active Directory Domain Services. And let me show you; if I go here, I will see the computers joined, the users, and everything that you would see, like, normally.
