Home / Nerdio Academy / Nerdio / Nerdio Fundamentals: Hybrid AD

Nerdio Fundamentals: Hybrid AD

nerdio author
Ryan McGuireCreative Strategist
0 commentsMay 27, 2019Videos

Joseph Landes
In this session we’re going to talk about an incredibly interesting and relevant topic, hybrid active directory, otherwise known as hybrid AD. At Nerdio, we have many partners whose customers are in the process of moving their on premise environments to the cloud and want to take advantage of the hybrid AD functionality built into our product. This will be the first of multiple sessions covering hybrid AD. Enjoy the session.

Vadim Vladimirskiy
In many cases, especially with larger deployments, customers don’t necessarily want to recreate their existing active directory, and as a result, they want to see if there is a way to deploy Nerdio and have Nerdio be an extension of their active directory. So why is this relevant? I mean, number one, as I mentioned a number of times, it doesn’t require you to recreate all the existing objects, which means all of the existing applications that the users may be using and authenticating with active directory stay the same. The domain membership of any existing VM stays the same. And probably most importantly, it allows a customer or a partner on behalf of the customer to take VMs from one location, let’s say it’s on-prem, and move those VMs via something like ASR or some other replication tool into Azure, even if those VMs are domain joined, because once they come online on Azure, they’re going to be identified by the same active directory IDs and they’re going to … Obviously they can’t run in both places, so you have shut it down on the source, but it creates for an easy way of migrating workloads from one place to another.

Vadim Vladimirskiy
Okay, so let’s look at this thing conceptually. So if we are starting out with an existing active directory environment, let’s say this is a non-prime environment. So let’s call this AD on-prem. And there is a domain controller here. So let’s call it ADDC. Okay. Then we have an Office 365 environment up here, which is Azure AD. And now we’re going to create a new Nerdio environment over here. So this is going to be Azure/Nerdio. And we’re going to spin up this environment and we’re going to place, as always, a DCL1 in this environment and by the default the domain, the AD on that DCL1 is going to be Nerdio.int. Although now with [White Label 2.0 00:00:03:10] that is something that can be changed, so it could be another name. But let’s just use Nerdio.int as an example.

Vadim Vladimirskiy
When this environment, the Azure/Nerdio … I said Nerdion, but Nerdio environment is provisioned, we are able to plug into the Office 365, and then any user accounts, so let’s say there is chatceo@somenumbernerdio.net. Okay, no, this is not Nerdio.int because that’s a fully qualified public domain name. So this user is going to be synchronized and it’s going to appear in here as well at that same email address. So this is what happens when you provision an account. Nothing different.

Vadim Vladimirskiy
Now, let’s say you have a non-premise AD, which may or may not be syncing with an Office 365. Let’s say this. Because for a large environment that’s already using office 365 that is complex and large enough that wants to keep their existing active directory, there’s a good chance that they’re already syncing with Office 365. Everything works similarly if they’re not. There’s just fewer things for the automation to worry about, but let’s, for the purposes of this illustration, let’s assume that they are. So we have this AD connect that is doing synchronization from this domain to this domain. Now, when Nerdio comes online, it has this unique, local unique domain name, whereas user accounts in here have some sort of other domain name. It’s probably company.com or something like that. So there is no conflict between users at this domain and this domain. So when they synchronize, they both happily co-exist in the same Azure AD tenant.

Vadim Vladimirskiy
All right, let’s keep going forward. So now, so we have this environment, we just provisioned Nerdio, and now what we want to accomplish is we want to take this existing active directory and we want to extend it into the Nerdio/Azure deployment. So let’s give this domain a name. Let’s call it, we refer to it as EAD, which stands for external active directory. So let’s call it EAD.local, just for illustration purposes. So this AD is called EAD.local. When we create the hybrid AD, when there is … there is a new domain controller that gets created inside of the Nerdio deployment called EAD-DC01. It could be renamed to something else. And it becomes a domain controller for this existing domain.

