Azure MFA and User Authentication

0:06It's time to talk about multifactor authentication, or MFA. Now MFA is far superior than simply using a username and password, and guess who agrees? That's right, Microsoft, and they've built it into Azure. So it's time to jump in and talk about multifactor authentication a little bit more and see what options we have within Azure. All right, so what is multifactor authentication? If you're not familiar with it, it's using multiple factors to authenticate.

0:37So instead of just a username and a password, we're going to use an additional factor of authentication. Now what are factors of authentication? Well, there's three of them. And these are all something-- so I'm going to put that up here something. And that is something you know. So what is something you know? Well, it could be a password, or it could be a PIN that you know, maybe your PIN to your debit card or something like that, but that is something you know.

1:09It's also something that you have. So in this instance, it could be that you have a YubiKey-- and that's just like a USB key that is used for authentication, so you can plug it in and that can authenticate you. It could be that on your cell phone that you have an app, like an authenticator app, and that generates a PIN that you enter, and it rotates that pin every 60 seconds or whatever. But it's something that you have.

1:40It's a physical something that you have. Or it's something that you are. So here, we're talking really about biometrics. So it could be a retinal scan of your eye, or it could be a fingerprint scan, so you got there, or it could be a palm scan. That's a great hand, by the way. So it could be a palm scan, but it is something you are biometrics. So something you know, something you have, something you are, and multifactor-- that's what we're doing here.

2:12So something you know would be a password, but we need another factor-- maybe a USB, a YubiKey, or an authenticator app, or some type of biometrics check to validate you are who you say you are. Now multifactor-- it is far more secure than a simple password. That is very true, and that's because it's passwords-- well, passwords are constantly being fished. There's phishing going on all the time, and passwords are exposed, and there's data breaches, and within those breaches, oftentimes, passwords are identified, and then those are put out there on the dark web out there for everyone to see or purchase or download or something.

2:57But the idea is passwords are breached all the time, and a lot of them are out there, and people reuse passwords. So that's another thing, password reuse-- not cool. So multifactor helps to address all of those things. Now, when deploying multifactor authentication, do you just turn everybody on at once? Well, generally not. You do some type of phased approach, where you're turning on individuals or groups of individuals. So you have a first group over here, and then you have a second group, and this way, your first group is really kind of your test group to make sure everything goes OK, and then you go ahead and you roll it out.

3:36So who's in this first group? That's the real question. Who should we put in this first group? Well, we really want to make sure all of our admins have MFA turned on first. So we want them in our first group to really test out. Plus they;re tech savvy. They're the folks working with it anyway. They're going to be able to troubleshoot and find problems. But our admins should be some of the first folks up here leading the pack when deploying MFA. Now what about different methods of authentication? We talked about using apps on your phones, or YubiKeys, things like that.

4:10But what options do we have within Azure? And so when it comes to Azure, we really have four primary options. I'm going to put 1 through 4 down here. And the first one is a phone call. So you could actually have an automated service call your phone, then you answer it, and it tells you a PIN number to enter. But in order for this to work, you have to have your phone number in your user account attributes because that is where the service is going to look up your phone number.

4:45And if there is no phone number there, guess what? They're not going to be able to call you. And then we have texting as well, and that can go through an app that is registered, or it could be to your phone number, but if it's to your phone number, again, you got have a phone number registered. Then we have a mobile app, and there are different mobile apps you can use. Microsoft Authenticator is a good one to use. Google has an authenticator. There's multiple out there. But the idea is you can use that mobile app, and the service can send you a message that you can approve.

5:17So basically, you get this message that says, do you want to allow this log in? And you either approve or disapprove and you just hit the button. Or along this mobile app, we're going to go down here-- it's still a mobile app, but it is a code or a PIN from the mobile app. So you open your mobile app, and you have a PIN that rotates, and this number that rotates every 60 or 90 seconds, basically you're going to need to enter that into an application, where you're going to have your identifier, your PIN here, and that rotates, so you're going to have to enter that, and that will be your additional factor of authentication.

5:55So we've got a couple of different options within Azure. Now let's talk about licensing. So with multifactor authentication in Azure, what licenses do you have to have? Well, let's find out. All right, here we are on Microsoft's documentation. We're looking at "Features and licenses for Azure AD Multi-Factor Authentication. Now we're going to scroll on down here. They talk about a couple of different things, but I want to go down to "Feature comparison based on licenses." Now your Azure AD free comes with multifactor authentication.

6:26All of these features come with your basic multifactor authentication, even the free. That's what I really want to point out. So if we go down here and look at the different features, though, we see that we have "Protect your Azure AD tenant admin accounts with MFA." This is also your general accounts. Don't think it's not because it didn't say general accounts or anything like that, but it does include it, and I'll show you in the documentation here in just a minute. Also allows you to use the mobile app, like your Microsoft Authenticator, as a second factor. But if you want to use features like phone call or SMS like texting you have to have your Azure AD Free for global admin-- so that's only for your global admins.

7:07But if you go to Office 365 licensing, and you'll see it's included for everyone there. So that would be good as well. As well as Azure AD Premium one, your P1 and P2. And there's different features as we scroll down here that you can look at. But I just want you to realize that your standard MFA, like we've talked about using the authenticator app-- hey, that's included for everyone. And as we scroll down here, Microsoft does recommend that you use conditional access, and that's something we're going to talk about not in this set of videos, but in the next set in this course.

7:39So we're going to get to that. And as we scroll down here, I wanted to show you-- here we go, Azure AD Free tier. All users in an Azure AD Free tenant can use security MFA by using the security defaults. And that's turned on by default, and we've talked about that earlier. So there you go. Now the thing is the mobile authenticator app is the only method that can be used for your multifactor when using MFA in the Azure AD Free security default.

8:09So just keep that in mind. Even if you just got the free version, hey, you can still use MFA with the authenticator app. So that is something good. And hey, I prefer the authenticator app. It's so easy to use. So there we go with MFA. That's kind of the basics of it-- just a good review-- and then looking at some of the options you can use and the licensing required for those options in Azure. But in the next Nugget, we're going to be deploying MFA in Azure Active Directory, so I look forward to seeing you there.

8:39I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[MUSIC PLAYING] Now that we've had a little refresher on MFA and discussed some of the features that Azure provides us within MFA, and even looked at the licensing requirements for MFA, it's time to jump into the Azure portal. And let's turn on some MFA already. Here we are in the Azure portal. I'm going to jump over to Azure Active Directory. Here we are in our Nugget labs tenant in our Azure Active Directory.

0:30Now, what we're going to do is we're going to deploy something called per user MFA, because we're going to turn it on per user. Pretty straightforward. So we're going to go under Users here. Excellent. And we see over here per user MFA. We're going to go ahead and click on that. It's going to open up a new tab here. Now, when it comes to deploying multifactor authentication in Azure AD, it is a 2-step process. Number one, we have to turn it on for the user. Number two, the users have to go through the enrollment process to set it up.

1:03And it's just a little wizard-- super simple. And they'll be prompted to do so when they log in. So how do we turn this on already? Here we go-- per user MFA. We come down here. Look at all of our users here. I want to show you this real quick. Multifactor authentication status we see is disabled. And we go all the way down, and we do have one-- that's me. I'm enabled already, but the other users are disabled. So how do we turn them on? Well, you can just click on that and say enable.

1:33It's that simple. So we're going to go ahead and turn this on for any Oracle. And you don't have to do it just for one, though. You could like select multiple, see? So we could go through here and select all of those and say enable, or we can select everything. Whoa, whoa, whoa, whoa, whoa? What happened? My enable MFA disappeared. Yes, because I've selected me, and I'm enabled already, so that changes this. So be careful when you do that. Don't select the folks that are already enabled. So I would want to disabled me-- there we go-- and enable is back.

2:04There we go. So let's go ahead and click on Enable here. And it says about enabling MFA. They give you a link to a nice deployment guide so you can read up on it if you want to. But here's something very important. If your users do not regularly sign in through the browser-- because that's where they're prompted to go ahead and enroll in MFA-- you can send them this link. So you would want to copy this link to your-- and email it to your users, because if they're not logging in through a browser, well, they're not going to get the option to enroll.

2:37And basically, we'll just come down here and say enable multifactor authentication, but I'm not going to do that. All you do is click that. I'm not going to do that for all these users because I don't need to. So let's deselect it. Why'd it deselect everybody? Let's go through here and deselect these folks here. I want to show you something else here. Now, let's go down to me and click me. Now, once it's enabled, I can go in here and I can disable it. So if you want to disable MFA for a user or users, just come in here and disable it.

3:08But then we have something that says enforce. Now, what is enforce? Now, enforce forces the users to register for MFA the next time they log in with a browser. Because when you turn this on, your users have the opportunity to bypass the setting up or enrollment for 14 days. But you can do enforce and force them to enroll. However, this will affect legacy applications that don't support MFA. So if you run on something like Outlook 2012 for some reason-- I know know-- you have a reason to run an old version-- and it doesn't support MFA, guess what?

3:45You're not going to be able to log in using MFA, so you're going to have a problem there. And at that point, we have to create something called an app password, which is a password that allows you to bypass MFA for your legacy applications. And we're going to look at doing that here shortly, but here, we have manage user settings. And if I was to click someone else-- you see-- that is disabled, all I get is manage user settings. So let's go ahead and I'm going to deselect any Oracle. And look at these manage user settings.

