 G'day viewers, my name's Oren Thomas. I'm a principal hybrid cloud advocate at Microsoft. And joining me today is... Hi everyone, I'm Sonja Cuff. And yeah, I'm in Brisbane, Australia. Oren and I are looking forward to talking to you about implementing hybrid identity with Windows Server. And what we are going to do first is introduce you to our moderator, Christiane. And I hope I've pronounced that right, mate. So sorry if I've completely bollocks it up for you. You can connect with Christiane on LinkedIn at the URL that's on the screen there. Okay, Sonja and I are going to talk about implementing hybrid identity. And one of the reasons that we actually chose this particular topic is that this is associated with this newly announced Windows Server Hybrid Administrator Associate Certification that we'll be going into beta some time in the next few weeks. So keep an eye on the MS Learn blog for that and our social accounts for that because you can get on the beta and actually take these two exams before they become generally available. And it should become generally available some time in the next, become available some time in the next couple of months. The other thing that we want to sort of highlight is that this particular module is related to one of the functional groups in the first exam here. And you can see here, the first functional group which is Deploy and Manage Active Directory Domain Services in on-premises and cloud environments which is all about hybrid identity. What else is hybrid identity about, Sonja? That's a good question. All right, look, there's a few ways to set up sort of hybrid identity and that's kind of the focus of this module, right? So it's going to talk about a few of the different ways that you can set up. Identity services, if you've been using them in your environment on-premises and if you're now using products and services in the cloud. Absolutely. Okay, so what we're going to do and this is a learn live module and the idea with a learn live module is that what Sonja and I are going to do is we're going to work through a Microsoft learn module that you can basically take to the link we sort of earlier and it'll obviously be associated with the paraphernalia around this particular presentation. So with a learn module, what we're going to do is Sonja and I are going to talk about it and we're going to point out some things that we find interesting about it. So at a very high level, Sonja, would you like to read this introduction? Yeah, absolutely. So this is what we're talking about. We're talking about configuring an environment that you've got inside Microsoft Azure so that your Windows Server infrastructure as a service workloads that require Active Directory are supported. So in essence, what that means is that if you're going to set up a virtual machine inside Azure that's running Windows Server on it, but you want to connect that to Active Directory, how do you go about doing that? But we're also talking about how you can integrate some of that information that's already inside your on-premises Active Directory or ADDS into your Azure environments. Now, here's a sort of a sideways question for you, Sonja. What is an identity? That's a really good question. Look, an identity is basically just a representation of something that is going to make a connection to a different system. So an identity might be a user. It might be a device. It might even be an application or other system that can have an identity as well. So if it's going to connect to something else, it needs to go through this process of authentication. So it needs to prove that it is valid and accurate. And then also that it does have the right access to the thing that it is trying to access or act against. So this is what we're talking about when we're talking about identities. Cool, okay. So the scenario, we don't really need to go into too much detail here other than to say that Contoso wants to do hybrid identity and that they've got a bunch of stuff on-prem and they're not getting rid of that on-prem stuff and they want to run a bunch of stuff in the cloud. And what they want to make sure that they can do is essentially use the same identities on-prem and in the cloud. And this has always been sort of a bit of the grail about dealing with identity is when I got started in IT, I remember wandering around the University of Melbourne and I'd walk into people's offices and they would sit there and on post-it notes, they would have six or seven different log-ins for different university systems because there was no unified identity. What we're trying to get to eventually is that you've got one identity and you can use that one identity to access your on-prem stuff, your cloud stuff and then your partner cloud stuff like a Salesforce application or something else that's running as software as a service. So in this particular module, we're going to go through the following learning objectives. Sonny, do you want to go through those? Yeah, so we'll talk about how to select an Azure AD integration model. There is more than one way to integrate your environment with Azure. So we'll talk about what your options are. Then we'll talk about how to plan for your Azure AD integration and some of the sort of prerequisites which leads nicely onto preparing your on-premises active directory environment or ADDS for that directory synchronization. So copying this information about identity up into the cloud. Then we'll look at install and configuring directory synchronization using Azure AD Connect. So the mechanics of actually installing Azure AD Connect in your on-premises environment and getting that set up. And then we'll talk a little bit about implementing seamless single sign-on. We'll also then go through enabling Azure AD login for an Azure Windows VM. So if you put a server up in Azure and you want to be able to log in using credentials that are stored in Azure Active Directory instead of a normal domain AD, how do you go about doing that? We'll describe Azure ADDS, what that is and how that's different. So you start to see a few of the same terms in this and you don't wanna get confused between ADDS and Azure ADDS, but we'll talk about what that is and then how to implement and configure Azure ADDS. And then finally we'll look at managing Windows Server 2019 in an Azure ADDS instance and how to join a Windows Server VM to a managed domain, this Azure ADDS environment that we've been setting up. So this module is pretty comprehensive. There's quite a lot that we're going to be going through. If you've got any questions as we go, if there are a few of the sort of identity components that are getting a little bit confusing and you don't quite understand the differences, now's the time to jump on the chat and ask us. You've got Orin and I here live to answer your questions. If we're not explaining something correctly, if you'd like a little bit more information about how it applies to an environmental scenario that you might have, pop in the chat, ask us a question. And we will acknowledge that it is Thanksgiving in parts of the world, not Thanksgiving in Australia because none of the European settlers were particularly thankful about the fact that they were getting mostly sent here as a present colony. That was funny, Sonia, you meant to laugh. Look, I'm thankful for being here as an immigrant to Australia, so let's just go with that. Okay, no worries. Sonia's from New Zealand. That's why her accent is strange and mine is perfectly normal. Okay. Yeah, you do. Okay, anyway, so the first thing we want to go in is talking about understanding or selecting an Azure Active Directory integration model. So this first sentence right here is really, really, really important. Yeah. As your AD is not ADDS in the cloud. Instead, it's an entirely new directory service designed for cloud-based and web-based applications, which shares some, not all functionality with ADDS. Okay, so Sonia said in the introduction that it was really important to understand that we were almost talking about three separate things here. We've got on-prem ADDS, and that's what we call it, we call it ADDS, but usually we just go Active Directory because that's what we've called it for most of the last two decades. Then we've got Azure AD, and Azure AD is this completely cloud service, and that, as it says here, is designed for cloud-based and web-based applications. So you've got users there, and you've got groups. And we'll be digging a bit more into that a little later. And then you've got this third weird thing that also exists called Azure ADDS. And that's a managed form of on-prem Active Directory, except for it's designed specifically for virtual machines that are running in Azure. So you can't use Azure ADDS and Domain Join an on-prem virtual machine to that, but what you can do is you can Domain Join a VM that's running on a virtual network in Azure there. So let's go into an overview of Azure AD. And Sonia, do you wanna give me an overview of what it is? Look, the main thing to get your head around, especially if you're used to an on-prem Active Directory environment is there are no domain controllers for Azure AD for you to manage. So you won't be able to go in and see where are my domain controllers? Is replication happening to different regions in Azure to make sure that my identities are synced globally? Like, none of that is visible to you and it works slightly differently behind the covers. So that really does make it a platform as a service offering. And that basically means that Microsoft is doing all of that management for you. So we make sure that the system's up and running and all of the redundancy and the resilience is built in. So you don't have to worry about any of that. It does look fairly similar. As you said, we've got some familiar things like users and groups, but there are also other things in here like Azure AD Connect, custom domain names. We'll talk about custom domain names because that's a pretty important thing. But in essence, Azure AD is acting as an authentication service. So it is going and validating login attempts to prove that they are accurate and valid to be logging in. What does it say down the bottom here? You've also got a set of features that are not natively available with ADDS. So this is where the power of the cloud comes in. When you have your identities in on-prem AD, Microsoft has no visibility of what's going on inside those systems. It can't see when users are logging on and if there's any potential issues with those sign-in attempts. But with identity synchronized up into Azure AD, when you're logging into that cloud-based authentication, we have visibility of not only your tenant but across all of our environment and what about what's happening against that authentication platform. So that means we can do things like turn on multi-factor authentication, have a look at those things and see whether or not there's anything risky going on that should be blocked. And there's a whole bunch of cloud features like being able to implement custom band passwords and a whole bunch of other features that you can now get because that identity is based in the cloud. Now, you can see here that it basically says the following things that you can also provide are configuring access to applications, single sign-on, as Sonia said, users and groups, creating users, enabling federation between organizations and we'll talk about that. It's not just something in Star Trek. Providing an identity management solution, identifying unusual sign-in activity which is a really cool feature that you can't do with on-prem AD. How you extend your on-premises AD to Azure AD, how you configure application proxy for cloud and local applications and how you configure conditional access for users and devices. So conditional access is one of those special ones where you say you can have access but only under these conditions instead of on-prem AD, which is you pop in your password and you sign on. With conditional access, it's well, you can type in your password and sign on but only if you're coming from a managed device from an on-location at a certain time. The next thing to understand is the idea of what a tenancy is and probably for a lot of you, how that maps to an on-prem forest. Unlike traditional on-prem AD, Azure AD is multi-tenant by design and it allows you to have isolation between its individual directory instances. Now to give you an idea of what that's sort of trying to tell you, the first is that Azure AD, even though it exists or it appears to exist as a monolithic service, it doesn't mean that when you open up the Azure AD console and you go to the user's list, you see absolutely every user in Azure on the planet instead. And look, I think IT pros who have already dealt with deploying software as a service applications for the organizations are a little bit used to that. So if there's a third party cloud-based service that I'm using, sure, when I go into the admin pane of that, I hardly wanna see my users. I don't wanna see the users for every single person that's using the platform. No, and there's actually more than a million separate tenancies in Azure Active Directory. And the term tenant usually means a company or organization. Now, the tricky one here is that you can actually have multiple tenants associated with your organization. You can actually have multiple directories within a subscription, though at any time and as your subscription must be associated with only one as your AD tenant. However, you can associate the same as your AD tenant with multiple subscriptions. That's clear, isn't it, Sonia? No, it's really not. Look, I tend to think about a subscription as being a billing and a management container more than anything else. So any resources that I put in the same subscription are going to appear on the same invoice or go through all my credit card as a pay as you go thing. And I can control the security of access to resources at a subscription level. So I could have a subscription for all my developers and I could have a subscription for my production environment and I could give developers lots of access to the development environment and not so much access to my production environment by doing that at the subscription level. But then it gets a little bit interesting when these directories come in because as you said, I'm not creating more than one as your Active Directory, like, or am I? Or it means that I can't swap between the two. Like, yeah, that one's a little bit of a mind bend. So another way of thinking about it is if you're used to the idea of resource domains or resource forests. That is that with on-prem directory, you can actually set it up so all of your accounts sit in one forest and then all of your resources, all of your servers, everything else, sit in other forests. So all the first forest does is host accounts and then there's a trust relationship that allows you to log on to and access all of the resources in the other one. So you could almost think about those separate resource forests as subscriptions that are associated with that first particular forest. Now, the next thing that comes along that's important is the idea of a default DNS name. But let's go, we've just got big Aunt Rod here who's got a wonderful name and he's, or she has asked, Office 365 Business Premium. A lot of these AD features come included for free, correct? Well, the answer is kind of because obviously if you've got a business premium, it's not free, but yes, they're included with that level of subscription. So coming back to this default DNS name, where do we get our default DNS name and how's it chosen, Sonia? Oh, look, it's, to start off with when you set up your first environment, you're going to get a domain name which is somethingorother.onmicrosoft.com and it's just the easiest way of getting an environment established that you can then go and claim to be your own. So it creates this kind of random name based off of the email address that's being used to first create that environment. But after that has been created, if you've got scuffandos.onmicrosoft.com, you can then go and add in your own custom domain name, which is the domain name that you've been using for your organization, usually for your email addresses and your website, for example, and we will talk about that a little bit more in depth, but to start with, you're going to have xyz.onmicrosoft.com and that default domain name will always exist in the system. It's not something that ever can be renamed, but as soon as we get your custom domain in there, then you can start to reconfigure things so that your users will, by default, when their identities get created, be Bob Smith at talwentraders.net, for example. And assigning the default domain name is a fairly easy process. All you do is you go into your DNS registrar or whoever hopes the DNS record could be in Azure. It could be at GoDaddy, it could be wherever and you create a bunch of text records and those text records verify that you are in the domain and then bang, you actually can set a new default domain. So whenever you create a new user account, it ends up with the same domain suffix. So in terms of the characteristics of Azure AD, we've got, it's primarily an identity solution that's designed for internet-based applications using port 80 or port 443 communication. As we said, it's a multi-tenant service. Now users and groups are created in a flat structure, which means that there are no organizational units and there are no group policy objects. That is that you can go and delegate things based on resource group. You can go and delegate them based on an individual resource, but what you can't do is you can't delegate based on organizational unit. So you can't delegate permissions based on organizational unit. Although we do have a new thing coming called an administrative unit that does allow you to collect things into an administrative unit, but it's not like a tree structure like the old organizational units can be. Now, here's two very important statements. The first is that you cannot query Azure AD using LDAP. Instead, Azure AD uses the REST API over HTTP and hopefully over HTTPS. That means that you can't use something like Active Directory Lightweight Directory Services, Active Directory Domain Computers to go and connect to your Azure AD instance. The other thing is that Azure AD does not use Kerberos authentication. It uses HTTP and HTTPS protocols such as SAML, WS Federation and OpenID Connect and OAuth for authorization. Now, why this is important and these two things are important is that there's many existing on-prem applications that use one or both of these different technologies. The on-prem application might use LDAP to look up against the directory. It might use a Kerberos to perform all of its authentication and authorization. So if your organization does have applications that use these things, you're going to then be thinking about how do I do this hybrid? Because you're probably not going to, at this immediate point in time, have the time to go and get your applications rewritten so that they use these newer or these different technologies for these particular bits of functionality. Okay, so what? I don't know that IT pros spend a lot of time worrying about LDAP or Kerberos, depending on how deep down in the identity stack you are. Maybe a conversation with your developers if you do have any custom built applications or with your vendors, if you're using any third party applications that you've installed in your on-premises environment. But this is a great example of why hybrid is a thing, right? Because there may be some things in my environment that I'm using that do need LDAP and Kerberos that I'm not going to be able to migrate into the cloud as far as those applications go. So I need to keep them running on-premises. So the ability to keep my on-prem AD that will keep those applications running and give me the LDAP and the Kerberos functionality, while also giving my users one account to sign in with so that they can also hit Office 365 and they can hit my other resources in Azure. Like this is one of the good examples of why hybrid is a thing. Now, one of our viewers, Big Ant-Rod, has got a question and wants to know is that are there any groups at Microsoft that they could reach out to to get the process started and avoiding any pitfalls of transitioning to using Office 365 and active as your AD? That's a good question. I know that we certainly have a big network of business partners that help out in that space. So if you go just to the Microsoft website, you can go into our partner directory and find a local partner. And that's probably your best bet because our range of business partners, they're independent companies, but they've dealt with lots of organizations of various sizes. So we have partners that look after SMB, like really small businesses, ones that look after bigger enterprise customers. If you're not confident enough doing it yourself, and it's not particularly difficult, I've done it on a number of occasions. It does kind of depend on how complex your existing AD environment is, how long it's been around for, how many versions of upgrades it's gone through and how much it's been modified to suit particular custom applications. But if it's a fairly sort of vanilla environment where you haven't done too much quirky, we're going to step you through the process of Azure AD Connect. And Azure AD Connect is really the thing that you need that will get your identities up and visible into Azure AD, which is the authentication plane for Microsoft 365. So then you'll be able to go into the Microsoft 365 portal, you'll be able to see all your users in there already, and you'll be able to go and assign the appropriate M365 licenses for like Office 365 Business Premium or whatever products you want to turn on from them that you're licensed for. Okay, so the next thing we want to talk about is your AD integration options. And it says here straight off the bat, small organizations that don't have on-premises directory can fully reside on, reside there, rely on Azure AD for authentication and authorization services. And that's basically the idea is let's say that you're setting up a brand new small business, you go and get your Microsoft 365 subscription, you store all of your files and folders in SharePoint, and you're not going to need on-prem AD. The likelihood is though that you're going into an environment, especially if you're looking at something like a government department or anything that's been around for a while, there's going to be an on-premises active directory instance, there's going to be on-premises resources and you're going to need to support those as well as using that stuff up in the cloud. And that's what a lot of people are already doing. They extend their on-premises AD DS to Azure. So what, no, sorry, what they do is they use Azure AD Connect to do that. And that's the second option here. This is the synchronizing on-premises AD DS with Azure AD. And that's using Azure AD Connect as Sonia suggested. So that's what a lot of organizations have got a Microsoft 365 subscription do and they have their on-prem AD. They sign into Exchange Online using their on-prem ID and everything works hunkidori. The first option that's listed here is extending on-premises AD DS to Azure. Now in this particular option, all you're doing is you're treating Azure as a remote data center. So you create a new site in Active Directory and you go and spin up some domain controllers in the cloud and then you allow replication between those domain controllers and your on-prem main controllers. Or you might go and configure it, as I was mentioning before, as a resource forest and that resource forest has a trust relationship with your on-prem forest, but you're doing it over something like a VPN or an express route connection. Yeah, and just pause on that one for a sec because I like the idea of thinking about Azure in that particular scenario as being just another remote data center. So in essence, I'm looking at putting a domain controller from my own existing AD domain up into the cloud. And we don't see it a lot, but there are reasons where it's useful. So you may be doing lift and shift of some VMs that do have older applications in them that need the LDAP and the Kerberos that we talked about earlier. Might be easier for them to validate against a domain controller inside the same cloud area because you've got your domain up there. But the other thing that I've seen a little bit is to remove a single point of failure in a network topology. Now I'm talking much smaller businesses here where we had one server that was in a location and in essence was the hub server. So the other sites needed to access the server inside this customer's environment, but that site sometimes would have issues with the internet. And if the internet went down, that meant that all the sites couldn't access the line of business application either. And so by moving that server into the cloud and maintaining the domain structure up there, it meant that the sites, the spoke sites could carry on connecting no matter what they did. In essence, we moved the hub site up into the cloud, but everything just carried on as normal because we didn't need to change any authentication methods. Now the other thing that's in this table that it's sort of talking about is this idea around how authentication actually occurs. And you've got two basic options. The first is where you synchronize your ADDS with as you are using a thing called password hash to synchronization. If I can get that word out. See, I'm not even going to try to see myself, please don't bite the thing. It's like asking a Scottish person to say purple burglar alarm. Apparently they trip up over that too. Okay, so the second is implementing single sign-on between on-premises ADDS and Azure AD. Now let me explain the differences between the two. The first, at no point in either of these models are we taking your password from on-prem and then decrypting it and then copying it over clear text and then putting it in active directory in the cloud and then re-encrypting it and saying, yeah, okay, it's the same password in both places. You're all good. Doesn't happen that way. What happened is that we take your on-prem password and we perform a cryptic one-way cryptographic operation against it. This is kind of called hashing. And hashes with solstice where you're doing a special sort of bit of magic with your hashing. But it only goes one way. You can't take a hash and run a cryptographic operation on a hash and turn it into a password. All you can do is take a password, perform the cryptographic operation and it turns into a hash. What we then do is that we've got a special source. So the special source turns it into the hash. Special bit of mathematics with a special bit of randomness involved. But we remember what the mathematics is and what the randomness is. We then replicate that hash up to the cloud. And when that's sitting up in the cloud, that's great. That's what's stored there. It's not your password. It's a mathematical result of your password being operated on. Now, when someone tries to authenticate against as your active directory going forward, the way that it works then is that as your active directory says to that person's computer, hey, when they go and type their password into the box, what I want you to do is don't send me the password. What I want you to do is I want you to perform this particular mathematical operation on the password and then send me the results of that mathematical operation. So it does that and it ends up being something that looks like a GUID on steroids and it fires that across the internet and then all as your active directory does is it looks at that and it looks at that and it goes, oh, the same. You got it right. You've typed in the right password. I'm gonna go and authenticate you. So that's how password hash synchronization works. At no point is your password stored in the cloud. Authentication occurs against a hash. But there are some bits of legislation written out there that kind of even make that sound a bit like you shouldn't be doing that. So the other option is single sign on between on-prem ADDS and Azure AD. So Sonja, what happens when I authenticate from say the cloud against Azure AD using SSO? Yeah. So this SSO method is primarily talking about something called active directory federation services or ADFS. And you're right in terms of it is for those scenarios generally where there is a regulatory requirement to not even store password hashes in the cloud. They're like, they're not allowed to escape the boundary of your on-prem network. So in this architecture, what we're doing is we are actually using the on-prem domain controllers to do the authentication. Azure Active Directory isn't doing any authentication at all. It's not taking credentials and checking its own database to see whether they're valid or not. Instead, what it's doing is when the user signs in, Azure is taking that request for authentication and it's passing it through down to your on-prem assist environment and down to your on-prem AD servers. And they are responsible for doing the yes or no that this person is valid and that they're authenticated. It will then pass an answer back up to Azure AD and Azure AD will go, cool, we're happy to let that person come in and access these Azure services. It's more complex in terms of the architecture that you need and you might appreciate that because those on-prem servers are doing the authentication process, they need to be highly available. So if they go down for any reason, your users are not able to authenticate in the cloud because there's no service in the cloud performing that authentication. And so you do need sort of multiple layers of resiliency and redundancy in your on-prem environment to provide that. But it is a very valid architecture for customers who can't even have password hashes syncing up to the cloud. But it's also fair to say that the vast majority of organizations that are using Azure AD and have an on-prem instance are just doing straight forward, bog standard password hashes and like making. And that works and that's what they need. And we're getting almost into edge cases when we're talking about other options. Okay, so now we've talked about the options. Let's talk about planning for integration. And we just covered here directory synchronization. So I'm not going to go, and Sonja and I are not gonna go into too much detail here because we've already talked about it and we'll actually show you what it looks like when you set it up. And the thing that you use to perform active directory synchronization at the moment is a tool called Azure AD Connect. And it's a freely available tool that you can download from Microsoft's websites. And it allows you to basically perform synchronization between on-prem and the cloud. Now, when you run Azure AD Connect, the following happens. Any new users, groups and contact objects in your on-prem AD are added to Azure AD. However, and this is important to know, and you will know this if you've ever set it up with Microsoft 365 licenses for cloud services such as Microsoft 365 will not be automatically assigned to those objects. So again, if you're sitting there and you've turned on Azure AD Connect and you've got 500 users in your on-prem AD, you'll have to go in and choose which of those users you actually want to assign licenses to in the appropriate as your console. Now, the attributes of users, groups and contact objects that are modified by on-prem AD will be uploaded and updated in Azure AD. However, not everything that is an ADDS attribute on-prem actually is synchronized towards your white because it doesn't use all of that stuff. If people have gone and created all of these weird custom attributes and put them into user account objects and they don't get replicated up, they're only a small subset of them do. If you delete a user from on-prem, they will be deleted from as your active directory. If you disable a user account on-prem, it will be disabled in as your active directory. And that's because Azure AD requires you there to be a source of authority. And when you've got that synchronization going, the source of authority is on-prem AD. If you delete a user in Azure, it's not going to go and delete that user on-prem. So in terms of the permissions to run as your AD connect, what do we need to have Sonia? Yeah, this is a very good question. So we're talking about installing a piece of software on our local server. So first of all, you're going to need to be doing that with an account that actually has those permissions. But if we go back to the slide, it actually talks about the fact that you're going to need a couple of different accounts to sign in with during this process. So you're going to need an Azure account that has global administrative permission in the Azure tenant. It's the account that's going to need to be able to connect up to this environment and be able to act against Azure AD by literally creating the new user identities in here, for example, that you're synchronizing up from on-prem. So it's just important to remember if you've done anything with roles in Azure, global administrator is an Azure Active Directory role. So that's a role that you can assign to someone inside Azure Active Directory in your Azure environment that gives them a special set of permissions and privileges to manage Azure Active Directory. It doesn't give them permission to do anything else with any other resources inside your Azure environment, only Azure AD. Next, you've got an on-premises account. So you're going to need someone that has the enterprise administrator permission in your on-prem AD. Because remember, you're going to be reading information from your on-prem AD. And so you need an account that when the wizard comes up, and we'll show you that in the process, you're going to need to enter an account that has those particular permissions. Or you can let the wizard go and create an account for you. And generally, it's a good idea to do that. And the reason that it's a good idea to do that is if you're using your own account and something goes wrong, or you leave the organization or your estate, then your account, you've got all of that problem. We've all been there as systems administrators where someone set up a service account to run using their local person account. And then you're sitting there going, why is this running as pier.roman at microsoft.com? It should be a service account. It is a service account. No, Pierre, it's not a service account. It should be actually running as a separate account. So it's always a good idea. It normally happens when your administrator leaves and you're like, we really want to disable their account, but we don't know what's gonna break if we disable it. Or two months later, you find out that something's not working anymore because you went and deleted the account for the person that left. Now, the other one the account will need is certainly on the machine you're installing it on. It'll need to be a member of the local admin's group, which if you're an enterprise admin, you generally are, but if you've got some weird security configuration, maybe you're not. Okay, so the other thing that happens is when you install as your AD Connect, it's added to the AD Sync admins group when you install the product. So you might even choose to create a separate account to actually go and install this process. So instead of it having it create it, getting ahead of it right from the beginning and creating the account before you run as your AD Connect called, this is my as your AD Connect account, but with a slightly better name. This account will be automatically added to the AD Sync admins group. You must sign out and then sign in again to use the synchronization service manager. Now, 99% of the time, you don't need to use synchronization service manager because all of this stuff will happen by itself. Synchronization service manager is where you need to go out and give it a bit of a kick because that allows you to go and actually go and fix some things that might not be working exactly as planned. But as with anything, when you're setting something up, this complicated. Don't expect to do it and expect instantly to set up this thing. And then to go and look at Xeroactive Rick and go, wow, I can see my 10,000 accounts there and only 15 seconds have gone past. Life does not work like that, right? What you do is you go off and you do something else for a while and then you come back later on. Now- Aaron, does the module explain why I've got these two screenshots showing on my screen? One that's got an AAD underscore account and one that's got an MSOL account. Can you explain to me the difference between those two? Well, here's a suggestion for you. MSOL, Microsoft Online, AAD. These are, and the hint here is in the description, the service account for the synchronization service and this is the account created by Microsoft as your active directory. So one of these is a service account and one of them is created by as your active directory. And we've actually got a question on this coming up in the Q&A. The specific accounts, the first one, the MSOL account is created during the installation of Azure AD Connect and it's configured to synchronize with the Azure AD tenant. The account has directly replication permissions for your on-prem instance and write permissions to certain attributes to enable hybrid deployment. That is that it can write to certain attributes and this is important because any account that's got the ability to perform replication can obviously access active directory at a certain level. The second one is the service account for the synchronization engine. It's created with a randomly generated complex password that will automatically be configured to never expire. Just believe it that it's long enough and it's secure enough that we're not worried about that one getting hacked. When it runs, it uses the service account credentials to read from the local active directory and then write the contents to a synchronization database that goes to Azure. This is using the tenant administrator credentials that you set up when you are configuring the connection wizard. Now, here's a big caution. Do not change this service account for Azure AD Connect after you install AD Connect because Azure AD Connect always tends to run using the account created during setup. If you change the account, Azure AD Connect doesn't run and schedule synchronization does not occur. Okay, so let's look at the process of actually preparing things. Now, 99% of the time, this is gonna work completely fine. But what pre-deployment checks should we perform, Sonia? And as I mentioned earlier on, it really does depend on the age and complexity of your on-prem environment and how much you've modified it. So it's gonna go and do things like you need to analyze your on-prem environment to look for invalid characters in some of those Active Directory object attributes and for incorrect user principal names. Go ahead and perform a domain and email discovery and figure out how many users that you've got that should be syncing so that you know all of that stuff. Identify the domain functional levels and the schema extensions and the custom attributes, especially if you have an environment that's been around for some time and it has gone through sort of multiple evolutions of Windows Server and upgrading its domain functional level. But the schema extensions and the custom attributes are interesting because this is where if you have gone and added different attributes to your user accounts, for example, or you've extended the schema that it uses as well, you need to know where that is in your environment just because of the implications of not being able to do that stuff in Azure AD. We've also got things like proxy servers if you're using any of those for exchange or Skype for Business, if you're using Azure AD Connect as part of your M365 deployment. So whether or not you've got any proxy servers standing between your on-prem exchange or Skype for Business servers and the internet and then your SharePoint domain, evaluating your clients for single sign-on readiness so not all of the clients that you're using might support SSO and then recording your network port use and DNS records related to M365 as well. So all of those good things to know just so that you know what you're getting yourself in for when you're going to do your Azure AD Connect. Now, as Sonia said, there's a lot of organizations out there that have had as your Active Directory, oh, sorry, on-prem Active Directory longer than my son's been born and my son's now at university. So one of the things that you might need to do is actually going to look at proxy address and use a principal name attribute. So the other one is that you might have to go and update blank and invalid user principal names and replace them with proper user principal names and then go through and actually remove some invalid characters because not every character that some people have creatively put in their first name or surname or simply might not be supported although we're pretty good with that is actually going to be supported because there might be some organizations that have got very creative with the way that they go and put characters in for some reason, I don't know what that is. But there are many organizations who when they're thinking about this sort of this hybrid deployment that might be the time that before they do that they go, you know what? This on-prem Active Directory that we've got, we put it in in 2000. It's 2022, maybe we'll go and create a new forest, migrate to the new forest and then go and hook it into the cloud because we're probably going to end up with a lot less surprises and amusing things that have happened to us than if we're going with a directory services instance that is a bit long in the term. Okay, so there are some health check tools that you can use. IDFIX allows you to identify and remediate a lot of these problems. There's also the AD Modify.NET tools that allows you to go and fix formatting issues. And you can find out a lot more at this link. And this is one of the other cool things about the way that learn works is that there's often links into the documentation. So a learn module is a constructed narrative where we're almost doing it like a bit of a breakout session where we're telling you a whole story and about a bunch of different technologies. But when you actually go into docs, you're finding out about a quantum or a very specific area of a very specific thing where it'll cover a very specific topic. So this is where we're blending topics together, sort of like a potpourri or a risotto of information about identity. But I like that particular additional reading link because it will help you find those two tools you just mentioned. So IDFIX and AD Modify.NET, you'll be able to find a link to download those tools inside that particular piece of documentation. Okay, so now we've talked about how you set up as your AD Connect. We're not gonna do that in a demo, but what we are gonna show you is we're gonna show you some screenshots because as your AD Connect only got a couple of screenshots when you actually set it up. So when you wanna set it up, the easiest way to do this instead of using Bing to find it in the Microsoft Download Center is to just go into your, as your Active Directory console, click on as your AD Connect and it says, guess what? This is what you've got. This is where, whether or not you've got it and you can press on this link here or click on this link or do whatever you do on links and it'll actually download the MSI file. Then you run it. Now, remember, probably a good idea to have specific accounts ready before you get to this point. And what it'll do here is it'll say, do you wanna use the Express Settings? And 99% of the time, the answer to that is absolutely yes, I'm gonna use the Express Settings because they're gonna do what I need it to do because my environment is not one of those crazy environments where I'm sort of sitting there going, hmm, because if you're sitting there going, hmm, you need to do more planning because you'll know that this is about to turn into one of those lengthy career events of your life where it's not just a matter of running the wizard once but you might need to run the wizard many, many, many times. So the next page, it comes up and it says, okay, you've got a connect to as your AD, that's where you provide your credentials to the account that's got all of the necessary permissions in Azure. Then it says, which directories do you wanna connect? Now, that will be which forest do you wanna connect from or which domain do you wanna connect from? And you can do multiple domains in the same forest if you've got one of those complex forest environments. And then you can come through and choose which organizational units you actually want to move things from. And this can actually be a fairly good way in terms of staging your move to as your active directory because what you might do is you might create a particular OU and then move accounts into that OU of accounts that are ready to be hybrid identities but keep other accounts that are not yet ready to be hybrid identities in OUs that you are not actually synchronizing to the cloud. So the way that this would work is that then you could go into as your AD users and computers and as a user's ready to be hybridized just drag them down into the right OU next time the synchronization occurs, excellent. They're now hybridized. So after you perform the initial synchronization you can then go and reconfigure synchronization options. Now, Sonia, what do I do to reconfigure my synchronization options? Look, it's really hard. You basically just go in and run the wizard again. And it's so weird because I think as IT pros we're used to, okay. So give me the 57 steps or the script and the commands I need to type in. So what I'm usually keen to go and run to things that are just step-by-step wizards because that's far too easy and that's what other people do. But honestly, Azure AD Connect is all wizard driven and to change in those settings just go and run Azure AD Connect again and you can go through the similar steps and just change the options. And these are of course Microsoft wizards. They're not Terry Pratchett wizards. So they can actually run and they're not Hogwarts wizards either. So what we wanna do here is we're gonna do a demonstration for you where we're going to show you where we've got an Azure AD instance where we've got a user and Azure AD instance. And what we're gonna do is we're gonna deploy a virtual machine that normally when you deploy a virtual machine you set up an admin account for it you log onto the virtual machine and if it's just a standalone virtual machine well you gotta go and create other accounts for it. But what you can do when you're deploying a Windows Server virtual machine in Azure is you can check an option that allows you to sign in within as your AD account. And that's what Sonia and I are gonna talk through now. And that's an interesting scenario because I'm used to the fact that if I install Windows Server Windows Server is gonna expect that Active Directory is its authentication mechanism and it doesn't really have any idea that Azure AD even exists. So the ability to do this to tell Windows Server that, hey, there's another identity platform over here because you're actually sitting on Azure and you can sign in with the accounts that are sitting inside Azure AD instead. Okay, so the way we're doing this is we're starting off in the Azure console. We're going to virtual machines. In the virtual machines page, we click add and we're gonna create a virtual machine. Now this is all fairly straightforward to anybody who's actually created a virtual machine in Azure. We give the virtual machine a name. We specify what region the virtual machine is going to be in. In this case, we're doing it fairly boring and keeping it in East US. Now here we've selected Windows Server 2019 data center. The next thing we're going to do is we're going to choose the size which we're happy with. We're going to need to set a username. Now, my particular preference is to use a username Prime which is a Latin reference and not in any way a reference to a transformer, some of which you might see up in the thing behind me. I automatically think Optimus Prime whenever I see you type that, sorry. And that's fine because Optimus Prime, for those of you who don't know your Transformers law is actually the Latin for best first and that's why the Transformer is Optimus Prime. A lot of Transformers have Latin names, who knew, right? So we put in our password. And the other reason that I don't lose administrator is that there are actually a whole lot of restricted names that you can't use. So the reason that I use Prime is that Prime is obviously something that I can always remember as my local admin name. And that's something that you should do and maybe something that you can configure a policy for to ensure that when people are deploying VMs in your environment in Azure, they are using a consistent local administrator name. So we're going through here, we're not gonna go worry too much about how we're gonna actually manage this. We are gonna say that we've got a Windows server license because that's gonna actually reduce the cost. Here, I'm not doing any much mucking around with the actual networking or the disk configuration. We're just setting which is the virtual network and the subnet that's associated with it. There's a bit of feedback there, I think. We click okay. Okay, so again, the virtual network, we've got that already set up. On the management page, this is where the magics are gonna happen. Right, so what we're doing here is we've got two things that are important. We've got a system managed identity and then we've got the option of turning on, login with Azure AD credentials. Both of these mean that this is almost like registering a computer account with Azure AD and then saying, hey, I wanna be able to log on with my Azure AD credential. So we then look at the advanced page. We're just gonna go through that. We're not gonna do anything with tags. I'm sorry, Sonia, I do know how you like a tag. I do like a tag, I do like a good tag. We click review and create and we create the VM. So that goes off and through the magic of television that VM is created very, very quickly. So we see that our deployment is underway. Deployment is complete. Doesn't usually happen that quickly. Now that we've actually got the VM, we click on the VM, we click here, we're going to go to access control. So when we've got access control, we need to configure a role assignment. So just enabling as your AD log in, doesn't allow someone to actually log in with there as your AD account. We've actually got to assign them permissions on the VM to do something. Now by default, the user account that actually created the VM, in this case, prime user is the owner. So of course they can log on. But what we're gonna do is we're gonna add a role assignment to another user who exists within Active Directory. So we select here and we scroll down and we've got two particular roles. Sonja, can you tell me that we'll actually have three roles. Virtual machine administrator, virtual machine contributor and virtual machine user. Which, what's the difference between these ones? Yeah, okay. So the clue a little bit is in the name, the fact that two of them have actually got login in that name and the other one doesn't. So you've got to remember that role based access control or this method of assigning an identity or a role and that role comes with an associated set of permissions of what that user or group is allowed to do against this particular resource that we're in. So the virtual machine contributor role is an Azure role that's used by Azure resource manager that would give somebody the ability to change the details and the configuration of this Azure virtual machine at an Azure level including things like adding tags or whatever. So this is not about what generally it can do inside the VM but it's what it can change in this Azure page for the virtual machine. So that has absolutely nothing to do with logging on. You can be a virtual machine contributor and it will not give you necessarily access, won't give you access to login via Azure AD to log into a remote session to that actual server. So it's the login ones that we wanna look at. And obviously you can see here one's called virtual machine user and one's called virtual machine administrator. So there's a bit of a clue that one of them is going to give you a higher level of privileges. It's gonna log you in as an administrator when you start up that remote session onto the server. Yep, so as Sonia said, one of them joins you as a local admins group. The other basically just makes you a member of the local user group. So here we're gonna select administrator and then we're gonna select one of the Azure AD principles. So I'm just gonna scroll down here and I'm gonna select one called Omega administrator. Now Omega administrator, it doesn't wait on what other permissions that person's gotten is your Omega administrator now has local admin privileges on that separate VM. So I close that, then I'm still in the portal here. I go back to overview. I select connect. I'm gonna use bastion, which gives me a web-based connection. I put in my username, Omega administrator at towentraders.net. I put in Omega's password, scroll down, I click connect and then what it does is it opens up, I think it's an active X control, certainly not a silver light one. And it'll actually remotely log me on and I've got a web-based remote desktop connection through to this particular virtual machine. It comes up, it's Windows server. It's the first time anybody's logged onto it so it throws up the server manager. And I can see that I am connected here to towentraders 2019 virtual machine. Okay, I think what we'll do now Sonia is we will throw to a knowledge check question board. I've got a question before you go to that knowledge check though, the process that you just showed us is setting that login to Azure AD when you first established the VM. If I've got an existing VM in Azure, can I go and turn that on after that virtual machine had already been deployed? I believe the answer to that is yes. And but you'll obviously need to restart the virtual machine because it's going to go and make some changes. So I believe the answer is yes. That was obviously in preview when we were setting that up the first time. So, and also you probably be deploying Windows server 2022 now but because we're hewing to where the module itself is, the module itself was done probably about six months ago. And six months ago, we actually hadn't released Windows server 2022 yet. But you can use it right now in the Azure portal. Okay, Sonia, here's a question for you. Which of the following statements about Azure Active Directory is true? Okay, so let's look at our options. Azure AD implements the same authentication protocols as on-premises ADDS. Azure AD is essentially on-prem ADDS in the cloud or see Azure AD users and groups are created in a flat structure. What does the audience think? If you're in the chat, like tell us whether or not what answer you think is appropriate here. I'm going to go through a little bit of a process of elimination because, oh, and I remember at the start of the session when you brought up like one of the first sentences that very clearly said, Azure AD is not just ADDS in the cloud. So I'm going to strike out B. The other thing that we talked about for a significant amount of time was the fact that two of our protocols, LDAP and Kerberos, aren't supported in Azure AD. And Ace trying to tell me that Azure AD does implement the same orth protocols as on-prem AD. So I think that one's telling me big fat lies as well. We also did talk a little bit about users and groups and OUs. So let's go with option C because if you have nested OUs, where you've made this like family tree hierarchy of groups under groups under groups. Yeah, I don't see Azure supporting that. So let's go with C. Azure AD users and groups are created in a flat structure. And it sounds like a couple of our people in the chat have also chosen C and the answer is, hey! I feel like I'm a millionaire. Was that like a $100 question? I think it was about a 25 cent question. Contoso IT staff have set up Azure AD Connect and are beginning to synchronize accounts. Maria in IT finds a new user account in Azure AD that has been created by the Azure AD Connect process. So Maria is looking at the Azure AD console. Now, which of the following accounts would Maria have found in the Azure console, not active directory users and computers? I think you're giving me a few hints here. And again, if you're watching live, pop in the chat and tell us what you think. But I'm just, look, it's one of those questions that you really have to unravel because when you go through sitting up Azure AD Connect, we did talk about the accounts that will get created and we had that screenshot that showed the AAD and the MSOL underscore type accounts. But the devil is in the detail with this question, right? So Azure AD Connect has been set up and it's starting to synchronize accounts. And Maria, as you said, she's finding a new user account and it's in Azure AD. So it's not in our on-prem AD. So by process of elimination, I'm gonna assume it's not A and it's not C because those accounts were created in our on-prem AD by the installation process of Azure AD Connect. So I'm gonna go with B. We didn't see sync underscore on the screenshots by process of elimination, I reckon it's B. Yes, that's one of those questions that probably should have been rewritten because also it says Maria rather than Maria. So it might be an entirely different person who's looking at the Azure AD console. And yet they were the correct one. They are, they are. Look, we've got a question from the audience too. If we were giving VM administrative access to Omega, would they also be able to make infrastructure changes to the VM like the size and stuff like that? Or are they only referring to the local admin credentials of the VM? So remember when you added Omega and you gave them access to virtual machine administrator login, which is giving them local administrative rights on the machine. Do you also give them admin rights to change the properties of that resource in Azure or not? No, no, it doesn't. The rights are completely separate. Basically that's an in the box, right? Versus an out of the box, right? So there was another role there that we were looking at. Do you remember which one that would actually give them those permissions? Oh yeah, that was the virtual machine contributor. So if we wanna give them those rights and they can have more than one role. So you absolutely can assign them both the virtual machine contributor to give them access to modify the VM properties in Azure and give them virtual machine administrator login so that they can log in as a local admin as well. Okay, okay, let's get back into the module. If I can find the right button, there we go. Okay, we're onto unit. Okay, so here we're going to talk about the hybrid version of this. This is Azure Active Directory Domain Services. Now, what Azure ADDS does is it runs as part of Azure AD premium. So that's one of the things you need to know because you've got to pay for it. But what it does is it provides a very managed, slightly cut down version of Active Directory where you've got Active Directory in the cloud but you don't have to worry about managing a domain controller. So what you get when you set it up is you set it up and then suddenly you've got a domain that you can join another VM too. And let's say that you join it and you've got domain admin credentials and you sign into that VM and it's domain joined and then you go and add your appropriate remote server administration tools, you can then even add Active Directory users and computers. But one of the things that you'll find fairly quickly is that there'll be only a limited amount of functionality within Active Directory users and computers. You can't go and create new GPOs but there is an existing user and computer GPO. So the idea of this is it's a middle ground between what we were talking about earlier which is I need full Active Directory in the cloud, full Active Directory on Prem Active Directory. I'm going to create a separate site, spin up a VM as a domain controller or two because you should always have two domain controllers on the side in case one of them dies. And then I will domain join something to that particular domain. This one is, I don't need all of that. All I need is I need some basic group policy stuff. It does need to be domain joined but I don't need everything. I don't need custom domain partitions and I don't need all of that. So what I'm gonna do is I'm going to allow Microsoft to give me like a limited virtual managed domain controller that I can't actually do anything or reboot but it just pretends it's there and that's how as your AD domain services works. So what are the benefits it provides Sonia? I think you've covered it really well. It's mainly that some domain functionality without needing to manage another domain controller. And at the start we talked about one of the options is the fact that technically you can put run up a VM and make it a domain controller and extend your active directory infrastructure into Azure. But then you've got another Windows VM to manage. You've got another directory controller to manage to make sure it's secure, to make sure it's replicating. So all of the advantages of not having the domain controller but the advantages of getting some of that domain functionality you need like some of those group policy settings for example, that's probably the main one. Now the thing that it says here and it's very important to understand is that these are the limitations. Only the base computer active directory object is supported. You can't extend the schema. So you can't go muck around with a schema. You don't need to know what the schema master is so you can't do anything with it. The OU structure is flat. You can't get creative with your OUs. There is a built in a group policy object which exists for both the computer and user accounts. You can't create extra ones. It's not possible to target OUs with the built in GPO. It basically applies domain wide. You also can't use WMI filters or security group filtering. It will apply to every computer object that is joined to that particular as your ADDS domain. However, what it does allow you do is to freely migrate applications that use LDAP, NT land manager and you shouldn't be using it on the key land manager anymore. You should migrate it away from that. I have not heard the word NTLM for a significant number of years. Wow. Well, there's a lot of things that still use it. So it's sort of like SMB1. It's still there. We just want to talk about it. Or Kerberos from your on-prem AD to the cloud. So it has the ability to securely administer your Windows server VMs whilst still using those older protocols and which might support applications that you've got. And one of the things is that the cost of rewriting an application might be so great that that's a migration block. And this might be a medium term step that you can keep around without the cost of actually spinning up a separate set of virtual machines to run Active Directory. It's cheaper if you've only got a limited set of things to actually run this managed version of AD than it is to actually manage it yourself. And you have the advantages of not having to manage the actual host domain controllers and keep those up to date. So when you are considering it, remember all of these limitations. Also make sure that any applications don't need to modify or write. They can only read from the old app directory. Write access to AD, GS managed domains, isn't supported, and if you need to do that, you're gonna need to spin up a domain controller in the cloud. It doesn't need a custom extension. So some of these older applications that were written certainly in the 2000s and the early 20 teens would actually use Active Directory to store application data. You'd extend the directory, you'd use a custom partition, and you'd store that because that was an easier way of storing a lot of information that certainly settings related to things than it was to go and, say, spin up a SQL database and have the application go and query the database to go and work out all the permissions that someone had. And that was the idea. That was certainly what we used to be doing with directory services. And make sure that any applications use a username and password for authentication. This means that if you are using on-prem certificate-based authentication or on-prem smart bar, there is smart card-based authentication, it's not gonna be supported by this very limited version of ADDS again. If you've got most organizations, most organizations are gonna be fine with this option and then this option, and then you're starting to get into the more complex, expensive, and expensive in terms of just the amount of knowledge and the understanding you require to do it, that's more over there where you're spinning up your own DS. Okay, so in this next module, this section, we're gonna talk about what you need to install and configure it. So, Sonya, tell me about implementing as your ADDS. Yeah, obviously you need to already have an Azure AD tenant and your Azure Active Directory subscription, and then you have to have password hash sync deployed with Azure AD Connect. So Azure ADDS, it's not a separate thing that you are going to install on-prem and sync to Azure. It's gonna take advantage of Azure AD Connect's functionality that is already synchronizing your user accounts up from on-prem into Azure AD, but it also needs to have that password hash sync process so that it can do the authentication and keep that authentication process in the cloud. It doesn't work with that ADFS scenario where we talked about where you're actually passing the author request back through down the chain of your on-prem environment. So that's really important. I think let me have a look. That's probably the main one. We also got, you have to select the DNS name that you will use for the service and the domain that will synchronize with your on-prem environment. So, domain namespaces, like especially if you've got a much older environment where you might've been using a local domain, for example, you wanna have all of that sort of stuff sorted out. Now, the recommendation here very strongly is that you should not use an existing as your on-premises DNS domain space. So what you would do is, for example, if you had tailwindtraders.com as your one that you were using mostly in Azure, you can have additional names that will use tailwindtraders.net or something like that. But when you are configuring this, remember that a trust relationship will exist so that you, even if you specify for as your ADDS, that it's tailwindtraders.net, you'll be able to sign in when you assign permissions to the tailwind traders. You'll be able to assign in using that other name, but most likely what will be going on in that particular domain is that user accounts will be signing in with that particular domain name. And as you know, when you're signing onto a domain controller anyway, you're almost never signing on with a user, UPN. You're usually going domain name slash username. So you've got the option of using a built-in domain name, probably not the best way to do it because you don't wanna have a domain that's on microsoft.com. Don't spin up a custom domain name that's sort of associated. And if you've got a complex environment, you might even choose a sub-domain. You can also recommend, we recommend that you avoid using a non-routable domain suffix. So if you've got tailwindtraders.oran or tailwindtraders.scuffy, we suggest you don't use them because they're not legitimate domain names. You might need to create additional DNS records, which is something that you can do, obviously within either as your DNS or your own DNS solution. In terms of creating it, you set up a subscription, you set up a resource group, you specify your DNS domain name and you'll see us do all of this in a demo, your region and just skew. Now, again, you choose whether or not you're gonna create a user domain and this will synchronize all objects from Azure AD including any user account created using on-premises environment or resource only synchronizes users and groups created directly in Azure AD. So the idea of this second one is that you have resources that need to run in a VM and you require these particular protocols, but you only wanna use as your AD accounts and not accounts that are actually syncing from on-prem. So it's a very special type of domain. You create it, you specify which virtual network. This is the other important part of this is that as your ADDS projects into a virtual network subnet, that means that you turn it on and then you've got to specify where it's talking to. It will not turn up in every one of your virtual networks. It'll only turn up in a very specific part of your Azure real estate. So do my servers need to be in that same virtual network subnet as ADDS? For the most part, you should put them there. You can use peering to slightly get around it, but for the most part, what you're doing here is you're doing a very specific implementation and it's a good idea to have all of your ducks in a row in this. Remember that we're not worried so much about broadcast traffic anymore. It doesn't matter if you've got lots and lots and lots of servers there. You're certainly not gonna be talking about several thousand servers in a particular subnet. Even though that's probably supported. Okay, so here's some additional reading that tells you a bit more about setting up, but what we're going to do in the next unit is we're going to talk about what managing Windows Server in an Azure AD environment looks like. So you have special groups. The AAD, DC administrators group are equivalent to a certain extent to the domain admins group. So you can configure the built-in GPO for the containers of the AAD, DC computers. So these are specially named containers that sort of look similar to what you'd have on-prem. But aren't. So it's AAD, DC computers and AAD, DC users. You can see those objects and they're the things that are replicating down from as your AD. The AAD, DC computers has got all of your computer accounts and that have joined the domain. You could administer DNS for the managed domain. So this is a case where you can go and create DNS records or modify DNS records if you want to. However, by its nature, these domain joined computers are already registering their DNS information into as your ADDS. And you can grant administrative access to computers joined to the managed domain. So you can basically add someone as a user account to the local admins group of another computer that you've joined to the domain. You just remember you can't extend the schema. You can't connect to domain controllers using remote desktop. So you can use the remote server administration tools and it looks like you connected to AD, but you can't go, okay, I want to RDP into that DC. It won't allow you. You also can't go in PowerShell into that remote DC. You can't also employ domain administrator or administrator enterprise administrator permissions. Okay, so to enable a user account for ADDS. Sonia, you didn't want to talk through this? Yeah, so we talked about the fact that you need a password hash, but the password hash also needs to be in a format that is suitable for both NTLM and Kerberos authentication. So remember we started at the front saying that Azure AD doesn't support Kerberos. So there's absolutely no point in us putting in a password hash sync for a synchronized user from on-prem that supports the Kerberos authentication protocol because we're not gonna use it in Azure AD. However, if we do go and turn on Azure ADDS and we are looking at for that Kerberos support specifically, we are gonna need the password in a format that supports the Kerberos authentication. So yeah, that's probably the main part in there. Now, the other one I wanna bring up because you'll see this in the demo is that you can sign on to an Azure ADDS domain using an account that only exists within Azure. But before you do that, you need to change the password once you've enabled Azure ADDS because that will simply trigger the process of creating that particular synchronized. Kerberos friendly password hash, absolutely. Exactly, so what we'll do now is that we will go across and we'll do the first part of this demo. So here we are in the Azure console. We're going into creating a resource. What we'll do is we'll type in Azure AD domain services. We'll click on Azure AD domain services. That's fairly straightforward. So we click create and then we get the usual bit of information. Now we saw some of this when we were setting it up. First, we select our subscription, then we select our resource group. We're gonna put it in the Tailwind resource group. The DNS domain name, we're gonna use tailwindtraders.net and this is tailwindtraders.com, which is the usual one. We're gonna use the standard SKU and we're gonna use that user forest. So we're going to replicate our user accounts as well. Here, we're specifying which virtual network we're gonna project into and the subnet is ADDS subnet. We're configuring our notification settings so that anything when there's alerts that go on and here we're gonna synchronize absolutely everything. So we're just going through with the defaults here. We click create. Now the creation of this actually will probably take about 25 or 30 minutes but through the magic of television we've actually allowed this to go fairly straightforward and it occurs automatically. So the next thing we're going to do is we're gonna jump into as your active directory because we've got the accounts that have been created there and all of these bits and pieces of information but what we wanna do is we wanna go to the tailwindtraders.net domain and we wanna verify that we've actually got our DNS servers now configured. So every VM that's on that network needs to use these DNS servers because they use the DNS servers when they're trying to connect to the domain controller to perform directory services connection. So what we've done is we've now updated our virtual network and the DHCP on our virtual network is now pointing at those particular DNS servers which means that a VM that's sitting on that network will now have the right DNS server to find the tailwindtraders.net domain. Now we're gonna jump down to as your active directory and if you remember we were talking about cloud native users and if we've got a cloud native user we needed to do something. Do you remember what I said we needed to do Sonja? Yeah, we need to get them to reset their password or like we can do a password reset for them here but that password reset is going to store their password hash in a Kerberos friendly format. Okay, so we selected gamma user and all we're doing here is we're gonna click reset password. We click reset password again and we've got a temporary password that they've been assigned. So I'm just gonna go and copy that and drop it into notepad. So now that we've done all of that we've got this user ready and we sign in as gamma user to the Azure console. We put in that temporary password and because it's a temporary password we've just asked for a password reset we need to update the password because don't use the temporary password to sign on to the VM because it's gonna wanna change that password. By doing this we've already performed that password change which means that we've now got a proper password for that user that is appropriate for them. Okay, so now that we've done all of that let's actually test all of this out by joining a Windows server to a managed domain. So here we go. We're back in the Azure console. We're going to virtual machines. What we're gonna do is we're gonna create a brand new virtual machine. We're not gonna do anything particularly exciting with the creation of this. We select our resource group. We give the virtual machine a name. Here we're calling it 2019. Azure Active Directory VM. We're not gonna select Ubuntu. We are going to select Windows Server 2019. We're not particularly worried about the size as long as it's a D2 VSV3. As usual, I changed the username to Prime. What I've got to roll out. Here we're looking at the management. I'm not gonna do too much mucking around here. I am gonna assign a Windows server license just to make it cheaper. I click Disks and you do have to actually own a Windows server license if you're doing that. Don't tell Fibs. Clicking Networking. Now, networking this is important. I need to make sure that I have this on the AADDS subnet. Because if it's not on this AADDS subnet, it's not gonna be able to perform that connection. Now, on the management item, I don't need to actually configure logon with Azure Active Directory. You can see I completely bypass that here. So we've got a mega user. We have not configured AADDS logon for this user and we have not configured the Azure role for this user because we're pretending that we've actually got this managed domain. So we click Create and it goes off and it creates that particular virtual machine. Now that that virtual machine is in process through the magic of television that's instantly deployed, we go and select it. So the first thing we need to do is we need to connect using Azure Bastion through that web console and we're going to need to logon with that initial prime account. Why? Because at the moment, it's just like any other newly deployed Windows Server virtual machine. It doesn't have a domain join occurring. So we logon as prime. It fires up Windows Server. It gives a server manager, waiting, waiting, waiting. Okay, so now we've got server manager. So from the local servers node, and there's about six million ways to do this, we can select work group. We can select change the domain and work group. And what we do is we come to domain and we type in tarlwintraders.net which is our Azure Active Directory Domain Services Domain. We then need to authenticate. So a normal user can domain join a machine. In this case, gamma user can domain join a machine. So we type in gamma user at tarlwintraders.net using the UPN. Welcome to tarlwin.net domain. Now, if you have domain joined a VMM, you know that domain joining any Windows Server computer requires you to restart. It goes and restarts the machine. So we're bumped back into the Azure console. We click connect again. We select bastion. And this time we're gonna log on as gamma user at tarlwintraders.net. We put in the password. That opens up that web-based RDP connection. And there we go. We've now, just like magic, managed to log onto that Windows Server VM because it's now completely domain joined. And we can see it's a member of the tarlwintraders.net domain. And it's got the name tarlwintraders.net. So, oh, oops, it's ID. Let's come back and do some nice check questions. So I think the interesting thing I found interesting about the whole process was the fact that the users are still in Azure AD. So when you went into Azure ADDS, there was no users pane. Like I'm not copying the user accounts to somewhere else as well. And it's because we've got that directory synchronization setup already between on-prem Active Directory and Azure Active Directory. That Azure ADDS is kind of the pseudo of both. It's picking up our on-prem user accounts that we've synced to Azure AD, but using them for authentication into the server, but giving us those AD extras that we didn't have with just pure Azure AD. It's a really interesting sort of my mail to get your head around how it hangs together. Now we're almost done. So we'll just finish out with these knowledge check questions. When planning to implement Azure ADDS, Sonia, which of the following statements is true? Look, I have gone on about how you can't support nested OUs. I don't know how many times you said that it's not possible to extend the schema. Like that's come up at least seven times. So let's go with C that we can't target specific OUs with the built-in GPOs because you did say the GPOs would apply to everything. Absolutely correct. And the final question, which role from the following groups in an ADDS domain could administer DNS on the managed domain, create an administrator customer use on the managed domain and administer computers in the managed domain. Excellent. Okay, so that's a whole bunch of permissions that they're going to need. And you did give us a nice little overview of this AADDC administrators group. So let's go with A. Absolutely correct. Anyway, with that, Sonia and I have absolutely come to the end of our time. So if you want to get in contact with us to ask us further questions, you can see our Twitter handles up on the screen there. It's at Sonia Cuff and at Oren Thomas. Thank you very much for your attention and we hope that you have... A great day. Wonderful day, fantastic day and empowered day. Absolutely. Thanks everyone. Bye.