FreeRADIUS responds by Accept instead of Reject

Hello,

I have noticed a weird behavior of FreeRADIUS server included in the application RADIUS spread through the App Center.

According to the logic FreeRADIUS server should respond by “Access-Accept packet” if LDAP entry of user has the assigned univentionNetworkAccess object class or belongs to LDAP group that has the same object class. In all other scenarious it should return “Access-Reject packet” for all requests.

However, we have figured out the following (we used radtest tool):

  • The user has the parameter “Allow network access” or belongs to LDAP group with this parameter enabled:

    1. Simple request to FreeRADIUS server without setting authentication method:

      radtest <username> <user's password> <ldap server> 1812 <RADIUS client password>
      

      We get the following response:

      Sending Access-Request of id 164 to xxx.xxx.xxx.xxx port 1812
      User-Name = "TestUser"
      User-Password = "xxxxxxxxxxx"
      NAS-IP-Address = 127.0.1.1
      NAS-Port = 1812
      Message-Authenticator = 0x00000000000000000000000000000000
      rad_recv: Access-Accept packet from host xxx.xxx.xxx.xxx port 1812, id=164, length=20
      
    2. Request to FreeRADIUS server with setting authentication method to MSCHAP:

      radtest -t mschap <username> <user's password> <ldap server> 1812 <RADIUS client password>
      

      We get the following response:

      Sending Access-Request of id 197 to xxx.xxx.xxx.xxx port 1812
      User-Name = "TestUser"
      NAS-IP-Address = 127.0.1.1
      NAS-Port = 1812
      Message-Authenticator = 0x00000000000000000000000000000000
      MS-CHAP-Challenge = 0x28c8a5df5a9438c8
      MS-CHAP-Response = 0x00010000000000000000000000000000000000000000000000003ab93eb930a00a3b112ed3257de1cd0f1bf3059b264c13c8
      rad_recv: Access-Accept packet from host xxx.xxx.xxx.xxx port 1812, id=197, length=84
      MS-CHAP-MPPE-Keys = 0x3fefc50b0ff9a88e3aca91c7a6f443a421b9209c5780e6ce0000000000000000
      MS-MPPE-Encryption-Policy = 0x00000002
      MS-MPPE-Encryption-Types = 0x00000004
      
  • The user does not have the parameter “Allow network access” that means RADIUS server should always respond by REJECT.

    1. Simple request to FreeRADIUS server without setting authentication method:
      radtest <username> <user's password> <ldap server> 1812 <RADIUS client password>
      
      We get the following response:
      Sending Access-Request of id 81 to xxx.xxx.xxx.xxx port 1812
      User-Name = "TestUser"
      User-Password = "xxxxxxxxxxxxx"
      NAS-IP-Address = 127.0.1.1
      NAS-Port = 1812
      Message-Authenticator = 0x00000000000000000000000000000000
      rad_recv: Access-Accept packet from host xxx.xxx.xxx.xxx port 1812, id=81, length=20
      
    2. Request to FreeRADIUS server with setting authentication method to MSCHAP:
      radtest -t mschap <username> <user's password> <ldap server> 1812 <RADIUS client password>
      
      We get the following response:
      Sending Access-Request of id 101 to xxx.xxx.xxx.xxx port 1812
      User-Name = "TestUser"
      NAS-IP-Address = 127.0.1.1
      NAS-Port = 1812
      Message-Authenticator = 0x00000000000000000000000000000000
      MS-CHAP-Challenge = 0x4e5ca55d6551cc7b
      MS-CHAP-Response = 0x0001000000000000000000000000000000000000000000000000648f2a36ae1642ea518e7d24a7ffef000ca910f2fdcccbc1
      rad_recv: Access-Reject packet from host xxx.xxx.xxx.xxx port 1812, id=101, length=61
      MS-CHAP-Error = "\000E=691 R=1 C=6d6d8012da7bb429 V=2"
      