4:17If I click on that, I have three options here. The first one is require users to provide contact methods. Again, this forces them-- next time they log in-- to provide their contact information-- again, their contact methods. So if you need to redo that for some reason, you can do that. Delete all existing app passwords generated by the selected users. Now, those app passwords are when we enable MFA and we need to still use legacy applications. So that's sort of those app passwords that we create.

4:48You can delete them all for a user if you want to, and you can restore MFA authentication on all remembered devices. kl if you've had a user go through multiple devices and they switch back to another one, you can restore MFA for that. So those are your options there under Manage user settings. So as you see, it's really simple to turn it on, which is superb because we don't like complex things-- at least, I don't like complex things. I like to keep it simple. Let's go up to the top here and look at service settings.

5:19We'll click on that up here, and there we go. Hey, look, there's our app passwords. So this is allow users to create app passwords to sign into non-browser apps, so we're talking to legacy apps here, really. So if you're not running legacy apps, you could just say don't allow users to create app passwords because you don't need them. But if you are-- and we're talking about legacy Microsoft apps-- something old like Outlook 2012 or something-- and you need to use apps passwords, then this is an option. And when the user registers or enrolls in multifactor authentication, they will have an option there to create an app password, or app passwords if they have multiple applications.

5:56So that's pretty cool. That's where we turn those settings on and off. And as we come down here, we have trusted IPs. This is pretty cool. So this allows you to skip multifactor authentication for requests from federated users on any internet. So this is when we're talking about our Federated. Users. So if you have on premise users, and you've done a federation from your local Active Directory to Azure, you can actually skip MFA authentication from these trusted IPs. So what would you do? Well, you put in your office IP addresses, really, is what you would put in here.

6:30And that way-- like your public IPs, as it's going to go out across the internet and authenticate to office, or portal, or endpoint, whatever you're accessing in Microsoft. But once you put those in there, you can actually allow your users to skip MFA because they're coming from a trusted IP address, so that's pretty interesting. And as we scroll down here, we also have verification options, and these are how the users can use MFA. And you see call to phone is grayed out, and that's because I don't have any phone numbers entered into anybody's attributes, so I can't use call to phone there.

7:10But I have text message to phone, notification through mobile app, verification code. And really, I like to select all these, and here's why. When a user goes through the enrollment, they get the option to choose which one of these they want to use. However, if I want to force something-- say I want them to use notification through the mobile app, I would deselect these. Then when the enrollment process comes along for a user, that's the only option that they have. If you want to give them multiple options, go ahead and select other verification options here.

7:41So that's where these come into play. Pretty cool. And then lastly, we have remember multifactor authentication on trusted devices. Now, this I do like because a trusted device is a device that's enrolled in Azure Active Directory. So that's what our trusted device is. And what we can do is if we click on this, and allow users to remember MFA on devices they trust-- this is between 1 and 365 days-- what this does is it allows them to no longer use MFA. They'll authenticate with MFA the first time, but then it's going to be remembered, so they won't have to on that trusted device.

8:18And here for 90 days, which is the default. But if you want them to use MFA every time they log in, do not enable this. But you can if you would like to. There may be certain individuals who you don't want to use MFA, and so that is how we can enable that feature. And then you would just come down here and just click on Save. Now, I want to tell you about something, and this is Microsoft's recommendation. I'm going to go back here to Users real quick. This is where we enable our per user MFA. Microsoft does not recommend you use this.

8:52If-- I want to put a big if out there-- if you're using conditional access policies-- now, conditional access policies we're going to talk about in the next skill, which is the next set of videos in this course. And the conditional access policy is basically where you set up a rule. And the rule says, if you're using this application, you have to use MFA. Or if you're using this application from this type of device, you don't have to use MFA, or you know what I mean? So what we're doing is these conditional access policies can influence how MFA is used. So what you could have then is a conflict.

9:25So you don't want to use per user MFA and conditional access policies. Just keep that in mind. You could end up with some big headaches, and nobody likes a big headache. And there we go. That's how to turn on, enable, configure, look at the settings for per user MFA in Azure Active Directory. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[MUSIC PLAYING] All right, now that we have enabled MFA for our users within Azure Active Directory, we are all done with MFA. Well, not exactly. We know that MFA, and really anything, isn't set it and forget it. We need to manage our MFA. There's going to be times when we need to troubleshoot MFA. Well, that's what we're going to look at right now-- our day-to-day management of MFA, and troubleshooting.

0:33Here we are in our Azure portal. We're going to go to Azure Active Directory. And we're in our NuggetLabz tenant, as usual. Now, here we go. Guess what? We're going to go over to Users because Annie Oracle-- well, guess what Annie did? Well, she lost her phone. That's right. And she went and got a new one. So she had to reinstall her authenticator app. And guess what? She installed it, but since she didn't have a backup of her settings, well, we need to re-setup Annie Oracle with MFA.

1:08How do we do that? Well, we're going to go into Annie Oracle. We're going to go down to authentication methods, down here on the left. We're going to click on that. And here at the top, we're going to click on require re-register MFA. Click it, there we go, operation complete. It's that simple. Next time Annie logs in through the browser, well, she's going to have to re-register for MFA. And at that point, she can re-setup her authenticator app. It's that simple. But you can also go in here and revoke MFA sessions.

1:41So if I click on this, it's going to revoke the session. So any active sessions that she has, through an MFA, it's going to terminate those sessions, forcing her to re-authenticate. Now, why would you want to do that? Because this, I see-- she lost her phone, got a new phone, and she needs to re-sign up. Well, what if we find out that she lost her phone, and that was on Friday. This is Monday. She gets a new phone, needs to register. But we've seen sessions logging in over the weekend. So somebody has been able to use her phone to log in with her MFA app.

2:15So that means we have a compromise. Well, boom. We go there, we revoke the MFA sessions, that knocks the user out. At which point, we would want to go ahead and probably change her password, because that would stop that from happening. And then we could go ahead and have her re-sign up for MFA. We'd have to go ahead and do that, as well. OK, so we see those are there. So that's our management of MFA. Now, let's look at troubleshooting. Let's go over here to NuggetLabz. And we're going to go down and click on-- where'd it go?

2:47Sign-in logs, there we go. And it's going to take this a minute to load. There we go, excellent. So these are our sign-in in logs, pretty straightforward. But if someone's having problems logging in with MFA, this is where we can come to get some clues to troubleshoot. So let's look at me. Now here, I logged into the portal. And I'm using MFA. I see success, success, interrupted, failure. Failure, hmm, failure-- all right. OK. So let's look at success real quick. We're going to click on this. It's going to open this up.

3:17I'm going to go over to the authentication details page. There we go. And here we go. It says here under result detail-- let's see if I can't spread this out a little bit-- the other direction, there we go. MFA requirement satisfied by the claim in the token. So MFA was successful. That tells me that when I logged in, MFA was used and it was successful. OK. But what if it wasn't successful? Let's go take a look at a failure. So let's open this one up, and the authentication details.

3:47First major-- result detail, that's what I'm looking at here. And there we go-- MFA requirement satisfied, requirement satisfied, OK. So the MFA stuff, I'm not seeing an error or anything. But if I go over to the basic info, failure region is right here. Password changes required due to account risk. OK, so there was something going on with my account risk. And we're going to actually get into that at a later point. But this is where we can find a failure reason.

4:18So there we go. This is how we can troubleshoot MFA logins. If we're having people failing to log in, usually a specific user, we come in here, look at the reason, and figure out, well, why is this happening? How can I fix this? So there's that one. There's also this one, this interrupted one. Let's take a look at that one. Let's see-- go to authentication details, it says MFA requirements were satisfied. So let's go back to the basic info-- status was interrupted, additional details-- this is an expected part of the login flow, when user is asked if they want to remain signed into this browser and make further logins easier.

4:57So when you see something like this, evidently it's not a big problem, right? It says it's normal. But here is actually a way to launch a sign-in diagnostics tool, which is really cool. So we can troubleshoot the event. So this is additional troubleshooting. There is a sign-in diagnostics tool. Let's go ahead and click that, open it in a new tab, and take a quick peek at this sign-in diagnostics tool. So diagnose and solve problems, sign-in diagnostics review, sign-ins. And this is the one that I had clicked, the interrupted.

5:30And it's actually running diagnostics, and it finished. It says, sing-in error details. It says, this occurred due to keep me signed in is interrupted when the user was signing in. OK, so what happened is I re-signed in again on top of myself because I had opened an incognito window. And that's what caused that interruption. But this is an additional tool that you can use to troubleshoot, sign-in diagnostics-- pretty handy. So that's how we manage our day-to-day MFA activities, and troubleshoot MFA signings.

6:01I hope it's been informative for you, and I'd like to thank you for viewing.

0:06We know that using usernames and passwords alone isn't really all that secure anymore. And hey, MFA came to the rescue and is able to help us with that. But is that our only option? Well, the answer to that is-- well, you'll see shortly. All right, teaser is, is that the only option? The answer is no, because we know passwords-- they're weak. They're always being fished, they're compromised, they're put out there on the dark web for everybody to look at.

