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

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

54. Evaluating requirements and solutions for authentication

I want to spend some time now talking about evaluating requirements and solutions for authentication.

OK, so, we need to be thinking in regards to the authentication method that’s going to tie everything together. If we’re going to do a hybrid environment, we’re going to be using on-premise ads with our cloud services.

OK.

So with your Azure identity, our hybrid identity solution, this going to be the foundation of authentication, right? And cloud access.

So user is going to essentially be able to log on on-premise their domain as well as authenticate to the cloud. And there’s some automation capabilities that we can consider utilizing there. But it’s important that we make a good decision on the authentication type we’re going to use when we start moving into Azure Eddie Connect. The good news is that you’re going to find this not necessarily set in stone. You can go back and run Azure Eddy Connect again and change things.

So, it’s not the end of the world. If you, you know, set something up and you’re like, You know what? I want to switch from hash authentication, hash synchronization over to the past authentication or something like that. Definitely something you can do. But obviously, getting it right the first time is a good thing, right? Can make life easier. Can save money, save time, right? And so these are things we want to be thinking about.

OK, now just kind of break it down some more. A little facts here about Azure 80 pass password hashing resolution. Again, this the one Microsoft recommends your usernames and your passwords will be synchronized out to the card, but the passwords are just the hashes, So, it’s not like your passwords are being synchronized out in clear text.

OK. One little thing I’d like to point out, too, that they don’t mention here I’m not mentioning in the slide is that Microsoft? If you choose password hash synchronization, Microsoft is actually monitoring the dark web and they are looking for hacks where password hashes have been breached and their security team will actually look to see if any of your hashes have been breached. And if they have, they can communicate with you and they can actually forest a reset on somebody’s password if they want. That’s really cool. Password hash synchronization is the only one of these that gives you that capability, so this another reason why this one’s considered a great way to do it. The problem is compliance. If you are in an environment where this going to be a problem you may not like, I’ll give you example I was working. I did with my consulting work. I worked with a hospital in Texas and I think they were south of Dallas or something. Dallas, Texas, in the situation they were in was setting up Azrieli Connect to synchronize. But because of compliance with HIPA compliance and all that, they could not have their password hashes synchronized to the cloud.

So at that point, you can’t really use hash synchronization, right? So you have to go with another solution.

Now, a possible other solution is to use a pass authentication. This also going to provide a pretty easy way to do it. This the new kid on the block, by the way. A few years ago, the only options we had was hash synchronization and federation.

So, if you, for compliance purposes, couldn’t have hash synchronization, you had no choice but to go with federation. And this another reason why some companies are still using federation because they implemented this years ago and there was no such thing as PTA. Then PTA came around, and it’s a whole lot easier to deal with than federation.

So most people are, you know, go with with pass through authentication. It’s a lot simpler to set up if you’re in that compliance situation. Of course, there’s a downside in that is that neither hash synchronization nor PTA support, third party MFA, third party smart card solutions, things like that.

So you may have to go with the federated solution if that’s the case, but PTA is a real simple way of setting it up. Not as simple as hashing organization, but you do have to install a little agent on your server and your on-premise environment, and that will agent is going to communicate with with Azure and authenticate you again. If you lose connectivity, though, people on the outside who want to access the cloud services would not be able to. The federated authentication is, you know, the third main solution that we have and with on-premise Active Directory, we’d have to implement something called ADF’s. And with EDF’s, you would have to set up EDF’s servers on your internal domain. You’d also have to consider setting up these things, called EDF’s proxies in your DMZ. You can actually get into having to have a lot of. Hardware with this one, you might have to have two federated servers on-premise, two EDF’s servers on-premise and then two AFC proxy servers out in your DMZ.

So this one can get expensive and again, it can be a pain in the butt to set up. But one of the biggest benefits you’re going to get is it can support more advanced authentication solutions, namely a third party, so third party non-Microsoft based solutions for authentication. Here’s a little flowchart for you. Kind of like a decision chart for you know what might be good, you know, a good solution for us.

So, if you look, look on there, it says, Do you want Azure 80 to handle sign completely in the cloud? OK. If no, then do you want to integrate with an existing federated provider? If no, do you have a signing requirement? Support it.

OK. Anyway, you can. You want take a screenshot of this and you can kind of think through it, and it talks about whether you should implement password hash sync plus seamless Esso or what.

Now, by the way, Seamless Esso, Is going to make it where when I if I’m setting up single sets of hope, I enable seamless acesso between my on-premise environment and Azure. What’s really cool about that is your on-premise users. When they log onto their domain account, they automatically get authenticated to the cloud so, they can begin accessing cloud resources, and they don’t get prompt that again without seamless.

So, if you just got plain old Hasso, then they log onto the domain. The moment they try to access their cloud service, they’re going to be asked to authenticate again.

OK, so seamless SSL was going to handle all that for you. Here are some considerations for password hash tag organization.

