Radius Authentication issues when using ÆØÅ



  • Hi,

    We are experiencing issues with our radius authentication method in PfSense when some of our users have an Æ, Ø OR Å in their password. When we are testing the authentication from Diagnostics --> Authentication we are getting an error saying 'Authentication failed'.
    Furthermore our Radius server(NPS on WinServer2019) returns 'Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.'

    Resetting the users password so they no longer have an Ø makes them able to get Authentication Successful.

    Do any of you know a solution for this?


  • Netgate Administrator

    I'm not aware of any solution there. I could well believe it's seen as an invalid character set though.

    I assume those passwords are validated against Winserver2019 when authenticating from other client types?

    Are you able to use those passwords for accounts on pfSense directrly?

    Steve



  • Hi Steve

    Thank you for your message.
    I've just tested creating a local account with a password that contains ØÆÅ. It works and they are validated correctly.
    If I try to use my Radius authentication as a login option in PfSense with a password that have ÆØÅ this fails, without ÆØÅ it works.
    You are correct that its validating against a Windows Server 2019 running NPS. Currently I got PfSense validating against it and a Remote desktop Gateway(MS product).


  • Netgate Administrator

    Just to be clear though those account in the MS server are using those same passwords without issue for other logins?

    I.e. it's not a problem with local accounts in pfSense. It's not problem with the MS server. It looks like an issue with the code that sends it to radius to be validated.

    Steve



  • That is true.
    Users are using password with ÆØÅ when logging onto Microsoft Remote Desktop services, which works. RDS also uses the same Radius server to authenticate as PfSense does.

    I think you are right that there is an issue with the code send to the Radius server, my best guess would be an encoding issue of some kind.


  • Rebel Alliance Developer Netgate

    Ran some tests on this a few different ways this morning. It appears to work fine when pfSense is set to use PAP or MD5-CHAP to the server, but fails when using MSCHAPv1 or MSCHAPv2. I've tried a few different ways to encode the values (UTF-8, UTF-16) and in varying places around the auth request but no luck so far.

    It works using any method I've tried with radtest at the CLI, so it appears to be an issue either in the PHP RADIUS code (PEAR modules for Auth_RADIUS or the CHAP specific module(s)) or how it's called when pfSense forms auth requests with these types of passwords.

    I created https://redmine.pfsense.org/issues/10352 to track it down eventually but at least at the moment I'm not seeing anything that looks like it would be a quick fix.


Log in to reply