0:39And it's just not that good. So MFA made us do something-- made us smile because it brought security to our authentication. But is that the only option? No-- an astounding no. Now I'm going to throw something at you. Ready? Passwordless. Passwordless? Passwordless? Hmm. No matter how you say it, it's kind of confusing, right? Well, how can I log in without a password, even with MFA?

1:10I had to put in a username and then a password, and then some type of other authentication mechanism-- a third part of this. But if I'm not using a password, well how does this even work? Well, you're about to find out, and it's pretty cool. So Microsoft provides us with three passwordless options, and you've already heard of some of these. You might not have realized, though, that they can be used in this way. The first one is Windows Hello for Business.

1:46So Windows Hello for Business can be used. What about the Microsoft Authenticator app? We've been talking about that. So there's our Microsoft Authenticator app. And something else we can use is, like we had mentioned, a YubiKey. Well, that is part of FIDO. And we're talking here FIDO2. And FIDO as Fast Identity Online. It's an open standard used for passwordless authentication. So Windows let's just use all of these things.

2:17All right, way to go. Now let's talk about each of these a little more in depth. Not too crazy-- just a little bit though. All right, starting off-- Windows Hello for Business. Now this is built into Windows 10 and later. So if you're using Windows 10 and later, then, hey, you are good to go. And this allows us to use biometrics. That's what Windows Hello allows us to do. I like saying it like that-- Hello. It allows us to use biometrics, so we can do things like a facial scan or a fingerprint scan, and once you authenticate with Windows Hello for Business, Azure AD, what it does is-- so we'll put your computer down here, and we'll put a big smiling face, because you did a facial rec ID, and you did that out there to our Azure appear in the cloud.

3:08And what happens is Azure then gives your device this cool little token. And there we go, that's our little token there. And with that token, you can continue to authenticate to Microsoft's Cloud Resources. So that is how it works, in a very simplified manner. But Windows Hello for Business is your first option. Then we [INAUDIBLE] Microsoft Authenticator app, and again, that's when we have our phone here, and we get that MS Authenticator app. And a couple of different ways we can use it-- number one, we can use what's kind of like a push message.

3:40So when we need to authenticate, a message is pushed to our phone, and it says, do you want to accept this login or approve the login? You're going to say approve or disapprove. Or you can use the PINs, the rotating PINs, that are in here-- that's P-I-N, there we go. And remember, those rotate every so often, like 60 to 90 seconds, they'll rotate. So you can enter that PIN into an application for the field there. So again, this is another way that we can go passwordless. You don't need a password because you can use either the push notification or the PIN, and away we go.

4:14And then lastly, our FIDO2 security keys-- this is kind of what they look like. It is a little USB-- looks like a USB thumb drive, really-- and you just plug it in, and it has some digital certificates on there that authenticate you as who you are. So what we do, then, is in our computer, we have to plug that thing in, and once it's plugged in, we go to authenticate. It can be used to authenticate us, but we don't have to necessarily plug it in. They also work via Bluetooth and NFC.

4:45NFC is Near Field Communication. So there are a couple of wireless options for some of these FIDO2 keys. But again, this comes down to something you have-- remember, we talked about that, something you are, something you know, something you have? This is something you have, and I actually have one of these, and it actually has a little box here, and it allows you to do fingerprint reading. So not only is it something that you have, it's also something that you are. So this is like a dual-purpose FIDO2 key.

5:15So that's pretty interesting. You can use those as well. Now the thing about this is the authenticator app-- guess what? The authenticator-- we'll put that up here. Authenticator app-- it is how much? That's right, it's free to use, free to download for use. When we come up with our Windows Hello-- so our Windows Hello, well, guess what? It is free to use. It's built into the operating system. But when it comes to these keys, they're not free, and they range in price. So they could be anywhere from, if you buy in bulk from like 12 bucks, but they can go up to like 40 bucks.

5:49So when you're deploying this solution, if you want to use these keys, well, if you've got 1,000 employees, that's going to be pricey. And guess what? People lose keys. You have to replace them. You have to manage them. Are they a good way to increase security? Yes. But guess what? So is, like, the authenticator app, and it's not going to cost you anything. So that is a downside of the FIDO2 keys-- it's something else to manage, and they do cost. So there you go. So that is how we can use passwordless authentication-- well, at least what it is and some options we have.

6:26In the next Nugget, we're going to see exactly how do we turn this on in Azure AD so our users can use passwordless. I hope this has been informative for you, and I'd like to thank you for viewing.

0:06Now that we know what passwordless is, and how we can use it, how it can help us further secure our environments. And we even know some of the options that we can use such as Windows Hello, our authenticator app, or FIDO2 keys within Azure Active Directory. So now that we know this stuff, let's put our knowledge to work. Let's go set this up. All right. Here we are. And we are in Microsoft Endpoint Manager. What are we doing in here?

0:36All right, here we go. Here's the down low folks. When you want to use Windows Hello for Business, well, that's part of a device. That's part of the operating system living on that device. So in order to use Windows Hello for Business, you need to have Intune licenses. And Intune is the device management product from Microsoft. So that's why we are in the Endpoint Manager Admin Center. Now we're going to set up Hello for Business. That's right. So here we go.

1:06We're going to click on Devices over here. There we go. Then we're going to scroll down to Enroll Devices. And where is it? There it is under Device Enrollment, Enroll Devices. And here we go. Now that we're in here, on the right over here, look for Windows Hello for Business. And here it is. So replace passwords with strong two-factor authentication. If we don't have a password, we are using passwordless. That's right. So we're replacing passwords with this strong two-factor authentication. I'm going to click on that.

1:37All right. Here's how we enable this. So what we're doing is really creating a Windows Hello for Business kind of policy. We're going to set some options down here. So I'm going to go ahead and go down here to Configure Windows Hello for Business. And it is enabled. And then I want to-- now, I could say disabled or not configured, but it's enabled because I want to enable it. Use a TPM, a Trusted Platform Module. You say required or preferred. Now, what is a TPM?

2:07Now, a TPM module is an actual chip or module on the motherboard of computers. And what it does is it stores cryptographic information like certificates. And these are used to verify and validate software running on computers. And so I don't know if it says anything in here about what they do, but what they do is they sit there. They got certs on them, right, certificates and digital keys. And what it does is it will check to make sure that prior to the operating system loading, that the pre-boot firmwares and softwares running are legitimate.

2:41So you don't have things like rootkits running. And also, some TPM modules will offload cryptographic operations to help save CPU cycles. But the idea is they're there to make sure that is a trusted firmware and software that's running on there. OK. There we go. So we're going to go ahead and say required because TPM modules are on most computers these days. Then we're going to come up with a PIN length. So we've got to have a PIN number. So this PIN, it's not just a number.

3:11It's a PIN because there are also characters and digits and letters and such. So we need to define the complexity characteristics of our PIN. So our minimum and maximum PIN length, I don't think I want 127-character PIN, let me tell you. Lowercase letters, says not allowed, allowed. You can say allowed or required. We can say required, we can day required. We can make this thing as complex as could be if you wanted to. Or you don't have to. And then the PIN expiration in days, how long do you want the PIN to be good for?

3:44And then as we scroll down here, the next one is remember PIN history. And if you've ever configured a password complexity requirements group policy in an on-premise domain controller, you'll see many of these are the same kind of thing. So your expiration of days, the history, so people can't reuse their PINs. Allow biometrics for authentication, so here's if you want to use a fingerprint scan or a facial recognition. Yeah, why not? And then, use enhanced spoofing when available. Yes. And this is a feature for Microsoft. Don't know if this is a whole lot about it.

4:14But it uses some intelligence like machine learning kind of thing, AI. And what it does is it tries to identify spoofing, and it'll block spoof attempts. If this is set to yes. Well, of course, I want the additional protection. Allow phone sign in. And this is a way for users to use their phone as a companion for their desktop. And they can actually use their phone as part of the authentication process if you want them to allow that. Now, one thing about that, though, if you do allow it, what if somebody loses their phone?

4:47You've got to go through the setup process again. It's just something to consider. And then lastly, use security keys for signing. And either yes or no. And the security key, that's those FIDO keys. That little USB plug-in key. It could also do Bluetooth. But that's what those security keys are. So that's how we would go through. And we'd have to click on Save at that point. And then we would have Windows Hello for Business enabled. Now, again, for this to work, the device has to be an Azure AD-joined device, and the user logging in must have an Intune license.

5:22So there you go. All right. We'll close that out and say, OK. And that's how we go through enabling Windows Hello for Business. Now, we're going to take a look at using security keys. It's our FIDO2, those USB keys. And we do this from within the Azure AD portal. So I'm going to jump over there. Here's our Azure AD portal. Now, what we're going to do is we're going to go down to Security we're going to click on that, then we're going to click on Authentication Methods right here. And here we have some options that we can enable, FIDO2 security keys, Microsoft Authenticator.

5:57That's what we're going to do next actually. So first, we're going to do FIDO2 two security keys. We're going to click on that. And it's really simple. All we're going to do is say, yeah, you can use them if you want to. All users can use them or only select users. And then we go up to the top to configure. We'll click on that. And allow self-service setup so the users can set their own keys up if you would. Enforce attestation, this enforces that you can only use FIDO2 Alliance-approved keys.

