Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Radius Authentication issues when using ÆØÅ

    Scheduled Pinned Locked Moved General pfSense Questions
    6 Posts 3 Posters 1.1k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S
      sebalbers
      last edited by

      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?

      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        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

        1 Reply Last reply Reply Quote 0
        • S
          sebalbers
          last edited by

          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).

          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            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

            S 1 Reply Last reply Reply Quote 0
            • S
              sebalbers @stephenw10
              last edited by sebalbers

              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.

              1 Reply Last reply Reply Quote 0
              • jimpJ
                jimp Rebel Alliance Developer Netgate
                last edited by

                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.

                Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                Need help fast? Netgate Global Support!

                Do not Chat/PM for help!

                1 Reply Last reply Reply Quote 1
                • First post
                  Last post
                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.