Radius - Where is my error

[half_life]

Log extract sent via email.  There is some clutter in it still due to Samba chatter.

[christian]

Received. Already investigating 

[christian]

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.

 

[half_life]

Here is what came back

Code: [Select]

#!CONNECTION ldap://192.168.0.8:389
#!DATE 2013-02-10T10:21:51.702
# LDAP URL     : ldap://192.168.0.8:389/dc=rapheal2,dc=localnet,dc=zone?objectClass??(&(cn=wireless)(objectClass=posixGroup)(member=dhoff))
# command line : ldapsearch -H ldap://192.168.0.8:389 -x -D "cn=ebox,dc=rapheal2,dc=localnet,dc=zone" -W -b "dc=rapheal2,dc=localnet,dc=zone" -s base -a always "(&(cn=wireless)(objectClass=posixGroup)(member=dhoff))" "objectClass"
# baseObject   : dc=rapheal2,dc=localnet,dc=zone
# scope        : baseObject (0)
# derefAliases : derefAlways (3)
# sizeLimit    : 0
# timeLimit    : 0
# typesOnly    : False
# filter       : (&(cn=wireless)(objectClass=posixGroup)(member=dhoff))
# attributes   : objectClass

#!SEARCH RESULT DONE (20) OK
#!CONNECTION ldap://192.168.0.8:389
#!DATE 2013-02-10T10:21:51.702
# numEntries : 0
For extra credit I re-inserted the question mark.  It pitched an error in Apachestudio.

[christian]

hummm, port is supposed to be 390 isn't it?

[thorsten]

any news?

Several updates were performed, but no one solved the problem so far.

Best regards
Thorsten

[christian]

1 -did you change LDAP port for 390 ?
2 - I was expecting Zentyal team to react to my comments but I suppose these are meaningless as there is no feedback from Zentyal.

[thorsten]

Hi Christian,

as you can see here, I was using 390 for LDAP requests of several services :-)
http://forum.zentyal.org/index.php/topic,14138.0.html

But I did not change anything within the Radiusd.conf for three reasons:

1.) I did not find anything helpful, e.g. the port - the configurtion structure behind Zentyal Radius is much more complex compared to a single radius installation.
2.) It will be overwritten from the .mas file after next alteration within the Zentyal administration interface (and I do not dare to change the .mas itself)
3.) There is no port setting for LDAP in the Radius config module ;-), see point 1 and 2 ...

The 5946 by half_life assigned to "mburillo" from Zentyal staff

Best regards
Thorsten

[half_life]

I also am waiting for some info from development on my ticket.  As Thorsten pointed out,  it was accepted awhile ago.  Several other people have reported similar problems in the forum.  There is one person that edited the configs by hand and got it working but I haven't had time to look into it.

[thorsten]

Hi Half_Life,

do you remember the thread solving the radius issue?

Thanks
Thorsten

[half_life]

Try here   http://forum.zentyal.org/index.php/topic,12863.0/topicseen.html

[thorsten]

Hi,

that worked - so the solution is deserved on a silver plate. It was really that simple making it too ununderstandable to me: Just remove a simple character "#" from a file and everything works - I have seen that ticket 5946 is the only task assigned to that Zentyal programmer - he seems to be a very bussy man...

Best regards
Thorsten

[half_life]

I finally had a chance tonight to look into it.  It worked nicely here as well.  I can finally turn off the 2.2 VM.

[shariqkhan1]

I finally had a chance tonight to look into it.  It worked nicely here as well.  I can finally turn off the 2.2 VM.

How did you manage to get it to work. I have removed the # and i still have no success.