6:28So it basically does a validation to make sure their FIDO2 Alliance-approved keys and they're not some brand of key that isn't FIDO2-approved because there are security features and standards that have to be met. So yeah, that I definitely do. And yeah, let him self-service set up. Why not? Now, if you want to enable a key restriction policy, meaning it restricts the keys to the ones that have their IDs, and these keys have what's called an AAGuid. And that is a global unique ID that's on these keys.

7:00And what we would do is, do you want to use this? OK, yes. Well, then we have to either block or allow. So here, we're going to create a Guid list, and we're going to say restrict specific keys. I'm going say yes. I'm going to block specific keys, and I can create a list here or I can say only allow specific keys. So I would click on this. And I would go in there and put in the key ID. And actually, it's too big. So I wonder if I could just copy this if it would take that.

7:31Let's see. Hey, sure did. And I say, OK. So this is a key that I'm going to allow. But I'm only allowing these. So this way, I could deploy certain keys to users. But as an admin, I'd have to come in here and put all these IDs in. And really, I don't think this is really necessary. I probably wouldn't do that. Now, the self-service, yes. And enforce attestation, yes. It's going to make sure you don't have some junk unsecure keys in there. There you go. So that's how to set up FIDO security keys, and you just click on Save.

8:01Then we're going to look at how to set up the Microsoft Authenticator app. So let's go back here and say, OK, we're back to our security authentication methods right here. And we're looking at our policy. So next, I'm going to click on Microsoft Authenticator. Do you want to enable this? Well, yes, I would like to enable that. You want to do it for all users or only select users? It's up to you. Then we're going to come over here to these three dots and click on this and go to Configure. Now, here we go, Authentication Mode.

8:32If we click on that, we could say password list or push. And password list, if we wanted to enter a PIN number. Require number matching. Now, number matching increases the security of Microsoft Authenticator. And how it works is-- I don't have a screenshot of this, I wish I did-- basically, when you're logging into an app if you're using this, it's going to actually instead of just sending you a push message to approve, when we turn this on, it's actually going to show you when you're logging in on the screen a number.

9:06It might be two digits or four digits. But it's going to give you a number. And you have to type that number in to your Microsoft Authenticator app. So you're not only just clicking Approve button, but you're also entering that number. And it just increases the security by another level. And then down here, we have show additional context in notification preview. And what notification context does is provides additional information. So on your login screen, you would not only get the Approve or Deny.

9:38It would show you who is logging in, the username, what apps they're logging into. And actually, even their location. So it's additional information so that you can make an informed decision on whether to approve or deny the connection request. And then we would say Done. And if we go back here to authentication methods, say, OK. That's how we turn on FIDO2 keys and the Microsoft Authenticator for passwordless authentication. I hope this has been informative for you, and I'd like to thank you for viewing.

0:05Did you know that, according to Garner Research, a password reset call to a help desk cost, on average, about $70 to reset a password, and that 20% to 50% of all the calls into a help desk are for password resets? Well, wouldn't it be great if there was a way that we could allow our users to reset their own password so they don't have to call this? Well, guess what? There is. It is a self-service password reset, SSPR, and let's see how that works in Azure.

0:38All right, here we are in Nugget Labz tenant. We're going to go up here to our users. Now in general, the way this would work-- let's say Bill calls in, and he says, yeah, about that, I forgot my password. So what would have to do is click on Bill Lumbergh come in here, and click on Reset Password, and go ahead and reset Bill's password. So let's click on that and let's see what happens. Oh, no. "Unfortunately, you cannot reset this user's password because password writeback is not enabled in your tenant."

1:10Guess what? Whenever you set up your Azure AD Connect for your AD-synced users, in order to do password resets, we have to enable password writeback, and that was not done when this was set up. So let's close this out. Let's go back to another year. So that's something to keep in mind. Let's find one that's not Directory synced. Let's go with Annie. All right, Annie, let's reset your password. OK, says here the user oracle@nuggetlabz.com will be assigned a temporary password that must be changed next time they sign in.

1:46So to display the temporary password, click on Reset Password-- bloop, there we go. It's going to reset it, and there's the temporary password. So now that's how we go through a manual password reset. But we want to avoid that, don't we? Absolutely. So we're going to close that out. So we're going to enable SSPR, or self-service password reset. So to do that, we are going to go back here to Users. So basically, we just went to our Azure Active Directory portal as our main page in our Nugget Labz tenant.

2:20We went to Users, we want to come down here to Password Reset. That's right, this is where the good old SSPR lives. Now I do want you to see this message here-- says, "These settings only apply to end users in your organization. Admins are always enabled for SSPR." Aha, so this is already enabled for all admins. It just does that by default, which is really nice because things happen and we know that we don't want our admins locked out because they don't know the password.

2:54So here we go. All right, so what we want to do is self-service password reset-- I've already got this turned on. But basically, it might be set to None, Selected, All-- I turned it to All and clicked Save. That's it for turning it on. But there is a couple of configurations that we should look at. Let's go down here to Authentication Methods. All right, there we go. So a number of methods required to reset. Do you want to allow a single method of authentication in order to reset a password or multiple?

3:26Then, I would like multiple, thank you. And then which methods should users be able to use? Mobile app notification, mobile app code, definitely email, mobile phone, office phone, security questions. Now if you click Security Questions, you have a couple options down here. Number of questions required to register-- so when somebody registers for this, how many security questions do they have to answer. Let's say four. That sounds good to me. Number of questions required to reset a password-- aha, three.

4:00Now the thing is down here it says, under Select Security Questions, you have to go through and select some questions. It says please select at least four questions. So let's do that. Let's click on this. You could write your own custom security questions, or go to the predefined. I like the predefined. So let's see-- how about that one. In what city did you meet your first spouse or partner? In what city did your parents meet? What city was your father born? Which city was your first job? What's your favorite food?

4:30I mean, you could select lots. And the thing is, when you select these, when they go through and answer these, they have the choice of which one of these to answer. So really, you could say mother's middle name, you could just select all these. And this way, when they come in here to set this up and answer the questions, well, they get to choose what questions they want to answer. You're just giving them a choice at that point. But if you don't want to give them a choice, only select four, and then move on. So we could say, OK, there we go. We have 11 security questions.

5:02But you don't have to do 11. You could do all of them, or you could do the minimum of four. Or if you change this to five, it's a minimum of five. You have to match at least the number of questions required to register. All right, so that is our authentication methods and there we go. Now we would just click on Save, and away we go. So that's how we set up our SSPR, or self-service password reset. We come under Property, and we say, OK, [INAUDIBLE].. Come into Properties, we turn it on for just selected users or all users, then we come under Authentication Methods, and we go through and set this up as well.

5:34I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[MUSIC PLAYING] So we're on the topic of usernames and password and passwordless and all of these types of authentication. Well, we also need to protect our credentials and our accounts. We need to do things like enable password expiration. We need to do account lockout settings and all of those good things that we're going to talk about right now. All right, here we are in our Azure Active Directory.

0:30We're in our NuggetLabz tenant. And what we're going to start with is password protection. So we're going to go down here to Security. Down here-- let me scroll up a little bit. There we go, Security. And we're going to go to Authentication Methods. And here we go, Authentication Methods. Excellent. And then to Password Protection. All right. There we go. So this is our password protection. Here, we can set the number of failed logins before an account lockout. So there's our lockout threshold. Well, it defaults to 10.

1:00That seems kind of high to me. Let's go with 5. Then, our lockout duration in seconds. So if an account locks out, it's only locked out by default for 60 seconds. All right. I'm going to stick with that for now. Then, we can have a custom banned passwords. So if we want to ban passwords, like commonly guessed passwords, let's say, yes. So it'd be like Summer22 and maybe even exclamation. And Fall2022-- there we go-- and maybe a Shift-1, 2, 3.

1:32Whatever-- P@SSW0rd. All those kinds of passwords-- we can Google it and find the 1,000 most common passwords and put them in here. And this will prevent users from using those passwords. That's awesome. Now, there's a word up here I want to talk about before we go on-- smart. Why is this a custom smart lockout? Hmm, interesting. I wonder what this says. Well, what this does is it uses some intelligence. So if we read here, it says, how many failed sign-ins are allowed on an account before it's first locked out?

2:07And we set it to 5. All right. Now, if the first sign-in after a lockout also fails, the account locks out again. So that means we don't have to wait five failed logins each time. So if we had five failed logins, the account locks out for 60 seconds. After that 60 seconds, the account's no longer locked out. If the first login is a failure, it immediately locks it again. All right. So there's some intelligence built into that. Well, what about a lockout duration? Check this out. The minimum length in seconds after each lockout-- yep, we know that.

2:40But if an account locks repeatedly, this duration increases. A-ha. So there is intelligence built into this lockout, and that's why it's referred to as smart lockout. That's pretty cool. All right. So we've got our custom banned password list. We talked about that. And then here we have Password protection for Windows Server Active Directory. What? So this isn't Azure Active Directory. This is actually your on-premise Windows servers, your Active Directory servers on-premise, or they could be running in the cloud.

3:16But basically, your servers running Active Directory, not Azure Active Directory. So what this does, it enables password protection on those servers. So it's taking these features, and it's pushing them down to your servers on-premise or if they're running as a VM in the cloud. Now, the thing is, you must install the Azure AD Password Protection Proxy Service as an agent on those servers for this to work. And then lastly, we have Mode. And this is for all these settings.

