Ldap-Group DN and the match "=~" check
Hello, I've made a little test and found that the match operator "=~" doesn't work on my setup (Freeradius 1.0.4) for Groups defined as LDAP DNs. Indeed I'd like to to use the following rule (in the users file): DEFAULT Ldap-Group =~ "cn=mygroupname,ou=(unit1|unit2|unit3),dc=mycorp,dc=org" Fall-Through = no This way, a unique rule will match 3 different groups having the same cn, but in different subtrees. Am I missing something or is this setup impossible with Ldap-Groups ? Thanks in advance for your answer. Regards, Thibault Le Meur
Thibault Le Meur wrote:
Hello,
I've made a little test and found that the match operator "=~" doesn't work on my setup (Freeradius 1.0.4) for Groups defined as LDAP DNs.
Indeed I'd like to to use the following rule (in the users file):
DEFAULT Ldap-Group =~ "cn=mygroupname,ou=(unit1|unit2|unit3),dc=mycorp,dc=org" Fall-Through = no
This way, a unique rule will match 3 different groups having the same cn, but in different subtrees.
Am I missing something or is this setup impossible with Ldap-Groups ?
You are missing something. Ldap-Group is not a real attribute that's copied to the config items. It's a "virtual" attribute. At runtime, the right-hand-side of the comparison is searched for in the LDAP directory. There's no way to do what you want currently. Source code changes and/or clever use of the ldap xlat might do it (see doc/rlm_ldap)
Am I missing something or is this setup impossible with Ldap-Groups ?
You are missing something.
Ldap-Group is not a real attribute that's copied to the config items. It's a "virtual" attribute. At runtime, the right-hand-side of the comparison is searched for in the LDAP directory.
Ok, that was what I missed indeed. However, I haven't seen it in the rlm_ldap doc file: your last paragraph is worth adding to this file I think ;-)
There's no way to do what you want currently. Source code changes and/or clever use of the ldap xlat might do it (see doc/rlm_ldap)
Maybe... but is ldap xlat yet available in the "users" file ? As stated in doc/rlm_ldap I thought it was only "hopefully shortly" available ? Thanks a lot for your answer. Regards, Thibault Le Meur
"Thibault Le Meur" <Thibault.LeMeur@supelec.fr> wrote:
Maybe... but is ldap xlat yet available in the "users" file ? As stated in doc/rlm_ldap I thought it was only "hopefully shortly" available ?
The issue is more that the LDAP module ignores the operator, and does a simple string compare. The server core needs to expose an API that does the operator-specific compare. It's probably not too hard... Alan DeKok.
Maybe... but is ldap xlat yet available in the "users" file ? As stated in doc/rlm_ldap I thought it was only "hopefully shortly" available ?
The issue is more that the LDAP module ignores the operator, and does a simple string compare. The server core needs to expose an API that does the operator-specific compare. It's probably not too hard...
Alan DeKok.
This means either translating a regexp filter to an Ldap filter, or getting the whole set of groups the user belongs to and then do the regexp compare. I'll have a look at the code when I have time (argh... I hate these last 4 words). Thanks, Thibault
Maybe... but is ldap xlat yet available in the "users" file ? As stated in doc/rlm_ldap I thought it was only "hopefully shortly" available ?
FreeRadius 1.1.0 definitely has it. Can't remember but I recall earlier versions having it too. Using it in the exact manner you want will be tricky however, since the result of the LDAP URI searched for an xlat can only be a single entry, and only a single attribute of that entry. There's a lot of funky stuff hidden away in the LDAP module, most of which I don't pretend to understand (e.g. profiles, default profiles, etc.) but you may be able to use that if you can't get the group thing to work directly. To be honest though, dumping user->group mappings every N minutes and using rlm_passwd to put them into the request may be easier.
participants (3)
-
Alan DeKok -
Phil Mayers -
Thibault Le Meur