Leveraging Azure MFA with CyberArk

Posting this here for future reference. We had a customer that wanted to leverage Azure MFA for authenticating users (IT Administrators) to CyberArk for accessing servers and checking out privileged credentials. CyberArk has two mechanisms to support this: 1) RADIUS authentication or 2) SAML authentication. We initially attempted to implement RADIUS authentication using Microsoft's Network Policy Server with the Azure MFA plug-in but threw up the white flag after many hours of debugging network packet captures. In the end we implemented this use case using Azure SSO to provide SAML-based single sign-on to CyberArk.

RADIUS authentication is a bit more "legacy"but has been the de facto protocol for step-up authentication use cases for many years. I won't get into the history of RADIUS but it has been around for a very long time (almost as long as the internet) and is widely used for network authentication such as to an IPSEC-based VPNs and 802.11X based Wireless networks such as Cisco Meraki. The advantage of implementing RADIUS authentication in CyberArk is that it can be integrated for additional use cases, such as requiring additional authentication when a user checks out credentials for critical infrastructure such as an Active Directory Domain Controller. The alternate solution using SAML essentially pushes the MFA decision out to your identity provider, which in this case is Azure, and only supports additional authentication during the logon process. 

Going back to my attempts to implement RADIUS authentication with NPS+Azure MFA, we stood up the NPS server and integrated Azure MFA following Microsoft's documentation (https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension). The flow is very similar to standard network-based authentication flows such as this sample diagram from Microsoft:

Each RADIUS authentication request is sent over UDP port 1812 to the NPS server and contains flags for different scenarios, known as service types. The service type describes the conditions such as if the user is going through a proxy, has a dialup connection (remember those), etc. More info: https://www.dialogic.com/webhelp/BorderNet2020/2.2.0/WebHelp/radatt_service_type.htm

 

Type (IETF Attribute Number) = (6) for Service-Type.

Length = 6

Value: The Value field is four octets.

 

1	Login
2	Framed
3	Callback Login
4	Callback Framed
5	Outbound
6	Administrative
7	NAS Prompt
8	Authenticate Only
9	Callback NAS Prompt
10	Call Check
11	Callback Administrative

 

The service types are defined as follows when used in an Access-Accept.  When used in an Access-Request, they MAY be considered to be a hint to the RADIUS server that the NAS has reason to believe the user would prefer the kind of service indicated, but the server is not required to honor the hint.

 

Login - The user should be connected to a host.

Framed - A Framed Protocol should be started for the User, such as PPP or SLIP.

Callback Login - The user should be disconnected and called back, then connected to a host.

Callback Framed - The user should be disconnected and called back, then a Framed Protocol should be started for the User, such as PPP or SLIP.

Outbound - The user should be granted access to outgoing devices.

Administrative - The user should be granted access to the administrative interface to the NAS from which privileged commands can be executed.

NAS Prompt - The user should be provided a command prompt on the NAS from which non-privileged commands can be executed.

Authenticate Only - Only Authentication is requested, and no authorization information needs to be returned in the Access-Accept (typically used by proxy servers rather than the NAS itself).

Callback - NAS Prompt The user should be disconnected and called back, then provided a command prompt on the NAS from which non-privileged commands can be executed.

Call Check - Used by the NAS in an Access-Request packet to indicate that a call is being received and that the RADIUS server should send back an Access-Accept to answer the call, or an Access-Reject to not accept the call, typically based on the Called-Station-Id or Calling-Station-Id attributes.  It is recommended that such Access-Requests use the value of Calling-Station-Id as the value of the User-Name.

Callback Administrative - The user should be disconnected and called back, then granted access to the administrative interface to the NAS from which privileged commands can be executed. 

 

When I was testing out the extension, I used the free-radius test client (radtest) which didn’t pass the service type flag and subsequently, the test was successful. I had to install WireShark on the NPS server and capture the differences. What I found is that radtest did not pass a "type" flag, while CyberArk passes type=8 (Authenticate Only) which resulted in a reject response, not by the NPS server but by the Azure MFA extension. This is what I found in the event viewer on the NPS server under Applications and Services Logs > Microsoft > AzureMFA > Authz > AuthZOpCh: 

 

NPS Extension for Azure MFA: NPS Extension for Azure MFA only performs Secondary Auth for Radius requests in AccessAccept State. Request received for User [user] with response state AccessReject, ignoring request.

 

Basically the error message is stating that the NPS server with the Azure MFA plugin only supports secondary authentication. Searching for "NPS Extension for Azure MFA only performs secondary auth" only produces two pages of results…None of which contained a fix.

As mentioned above, in the end we did successfully implement this customer's requirement by leveraging the SAML IdP in Azure to handle the authentication process and then perform SAML-based single sign-on to CyberArk. There are many advantages to this approach: 1) organizations can implement conditional access policies to only require users to perform additional authentication based on risk such as accessing from a new device, impossible travel, etc. Microsoft also introduced new identity protection features in Azure such as the ability to detect leaked credentials which adds an additional security layer...very important for security solutions like CyberArk.

If you have found a solution for integrating CyberArk with Microsoft NPS+Azure MFA, feel free to drop me a line.