Freeradius and ldap attribute mismatch

[Alan DeKok]

On Jul 17, 2018, at 3:51 PM, Petit, Benoit <b.petit at bell.ca> wrote:
> We are in the process of migrating Freeradius in our production environment. The current version is way too old (running on Red Hat 3! seems like nobody really wanted to do the upgrade). Anyway, I finally managed to make authentication work. But I still have a problem. It looks like the client's device doesn't "receive" the Class attribute on the login process, even though I see it in the logs. You will see in the logs below that all LDAP attributes are passed on login. The only difference is that the Class attribute is in hexadecimal instead of text.

  It's supposed to be in hex.  Class is an opaque binary blob, not a humanly readable string.

> From your expertise and knowhow, where could this error come from? Freeradius, Openldap or the client's device?
> 
> Thanks in advance. Here are the logs:
> ...
>  WARNING: Empty pre-proxy section.  Using default return values.
> Sending Access-Request of id 76 to 10.68.x.x port 1645
>        NAS-Identifier = "Juniper IVE"
>        User-Name = "xxxxxxxxx"
>        User-Password = "873901936144"
>        Tunnel-Client-Endpoint:0 = "10.254.x.x"
>        NAS-IP-Address = 10.226.x.x
>        NAS-Port = 0
>        Acct-Session-Id = "xxxxxxxxx at ssl-admin.bell(Admin Users - FreeRadius-Test-New)\"Mon Jul 16 12:55:07 2018\"+/SSGJd2"
>        Proxy-State = 0x323037
> ...
> Waking up in 13.0 seconds.
> rad_recv: Access-Accept packet from host 10.68.x.x port 1645, id=76, length=83
>        Class = 0x53425232434c9db383ebde9481cabcc01180250180038198ce8002800881b198a683b1c4eab312800e819db383ebde9481cabcc080cf9af0
>        Proxy-State = 0x323037

  The Class attribute is coming from the hime server.  It's not coming from LDAP.

  The Class attribute is also *very* long.  That's likely why it doesn't work.

  The NAS probably only supports Class attributes of 16 bytes or so.  If you shorten the Class to that length, it will likely work.

> ---------------------------------------------------------
> Last thing: when the user tries to login on his device, he gets the following message in his device's logs:
> 
> 2018-07-16 12:27:10 - ive - [10.254.x.x] baxxxx at ssl-admin.bell(Admin Users - FreeRadius-Test-New)[] - Login failed. Reason: No Roles

  See the vendor documentation for what the message means.  We didn't write that product, and we know nothing about it.

> 2018-07-16 12:27:10 - ive - [10.254.x.x] baxxxx at ssl-admin.bell(Admin Users - FreeRadius-Test-New)[] - Primary authentication successful for baxxxx at ssl-admin.bell/FreeRadius-Test-New from 10.254.x.x
> 
> A test with another user last Friday had the following logs on the device's logs:
> 
> 2018/07/13 10:10:33 - [10.254.x.x] - baxxxx at ssl-admin.bell(Admin Users - FreeRadius-Test-New)[] - Variable userAttr at FreeRadius-Test-New.Class = "<Binary Data>"
> 2018/07/13 10:10:33 - [10.254.x.x] - baxxxx at ssl-admin.bell(Admin Users - FreeRadius-Test-New)[] - No match on rule 'userAttr.Class = 'ssl-oper''
> 2018/07/13 10:10:33 - [10.254.x.x] - baxxxx at ssl-admin.bell(Admin Users - FreeRadius-Test-New)[] - No match on rule 'userAttr.Class = 'admin''
> 2018/07/13 10:10:33 - [10.254.x.x] - baxxxx at ssl-admin.bell(Admin Users - FreeRadius-Test-New)[] - Realm Admin Users - FreeRadius-Test-New did not map user baxxxx at ssl-admin.bell to any roles
> 2018/07/13 10:10:33 - [10.254.99.171] - baxxxx at ssl-admin.bell(Admin Users - FreeRadius-Test-New)[] - Sign-in rejected. Reason: No Roles

  Ask the vendor why their product doesn't work.

  Alan DeKok.