Vadim Vladimirskiy
So basically we have a site to site VPN between these two environments. So there is a site to site VPN. And then this new VM gets provisioned, which is a domain controller inside of the existing active directory. This then gets promoted, so it gets added as a member server, it gets promoted to the domain controller, but it’s residing inside of Azure within the purview of Nerdio. and then Nerdio becomes aware of the various objects that are now available inside of the EAD, that local domain. So the NAP, as we’ll see in a few minutes becomes … The context of NAP is now aware of both the default domain it was provisioned with, which is that Nerdio.int, as well as EAD.local, which becomes a new domain that is added when hybrid AD is created.

Vadim Vladimirskiy
Okay, so what does this now allow you to do? What this allows you to do is you can take user objects which exist within this domain right here, within the EAD.local domain, and then you can entitle them to various resources within the Nerdio.int, or you can spin up new servers, you can add new user objects. You basically have one central management interface, the Nerdio admin portal, that cannot only manage Nerdio.int resources, but can also manage the EAD.local resources. So conceptually this is what we’re trying to accomplish. We’re trying to con create this connectivity right here between Nerdio and an on-premises active directory.

Vadim Vladimirskiy
Let’s see from a NAP perspective what a freshly provisioned NAP account or an NFA account looks like. So if you look at this account, this is something you’ve seen many, many times. If you look under users, you don’t really notice anything different. There isn’t an indication of what domain these users exist in other than if you click on the name and you look at this username field, it will tell you what this domain is and you can see it’s the same as this domain, which is the result of it being a UPN and AD. But anyway, this is what a clean environment looks like with the Nerdio.int domain out of the box. So if you wanted to create a hybrid AD, you wanted to extend an existing active directory into this interface, you would start out on the domain screen. You would come in here and you would click this button that says add domain trusts.

Vadim Vladimirskiy
So the first component or the first step into making this happen is creating this domain trust. Now, it says it’s domain trust, but there’s a lot more than happens and I’ll walk you through that in a minute. But from a UI perspective, what does a user or partner have to do? It’s really, really simple. So you come in here, you obviously need to have a VPN in place already. Once you have a VPN in place, you come in and you specify the IP address of the domain controller, that is the EAD.local domain controller. You give it the username and password that has admin rights on that domain. And then you click the test connection button.

Vadim Vladimirskiy
Clicking test connection really performs a very extensive set of validations and makes sure that the server is reachable. Makes sure that it can execute scripts on it. Makes sure the username and password is correct. Makes sure the functional level of the domain is right. It also tries to validate that it has access to DNS because DNS is a core component of active directory working, so by default the assumption is it’s running on the same domain controller as the IP address that will be specified here, but if it happens to be running somewhere else, there is an option to enter the IP address. Again, this would be in the on-prem environment. So you test this connection, it goes through a bunch of validations, gives you a bunch of check boxes that basically say everything passes, and then once that happens, you will see the EAD.local domain listed in this dropdown right here. That just means the validation was successful. And then you have one other option to make. Again, the default is when you click save, a new domain controller will be spun up in Azure and it will be called EAD DCL1. If somebody has an issue with the naming convention and wants to use something else, they have the option to name that server something else.

Vadim Vladimirskiy
So that’s really all you got to do. Give it the IP of the domain controller, credentials, test the connection, click save, and Nerdio will go in and perform a whole slew of operations and automations to spin up a domain controller to add it to ead.local domain, promote it to be a domain controller, and do lots of other stuff, establish a trust, et cetera, et cetera, et cetera. So that’s going to be performed.

Vadim Vladimirskiy
Now, let’s see what actually happens. So we have this article, this KB article on our site that describes the hybrid AD process in really great detail. We wanted to create as much transparency as we could, even sort of exposing a lot of the secret sauce that Nerdio has as far as this action goes because we want people to be comfortable with what’s actually going to be happening. Because this is now plugging into potentially a production environment and they want to assess the impact that it may have. So it’s obviously a very non-disruptive thing, but anytime someone gives credentials to their existing active directory, it’s obviously a bit concerning. So we created this extensive article that gives all the background and the specifics. So we covered much of this. We covered the background as to why you would want to do this. We covered the terminology. There’s Nerdio AD, which is typically Nerdio.int but can now be changed. Then there’s this external AD we talked about.