OK? Password hash synchronization hands-down is going to be one of the easiest things for you to deal with and deploy the maintenance. The management, it’s all, you know, pretty straightforward. It’s also the recommended solution that Microsoft gives you.

OK? The you know, the setup and all that is pretty straightforward for your users. It’s actually pretty simple as well.

OK.

Now there is one little small catch to this, and it’s not a big one, but with password hash synchronization, when somebody changes their password like on-premise, it’s going to synchronize it to the cloud. But there could be a maximum of two minutes of when that happens.

So just be aware, especially, you know, without the whole with this whole seamless acesso thing, that there could be a two minute period where the passwords don’t match right? So just consider that that is if there is a drawback to this one. Besides the compliance problem with with password hashes, that would be the biggest drawback, I would say.

OK, now looking at the consideration for through hash authentication or I’m sorry, pass through authentication to this one’s pretty simplistic to set up. You’re going to install the little agents on your servers. Microsoft recommends that you have about three of those agents and they can be installed on. Believe it or not, they can be installed on just about any type of server.

So you don’t have to have three dedicated servers.

OK, you can have it installed on three foul servers, OK? The great thing too, about Peter. You don’t have to put it in the DMZ, kind of like with federated services, you’ll have to have a demilitarized zone perimeter network to put the federated proxies. But with PTA, you don’t actually have to open up a bunch of ports coming in. It’s going to go. It’s got to have an internet connection going out, but you don’t have to have a bunch of stuff coming in.

So that’s nice.

OK. And then finally, with federated authentication, this one, again, as I’ve said, is definitely the more difficult to set up. It’s usually for the bigger companies. You know, it’s going to be a bigger investment. You’re going to have to have a minimum probably of four servers if you are hoping to provide redundancy for it, meaning two federated services on servers on the inside and then to federated proxy servers in your DMZ. They’re going to kind of be the middleman between the cloud and the on-premise adversaries. You don’t want services on the cloud. Communicating inbound to an HDFC server on the inside because that would be a security risk.

So this why you have to have a proxy to kind of be a middleman between those.

OK.

So these are going to be more of an investment. They’re definitely more of a headache. The benefits are for compliance reasons. Your password hashes are not going to be stored on-premise. They’re going to be I’m sorry, your password hashes are not going to be stored in the cloud, they’re going to be stored on-premise only. And the other big benefit is, of course, I’ve said, the third party multifactor authentication solutions and all that those are going to be supported as well.

So that’s going to be. The solution you would put in place if you were in that situation, OK? All right.

So all of these things that we’ve looked at just now are things we need to be thinking about if we are going to be moving towards setting up Azuri to connecting and setting up our authentication solution.

55. Preparing to implement Azure AD Connect

Now, as I approach the idea of being able to synchronise my on-premise domain with my Azure ad, it’s important for me to figure out exactly who all is going to be synchronized.

OK, so, I may want to synchronize my entire domain at some point. But in the beginning, Microsoft usually recommends that you do a pilot, a pilot group of users that are going to be moved there to the cloud first and then bring everybody else later. Don’t forget that when you run a lot, when you are going to run Azure Kinect, which is going to do the synchronization, you don’t have to synchronize your entire domain. In the beginning, you could synchronize whoever you want and then you can run it again later and synchronize everybody else.

So here I am on my domain controller. In my one, I’m going to click start. And then I’m going to click server manager. All right, and we’ll just wait on server manager to load up here. Finish processing at that point will be able to go into Active Directory users and computers, and we can start looking at our accounts.

So, we’ll click tools and we’re going to click Active Directory users and computers.

OK. And I’ve got a few just different users and organizational units and things that I’ve set up here just for demo purposes. You’ll notice that I’ve got some different apartments. I got finance and H.R, I.T. research, sales, users development.

So some different containers here. And here is my department now. The logic is this you know, who better to do the synchronization to be synchronize first and do the pilot of Azure ad than your I.T. people, right? Although maybe you don’t want all of your ID people to go.

So one solution you can do to deal with this just right click here like, I’m going to right click it. I’m going to click new create a group. I’m going to call this group cloud users all right, and then I’m just going to click OK, or actually not cloud users. I’m sorry, cloud admins. And then we’ll click OK, and I’m going to double click on cloud admins. And at that point, I can click members and I can add the people that I want to add.

So maybe I’m going to add the administrator and I’m going to add this Andrew Wilson guy. I’m going to add Billy Smith, and maybe I’m going to add Jane Doe.

OK, those are going to be my maybe my cloud admins or whatever that are going to that are going to be synchronized.

So from there, you’ll once we do run our Azure Eddie Connect synchronization wizard will be able to select if we want, we can select the entire interview, we can select this particular group. We can exclude things so, we can include, we can exclude. We have pretty granular with the actual synchronization of it.

OK. And we can have our user account synchronize. We can get in to group based synchronization and all of that good stuff as well. But it’s important to sort of playing this out and think about what, OK, who is actually going to get synchronized?