On 24 Apr 2014, at 23:20, Alan DeKok <aland@deployingradius.com> wrote:
Josh Essar wrote:
I have having some problems with ldap group checking. Our students do not have a common group that they are a member of. They are all a member of a group based on their username (ST_Students for every student that has a username that start with st). We then have groups based off each letter of the alphabet (S_Students would contain the SA_Students through SZ_Students groups). We then have another group called students, that has the A_Students through Z_Students groups.
That is an... inventive approach. I can honestly say I've never seen that before.
(0) Performing unfiltered search in 'CN=GROUP5,OU=staff,OU=people,DC=our,DC=domain', scope 'base' (0) Waiting for search result... (0) Group name is "GROUP5" rlm_ (ldap): Deleting connection (4) (0) User is not a member of specified group
Debug FTW!
<shrug> That seems definitive.
You LDAP design is way too complicated. The multiple LDAP directories and groups buried within groups makes it nearly impossible to create a working RADIUS system.
Maybe someone more familiar with LDAP magic can say more. But my $0.02 is to ensure that your database actually stores user data. All of it. In a sane format.
Even if you do fix the group membership issue, the repeated LDAP searches will DESTROY performance. You'll be lucky to get 10 authentications per second out of it.
Depends. If the child groups reference the parent in some way, it's only one extra search. But that only gets you one level of nesting. Anything beyond that gets insanely slow. Anyway it's not supported currently and I don't think it'd be a sensible thing to add support for. I think Phil mentioned something about a magic attribute you could search for in AD (with all those rebinds i'm guessing this is AD) which supported nested grouping. I started to look at adding it, and wrote most of the code, but didn't have time to finish it. If Phil can confirm that, that feature would help in this situation, I'll finish it off and merge the code. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
