Troubleshooting: VPN Login Over RADIUS Fails for Users With Many MFA Options

Version Affected: All
 
 

Overview

Users signing in to a virtual private network (VPN) through the SecureAuth RADIUS server can fail at the multi-factor authentication (MFA) step when they have many MFA options. The login fails at the point where the VPN client should show the user's list of MFA options, while other users on the same device, network and VPN gateway sign in normally.

The affected users have noticeably more MFA options than the users who sign in successfully. Typically:

• The VPN client shows a generic error and returns to the username and password prompt. Cisco AnyConnect, for example, shows Login error.
• The SecureAuth RADIUS log shows the warning The challenge message you are trying to send might be too long for your VPN Client. and then an Access-Challenge.
• The VPN gateway logs a failure. A Cisco Adaptive Security Appliance (ASA) logs AAA unable to complete the request Error : reason = Invalid response received from server.

The image below shows Cisco AnyConnect reporting Login error. and asking for the username and password again, instead of showing the user's MFA options.

Cause

When a user has to complete MFA, the SecureAuth RADIUS server sends the VPN gateway a RADIUS Access-Challenge that lists every MFA option available to that user, each with its label and a masked phone number or a device name. Every option makes that message longer. Past a certain length, the VPN client or gateway does not accept the challenge, and the login fails before the user sees the list. The exact length at which this happens is not known at this point, and it may differ between VPN products.

A user's options build up from several sources, and options the user no longer uses still count until they are removed:

• Each phone number in the profile fields the realm uses for phone numbers can provide a text message (SMS) option, a voice option, or both. With Active Directory, these fields can include attributes such as telephoneNumber, mobile and otherPager. Check the realm's Datastore Properties to confirm which attributes hold the relevant data.
• A single mobile app device can provide more than one option. Depending on what it is registered for, each device can be responsible for totp (a time-based one-time passcode, TOTP), pushLogin (a login request), pushBiometric (a fingerprint or face recognition request) and pushOTP (a passcode sent to the app).
• A personal identification number (PIN), if the user has one, is one more option. Depending on how the realm is configured, the PIN may be stored outside the directory. For Cloud customers, the PIN value is held in the tenant data, so it may only be visible in the self-service or Help Desk realm.

As a rough guide only, built from the default option labels in uiTextsBundle.properties and assuming one numbered line per option, the list comes to:

• About 330 bytes for nine options, for example three phone numbers, two mobile devices that are each registered for both login requests and passcodes, a separate passcode app and a PIN.
• About 240 bytes for seven options, the same user with one of those mobile devices removed.
• About 155 bytes for five options.

These figures only show how quickly the list grows. Its real size also depends on how the RADIUS server lays out the list and on the length of each device name.

On a Cisco ASA, Cisco documents a related behavior in bug CSCvc93483: when a RADIUS Access-Challenge carries more than one Reply-Message attribute, the ASA uses only the first one and drops the rest. The RADIUS specification (RFC 2865) limits each Reply-Message attribute to 253 bytes, so a longer message has to be split across several attributes or shortened. This may explain the failure on an ASA, but it has not been confirmed.

Resolution:

Reduce the number of MFA options the affected user has, or the length of each one. The options below run from the narrowest effect to the widest.

Optional: confirm the cause first. In the Identity Provider (IdP) Admin Console, in the policy applied to the realm, add a temporary rule that lets only the affected user skip MFA. Then ask that user to sign in to the VPN again. If they connect, the list of MFA options is the cause. Remove the rule as soon as the test is done.

Option 1: Remove unused MFA options from the affected user's account. This affects only that user.

1. Find out which options the user no longer uses, such as an old phone number or a mobile device they have replaced.
2. Remove them. The user can do this in the self-service realm, or a help desk engineer can do it in the Help Desk realm. In the list of registered mobile devices, clearing a device's check box deletes it.
3. For a phone number that comes from a directory attribute such as mobile or otherPager, clear the unused value in the directory.
4. Ask the user to sign in to the VPN again.

Option 2: Turn off MFA methods you do not need. This affects every user it covers, not only the affected user. Turn methods off in one of two places:

• In the policy applied to the realm, in the IdP Admin Console. This affects every user of every realm that uses that policy.
• In the global MFA options. This affects every user on every realm.

Option 3: Shorten the MFA option labels. This shortens the list for every user who signs in through the RADIUS server. It does not reduce the number of options, so for a user with many options it is less certain to help than Option 1.

1. On the RADIUS server, open C:\Program Files\SecureAuth Corporation\SecureAuth IdP RADIUS Agent\bin\conf\uiTextsBundle.properties in a text editor.
2. Shorten the text after the equals sign on the OPTION_ lines, for example OPTION_P2A=LOGIN REQUEST instead of OPTION_P2A=SEND LOGIN REQUEST TO MOBILE APP. Leave the key to the left of the equals sign unchanged.
3. Save the file.
4. Restart the SecureAuth RADIUS service so that it reads the new labels.

The image below shows the OPTION_ lines in uiTextsBundle.properties, which hold the label shown for each MFA method, and the SUB_OPT_ lines, which hold the prompts for choosing a phone number, email address, help desk or device.

Special Considerations

The temporary rule used to confirm the cause lets the affected user sign in without MFA for as long as it is in place. Target it at that one user only, use it only for the test, and remove it as soon as the test is done.

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.