Let’s face it, no one likes passwords. They are easily forgotten by end users and IT administrators perceive them as a potential security risk. Social engineering is becoming more and more common and plays a part in users giving their credentials to the wrong people without realising.

To put an end to the password nightmare, Microsoft has a solution that comes in many flavours, in the hope that this technology will be adopted by a broad range of customers. In this blog I am going to be discussing ‘key-based GPO managed’, which is a hybrid between new technology (Hello for Business) and some group policy and configuration from an on-premise active directory.

“Ninety percent of Microsoft’s employees can log on to the corporate network without a password” – Bret Arsenault

First things first, it’s important to understand what you will need in order to get Hello for Business working in an environment – surprisingly, not a lot!

Windows Hello for Business key-based GPO managed: prerequisites

So, the main things for Windows Hello for Business key-based authentication are as follows:

  • Active Directory (on-prem)
  • Azure Active Directory subscription
  • Windows Server 2016 Domain Controller
  • Azure AD Connect (AD sync from on-premise to Azure AD)
  • Active Directory Group Policy (on-premise)
  • Active Directory Certificate Services

Planning an adequate number of Windows Server 2016 Domain Controllers for Windows Hello for Business deployments

It’s crucial to understand how many 2016 servers you will need to support a Hello for Business deployment, but how can you understand how many domain controllers are required? Through the use of performance monitoring on your 2016 domain controllers, you can determine existing authentication traffic. In fact there is a ‘KDC AS Requests’ performance counter which can be used to determine how much of a domain controllers load is due to Kerberos authentication, thus allowing you to plan adequately.

Determining total AS Request load

It’s important to monitor the request load to ascertain exactly how many 2016 servers should be required. It’s recommended that organisations use this performance monitor to understand in greater detail what that baseline is.

Pick a location where you plan to upgrade the domain controllers. Pick a time when authentication is deemed to be at its highest – first thing in the morning would be a ideal as everyone gets to the office and logs in to their machines. When an appropriate time has been established, enable the performance counters on the domain controllers in question and collect KDC AS Requests performance counters for a period of time (Microsoft suggests up to two hours). It would be wise to kick-off the performance monitoring 30 minutes before the initial influx of authentication requests (sign-ins and unlocks) on the devices. Continue to monitor for 30 minutes after the initial authentication deemed to be significant.

For example, if users are arriving at the office at 09:00am, the performance capture should begin at 08:30 and end at 10:30. It’s important to see authentication patterns and catch it at its highest and lowest.

How much is enough?

Microsoft work on a 70 percent threshold per domain controller for authentication requests, so continue to monitor the environment until this criteria is met. If a domain controller is still responsible for 70 percent or more of the authentication requests, it’s important to consider adding additional domain controllers to reduce the distribution of authentication volume.

Final thoughts

The idea is to have the flexibility to scale based on the authentication requests, and performance monitoring is a great way to enable you to gain a better understanding on how this will look.

About the author