Vadim Vladimirskiy
Preparing to set up hybrid AD. You need public IP address of the firewall, you need the ability to set up a VPN tunnel, you need to know the name of the external AD, you need to have credentials, you need to know the DNS server IP address. All the kinds of things that anybody who manages an active directory will really know off the top of their heads. So nothing really complicated here as far. As setting it up, there are four steps. The first one is simply adding a VPN tunnel. We’re not going to spend any time on that now. We’ll deal with it when we talk about VPN, but suffice it to say you simply click the on button to enable VPN in Nerdio. Then you click to add a connection. Type in the IP address and the local network for the on-prem environment. Then do the same on the on-prem environment side and your VPN is up. So really super simple.

Vadim Vladimirskiy
Step number two, setting up this domain trust. So this is the set of steps we just went through. Specify the IP address of the domain controller on the other side of the VPN. Login credentials, click test. It then goes through these validations to make sure everything is in order. And then once everything is validated, the save button becomes highlighted, and click it, and it’s going to perform all of these tasks. So first it’s validation. Make sure the site to site VPN tunnel is up and the the domain controller on the other end is reachable. Make sure that the AD functional level is 2008 or higher. Make sure that the DNS server is reachable and also validate the credentials. Kind of simple.

Vadim Vladimirskiy
Then it’s going to create a new VM in Azure to be used as this domain controller. The default name is EEA DLC1, but it could be overwritten with some other name. It then will create a brand new OU in the existing active directory. So in the EAD.local. And it’s going to call it users and groups. Hopefully there isn’t one by that name already. There obviously shouldn’t be, it’s not a default name or anything like that. So that’s what it creates. It will then create a new administrator account that’s going to be called Nerdio administrator. It will place it inside of this newly created OU. And it’s going to make a domain admin, schema admin, enterprise admin in the existing domain. So that’s going to be the user whose going to perform all of the actions.

Vadim Vladimirskiy
Then it’s going to do some DNS work. I’m not going to dig into the specifics of how this DNS has done, but it’s going to add some conditional forwarders in a couple of different places. It’s going to join this newly created VM to the EAD.local domain. It will then promote it to a domain controller with DNS. So now it becomes another domain controller in the environment. It will create the necessary AV replication sub net in sites and services, and the connectivity, and then it will create a two way domain trust between the NERDIO domain and EAD domain. So by the time that process is done, we will now have the ability to allow AD resources from the external domain to be seen in Nerdio and vice versa.

Vadim Vladimirskiy
Now, by doing step number two, which is enabling the domain trust, the only thing that’s going to change is that we are going to have a new entry. We’re going to have a new entry here that’s going to say there is a domain trust that’s been added. This NAP managed field is going to be set to no at this point. And then we will see a brand new server that is going to be listed under servers. Other than that, from a user experience or UI standpoint, nothing else really changes in the NAP. So all we’ve done so far is set up a domain trust, but we did not yet grant Nerdio admin portal visibility into that external domain.

Vadim Vladimirskiy
So let’s go to the next step. The next step is going to actually be setting that trusted domain as what we call NAP managed. So sending it as NAP managed is what changes the UI in the Nerdio admin portal to make it aware of that there is a new domain in place now and now you can see and manage those objects. Again, super simple. You now have this entry that I’ve described, it’s going to be NAP managed, it’s going to be no at this point. There’s going to be a highlighted button, so NAP set as managed. You click there. And then the next question is what happens with Azure AD connect? Okay, so remember we made the assumption in our diagram that I was doing on the whiteboard that since it’s a large enough environment that is warranting to do a whole hybrid AD deployment, they’re probably synchronizing that AD with Office 365 already. And we kind of accommodate all scenarios.

Vadim Vladimirskiy
So scenario number one basically says, hey, Azure AD connect is running on that very same domain controller whose IP address we specified up in this step right now. It’s a pretty decent assumption but may not always be the case. The other option is AD connect is running somewhere else. So you can type in the IP address of that AAD connect server. Or you can say, look, I don’t have it running anywhere else. I want to run it on this newly provisioned DCL1 or EAD DCL1 VM from this step right here. So those are the three options for AD connect. Now, why is AD connect question even coming up with this point? The reason for this is because when Nerdio manages user objects and group objects and contacts and mailboxes, it needs to be able to trigger AD connect to do a synchronization after any changes that it makes to the local active directory. So it needs to be aware where to send those synchronized commands when it’s making changes, and this is what’s going to tell it where that AD connect is running. And then you click confirm.

