No good news after having spent time looking at your log file.
Here is what I can highlight but I don't have any correlation yet.
at 21:41:22, conn=91371 will perform 4 times same LDAP request (let's call it req-A) in a raw.
at 21:41:30, same conn=91371 performs again 4 times req-A
Then matching these two steps, you have:
at 21:42:14, 5 connections (from conn=91372 to conn=91376) performing req-B
at 21:43:14, again 5 connections (from conn=91377 to conn=91382) performing same req-B
starting at 22:02:41, conn=91460 performs every 30 seconds, same request (req-C) till you changed back loglevel.
So what are req-A, req-B and req-C
req-A:- search for any entry matching uid=dhoff. 1 is found dn is read
- search for any entry matching (&(cn=wireless)(&(objectclass=posixgroup)(?member=dhoff)))
none is found
- search for groups dhoff belongs to (looking at memberof attribute) 1 is found
- search if entry=cn=wireless... contains cn=wireless attribute
1 is found
- search for any entry matching uid=dhoff 1 is found radius
and password
related attributes are read
req-B:- simple and successful LDAPBIND for uid=dhoff
req-C:- search for all entries matching "objectclass=posixaccount" 11 are found
- search for entry containing any "cn" attribute in RootDSE
none are found
- search for all entries matching "obkectclass=zentyalgroup" 7 are found
- search for entry containing any "cn" attribute in RootDSE
none are found
based on this, I can't make any conclusion but only comments.
- I suppose req-B is linked to req-A: for the first raw of 4 req-A, we have 5 req-B in a raw then again 5 req-B for the second req-A sequence.
- req-B is LDAPBIND, thus (successful) authentication.
- I don't thin req-C is Radius related but this one is very strange, reason why I describe it here.
- To me, authorization can't work because of the strange LDAP filter with unknown operator I already commented.
One more LDAP related comment, just for the "fun":
- this strange (I really refrain myself to write "stupid") ldap filter made of "(&(cn=wireless)(&(objectClass=posixGroup)(?member=dhoff)))" could (should) be written
"(&(cn=wireless)(objectClass=posixGroup)(?member=dhoff))" (except if "?" as a special meaning) because:
(&(something)(&(something)(something)))
is same as:
(&(something)(something)(something))
BTW, may I suggest you manually run ldapsearch based on:
(&(cn=wireless)(objectClass=posixGroup)(member=dhoff))
(notice I removed the quesiton mark) and let us know the result.
As a matter of conclusion, we are currently performing some kind of reverse engineering while it would be much easier if Zentyal staff could jump in and comment or help.