Microsoft Azure AZ-800 — Section 7: Implement and manage hybrid identities

52. Evaluating requirements and solutions for synchronization

We’re going to spend some time now talking about the evaluating of requirements and solutions for synchronization, so this where we start thinking in terms of, you know, if we’re going to, we’re going to be planning out the concepts of synchronizing our on-premise Active Directory accounts into the cloud. We have to understand the different solutions that are available to us.

So first off, we are setting up a hybrid identity config configuration here, and we’re going to be trying to synchronize with Microsoft 365. And so planning all of this out, trying to design how all this going to work is going to involve figuring out what your business needs are and then knowing what your technical requirements are going to be in order to do that. In other words, I need to know what’s my aim of my business? Are we planning to keep our on-premise Active Directory around for a long, long period of time?

Are we eventually going to just go full blown into the cloud and get rid of our on-premise domain? Because keep in mind, you have tools for managing computers and things on-premise. A lot of people think that, you know, Oh, we can’t get rid of our domain because we use group policy objects, GPOs and all that. Well, there’s all kinds of solutions that involve managing all that stuff in the cloud as well. But I won’t get into that here because we’re focused on synchronizing.

So you got to figure out what your business needs are the technical requirements and then decide which direction we want to go on. Directory synchronization OK, so directory synchronization is going to involve synchronizing that on-premise Active Directory domain out to the cloud, and we got to figure out the best solution for that, right? So, when it comes to all that, Microsoft has the authentication for hybrid identity and there’s basically two strategies here. The first would be managed authentication.

Now this by far the most common these days.

So the managed authentication, this means basically that you’re going to let Azure ad handle the authentication process and you can utilize locally stored hash versions of your passwords, which basically means that Active Direct Azure Active Directory is going to get a copy of your hashed credentials, encrypted credentials. And at that point, when somebody logs on the domain, it can authenticate to the domain. But when they’re logging into the cloud, it can authenticate in the cloud. The passwords are all going to be the same. And the other thing is that Microsoft does know your hashed credentials and there is an alternative way to do it where if you don’t want Microsoft to know your hashed credentials, there’s a way to do that. We’re going to talk about that. Another option is Federated Authentication. Federated Authentication means that you’re going to use a what is known as a federated server, and this a more advanced approach. You can do this on a very large scale. If you wanted your authentication to be sent somewhere else and be authenticated by someone else, you could. Or you can even set up what is known as an ADF server on-premise Active Directory Federated Server for handling Federated Authentication yourself.

OK, so there’s ups and downs of that, and this something we’ll elaborate on. But for managed authentication, there’s two main options you have password hash synchronization. They have an acronym for that, which is Page S, right? And then essentially, this going to be the recommended way. If you ask Microsoft’s advice, they’re going to recommend you do this, that you use password hash synchronization. It’s going to be one of the easier approaches and there’s some, some definite benefits that get elaborated on that that you’re going to get with that. Namely, one of the greatest things is like if we have people who are outside our domain logging on and they need access to the cloud resources, and for some reason, the cloud has no contact with our on-premise domain. Users can still log on to the cloud services.

So, if you were to lose your company’s internet connection or something to the cloud and users outside who are part of your organization may be working from home, they could still log on with to pass through authentication. That’s another solution. Parser authentication you’re going to install an agent on-premise that’s basically a little piece of software that’s going to run on your server on-premise, and you’re the Microsoft Cloud Services does not know your password. What happens is they go to somebody outside, goes to log on to the cloud service, so will communicate with this agent. P.T.A. agent will then authenticate you against the domain controller and then you get logged on. The downside of that one, of course, is if we lose connectivity with our on-premise domain, somebody on the outside trying to log on to the cloud service would not be able to authenticate to the cloud service.

OK.

So just kind of looking at this little example here, we’ve got again, password hash synchronization. And again, if you look there closely, you’ll see on the left side of the little example you’ve got your organization, your on-premise, Active Directory and you. Azure Kinect, which is going to synchronize credentials out to the cloud, it’ll synchronize the hashes as well the password hashes. And at that point, those hashes are there in the azure. The great thing is, if you see they’re in the middle of the screen, you’ll see the middle of the drawing there. You’ll see the remote user, the user can log on even if there’s no connectivity with your on-premise network.

So again, this going to be a good solution for that. But for compliance purposes, you may be in a situation where maybe you can’t have your password hashes sync synchronized to Azure ad.

So at that point, you may be better off going with the different solution. Like Peter, pass through authentication with pass through authentication. If you look and notice, you’ll see that that user, that little remote user as he goes to authenticate, he’s going to try to authenticate with Azure Azure, and he’s going to communicate with your on-premise Active Directory using this thing known as a parser authentication agent.