Vadim Vladimirskiy
It validates that it can in fact reach the server that you’ve specified, either this one, one in another IP, or the newly created one. It also tests that AD connect is installed and running, so it will run some powershell commands to make sure that’s working. And then once that happens, then NAP performs a bunch of other functions. And I’ll go through that in second. This all happens in the background. The user has to do nothing other than click set as managed, select one of these boxes, and click confirm. That’s all they have to do. On the back end, the validation is connectivity to AD connect server and ability to execute powershell commands. If it’s not currently installed, then it should be installed in this server that was provisioned earlier. Then there is another DNS conditional record forwarded that gets added in, some additional DNS work that gets done. This Nerdio administrator gets added into some additional groups in the EAD domain. We are now enabling the DCL1 to service licensing requests for terminal services in servers in another domain, which is what’s necessary because DCL1 is this RDS licensing server.

Vadim Vladimirskiy
And again, nothing for the user to do. The alternative to what’s happening here automatically in the background is something that an administrator would have to manually execute. And each one of these steps is multiple powershell commands and and lots of complexity. So again, hopefully you appreciate how much simplification there’s here. Nerdio.int, we’re doing some work with the UPN suffixes, enable UPN suffix for routing. Create additional sub OUs inside of that users and groups OU. So for instance, when Nerdio manages the environment, it manages things only within this OU. So when it writes a new user or when it views users, it’s only users that exist within this OU and nowhere else outside of this OU. Just to keep the scope of Nerdio limited to an OU structure as opposed to the entire domain … entire structure.

Vadim Vladimirskiy
There’s some GPOs that get created and linked, there’s security groups, there is some RD gateway routing stuff, there’s some additional security work, et cetera. So some routing policies. So all of that happens in the background. And then once that happens, the UI in Nerdio changes. Let me show you what it looks like once that happens.

Vadim Vladimirskiy
So step number one, we now have this line item in here. And this line item tells us we have a new domain trust. Here’s the IP address of the domain controller that we initially linked with. It is managed by SLC or NAP depending on if it’s white labeled or not. And we can see when it was created. We’ll talk about importing users in the bit, but for now I just want to show you that there is an edit button, that if you at some point want to move AD connect somewhere else, you have the ability to make that change right here.

Vadim Vladimirskiy
So this is one tiny place where things change. But throughout the UI, you will now notice another active directory entry that didn’t exist before. So if we look under users in a non hybrid AD environment, there is no indication of what domain those users live in. Whereas if you go under users in a hybrid AD enabled environment, you can see the active directory of each and every user object. Same thing applies to groups. Same thing applies to contacts. So you can see again, there’s an active directory column. So you see most of these are in the default domain, kind of the Nerdio.int equivalent. But here’s one that was automatically created in the EAD domain.

Vadim Vladimirskiy
If you look at servers, you have a similar picture. You now can view what domain that server belongs to. So we have all of our servers belonging to the original domain. This is the Nerdio.int equivalent, and we have our EAD DC777 that obviously belongs to the new hybrid AD domain that’s plugged in. And the really important thing is now when you add a server or you add a user or you add a group or you doing anything else that basically interacts with active directory, there is a selection box that’s available that will always default to the EAD. And the reason is if someone went through the trouble of enabling EAD, that’s probably what they want to be using. And they don’t want to be using the Nerdio.int or equivalent domain.

Vadim Vladimirskiy
So when you go to add a new server, for example, it prompts you and asks you, okay, what active directory should this server be placed to? And by default this is always going to be set here. So when you give it the name and click okay, that server will be spun up and it will be added into this domain. And obviously it’s going to be listed in this screen, having this active directory domain name next to it. Similarly, if you go and let’s say you decide to create a group, a brand new group, which is not the common, because you already have all of these groups probably, but I just want to illustrate this here. Let’s say you’re creating a security group. So again, now, where should this security group be created? Now you have two choices. You have the EAD or you have the existing domain in here.

Videos in the series