1. Manage password and authentication policies
Now that we’ve gone through the process of synchronising our on-premises Active Directory with the cloud, I think it’s very important that we have a good understanding of the different authentication options and policies that we have in both scenarios, both on-premises and in the cloud. Okay? First off, notice I’m on the portal Microsoft.com, and it is saying that Azure Ad Connect is working and that it did synchronise 15 minutes ago or last synchronised 15 minutes ago. Anyway, we’re going to look first at our cloud-only user. So you saw earlier that we have some users that are being synchronised on-premises and we have some users that are synchronised in the cloud, okay? Now the users that are on premises are going to get their password settings and policies from the domain, and those are going to synchronise out to the cloud. But what about our cloud-only users? Okay? So what I want to do is look at the password settings for our cloud-only users, and then we’re going to take a look at the password settings for our domain users. OK? So what we’re going to do is we’re going to click this little show all ellipse symbol here, alright? We’re going to drop down settings, and then you’re going to click on Settings. All right? So we’ll go to Settings, and then you’ll see Security and Privacy. So we’ll click that, and then it says Password Expiration Policy. So we’re going to click on that, and here we go. We’ll enable the password expiration policy. Notice the default. The default is 90 days. So everybody’s password in the cloud is going to expire in 90 days. If you’re a cloud-only user and you’re not synchronising on-premises, you’re going to have a 90-day expiration period. Okay? Now the other thing would be that you would get a notification to let you know that your password was going to expire in 14 days. Okay? So 90 days is the limit. That’s when it’s going to expire. All right? The user would have to change their password within that 90-day period. If they don’t, they’ll be forced to the very next time they log on, and then they do get a 14-day notification. If you want to change that, you can obviously do so right here. I wanted to change it to, like, 100 days or something. I could very easily. All right, now for the other side of your password policies, restrictions, and all that, I’m going to jump over to the Azure Portal for that.So we’re going to go to Portal Azure.com, and then we’re going to go straight into Azure Active Directory. We’re going to click on the little menu bar and go to Azure Active Directory, okay? Then we’re going to go down here to the Security Blade, and we’re going to click right here where it says Authentication Methods. And then we’re going to click on Password Protection. Okay? So right here, we’ve got our lockout threshold. So, essentially, this is the amount of time or the number of times a user will be locked out. They will be locked out after entering their password a certain number of times. As you can see, it is set to ten. If a user enters their password ten times, they’re wrong, and they get locked out. The lockout duration is kind of short. The timer is set to 60 seconds. Okay, so not very long. You could adjust that if you wanted to. Okay, keep that in mind, and I’m not getting into this right now. I did want to say, though, that there is this thing called Azure ActiveDirectory identity protection, which is also monitored. It’s basically a machine learning and AI system that’s watching, and it will begin forcing things like multifactor authentication and all that if a user keeps entering their password incorrectly too many times. Okay, I can elaborate on that a little bit more later, though. From here, I can also request custom banned passwords if I want. You could put together a huge list of passwords. If you go out there on the Internet, you can find all sorts of lists of the world’s most common passwords and definitely the dumbest passwords that you can use. Now, if you remember when we did the Azure AD Connect thing with on-premises Active Directory, if you did that, then the great thing about that is Microsoft’s hash synchronisation feature. They’re actually monitoring to see if any of your password hashes—those are the encrypted versions of your password—are leaked out on the Internet in any of the hacker databases. So that’s really cool. So, if you used hash synchronization, you have that going for you. But, once again, we’re only talking about TalkCloud accounts at this point. Okay. But if I wanted to turn the liston, I could just paste those in there. Down here. I’ve got password protection enabled on Windows Server’s active directory. Okay? So with that, right now, we’re basically saying that Active Directory is handling our passwords for our on-premises environment. Okay? I’m going to leave that on, and then I can do enforced mode. Enforced mode is going to actually turn this on right now. Just so you’re aware. With audit mode, it’s just auditing. It’s not really locking users out. Okay. Of course, I’m in a little lab environment, so that’s not really a big deal. But if I wanted to save that, I could go ahead and save it, and I’m good to go. Okay. All right, so in the next little section here, I’m going to show you the on-premises policies. Okay, so here we are on a domain controller, and I want to show you the password policies for our domain. So in our case, we are synchronising our on-premises accounts out to the cloud. So we are going to be controlling our policies by default right here in the domain. So I’m going to go ahead now. I’m going to open up the server manager. I’m going to go to Tools and then Group Policy Management. Okay? So in Group Policy Management, your password policies are kept in the GPO. That is called the default domain policy, which is linked to the domain. So I’m going to go ahead and edit that GPO. It’s going to bring the Group Policy Editor up on the screen here. Your password policies will be located under computer configuration policies, Windows settings, and security settings. And then you have account policies and password policies. So, just a quick rundown of what these policies entail. Okay? So we have an enforced password history. This is going to make it so that it will remember a certain number of passwords. So a user can’t just keep reusing the same passwords over and over again. Okay? You have reached the password age limit. That’s the maximum amount of time that a user can keep a password before they have to change their password.As you can see, 42 days is the default minimum password age and the number of days they must keep a password before changing it. Okay, so you have a minimum and a maximum. One day they have to keep their changed password; they have to keep it for a day before they can change it again. Then you have the minimum number of characters. The minimum password length is set to seven characters. Okay? You can set that at a higher level if you want. You have a password that must be complex enough. That means your password must have at least three of the four following things: an uppercase character, a lowercase character, and a number symbol. Okay? And then lastly, store password versus user versus encryption. You don’t want that. That’s not a good thing. This is an old policy that’s been around for 20 years and came out with Windows 2000. And back in those days, when Windows 2001 first came out, we still had a lot of legacy computers in our environment, mainly Dolphins, that needed to interact with the domain. And it couldn’t because it didn’t support hashing passwords or the two protocols required for domain authentication, NTLM and Kerberos. So what you could do is, if you had a user who was using an old operating system like Daws, you could turn that on and then allow them to get in. There was an older remote access authentication protocol called Chap that used that to challenge the handshake authentication protocol. That’s very old stuff, and enabling it will significantly weaken your domain. So we don’t want to turn that on. Okay, the last thing I’ll show you is my account lockout policy. Okay? So this is going to let me set the lockout settings. I can set my threshold. Let’s say I set that to three. That means you could enter three passwords, and then you would get locked out. Okay? You have set the account lockout duration. That’s the amount of time you would be locked out. So if I set that to an hour, you would be locked out for an hour. I could even set it to infinite, which means you’d have to get an admin to unlock you. Okay? I have a reset account lockout counter, and that’s going to reset your strike counter. What happens when you get one wrong password on the board? Let’s say you put your fat finger on your password; you get one strike against you, okay? That timer would begin ticking. Let’s say it’s a ten-minute timer. You get another strike. That timer is still ticking. Now, if you get another strike before that timer resets, then you’re out. At that point, if you had threshold 3, it would hit the duration. But if you still had two strikes, okay, and that reset timer timed out—let’s say it got to 10 minutes—then it would wipe away your strikes. You can enter two more strikes before entering a third and be fine as long as the timer runs out. So that’s what that does. Okay? I’ll also say this: When a user logs on, it also resets their strikes. Okay? So those are your password settings, and you can enter them in the domain. And of course, all of your Active Directory users have to adhere to those policies, and they’re going to get synchronised to the cloud for just the domain users. The cloud-only users would not be affected by this. Okay, so that gives you guys a good understanding of the different password settings and policies and the authentication policies between the two sides. Both AAD, which is the on-premises ActiveDirectory domain service, as well as Azure AD.
2. Managing sign-on options with MFA and SSPR
I’d like to talk to you now about the different sign-on options that we have in regards to our cloud services. To begin, users can authenticate in the cloud in a variety of ways. One way that a user can authenticate to the cloud and get access to their resources is to open up their Office portal. They have access to the office. They can go to Portal Office, and as you can see, they’ll have access to the Office apps. Okay? So these are basically the Office online apps. They can utilise Word, Excel, and PowerPoint, and all that good stuff.
Another thing that will trigger them to sign on is if they actually have downloadable versions of Word, Excel, PowerPoint, and all that, and they have to activate it, they will have to authenticate with the cloud. Okay? Now, when a user authenticates to the cloud, they have to provide a way to prove who they are. Traditionally, the way they’re going to do that is with a password. Okay, so if I jump back over here to Azure ActiveDirectory—by the way, this is Portal Azure.com—and I go here, I can click on my users that are available. And then, typically, a user will log in using a password, correct? Okay. Now, of course, if we are synchronising the user account with the domain, as you can see here, this is a user that is synchronising with the domain. So the domain is where his password and all of that are managed.
And that gets synchronised out to the cloud for your cloud-only users; if you have any cloud-only users, okay, like I do here with Greg Johnson, for example, okay, we can look at his information. We can do a password reset on him if we want. And right now, that’s his only way of authenticating. Okay? But what I want to show you guys is that when you look at a user, you’ve got authentication methods right here. So I’m going to click on that, and this is where I can specify ways that this user can authenticate. Now, first thing, Microsoft has a feature called MFA (multifactor authentication). The user must have a licence to use MFA unless they are a global administrator. For example, when you start your Azure and Microsoft 365 environment, you are a global administrator. You get to use multifactor authentication for free. But Greg Johnson is not the global administrator at the moment. so he cannot use it for free.
So he’s got to have a license. We can verify that he’s got a licence to use this by going to the licence right here. Your licence right here, called Enterprise MobilityPlus Security, is a licence that actually gives him that capability to use MFA. If we click on it, you’ll notice that one of his options right here says MFA. Of course, if we did not want this user to have access to that and support MFA, we could disable it. But ultimately, multifactor authentication is an extremely powerful feature. So it’s not generally something you’d want to turn off. Normally, you want that to be turned on. So the thing is, Greg Johnson is going to have to prove who he is when he logs on to use MFA. The first thing I’d like to do is demonstrate how I can force MFA on a user. In other words, force the user to use multifactor authentication.
To do that, I’m going to go back straight over here to Azure Active Directory. We’ll click on users. Now look up here, and you’ll see this little bar right here. Sometimes multifactor authentication will work on this bar. But depending upon the resolution of your screen, you may need to select this little ellipses symbol, and then you’ll see it. Okay? So I’m going to go there. I’m then going to turn this on. I could force this on for Greg Johnson if I could actually force it on for all my users. But if I wanted to, I could force it on right here for Greg Johnson. I can say allow. It says, “Okay, you’re about to enable multifactor authentication.” Okay? So if users do not regularly sign in through a browser, you can send them this link to register with multifactor.
So it’s basically saying that I could email them if they were using an app or something that didn’t support it, and they could go there and do it and register. Because what’s going to happen is that the very next time this person logs on, it’s going to make them enter in some authentication information. Now you could pre-populate that for the user if you wanted to by going back over to the user’s account here. And then, if you go down here to authentication methods, you could specify what those are. Now remember, multifactor authentication is going to make it so the person has to have more than just a password. They’ll need to have their phone nearby for a text message or make a phone call on their office phone, and it’ll basically be a Cortana voice telling them to enter a number and then it’ll authenticate. You could also send an email. You can have an email do it as well. If you leave all that blank, the user is going to have to enter it the very next time they log on.
So, if I go back to the service settings at the top, you’ll notice that it says allow users to create app passwords to sign in to non-browser apps that are application-related for specific applications they use. I’m not going to get into that right now because we’re going to be talking about apps later in this course. But if you look down here, there are two things I can say about trusted IPS. If I wanted, I could make this user log in from a specific IP address. Then, at the bottom, it says “methods available to users.” Phone call, text message to phone notification via mobile app verification code These are the options I have if I want them. I could turn those off if I wanted to. Okay? So that is how multifactor authentication is going to work. Number one, you’ve got to have a licence to use it unless you’re a global administrator.
Number two, it’s got to be enabled, okay? And then, at number three, you can control these settings here. If you want something else, I’d like to show it to you. I want to come over here. Now I’m going to go back to Azure Active Directory. Okay. And then I’m going to go down here to where it says password reset. And then there’s a really nice feature called self-service password reset. By default, this is turned off, and it’s critical that you understand this for the exam. If you’re taking an exam, make sure you understand that self-service password reset is turned off. You can turn this on for selected users if you want. Or you could turn it on for everybody if you want, which is what I’m going to do. Now, when you turn this on, it will make it so users can actually change their passwords if they need to. Once you turn that on, you can set the options over here under authentication methods,
OK? If they want to reset their password, I can require them to receive a code via email or mobile phone. Or I could use these other options. I could even require two methods to allow them to reset. And I could choose from these different methods here, like security questions, for example. I could enter how many questions they have to have. Make them enter in five. They have to have a minimum of three questions answered. You can set it to what you want here. And then, if you wanted to set the security questions, you could click that. And there are a bunch of predefined ones that you could go with if you wanted. Just select the ones that you want them to use, however many you want. And then at that point, you would click OK.
And then, at that point, you could save it. All right? So you set that to whatever you want. You then click Save, and that feature is now officially turned on. Okay? That’s called the self-service password reset feature. SS PR. That is an acronym I would be aware of, SSPR. All right, so those are your different authentication methods, all right? Password: You can do multifactor authentication (MFA).And then there’s also the SSPR feature, which is, by the way, self-service password reset. You don’t have to have any kind of special licence or anything like that for SSP, but you do for MFA. That’s a licence thing, which your company can licence by itself. Or if they get the EMS license—enterpriseability plus security—then it comes built into that. All right. All right, guys. So hopefully that gives you an understanding of the different authentication policies that we have out there in the cloud.
3. Performing Azure AD join
Let’s now take a look at how a Windows computer is actually going to get linked to the cloud. This is now referred to as an Azure advertisement. Okay. not to be confused with Azure Ad Connect. Azure Ad Connect is what? User and attribute information are synchronised from our on-premises Rim environment to the cloud. Azure Ad Join is a method by which we can link devices to the cloud. Now all sorts of devices can be linked to the cloud. Okay? We’re going to be looking at connecting Windows 10. But, later in the course, we’ll talk about Android and Apple and all that good stuff.
Okay? But first, there are some requirements that must be met. We need to configure a few things and make sure that everything is in order before we try to join the Azure ID. So to do that, I’m going to go over here to the menu bar. I’m going to go to Azure Active Directory. The first order of business is to ensure that users have the ability to join Azure Ad.
OK? And to do that, there are a couple of things that have to happen. Number one, I’ve got to go to company branding, all right? And if this is the first time you’ve ever been in charge of company branding, there’ll be nothing here. You’ll have to click “Create Something” for it to show up. Okay? So then I’m going to go right here, and I’m going to click default. And you have got to give your company a sign-in page text.Now you’ll notice I’ve already done that.
It says, “Welcome to exam lab practice.” Okay? That is a requirement. You have to do that. If you don’t, your devices are not going to be able to join Azure to do Azure 80 Join. Okay? Another thing is going to happen. If you are going to do autopilot, which we talked about previously, that’s going to be a requirement as well. Computers have to have them, and you have to have that sign-in page text there to do it, which is why I already put it in place because I knew that I wanted to be able to do autopilot. Okay, so the other thing here, as you’ll notice, can spruce things up a bit. You can include a logo in the banner if your company wishes. so you can adjust the colour scheme.
Here’s a bunch of stuff just to spruce it up. But the only thing that is a requirement is this right here. You are going to want to remember that for the exam, company branding is a requirement. If you’re going to do autopilot, if you’re going to do Azure AD join, you’ve got to have this as part of the deal. Okay? So that’s right over here on company branding. Okay? The other thing I want to show you is that I’m going to click devices right here and device settings, and then there’s an option right here. Users may add devices to Azure AD. Okay, we’ve got to turn that on for all users or just some users. So we’re going to make sure that’s turned on. Okay, so that’s good. We’re ready to go. Now we’ll go over how to connect a Windows 10 computer to Azure AD. Once we get into Settings, we’re going to click Accounts, and then we’re going to click this thing here that says Access work or school. Then from there, I can connect it to Azure AD.
Now you’re going to notice that mine is already connected. Why are mine already connected? Well, you may remember me doing that Autopilot example where I did it with Autopilot. Okay? But if it isn’t already connected, all I have to do is click the connect button right here. And then I’m just going to put my credentials in. All right? At that point, it’s going to allow me to link it again. I’ve already done it, so I don’t have to do it again. Autopilot did it for me a little earlier, but that’s it. So you can leak now if you want. You can also disconnect.
So disconnect, and at that point, it’s going to disconnect it from Azure Active Directory, which will require me, of course, to put in some credentials and all that. And then I can disconnect. And if I wanted to reconnect, I could. Okay, now, this is pretty straightforward. Again, with Autopilot, you can do it manually. GPOs, package SCCM, endpoint management, and other methods are available. But that’s how you would actually link your device to your Azure ad.
