Hi Phil,
we fixed the problem by using the radiusGroupName attribute in the
user's object instead of posixGroup-Objects.
Thanks for your help anyone!
Am 2013-01-09 12:38, schrieb Phil Mayers:
On 01/09/2013 08:29 AM, Rudolph Bott wrote:
However, our groups are stored underneath
"ou=groups,dc=example,dc=org"
- so rlm_ldap is not able to find them with the basedn shown above.
We
Unsolicited advice: that's not a great schema, and you should look to
move away from it.
are also not able to change the basedn to something else, since
there is
a different user-tree underneath dc=example,dc=org which should not
be
taken into account by freeradius.
Define a 2nd copy of the LDAP module with the base DN of the group
area.
Run the 1st LDAP module before doing any group checks so that
"Ldap-UserDN" is populated.
Check the per-instance Ldap-Group attribute of the 2nd instance.
Like so:
ldap {
# base DN for users
}
ldap ldap2 {
# base DN for groups
}
...
authorize {
...
ldap
if (ldap2-Ldap-Group == FOO) {
# will search 2nd base DN using user DN of 1st module
}
...
}
Alternatively, if your users are all in a flat hierarchy, you can
hard-code Ldap-UserDN and skip calling the 1st module (unless you
need
data from there, of course)
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
--
Mit freundlichen Grüßen / with kind regards
Rudolph Bott
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