So this a little piece of software that’s going to communicate with Azure.

So Azure, it does not know your password at that point.

OK. Again, the only downside is exaggerated was to lose connectivity with your on-premise domain. Well, at that point, this remote user that you see here would not be able to log on your domain. Users can log on, but the cloud services, you know, somebody on the outside, somebody’s trying to reach cloud services, they would not be able to.

OK. And then lastly, here we have federated authentication again. Federated Authentication is for a large scale environment, usually a much larger organization. And at that point, you know you can have a lot of things going on. One of the main things that federated authentication can do that the other two can’t is if your company is using third party authentication systems, OK, you’re not using the Microsoft MFA Multi-factor Authentication System you’re using. You’re using some third party solutions, maybe for smart cards, third party multifactor authentication, the federated authentication is going to be one of the probably one of the better, better ways to go. And one of the more common ways to go for bigger organizations that are in that type of situation.

OK. One of the thing about federated authentication with federated authentication, Microsoft again does not know your password hashes, so for compliance purposes, this would meet those needs as well, just like Peter does. But same problem with federated authentication if for some reason, Azure 80 cannot communicate with your federated services if you’re using like an Active Directory federated server to do all of this, if you lose connectivity, if, if, if you’re Microsoft 365 services, lose connectivity with your on-premise Active Directory or your federated server, then unfortunately, the anybody who’s outside would not be able to log on.

So, you know, all of these kind of have their ups and downs, and you kind of have to think about it and plan out what’s going to be the most important solution for you. I’ve I’ve worked with some, some very, very big companies before. As I told you guys, I do consulting work and one of the things that I was hit with one big one of the big companies I worked with one of the I.T. departments, they were telling me that like, we don’t understand why we hired a consultant to install our right to do this synchronization. And we have federated services. And it seems like so much trouble because it is a lot of trouble. But it turned out that that company had a third party multifactor authentication solution.

So those are the reason why whoever the consultant was that set up their federated server, that’s why they ended up doing that. But that’s one of the considerations that you got to think about. But all in all, with planning this out, it’s important to have this understanding of sort of the ups and downs you’re going to get out of all three of these.

53. Evaluating requirements and solutions for identity management

Let’s talk now about evaluating requirements and solutions for identity management, so as we as we move towards this concept of being able to synchronize with our on-premise identity, we do need to be thinking about the things that we’re going to be synchronizing. And considering the fact that there could be some issues in our existing Active Directory, you know, a lot of companies, especially companies that have been around for a very long time. They could have issues in their on-premise domain just from years and years of wear. Right. You know, a lot of the companies I’ve worked with have, you know, they’ve at least been around since the 1990s, and they might have started out with a Microsoft into four domain and then upgraded to Active Directory, you know, Windows 2000 when it came out. And then, of course, they upgraded to 2003 and 2008, 2012, 2016, 2019. And you’ve got all this stuff that over the years has kind of built up. And of course, you have to consider that Active Directory on-premise also allows certain things that perhaps the Azure ad does not. There’s a great tool for that the I.T. fix tool that can be downloaded, and it can do a little bit of a clean up for you. Another thing we’ve got is once we actually do set up Azrieli Connect, we have Azure Connect Health and we can get some reports and things for how healthy the environment is. You definitely, though, should try to clean things up as much as possible. We definitely do not want any kind of false positives being generated because of issues we’ve got.

So cleaning up errors and things like that. One of the things you want to do is look at your event logs and and all of that with your on-premise Active Directory domain controllers and look to see if you got any kind of replication, error or synchronization errors. There’s a, you know, DC diag come in. You can you can utilize in your on-premise Active Directory. It’s going to help you with that. And Microsoft generally recommends that if you’re looking for synchronization problems, try to just go back 100 days. You don’t need to go back to the beginning of time on it. Just kind of go back and try to clean up things that shown up over the last hundred days. That’s their recommendation.

OK. And so at that point, you can, you know, consider moving towards doing the synchronization.

OK, just big thing there is try to troubleshoot anything. You got clean everything up that you can and fix any errors that you can before you attempt to do the synchronization.

OK, now as far as is, all of this goes, removing objects that are no longer even necessary is a good idea.

So another thing that I’ve found in my consulting career is, you know, going into a company has been around for a long time. You wouldn’t believe the amount of objects that are inside of the on-premise Active Directory that are no longer even used.

So the thing you need to do is try to figure out, you know, what objects are still even needed, go through and start wiping those out as much as possible, anything that’s not needed.