3:47Do you want to just audit this so it will log what would have happened? Or do you want to enforce it? So that's your options there. But I do want you to remember, this is pretty interesting. I just find this really interesting because they want you to allow you to push these settings and the intelligence in these settings down to your on-premise servers, your Active Directory servers, if you want to. We'll say no for now. All right, there we go. So this is our password protection and smart lockout threshold.

4:20But wait, there's more. That's right. We're also going to talk about password expiration policy. Now, I don't see password expiration in here anywhere. Hmm, interesting. It must be somewhere else. Well, it sure is. It's actually located in the Microsoft 365 Admin Center. So let's jump over there. There we go. Here we are at Microsoft 365 Admin Center. Now, in order to make this change, basically we're setting a password expiration policy. We're going to go under-- down here under Settings.

4:51We're going to go to Org settings. There we go. And then we're going to click on Security and Privacy tab up here. There we go. And then we're going to go down here and select Password expiration policy. There we go. And this is setting the password policy for all users in your organization. So we clicked on that. And it says-- right now, it's Set passwords to never expire. I'm going to uncheck that. And here, I can set the number of days before a password expires.

5:22So we could set this to 90 days, 180 days. Maybe you want to change twice a year. Whatever that might be. And then you would go down here and click on Save. And that's all there is to it. It's fairly simple. And there you go. Those are some settings that help us increase the security of our passwords, allowing us to do password rotation, do a password expiration policy, using those smart passwords, using password protection and smart lockout thresholds. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[MUSIC PLAYING] Most people use passwords as a form of authentication. We have a user account and we have a password. But there's another way to do it. We can also use certificates. And guess what? Microsoft Azure now natively supports certificate-based authentication or CBA. So let's jump in and talk about certificate-based authentication. So is this new in Azure?

0:31That might be a question you're asking. Well, the truth is, no, not really. It's been around for many years. However, within Azure ID, in order to use certificate-based authentication or CBA, we had to use something like Active Directory Federated services, or ADFS, or some other technology to make that happen. But now, we have the opportunity to use cert-based authentication, natively. So that is a cool thing, natively within Azure.

1:03So that's pretty darn cool. So now, we can implement this, and use certificates to authenticate to Microsoft Azure. But that's a little different than using a password, right? Absolutely. And it requires a PKI infrastructure. So that's a public key infrastructure. So that means you're going to have to have some type of certificate server. So within the Microsoft environment, maybe in on premise environment, you're going to have your Active Directory domain.

1:34You've got your domain controller over here. And you're going to need to spin up a server that is a member server of the domain. And on that member server, you're going to install certificate services. In that certificate services, is your PKI infrastructure. And as part of this, you're going to have what's called a CA, or a certificate authority. And that CA is going to allow you to generate certificates. And then, you're going to be able to use those certificates to authenticate to Azure.

2:10Now, you don't have to stand up your own CA. You could obviously go and purchase public certificates from a public CA. However, that's going to be pretty pricey. So this is a pretty good setup here to set up your own certificate services within your domain. So once you generate the certificates, well, one question is, where do these user certificates reside? And there's a couple of options. Number one, you could install those certificates on the user's computer, and that way it's always there.

2:43So as long as they have their computer, well, guess what? They've got their certificate as well. Another option is to use something like a YubiKey, which is a USB security device. And you can install the certificates on those, and then protect the device with a PIN. So you have to enter a PIN before the device will mount and you can read the data on it. You could also use a smart card, which is a credit card sized card that has a microchip on it. And you can store them on there as well.

3:14And this also leads into the idea of using Multifactor Authentication with certificates. Because if I have a YubiKey here, and it has my cert on it, well, guess what? This is something that I have. And if I have to use a PIN in order to access it, that's something that I know. And there are two different types of authentication mechanisms. Therefore, it is Multifactor Authentication. But I have a USB security key like a YubiKey.

3:47But on that key, we've got it looking like this here. It actually has a fingerprint reader right on it. So in order to access the data, I have to use a fingerprint. So that's something that I am. So again, that, in combination with what I have here, in this instance, is Multifactor Authentication. So you don't have to use multifactor, but you can, and that's an option. And we're actually going to look at configuring that later on. So let's talk about some key benefits of using certificate-based authentication.

4:22So number one is going to be user experience. And here we're talking about a good user experience. Because well, number one, we don't have to go and set up an ADFS, or Active Directory Federated Services. So it's easier on our admins in the setup, and complexity. Also, for our users, guess what? You don't have a password that you have to remember. You just need to have the certificate. So it is an increased user experience, or an improved user experience.

4:53Number two, it's easy to deploy and administer. So again, we're not needing an ADFS. We can use policies to set up some rules, such as MFA, whether it's required or not. And we can also directly authenticate against Azure, meaning we don't need a third party in the middle, or a proxy, or anything. And then, of course, no complex setups like we have with ADFS. And we're actually going to go through and set this up.

5:25So you'll get to see how simple it is. And then lastly, secure. Because it's more secure to use a certificate than a password. We also have no need to store passwords in the cloud, because we're going to put a public key in the cloud that allows Azure to authenticate our users through their certificates. And there's no need for us to store our on-premise passwords in the cloud. And of course, secure, it allows for MFA, or Multifactor Authentication, which we had just talked about.

6:02So those are three key benefits to using certificate-based authentication. Improved user experience is easy to deploy and administer. And it's secure. So let's talk about the process here. So how do we go about deploying this? Well, number one, we need to set up a PKI infrastructure within our environment. All right. So-- or we could use a public PKI. It doesn't matter, either way. You need a PKI so that you can generate certificates.

6:33And that is step 1. Step 2 is going to be, deploy certificates, so that our users have those certificates, whether it's on a computer, on a smart card, or a USB security device, our users have to have them, so that they can use them. Number 3 is to configure certificate-based authentication policies within Azure, 'cause these are going to be our individual settings and policies about it. Then number 4, basically just turn it on.

7:04Turn on CBA in Azure. And at this point, we have a PKI. So we can generate, distribute certificates to our users. We set up our policies that we want to use. And then, we turn it on. And then lastly, well, we simply use it and manage it. There we go. So that is the process that we are going to go through. Next up, is a question you may have. Well, what are the licensing requirements to use certificate-based authentication? Do I have to have an E-3 or an E-5?

7:36Do I have to have a certain level of Azure ID? And the answer to that is, it doesn't matter. As long as you have an Azure ID account, and you've set up your tenant, you can use it. So there are no special licensing requirements. And that is pretty darn cool. And lastly, why should we even consider using certificate-based authentication? Well, it comes down to enhanced security, and usability.

8:08And when it comes to passwords that we've used for so long now, well, passwords can be cracked. We know that. So you can use dictionary text to try to crack passwords. And that's being done all the time. We end up with password re-use and weak passwords. It happens. So really it comes down to bad password hygiene. So if we were to use CBA, and we do away with passwords, we do away with these weaknesses as well.

8:43And certificates are created using strong encryption. So when we do that, it's very unlikely that they could ever be cracked. It would take a very, very, very, very, very, very long time and lots of processing power. And with certificate authentication, our users don't have to remember those pesky passwords, which also means hey, for us admins, no password reset. Hey. So overall, CBA is easier to use and more secure.

9:13So it comes down to security and usability. So that is certificate-based authentication, what it is, what the requirements are, licensing, what type of setup it is, and the process to go through that. And of course, well, why even use it? So now that we know about CBA, it's time to jump in to our environment and set this up already. So I will see you in the next Nugget. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[MUSIC PLAYING] So now that we're all excited about certificate based authentication in Microsoft Azure, it's time to perform step 1 in our setup, and that's to set up our PKI in our environment. So I've got a lab environment set up. We're going to jump onto one of the servers, and we're going to set up our certificate authority in PKI infrastructure. So here we go. All right, here I am on my server. This is a member server.

0:30So I'm going to install certificate services. So I'm going to go over here to Manage. I'm going to go to Add Roles and Features. Let that load up here. All right, there we go. We'll say Next. And this is role based. There we go. Select a browser, select the server. I'm going to select that one right there. It's the one we're on. Next. And we're going to select Certificate Services right there at the top, say Add Features. Excellent. Perfectamundo.

1:01So now that we've selected that, we're going to say Next, Next, and Next one more time. All right, now we have options to install additional features. So if you wanted your users to enroll themselves in certificates, you'd probably select the-- let me cancel that real quick --the Certificate Authority Web Enrollment so they could do that. You'd click this, and then it's going to also install the is IIS Web Services. So I'm going to say Add Features because that's what I'm going to do here in the lab environment. But otherwise, you could just install that, the original Certificate Authority.

1:36You could use group policies to push this out so that the certificates would automatically get pushed to all the users once they log in on their computers. But if you do the Web Enrollment, the users could then also copy that to a YubiKey or something like that, just depends on your setup. But for the lab, we're going to go ahead and do the Web Enrollment. So I'd say Next, Next again. Go ahead and Next again. And go ahead and say Restart if Required. We'll say Yes and go ahead and install there. And it's going to take this a few minutes to go through and install.

