Multi-factor authentication - Windows Server Tutorial

- [Narrator] Earlier in this course we set up a Relying Party Trust in the Landon Cafe domain. The purpose was to identify users that needed single sign-on to an application in a partners domain. The responsibility of identifying and authenticating users is probably the most important task in this entire process. Historically, there have been three different ways that a network user could prove their identity. What a user knows is the most basic form of authentication. It refers to user names, passwords, PINs and secret answers, things that someone would memorize and would recall to gain access. What a user has is another level of security. It requires each user to always carry with them a Smart Card with certificate, or maybe a specific mobile phone or some other hardware that is not likely to be held by another person. And the third form of authentication refers to what a person is. This includes fingerprints, facial recognition, and other biometric factors of authentication. Multi-factor authentication is the application of more than one of these methods or factors of authentication. For example, a user logs into a work station with their user name and password, which they know, and they insert a Smart Card with a specific certificate issued to them. This card is something they have. Together these two factors provide more assurance that the user at the console is the user that's been granted access to a resource. Landon Cafe wants to honor their responsibility to carefully restrict access to the hotel billing application. So they've issued user certificates to the small handful of employees that are added to the guest billing group. They've installed these certificates on Smart Cards and issued these individual Smart Cards to the employees. Requiring this second factor of identification for our existing Relying Party Trust will take two steps. So let's go to the AD FS server in the Landon Cafe domain to see how to define multi-factor authentication for our Federation Services Farm. So here we are, in the landoncafe.com domain. On the Federation Server that's running AD FS. In the AD FS management tool, I can expand service in the tree off to the left. The second thing in the list is authentication methods. That's what I'm going to select. Now this central pane is our starting point. The primary method for authentication is different depending on where you're located. If a user is connecting from the local network, they can be authenticated based on their integrated Windows login, or by a Microsoft Passport. But if they're connecting from outside the local network, integrated Windows authentication may not be appropriate. So a login form would be the default. Below this we see that multi-factor has not been enabled. I'm going to go ahead and click the Edit link so we can change that. The first thing I notice on this screen is the very limited list of options. I mentioned Certificates and that is one of the check boxes available here. In fact, that's the only type of multi-factor authentication that you can use in an all on-premise domain without installing other components. Other multi-factor authentication solutions include having a code sent to a specific phone by text message or by calling a predefined number and asking for a PIN but these other systems require access to a phone network and telephony components not included in Windows server by default. There are also third-party add-ins as well as the Azure solutions to provide these options, but for a simple on-site active directory, certificates are really our only choice. We will take a look at Azure integration later on, but for now, I'm going to go ahead and select Certificate Authentication and apply that change. And with that selected, I can move over to the primary tab and I can specify that Certificate Authentication is allowed to be used both on the internet and on the externet, then I can go ahead and apply and save these changes. That completes the first step. The second step is to update our Relying Party Trust. Here under Relying Party Trusts, we can see the one that was created to connect to the landonhotel.com domain. I can't just create a new Trust for the multi-factor authentication, because we only get one for each domain and I don't want to change the claim rule, but I do want to update the access control policy for this Trust. So off to the right, I'm going to select Edit Access Control Policy. Remember the Claims Issuance Policy is where we specify the rules about how the claim will be created and sent. Inside the Access Control Policy I can see the multi-factor authentication options. And in this Access Control Policy, we now have some more meaning to these MFA options. In addition to permitting everyone, we can permit everyone but require multi-factor for specific groups, or we can require multi-factor authentication for everyone. For our purposes, we only need to use multi-factor authentication for the users that are going to be issued claims to access the Landon Hotel billing application. So we're going to permit users from a specific security group, and from here I can type in Guest Financial because that's the group we created in this Active Directory domain. If I use this type of access control policy, then I'm limiting access to these claims to this one group. And I can tell here which group it was, but if I need to use this trust for more business functions I may need to go back and switch it to Permit Everyone and require multi-factor authentication which would allow me to grant access to any of my users that happen to be carrying one of these Smart Card certificates. Adding this additional factor of authentication is one way that Landon Cafe can step things up to make sure that they are protecting the trust that has been extended to them by the hotel.