If you’re in the cybersecurity space you have likely heard of multifactor authentication, or MFA. Multifactor authentication has a wide variety of benefits and can be deployed a number of ways including mobile authentication applications, OATH OTP applications, PKI based credentials, SMS, Phone Verification, and the list goes on and on. The type of multifactor authentication you want to use really depends on the risk level of the application or resource that you are protecting. The higher the risk, the stronger the MFA credential should be. NIST gives a good guideline in the SP-800-63 publication.
Centrify supports many different MFA factors, and in addition to providing MFA for web and mobile applications, there is also a solution for MFA for servers. This goes beyond simply MFA because it plugs into the role based authorization framework that the flagship Centrify Server Suite product provides. For example, if I want my users to MFA only when they are launching a specific windows application or unix application, I can do that by tying the MFA requirement to a group (and role in Centrify) in AD and I now have role based authentication. It becomes really easy to manage your users’ authentication/authorization requirements when all you need to do is put them in the right AD group. Recently Centrify also added MFA for Windows Login. So now this solution can be extended to the larger group of individuals who may be logging on to Windows Workstations and need some sort of MFA. For a high level overview of this solution, please see this link.
The goal of this post is to take you through the steps required to setup MFA for Windows login using Centrify Identity Service (as your authentication and policy server) and Centrify Server Suite (to enforce role based access control). The post assumes that you have a Centrify Identity Service tenant deployed and a Centrify Server Suite deployment. The post assumes you have some knowledge of Centrify Server Suite configuration and Centrify Identity Service configuration. It also assumes you have setup MFA for a user (or a group of users) in the Centrify Identity Service. If you have not, this link provides good guidance on getting started.
Step 1: Role Generation
Go to your Centrify Server Suite Access Manager. Find the Zone where you want to setup the role for windows MFA, I am doing it in my top level Zone so it can be used everywhere. Go to Role Definitions and right click and generate pre-defined roles (the 2nd option in the dialog below). I'm using version 126.96.36.1998 of Access Manager.
Now you should have a “require MFA for login” role definition available for your use. See the highlighted object below.
Step 2: Assignment
Now we want to assign this role definition to the users that we want to login to Windows with MFA. I would recommend you test this with a couple users initially to ensure its working, and then come back and assign it to specific groups as you increase the scope.
First you can add an AD group to hold the users that you want to enforce MFA for. This will easily allow you to put one or 2 users into the group and test the feature out before you deploy it further. Below, I have created a security group called “Windows_WS_MFA” and I have assigned one of my Windows Admins (Don Bauman) as a member.
Step 3: Assignment continued…
Next, in Access Manager, you can assign the role definition to the AD group. I have taken this one step further by placing the assignment at the computer role level. This means that for a specific set of computers (in my case one windows workstation), I am going to specify that anyone in my “Windows_WS_MFA” role will need to MFA in order to login (because they will be assigned the “require MFA for login” role.
Step 4: Configure Centrify Identity Service to enforce MFA as a login profile
This post assumes that you already have the Centrify Identity service configured with the Centrify Connector to point to your on premise AD environment and the user that you are using is already enrolled into the CIS platform. There are several posts in the community that show how to get this configuration up and running. From an administrative side, you want to make sure that your user (in my case Don Bauman) is tied to a role (lets say Role A), that is tied to a policy (lets say MFA), which specifies a particular authentication profile. The authentication profile can be found in the CIS settings object and this is where you can define what multifactor options are available per profile. You need to ensure that your user you are testing with is enrolled in the identity service and has enrolleed for the mobile authenticator (or has other MFA properties defined in AD or the cloud directory, for example the mobile number for phone based MFA or SMS and email for email based MFA). Its also a good idea to enable OATH based MFA so you can leverage an OATH token for offline authentication.
Step 5: Install the new windows agent.
Assuming your user is all setup for MFA in CIS (again there are community posts that will walk you through this), you need to upgrade the agent on your windows system so that the MFA capability will be available.
Go to the Centrify support site and get the latest bits for the agent:
Click on the link above and you can download the new Windows Agent.
Save the Zip file into a known folder location. Extract the contents of the zip file and run the installer as an administrator (or Run with Privilege if you have the role setup appropriately).
You may get the following message if you already have the windows agent installed. You can choose to proceed by selecting Yes, or you can uninstall the current Windows Agent and then reinstall the new windows agent. I chose to reinstall the new agent so I could join the appropriate CSS Zone manually during the install to show the link.
After selecting No and then uninstalling the old agent, you can go through the installer again.
Accept the license agreement…
Step 6: Configuring the Windows Agent for MFA
Once the agent install is completed, you are asked to configure the agent. Select Next.
The next Step will ask you what hierarchical zone you would like to join. This is mandatory in order to control the windows system with the agent. I chose to join the zone that all my windows workstations are housed under.
You may get the message below which is ensuring that your trust the authentication server you are using (i.e. the Centrify Identity Service). You should ensure you set up the certificates appropriately.
Once the agent is installed and enrolled with the Centrify Identity Service, you will get the message below.
Step 7: Restart and Test the Agent
Now a restart is required. When the machine comes back from the restart, you can login with your user (Don Bauman in my case) who will be prompted for MFA.
You will see a brief message indicating that the Windows system is connecting to the Centrify Identity Service.
Next you will get to choose the MFA option that you want to use to login to the system. This is based on the MFA methods that your user has enrolled in with CIS, and it depends on the authentication profile that is being enforced for the policy that is tied to the role that your user is a member of.
You can select the MFA of your choice. I selected SMS.
You will then get a message that the text was sent to the phone that is registered with your user. You can then follow the link in the text message on your phone.
Once you get the text message, simply click on the link to approve the access.
You will then see a branded screen where you can approve or deny the access. Go ahead and Approve it for this test.
Once you get the message that your authentication was successful, you will be automatically logged into the Windows machine.
Congratulations! You now have Windows MFA working. Once you are logged in, you will get an option to setup the Centrify Offline passcode. This can be useful if you are in a location where the Windows Machine cannot reach out to the Centrify identity service to send you an MFA request.
IMPORTANT NOTE: Realistically, offline login should only be used when you are not using zones. The challenge with setting up offline MFA when using zones is that an administrator would need to capture an OTP code for every single server that they have access to. This is not scalable and therefore is not recommended. Instead, when you are using zones, you are better off using rescue rights and promoting a role with rescue rights in scenarios where an administrator is unable to login to the windows server (I've provided some guidance below). For more information on how to use MFA for Windows login when you are not using Centrify Server Suite and Centrify zones, please see the following article:
So lets say you have setup MFA login for a windows administrator, but for some reason the system is offline, and you cannot authenticate with MFA. This is where rescue rights come into play. Its easy to setup rescue rights in Access Manager. See the screenshot below.
When a situation like this occurs, the best practice is to create a Role Assignment (you can make this more granular with a computer role) to promote the rescue rights role to a limited set of administrators that can logon to fix the connectivity issue with the system. Similar to more privileged accounts on various operating systems, this role should be promoted as needed rather than assigned permanently.
Congratulations. You are now setup for Windows Login MFA to your Windows System. Now take the concepts described above and deploy more groups of your users/administrators to enable MFA for them. Remember MFA is a great way to add security to your logins without having to make your users’ passwords unecesarrily complex. The more complex the password rule, the more likely your users are going to write them down. Without the password complexity, your systems are susceptible to a variety of attacks. MFA solves this problem by giving your users a secure method of logon that is very easy to use.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.