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