2:08So we will continue once it's finished. All right, this installation is finished. It did not reboot. So what we're going to do now is click on Configure Active Directory Certificates Services on the destination server, right here. Or you could say Close and go up to this icon up here, under notifications, and you can also click on it there, so either way. So what we're going to do, go ahead and click on it here, and it'll open this window right here. So what we want to do is provide credentials. Make sure that you are using your domain administrator or an account with the proper credentials because if you don't have proper credentials here, our next step won't quite work.

2:45So we'll say Next, and we want to go ahead and select Certificate Authority, and give it a minute to check things out. Then select Certificate Authority Web Enrollment and say Next. Now if you don't have proper credentials, you won't be able to select Enterprise CA. It'll be grayed out. You'll have to select Standalone CA. That's not going to work in this instance. So we're going to have an Enterprise CA. So make sure you select that. Go ahead and say Next. And we're going to say is a Root CA. It's a Root Certificate Authority in the PKI hierarchy.

3:20So this is the top of the food chain as you might say. We'll say Next. Create New Private Key, yes please. Next again, select your cryptographic settings here. We're going to go with a key length of 2048 SHA256. All right, super duper. Create a name for the key. You can just leave the default if you want. That's what I'm doing. Now specify the validity period. How long do you want this certificate to be valid for? So you're going to need to check with your company or organizational policies to find out or check with the security folks.

3:54All right, there we go. And maybe you are the security folks, so you get to make this decision. I'm going to leave it at 5 years. We'll say Next and go ahead and specify database location. You can leave that up to default and go ahead and click Configure. Now it's going to go through and configure these, and it does it pretty darn quick. There you go. Configuration succeeded. So I can go ahead and close that out, close this out. And now I could come over here to Tools, Certificate Authority. Let that open up, right here.

4:24There we go. And we can expand that. And we see that we now have a CA. We've got Certificate Templates down here. And we're going to be using user certificates to authenticate our users. But then you can come in here and look at Revoked Certificates, issued, pending, and failed requests, all of that good old stuff because you may at some point have to go and approve a request depending on how you set things up. So now we have our CA up and running. It's our PKI infrastructure, and that was step 1.

4:56So in the next Nugget, we're going to set up step 2, which means we're going to basically issue a certificate for one of our users. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[AUDIO LOGO] Now that we've got our PKI set up in our lab environment, whoa, it's time for step 2. And that's where we make sure that our user has a user certificate so that they'll be able to use that later on. So let's make that happen. All right. Here we are. I'm on a Veeam machine here, my lab environment. And it's a Windows 10 Enterprise workstation. So what I'm going to do is go through the Web Enrollment process to grab a user certificate.

0:33So I'm going to go over here. And since I'm using self-signed certificates in this, I'm going to use Internet Explorer. I'm sure many of you are not a fan of that. But because of the security settings within like Google and Edge, it-- Well, let's just say this is what I could get to work. So we're going to go out to our certificate authority. I'm going to go ahead and put in the URL here. That's at our nuggetlabz-ca.local/certsrv.

1:03That certsrv is the Web Enrollment page. So we'll hit Enter. Should ask us to log in here momentarily. More Information, Go on to Page. There we go. And log in. And I'm logging in as Johnny Appleseed, johnaseed-- there we go-- @nuggetlabz.com There we go. Excellent. Now what I go do is go to Request a Certificate, say User Certificate. And this is a Security warning, saying, hey, they're trying to do stuff-- digital certificate operations on your behalf.

1:38Say Yes. There we go. Expand More Options. Select your options in here. I'm going to leave it at the defaults. Say Submit. It's generating. And say Yes again. And there we go. The certificate you requested was issued to you. So you can click Install the Certificate, but I've already done that. So I'm not going to do it again. But what I want to show you is if we go down here to mmc, go ahead and hit Enter. We're going to go up here to File, Add/Remove Snap-in, we're going to select Certificates, Add.

2:11There we go. Current User. Excellent. Go ahead and click OK. Now, if I expand this, I'll go under my Personal Certificates, I should see my John Aseed Nuggetlabz certificate. And that's what I have right there. So I know that I now have my certificate. But I could always just click over here back on this page and install it. Like the first time I did this, I would install the certificate. And it would just go ahead and put it in there for me.

2:41So now Johnny has his certificate. So that wraps up our step 2. In the next Nugget, we're going to jump into the Azure portal and begin configuring CBA, or Certificate-Based Authentication. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[MUSIC PLAYING] All right, now it's time for us to jump into the Azure portal and start configuring CBA or Certificate-Based Authentication. So let's get started. All right, here we are. We're actually on our certificate authority server. And I've brought up the NMC here, and I want to go to File. And I'll show you why here shortly. I add or remove snap-in. We're going to select Certificates. Say Add, and we're going to select Computer account because I need to export the certificate authorities certificate, so I can import it into Azure so it will trust my certificates.

0:42So we'll say Next. Go ahead and Finish. OK, there we go. So let's go ahead and expand this. It's very important that when you see certificates here, it says local computer. Next, we're going to expand Personal. Go to Certificates. This is the CA's certificate. We're going to right-click on that and go to All Tasks and Export. There we go. We've got an Export Wizard. We'll say Next. Say no, do not export the private key. Say Next. We want this in a CER format.

1:14Then we'll say Next again. Give it a location. We'll go to our Desktop. There we go, and we'll give it a name. Let's drag a little further up. There we go. We'll call this our Ca-Cert. How about that? Enter, and say Next and Finish. And there we go. There's our Ca-Cert over there. Go ahead and close that out and excellent. There we go. We're finished with that, so I'm going to minimize that. Now, here we go.

1:44We're in our Azure portal here. We're going to jump into Azure Active Directory. Click on that. Excellent. Now, we're going to scroll on down to Security on the left. Click on that security. You can open this up. Now, we need to find certificate authorities. Here under Manage, we're going to click on that because we have to import our certificate in here so that it will be trusted. And I've actually already done that here. But the idea is you come up here. Click Upload. It's going to open this slide out here. You're going to browse.

2:15You're going to select your certificate. Here we go. Say Open. And is this a root CA? Yes, it is. Then you can provide your URL for your Certificate Revocation List or your CRL. And that's where a CA will-- if it identifies a compromised certificate, admins can go ahead and revoke that certificate, so it's no longer valid. And if you provide this, it allows Microsoft to go out and check to make sure that a certificate has not been revoked. So it helps increase security.

2:46And then we'd come down here and click Add. And it's that simple. So you go ahead and add our certificate authority. I'm going to cancel that because I had already added it in here. So now that Microsoft trusts our certificate, it will allow our users to authenticate once we finish the configurations. So the next step is to configure some binding policies. Now, binding policy helps determine if this is going to be single factor or multifactor authentication. So let's go ahead and configure that.

3:17So what we're going to do is come over here and select Authentication Methods here. It's going to open this up. And at the bottom, we see certificate-based authentication. We're going to open that up there. Excellent. Now, when you first come in here, this is going to be turned off. So what are you going to need to do? Well, you're going to need to turn it on. There we go. Then default is all users. So this is going to be turned on for all users by default. But you don't have to do that, and I didn't because I want to do some testing.

3:48So I say selected users, and I put Johnny Appleseed there in there as the only user who this certificate-based authentication will apply to. And this is-- when we're going through and setting this up, you want to test it to make sure it works and such. Then you can come in here and change it to all users, but you need to make sure all of your users have certificates. Keep that in mind. And then you're going to go ahead and click Save so to the save that. There you go. It's going to drop you back out. So now we have to configure our policies. We're going to go back in here. I'm going to go to the Configure tab.

4:20And here's our policy. So by default, your protection level is single factor authentication. But you could always move it to multifactor if you want to. And you can also add rules down here. So let's take a look at the add rules. So what this does, it allows us to get a little more granular. So what you can do is you can add a rule because these here, this protection level, single-factor, multifactor, that's global. So no matter how many different CAs and certificates you have, it all applies to everyone. But you can create rules in here for specific certificate issuers, so specific CAs, or by a policy OID, either way.

4:58But if you wanted to, you could select a certificate from a certificate authority like that and then say they're going to use multifactor, but everybody else uses single factor. So I'd have single factor over here, and then I can say multifactor for any certificates from this certificate authority or certificate issuer. So you could do that. So that allows us to be more granular, and you can set those rules. So I'm going to cancel that. I'm going to leave it at single factor for now. All right, and the next thing we need to do is set up username binding policies.

5:29And that's right here. And it's actually pretty simple. And what this does, this is within the certificate field. It is the attribute principal name here, and there's RFC822Name. And then we have to map that to a user attribute within Azure. So if it sees that certificate come in, it knows that the principal name attribute needs to match the user principal name attribute. And this was this way by default. I didn't have to change anything. And that's how we want it. So since I didn't actually make any changes, I don't have to save anything because I'm only using single-factor authentication, and these are going to work for me out of the box.

6:09So there we go. So now that we've got it turned on, we've got our policies, and we had set up our trusted certificate authority under here, where we imported our certificate, well, hey, it should work. So what do you say, we test it out? So let's go ahead and do that. Let me jump over to here, back on my Johnny Appleseed machine. And what I'm going to do is open up-- actually, it's already on the desktop. I'm going to open up Google here, and I'm going to go to myapps.microsoft.com.

