Thanks for the quick reply. The only thing that bugs me here is that the long Class attribute that I receive on the new server is the same one on the current server in production, which runs Freeradius version 1.1.1 and Openldap 2.0.27-11, and been working perfectly for years. Tks, Benoit Petit Analyste Technique | Technical Analyst Sécurité et Intelligence Digitale TI | IT Security and Digital Intelligence 1 Carrefour Alexandre-Graham-Bell - Aile E - 3e étage - Verdun - QC - H3E 3B3 514-391-9247 L'utilisation de ce message et régie par notre politique de courriel. www.bell.ca/PolitiqueConfidentialiteCourriel The use of this message is restricted by our mail policies. www.bell.ca/EmailConfidentialityWarning -----Message d'origine----- De : Freeradius-Users <freeradius-users-bounces+b.petit=bell.ca@lists.freeradius.org> De la part de Alan DeKok Envoyé : 17 juillet 2018 16:44 À : FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Objet : Re: Freeradius and ldap attribute mismatch On Jul 17, 2018, at 3:51 PM, Petit, Benoit <b.petit@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@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@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@ssl-admin.bell(Admin Users - FreeRadius-Test-New)[] - Primary authentication successful for baxxxx@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@ssl-admin.bell(Admin Users - FreeRadius-Test-New)[] - Variable userAttr@FreeRadius-Test-New.Class = "<Binary Data>" 2018/07/13 10:10:33 - [10.254.x.x] - baxxxx@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@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@ssl-admin.bell(Admin Users - FreeRadius-Test-New)[] - Realm Admin Users - FreeRadius-Test-New did not map user baxxxx@ssl-admin.bell to any roles 2018/07/13 10:10:33 - [10.254.99.171] - baxxxx@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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html