Eventually, the provided examples of output of radtest tool show that user with forbidden access to network still has access to network if requests to FreeRADIUS server are not encrypted.

For example, OpenConnnect VPN server does not encrypt requests to RADIUS server and this means that any user, which account exists on UCS server, can connect to infrastructure.
I am worried right now because of that, since this looks like a vulnerability for me.

Could you please explain to me whether the aforementioned behavior is normal and planned or not?
Is there a chance that something is wrong with parameters in Univention Configuration Registry?

Thanks in advance.

Hello!

Can anybody pay attention to the issue?

I have updated our version of UCS up to the recent release 4.4 and still see the same behavior.

Here is the output of command “univention-radius-check-access”:

DEBUG: [user=TestUser; mac=None] Given username: "TestUser"
DEBUG: [user=TestUser; mac=None] Given stationId: "None"
DEBUG: [user=TestUser; mac=None] UCS@school RADIUS support is not installed
DEBUG: [user=TestUser; mac=None] Checking LDAP settings for user
DEBUG: [user=TestUser; mac=None] DENY 'uid=TestUser,cn=employees,cn=users,dc=example,dc=com'
DEBUG: [user=TestUser; mac=None] -> DENY 'cn=TestGroup,cn=team,cn=groups,dc=example,dc=com'
INFO: [user=TestUser; mac=None] Login attempt denied by LDAP settings
DEBUG: [user=TestUser; mac=None] User is not allowed to authenticate via RADIUS
DEBUG: [user=TestUser; mac=None] --- Thus access is DENIED.

However, if we use radtest tool we get the following output:

radtest TestUser <user password> ldap.example.com 1812 <radius password>

Sent Access-Request Id 200 from 0.0.0.0:49719 to 192.168.254.131:1812 length 99
        User-Name = "TestUser"
        User-Password = "<user password>"
        NAS-IP-Address = 127.0.1.1
        NAS-Port = 1812
        Message-Authenticator = 0x00
        Cleartext-Password = "<user password>"
Received Access-Accept Id 200 from 192.168.254.131:1812 to 0.0.0.0:0 length 20

If we use authentication method PAP, we get the same result:

radtest -t pap TestUser <user password> ldap.example.com 1812 <radius password>

Sent Access-Request Id 64 from 0.0.0.0:46738 to 192.168.254.131:1812 length 99
        User-Name = "TestUser"
        User-Password = "<user password>"
        NAS-IP-Address = 127.0.1.1
        NAS-Port = 1812
        Message-Authenticator = 0x00
        Cleartext-Password = "<user password>"
Received Access-Accept Id 64 from 192.168.254.131:1812 to 0.0.0.0:0 length 20

And if we use any of remaining authentication methods, everything works correct then:

radtest -t chap TestUser <user password> ldap.example.com 1812 <radius password>  

Sent Access-Request Id 220 from 0.0.0.0:52529 to 172.31.254.131:1812 length 84
        User-Name = "TestUser"
        CHAP-Password = 0x3870626f163ba6551ca9c78ec7cdc041a2
        NAS-IP-Address = 127.0.1.1
        NAS-Port = 1812
        Message-Authenticator = 0x00
        Cleartext-Password = "<user password>"
Received Access-Reject Id 220 from 172.31.254.131:1812 to 0.0.0.0:0 length 20
(0) -: Expected Access-Accept got Access-Reject

Could someone point me on misconfiguration or setting that might be the reason of the described issue?

Thank you in advance.

Hi,
thanks for your detailed report. We currently only support the “Allow network access” attribute together with mschap authentication. EAP-PEAP for 802.11x does not support PAP (for example used for wpa enterprise).

I agree that this is unexpected for users who plan to use radius for something else than 802.11x and opened a bug

Hello,

I appreciate your response and step of creating issue on bug tracker.
I hope we get a solution soon.

Thank you!

1 Like

When will this be fixed? We use eap-peap and it’s becoming a problem not being able to control users be denying them access by unchecking “Allow network access”.

Mastodon