Thanks a lot Alan, for the quick and excellent support!
How are ldap check items meant to be configured and work in freeradius 3?
They don't. There's no documentation which says that this works.
That’s why I was asking. I think I was on quite a wrong track.
The good news is that there's a simple fix. Edit the "authorize" section of the virtual server, and add some text after the line containing "ldap“:
if (control:NAS-Identifier && control:NAS-Identifier != NAS-Identifier) { reject }
I think your suggestion tries to check if radiusNASIdentifier is set in LDAP - if not continue, if yes compare it to the NAS-Identifier in the request. This works fine for EAP requests with a NAS-Identifier set, but still permits requests without it, e.g. from radtest, because the NAS-Identifier is empty then and the evaluation throws an error instead of a reject: Debug: (0) [ldap] = updated Debug: (0) if (control:NAS-Identifier && (control:NAS-Identifier != NAS-Identifier)) { ERROR: (0) Failed retrieving values required to evaluate condition So I inserted this before your code and now it works: if (control:NAS-Identifier && !NAS-Identifier) { # reject if NAS-Id required but not present reject } Thank you again! Jan
Am 13.04.2018 um 22:47 schrieb Alan DeKok <aland@deployingradius.com>:
On Apr 13, 2018, at 4:31 PM, Jan Baumann <freeradius@cyberways.net> wrote:
I have a well running freeradius 3.0.12 (Debian 9 package) with mysql und openldap backends.
You should really upgrade.
Usernames are of course unique and exist either only in ldap or mysql.
Everything works for ldap and mysql users, except one thing:
If I add a check-item into mysql radcheck table it works as expected. If I add the same item into openldap, it is not taken care of and access is always permitted if the item matches the request or not.
The comments in raddb/mods-available/ldap explain how the module works. It says nothing about matching items.
But... if I add a reply-item to openldap is is delivered as part of the radius access accept message.
debug output:
(0) ldap: User object found at DN „uid=jbaumann,ou=people,dc=cyberways,dc=net" (0) ldap: Processing user attributes (0) ldap: control:Cleartext-Password := '12345'
That works.
Radius pulls the NAS-Identifier control item from ldap correctly, but does not reject the request if it does not match.
Because nothing in the documentation says this is how the LDAP module works.
For the cleartext password it works.
Because the PAP module looks at control:Cleartext-Password.
I don’t see any hints of processing NAS-Identifier in the debug output at all, regardless which operator (=, := or +=) I try. It also pulls the Tunnel-Private-Group-ID reply item from ldap and successfully puts it into the reply message. So my ldap users can successfully log in with PEAP, but into any wifi SSID. Mysql users are correctly rejected if the NAS-Identifier does not match.
config of ldap module:
compare_check_items = yes
What's that from? There's no such configuration in v3.
update { control:Cleartext-Password := 'userPassword' control:Expiration := 'radiusExpiration' control:NAS-Identifier := 'radiusNASIdentifier'
The documentation is clear on what that does. It's looking at the "control" list, NOT the request. It's setting the value based on ":=", not comparing it.
So even if the LDAP module did compare items (which it doesn't), the above configuration would still be wrong.
I am trying to fix this for the entire past week, so may I please ask the experts here. How are ldap check items meant to be configured and work in freeradius 3?
They don't. There's no documentation which says that this works.
The good news is that there's a simple fix. Edit the "authorize" section of the virtual server, and add some text after the line containing "ldap":
if (control:NAS-Identifier && control:NAS-Identifier != NAS-Identifier) { reject }
Which I think is what you want.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html