6:43There we go. And It should ask me to log in, and log in. Pick an account. So I'm going to pick my Johnny Appleseed. Trying to sign you in, and now I could enter my password. But we're using certificates, remember? So I'm going to come down here to sign in with a certificate. I'm going to click on that. It's going to pop this up. It sees that I only have one user certificate on this computer. So it basically it selects that by default, and I just say, OK. And now, it logs me in. Hey, do you want to stay signed in?

7:14Not this time. Thank you very much. But it's going to go ahead and sign me in. And you see that is a passwordless authentication using certificate-based authentication. So that is pretty darn cool. So we saw that whole process, all the way about talking about what CBA is, all the way into setting up our PKI infrastructure, getting a certificate for our Johnny Appleseed user, and then setting it up within Microsoft Azure, which is actually pretty darn simple. So that's the entire process. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[INTRO SOUND] For years, I wondered when I deploy an Azure virtual machine, why can't I log in with my Azure AD credentials? Wouldn't that be really cool and super handy to be able to do that? Well, guess what? Now you can. That is right. You can now deploy Azure VMs, Windows, and Linux, and log into them with your Azure AD credentials, as long as you deploy these properly, and of course, you set up the proper permissions or roles for specific users.

0:36And that's what we're going to look at right now. All right. We're starting off with Windows Azure VMs, because this new feature of logging into your VMs with your Azure AD credentials works for Windows and Linux. But we're going to do these in two separate videos. So we're starting off with Windows. So when we're logging into Windows virtual machines in Azure by using your Azure AD credentials, there are some things that we need to know about. Let's first start with some of the benefits. We're just going to take a look at a couple of them right out of the Microsoft documentation.

1:08And the idea is that we're actually using federated and managed domain user accounts, because we're able to manage them all through Azure AD. Now a key one is right here, reduced reliance on local administrator accounts, because instead of having local administrator accounts for everybody that needs to login and use it, well, we can just use the proper role within Azure AD, and assign that role to our Azure AD account. And we can manage local administrators that way.

1:40So we don't have to worry about local admins on the box so much. We can also control password complexity and password lifetime through our policies in Azure AD. We can use our role-based access control to specify who can log into an Azure VM as a regular user, I just would say here. And as administrator. And we're going to look at that because there's actually two separate roles. There's a role for regular users and a role for administrative privileges. And then when somebody joins or leaves your organization or your team, well, you just simply go into that role and remove or add that person, and then they have that ability or no longer have that ability to log in to the VMs.

2:16So that's pretty cool. We can also use conditional access policies to require things like multifactor authentication. And take advantage of sign in risk. And that's when risky activities are happening with an account, or a user signing in. Well, it can require things like multifactor authentication or password reset, if there's risky activities going on with the specific account. So that's our conditional access policies. And we can also deploy and audit policies. And those are some of the really cool benefits of using your Azure AD credentials to log into your Azure AD VMs.

2:52Now here is the thing. If you do enable this, because what we're doing here is we are actually joining those VMs that we spin up to our Azure AD. So they are Azure AD joined. And once we do that, well, we can't join them to another domain, like an on-prem domain or something. So just keep that in mind. If you want to use this feature, then the VMs you spin up are going to be Azure AD joined only. So do keep that in mind. Now some requirements. Well, when it comes to Windows machines, there has to be of a couple of distributions-- Server 2019 Datacenter or later, and Windows 10 1809 and later.

3:31So if you're wanting to spin up VMs with OS's earlier than this, this feature is not available. Now here's something that we're going to see later on. Once we spin this up, and we try to connect to these VMs, there are some restrictions, or we could just say requirements. And that is that the device you're trying to RDP from, it must be Windows 10 or later PCs, also servers as well, 2019 and later, that are Azure AD registered, Azure AD joined, or hybrid Azure AD joined.

4:07So this means if I try to RDP to a Windows host that I've spun up and set up properly so I use my Azure AD credentials, well, I can't do it, unless the device I'm on is Windows 10 or later, and is Azure AD registered, Azure AD joined, or hybrid Azure joined. So if I'm trying to do this from a device that is maybe a Mac computer, guess what? It's not going to work. Or a Windows computer. Maybe it's a early version of Windows 10, not going to work.

4:38Well, hey, maybe I use a Windows 11, so that's later, right? But it's not Azure AD registered, joined, or hybrid joined, it's not going to work. So keep that in mind. That's another requirement. And as we scroll down, last thing we look at here is the availability in the Azure cloud areas. It's available in Azure global government in China 21Vianet. There you go. And there's network requirements as well. And this simply means that on your host that you spin up, if you set up firewall rules, you have to allow outbound TCP 443 to these URLs.

5:15Keep that in mind. And if you set up network rules within your virtual environment that prevent communications outbound over TCP 443, you need to make exclusions for these, because this is how it's going to connect and authenticate your Azure AD credentials. All right. So that is documentation. It's time to jump into the portal and get started. So let's do that. Let's jump over here. Here we are in our portal.azure.com. I'm going to jump into Virtual Machines. I'm going to go to Create Azure Virtual Machine.

5:46There we go. And we're actually going to spin up a Server 2019 Datacenter. So I select my resource group. There we go. NuggetLabz is virtual machine name. I'm going to call this Win-Test1. Here we go. US East 2 is fine. No redundancy, security type standard. We're just doing some testing here. I'm not too concerned. Windows Server 2019 Datacenter. There we go. Excellent. I'm going to stick with this size. And I'm going to create a user account here. Bob. Put in a password here.

6:17Verify that password. All right. Excellent. Now I'm going to scroll down here. Public inbound ports, I need to allow 3389. And we're going to restrict that here shortly. So I'm going to go ahead and select that. Say Next for my disks. I'm just going to go with standard SSD. We're just doing some testing here. Definitely delete with VM because again, this is lab. So there we go next. All right. Networking, networking, networking. This all looks good. Just go with some default settings here.

6:48I'm not too worried about this. But I do want to delete the public IP when the VM is deleted, because I'll be deleting these here shortly. Now this is the difference. This is key. When we get to the Management tab here, in order to enable Azure AD credential authentication, you need to come under Azure AD. And you'll see here, log in with Azure AD. Well, we need to turn that on. And then by default, it also turns on identity. This enables system assignment managed identity.

7:18And you need to make sure that does get checked, and it does that on its own. But just double check to make sure. All right, cool. So that is the key right there. We have to enable Azure AD log in with Azure AD. That's the key to enabling this feature in here. So go ahead and scroll down here. Everything there looks good. Go into Advance. Don't need anything there. Tags, I'm good there. Review and create, I'm going to let this go ahead and do a review. And then we'll click on Create. So we can go ahead and create this machine for us.

7:49So go ahead and click Create. And now it's going to start into the creation process. Now while it's spinning this up, it's time to talk about identity and access management and our role-based access control, RBAC when we're talking about our roles and security. So what's happening is, right? Well, right now it's deploying this. We're going to jump to another tab. All right, there is something we need to do here. We need to go into resource groups. We need to select the resource group in which we spun up that VM, which was NuggetLabz. So let's go in there. What we need to do in here is set up some roles.

8:22Now the roles already exist. But we need to assign people to them. So let's go over here to access control, there IAM. I'm going to move this over a little bit. And what we need to do is we need to go ahead and click on Add, Role Assignment. There we go. And there are two roles in particular that we need to be familiar with when it comes to this feature. And that is virtual machine-- let that load up there, administrator login. Now, if you give someone this role, it means that they can log into one of these Azure VMs as an administrator.

8:57So when they log in, they're logged in as an administrator. So they have those admin permissions. And that's where we come across that benefit of not needing to manage local admin accounts on those VMs. And the other role we need to look at is down here at the very bottom. And this is virtual machine user login. And this allows whoever has this role to log in to these virtual machines as a regular user, so that they're not an admin user, just a regular user. So what we're going to do, we're going to go into virtual machine login and click on that.

9:30We're going to say Next. Then we need to add members. So basically, we can select user group or service principal, or we can select a managed identity. I'm going to do user group or service principal. I'm going to say select members. There we go. And what I would do is just go in here and select somebody, like John Appleseed. So I can say that. Say select. And now John Appleseed. And I could do select members. Go ahead and add me in there as well. There we go. Select.

10:00There you go. So now if John or myself log in to one of these VMs, well, we're doing so as an administrator, so that we do review and assign and go ahead and review and assign. At which point, it'll go ahead and do that. But it failed, as you see up here, just because both of those accounts are already assigned to that role. I just wanted to show you the process of doing so. So there you go. But if you want someone to be able to log into VMs, but only as a regular user, then we're going to go in and go in here and select the virtual machine user login right there.

10:34This one right here. So when somebody has that role and they log in, they're logging in as a regular user, not an admin. So keep that in mind. So this was like step 2. Step 1 was to go through and create the VM. Step 2 was to enable the roles and assign members to those roles. So now that we've done that, hey, we should be about ready to log in. So let's jump back over and check on our VM. Well, it's still deploying. So we're going to pause this for a few minutes while this finishes deployment. All right, we are back.

11:05Our deployment is complete. So I'm going to click on here, is go to resource. It's going to bring us right into our Win-Test1. And the first thing I'm going to do is I'm going come over here to networking, and I have a rule here for remote desktop protocol, RDP. And it's open to anybody in the world to log into it. So we're going to click on that. And we're going to edit that rule. And I'm going to go over here and copy my address here. There we go. And we're going to come over here, and we're going to say source is IP address, and I'm going to stick in only my IP address.

