Anyconnect fails to connect with special character password £

[Ahmad Saad4]

Hi there!

We've just discovered if we include special charterer £ in the password, the user won't be able to login, and once we remove that symbol the user can login normally.

We've tested the password with following special characters %?-_<+>#@&$* ! and there was no issue to login.

We're using RADIUS to authenticate VPN users against Windows 2016 AD, and we have set AD to 15 Characters for password length.

ASA version 9.12, AnyConnect version 4.8

Is this a know bug in the ASA/AnyConnect? if so, is there a fix/workaround for it ?

Thanks!

[Tyson Joachims]

It seem that it has something to do with encoding so there are certain characters that do not work. You can use this website to check as to which characters will cause you problems: https://www.charset.org/utf8-to-latin-converter. Input your password into the UTF-8 field and convert to Latin. If you get a result then the password will work. If you don't get a result, it is because a special character within your password cannot be converted and thus is invalid for use.

Alternatively you can input in the Latin field and convert to UTF-8. You will always get an output but some characters get changed which is likely the case that is happening here. For example, £ becomes £ while é becomes é

Source: https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-c02571732

[Ahmad Saad4]

Thanks so much for your reply.

My client stated that It’s strange as they're sure that the users were using the £ symbol before. There was no change on the ASA,AnyConnect nor to the RADIUS/AD. It's kind of mystery. 

[patoberli]

What you can do, switch to PAP instead of CHAP in the radius configuration on the ASA. If I remember correctly, that way the ASA doesn't anymore also encrypt the password and it should work. The password should still be encrypted with the radius shared secret, but make sure it's a long one!

[Tyson Joachims]

@patoberliActually I would recommend moving to MS-CHAPv2. I just tested this in detail and was able to recreate the problem and was able to solve it by using MS-CHAPv2 instead of PAP for the RADIUS authentication of the VPN users. Here's how to do it:

1. First make sure that your RADIUS server will accept MS-CHAPv2 from the ASA. I'm using Microsoft's Network Policy Server (NPS) as my RADIUS server so I just need to edit the "Constraints" for my "Network Policy"

2. Next go to the tunnel-group general-attributes and enable password-management:

tunnel-group RA-VPN general-attributes
 password-management

Now you can use those fancy characters! Also, now when users connect and their domain password has expired, they will be able to reset their password through AnyConnect

Please consider rating all helpful replies

[patoberli]

I think I couldn't do enable this, because I'm using MFA on the NPS 2019 server (with Microsoft Azure AD) via Radius. I don't anymore remember it, but there was a reason why I had to disable ms-chapv2 on the ASA.

[patoberli]

Sorry for warming up this thread again, but it seems I've finally found a working solution with MSCHAPv2 and even the Microsoft MFA plugin!

It takes several steps to do:

On the NPS set the following to enable NTLMv2 for Radius (this is needed since an update in ~2019 by Microsoft, which disabled the default use of NTLMv1 on domain controllers, which is used by NPS to authenticate users against the DC)

If you must use MS-CHAPv2, you can enable NTLMv2 authentication by adding this registry entry:

Select Start > Run, type regedit in the Open box, and then select OK.
Locate and select the following registry subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Policy
On the Edit menu, point to New, and then select DWORD Value.
Type Enable NTLMv2 Compatibility, and then press ENTER.
On the Edit menu, select Modify.
In the Value data box, type 1, and then select OK.
Exit Registry Editor.

Source: https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/lt2p-ipsec-ras-vpn-connections-fail

Probably no service restart needed, but can't hurt. 

Next step - on the ASA, enable MSCHAPv2 for the radius servers in question. 

This is it basically. Now if you also use the MFA Plugin to use Azure AD MFA (Source https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension-vpn) then one more step is needed if you use SMS or OTP instead of Authenticator App - Push (or Call) (Source https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/36647266-mfa-nps-ext-support-for-network-policies-via-rad).

In this case on the NPS open the Connection Request Policy and there open the Use Windows authentication for all users one (which is used when using SMS/OTP by default, see the authentication logs for a VPN user), switch to the Settings tab and enable MSCHAPv2 (and just to be sure) PAP. You will get an error saying you are enabling insecure methods and if you like to view the Manual, select No to save this.

I really hope this helps somebody, to fix the Umlaut (and other non US-ASCII characters) problem with AnyConnect and Windows NPS.

[Tyson Joachims]

@Ahmad Saad4 did my solution of using MSCHAPv2 work for you in resolving the issue?