So, they, you know, here, they mainly focus on the fact that you consider those objects in garbage or at least stale objects, objects that aren’t being used right? So go through and try to clean all that up as much as you can. This going to include e-mail as well. If you’re transitioning on-premise, exchange and exchange online or whatever, go through and clean up contacts. Global address list. Try to get all that stuff cleaned up as much as possible. Get rid of service accounts that are no longer needed. Groups that are no longer needed. Consider also, If you’ve done any kind of business to business collaboration, maybe with other companies, any of that stuff that needs to be cleaned up. I mean, you’ve got situations where companies have partnered up with another company, like 20 years ago, and they’re no longer even partners, but there’s traces of objects still out there. Get rid of those, right? Get rid of computer accounts and things like that that are no longer necessary in your environment as well. And then the thing you also think about here is consider fail over in disaster recovery when it comes to setting up your synchronization.

So you’re going to be utilizing Azure Connect on a server. This the software you’re going install on a server that’s going to do the synchronization. And the thing is that you can only have one Azrieli Connect server doing that synchronization for your domain at a time. And of course, that brings to question or isn’t that a single point of failure? Well, yeah, it’s definitely a single point of failure.

So good news is Microsoft does provide a couple of little solutions for this number one, you can deploy a second Azure 80 Connect server, but it is known as a staging mode server, a staging mode server as a server that sort of sits there passive unless the main server was. Go down.

OK. You also need to again be monitoring the Azure Connect Health to make sure things are properly synchronizing, but you can always go to that staging mode server and promote it, and it can become the active server if the main server was to fail. Another solution is to virtualized your Azure 80 Kinect server. Use it as a virtual machine, and the great thing about that is we can do with virtual machines. We can do what’s called live migration, so, we can have a duplicate of that and we can have it do a live migration over to another machine in a situation where perhaps the servers gone down and all that. Not to get deep into clustering and all that, but we do have some good solutions in regards to virtualization that can provide some redundancy.

Now, the Azure 80 Kinect wizard when you run through the Azure 80 Kinect was or one of your options there towards the end, right before you’re about to tell it to install and start synchronizing and all that, you have that option right there for staging.

So you’ll see it’s a little checkbox says Enable Staging Mode when selected synchronization will not export any data to Azure A.D.

So this how you can configure your server to be a staging mode.

So you set up Azure 80 connect on a main server, but then on a second server, you could configure staging mode there.

OK. Another consideration for running through Azure 80 Kinect and beginning to synchronize is they make you select something known as a source anchor.

Now, a source anchor is going to be an attribute that both your on-premise Active Directory as well as the Azure ad. Have they both have this attribute, OK? It is attribute they tell you it’s an immuTable attribute, immuTable ID and immuTable. It basically means that you cannot change this attribute, and it is an attribute that both the on-premise account will have, as well as your azure, adding the idea there is, there’s got to be a way to link the two together because remember you’re on-premise user account and your Azure eight user account. They are actually two different accounts, but there’s got to be something that that links them together so that the on-premise Active Directory in the Azure ad no, to match those accounts, right? So this going to be involved. This going to be one of the things you do when you go through and select Azure. You weren’t through the wizard. It’s going to it’s going to select that for you. And your sync engine, which is going to be the Azure aiding Connect server, is going to utilize that attribute even if something goes down or if you’re using staging mode. As long as you’ve selected the source anchor and on-premise, Active Directory knows what it is as well as your azure. It knows what it is. You’re good to go. The typical one they mention here is the MSD’s consistency grid globally unique identifier, and that’s a very common one source anchor that is going to be used to do this. You could choose something different if you want, but that’s the typical one. It’s going to give this big, long number, and this big, long number is going to be the same on-premise as it is out in the cloud.

So, it’s all going to it’s all going to properly match. But those are some of the considerations if that you want to be thinking about in regards to when you’re running Azure, any connect, the fact that you need to provide some redundancy as well as your source anchor and you know, nine times out of 10, most everybody is going to go with that source anchor. One other little thing I want to say on that. Another thing that’ll play a role in this the user principle name, which is the email address name.

So your user accounts have a user principal name, which is an email address style name like, you know, John Christopher at Examlabpractice.com. I’m going to want that if I’m like using on-premise exchange and I’m using an exchange online. Obviously, I’m going to want all that as well.

So you’re going to notice to the Azure. It is going to make you select that to. You have to have a user principal name to name your objects and then the behind the scenes source anchor is going to be some kind of a unique number that never changes between the two.

OK.

So hopefully that gives you now a decent understanding of understanding some of the redundancy involved there, the concepts of source anchors and how all of that sort of fits into this synchronization identity authentication process.