11:37There we go. And we're going to click on Save. And we'll give that just a few seconds here to save. And that way, only my IP address can RDP into this host from outside the VM environment. So there we go, our source is updated. Perfect. There we go. Now, I don't have to worry about people trying to brute force via RDP into this host. All right, so now guess what time it is? Well, it's time to log into our host. So we're going to jump over to a VM here just a second.

12:07All right, here we are in our lab environment. And I'm on a virtual machine that is actually Azure AD joined. And I'm logged in as Johnny Appleseed. So let's go ahead and click on that icon right there and click Remote and Remote Desktop Connection. There we go. And let's go ahead and put our IP address in there, 20.110.101.137. Let's double check, make sure that is correct. If I jump back here, 20.110.101.137. It looks good to me. We'll jump back over here.

12:38And that's the IP of our server out there. So now I'm going to say connect. And I need to put in my password is Johnny Appleseed. And hit Enter. And see if it works. It says, hey, it looks like it's going to work. Awesome. There we go. It's connecting to Win-Test1. We see there. Say go ahead and you want to connect despite the certificate error. Yes, I do. And there we go. We are officially connected into our Azure Windows VM using Azure AD credentials to log in.

13:13Super. And there we go. That is how we do it. Now as a quick recap, we need to create our virtual machine. And in the Management tab, we need to enable login with Azure AD. And then we had to go into our roles. And in the roles here, we were looking at virtual machine user login as a standard user login, and virtual machine administrator log in to log in as an administrator. And then lastly, when we come back over here, we have to log in from a Windows 10 or later computer that is Azure AD joined, Azure AD registered, or Azure AD hybrid joined.

13:52And there you go. That's how we make that happen using Azure AD credentials to log into Windows Azure VMs. In the next Nugget, we're going take a look at how to do this with Linux VMs in Azure. So stay tuned for that. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[MUSIC PLAYING] Now it's time for us to set up an Azure Linux VM and then set it up so that we can log in to that VM using our Azure AD credentials, which is a new feature. So let's get started. All right, here we are in the documentation. We're going to take a quick look at a couple of things when it pertains to log in to Linux VMs in Azure by using Azure AD and OpenSSH.

0:30All right. So first off, we're taking a look at some of the benefits, and you'll see that many of them overlap with the same benefits from logging in with Azure AD creds to Windows machines. Well, the first one is basically simple. You get to use your Azure AD creds to log in, makes it a little easier. It also helps with SSH key based authentication because you don't have to share those keys and move them around because you can have your own as your AD key. There we go. So the next step, reduce reliance on local administrator accounts.

1:03We saw that with the Windows Azure VMs as well. Help secure Linux VMs by configuring password complexity, password lifetime policies. The same thing we saw with the Windows VMs. And then you can use your role-based access control using those two roles that we looked at in the last Nugget. And we're going to look at those again as a quick review. And that was our virtual machines administrator login and virtual machines user login roles. And then we can also use conditional access policies, especially to enable things like multifactor authentication, and so on and so forth.

1:35So let's scroll down. Those are some of the benefits, keep in mind. But we are limited to specific Linux distributions. So which ones are supported? Well, they're right here. Take a look here. We are going to be deploying an Ubuntu 1804 LTS or Long-Term Support flavor today. So that is definitely one of those. So these are the supported distros. So if you want to use something else, it's not supported at this point in time. But that might change.

2:06And when it comes to which regions support this, Azure Global, Azure Government, Azure China 21Vianet. All right. And one more thing to look at, if we scroll down here, there are networking requirements just like there were with the Windows setups, and that's simply that we need to allow outbound TCP port 443 to these locations. And remember, that could be your own Host firewall rules on your Linux host or in your network environment there within Azure. So keep that in mind. All right, so that wraps up our documentation.

2:37Time to get started. Let's jump into the Azure portal. Jump over to Virtual Machines. We're going to click on Create to create a new virtual machine. There we go, and there we go. Excellent. Select our resource group, NuggetLabz. Excellent. Virtual machine name, we're going to call this-- let's see. Linux-Test1. US East 2 is fine. Availability option is fine, security type. Aha, image, definitely not Windows. We need to go with an Ubuntu 1804 LTS. Perfect, there we go.

3:07And the size is fine. Let's see. I'm going to actually set a password for this instead of a SSH public key. So what I'm going to do is set that up. There we go. Excellent. Let's see. Allow 22 for SSH, sounds good to me. Disks, delete disk with VM. Let's just go with standard SSD. And that works for me. I don't need anything else. Down here under networking, everything looks good.

3:39We do want to delete public IP with V machine. Excellent. All right, now, management. We have to do the exact same thing that we did in our Windows VM setup, and that is under Azure AD. Check the box for Login with Azure ID, and that automatically enables system assign managed identity. This is key. When we select these options, it's actually going to go in and install a couple of packages on our Linux VM to help this work properly.

4:09All right, there we go. Next to Advanced, there's nothing we need in there. I don't need to assign a tag. Excellent. We're going to let this finish its validation. Then we'll go ahead and click on the Create button. So let's do that. And that's going to start the creation of our virtual machine. And just like last time, we're going to jump over to our resource group and look at the permissions required because it's a good review, and you need to know this information. So under Resource Groups, we're going to go to our NuggetLabz. There it is.

4:40And let's slide that over. And under our Resource Group, we need to go into IAM. That's our access control area, and we're dealing with roles. So we can take a look at the roles that exist here. And what do we need to work with? That's right, virtual machine roles. Virtual machine, there's two of them-- administrator login. So if you assign someone this role, you make them a member of this role. They will be able to log in to either a Windows or Linux virtual machine in your Azure environment as an administrator.

5:13So when they log in, they have administrator privileges. The other option is user. So it is-- let me put it in login there because this will narrow it down. So it is this one here, Virtual Machine User Login. If you make someone a member of this role, when they log into a Windows or Linux VM within your Azure environment, they will log in with regular user permissions, not the administrator permission. So keep that in mind. Those are the two key roles that you really need to keep in mind because when we're talking about logging in with the two Azure VMs with Azure AD creds, you've got to have one of those two roles assigned to your account.

5:51So let's jump back over to our VM and check on its deployment progress, and it's still deploying. So we're going to pause for a minute and let this finish up. All right, our deployment has completed. So let's jump in and go to Resource. Go right into our Linux-Test1 VM and go over to Networking over here on the left. Click on that because I've got SSH open to the world for this host, not very good. So let's change that. Let's go to IP address, and let's paste in my IP address. There we go.

6:21Click Save. Excellent. Now that that's saved and we have roles assigned-- because we did that actually in the last Nugget. We assigned the proper roles so that Johnny Appleseed and my account both have the virtual machine administrator log in role. So we could log in. I should be able to SSH this thing now. So how can I do that? Or better yet, where can I do that from? So let's jump over to the documentation real quick and take a look.

6:52All right, here's the documentation. It says log in by using Azure AD user account to SSH into the Linux VM. You have two options really, using the Azure CLI. All right, that's what we're going to do. But you could also use the Azure Cloud Shell. OK, that's pretty cool. So you have to do it through either the Azure CLI or Azure Cloud server. You can't just open up an SSH tool or SSH from another Linux host or from maybe your Mac or something. You can't open up PuTTY and SSH out to this machine from your workstation.

7:24You've got to do it through Azure Cloud Shell or Azure CLI, at least for now. So we're going to use the Azure CLI. So that being said, I'm going to jump over here, go to-- here's a NIC public IP address. Let me copy that. There we go. I'm going to put it over here. There we go. Excellent, super duper. Now, let's jump over to our lab environment here. I'm on a server here. This is actually one of my domain controllers. I'm going to open up a PowerShell. Let's go ahead and open up PowerShell as an administrator.

7:57Excellent. There we go. So what are we going to do? Well, we're using the Azure CLI. So what I'm going to do first is az log in, and I'm going to have to log in. There it goes. It's opening a browser so I can log in. And then I'm going to select my account there. I need to enter my password here. There it goes. And I need to throw my MFA. Excellent. So I'm now logged into Azure. I'm just going to minimize this.

8:28There we go and bring my PowerShell back up. There we go. We are logged in right now. Excellent. So at this point, I'm going to clear the screen there, and we're going to type the command to connect to our host, and that is, az ssh vm, all right-- that's pretty simple-- dash in. I provide the name of my VM. So that was Linux-Test1. There we go, and I type in the g, the resource group that is a part of, which is NuggetLabz.

9:02There we go and hit Enter. And now, it's going to go through the process of logging me in using my Azure AD credentials into the Linux-Test1 VM. And now it's asking me, do you want to accept the fingerprint? Because this is a self-signed certificate within the Linux host itself. Say yes, and excellent, and now it's going to connect me into my host. And look at there. I am now connected to Linux-Test1 using my Azure AD credentials, as you can see here, bob@nuggetlabz.o mnimicrosoft.com.

9:36So that is how we go through the process of setting up a Azure Linux VM to accept Azure AD user credentials to log in as either an administrator or as a regular user, depending on which role we select, and that's the process. I hope this has been informative for you, and I'd like to thank you for viewing.