Zentyal Forum, Linux Small Business Server
Zentyal Server => Installation and Upgrades => Topic started by: thorsten on January 01, 2013, 02:56:29 pm
-
Please help:
I had Zentyal 2.2 running perfectly but after an updgrade I do not manage Radius devices.
- Zentyal "Radius" Module is running
- Radius Certificate is active
- "CA" Module is running
- IP of server and client are set correctly
- Shared secret passwords are set to "test" for client and server
- Clients are activated
- A Zentyal group called "Radius" is created containing some Zentyal users
- The correct group is selected within the Radius module
- Module "Users and groups" is running
now I try e.g. to join my I-Pad using WPA-Radius authentification from my radius enable access point
The I-Pad receives the correct Zentyal certificate
- - from is i think that I set up client, server, IPs, shared secret, CA etc. correctly, otherwise the Radius client (my AP) would not be able to show the Zentyal Certificate to the AP-Client (My I-Pad)
Than my I-Pad asks for User name and Password -> Whatever I typ seems to be incorrect, the answer is "wrong User / Password" combination.
Please believe my - I even used the user "fooo" with the password "barr" ... It did not work.
What may I have missed???
Thx
Thorsten
-
bump
-
Older AP? You might need to put a port forward rule in redirecting port 1645 to port 1812. Are you sure that the certificate is coming all the way from Zentyal and not the AP? Watch /var/log/freeradius/radius.log while you are attempting to log in and watch for activity (eg tail -f /var/log/freeradius/radius.log)
-
Hi Half_life,
please find screen shots from my I-Pad and from my Zentyal CA: there is a perfect match of time stamp of the Certificate shown on my I-Pad and on the CA (Dez. 20th, 2022 / 00:28:33 +1h for Berlin vs. GMT, respectively). Yes, I am sure, the certificate is handled correctly. I am also sure that the user name "thorsten" and the password are typed correctly - at least once in a million times should have hit by accident 8)
Next idea: The AP is quite new and it worked perfectly on port 1812 with Zentyal 2.2 for about 12 month - I never had any issues on that. The problem is the same for any other Radius client I used before.
please find /var/log/freeradius/radius.log :
The IP 172.17.0.4. is correct (the AP) and the Mac Address matches my IPad, so I am sure, the connection is correct, too.
However, I do not know what port 0 means - I did not change and port settings, neither on the firewall (service Radius: any LAN to 1812 UDP) nor the radius client settings on the AP (Port 1812).
Best regards
Thorsten
Wed Jan 2 21:18:01 2013 : Info: Exiting normally.
Wed Jan 2 21:21:24 2013 : Info: Loaded virtual server inner-tunnel
Wed Jan 2 21:21:24 2013 : Info: Loaded virtual server <default>
Wed Jan 2 21:21:24 2013 : Info: Ready to process requests.
Thu Jan 3 22:52:20 2013 : Auth: Login incorrect: [thorsten] (from client 172.17.0.4/32 port 0 via TLS tunnel)
Thu Jan 3 22:52:20 2013 : Auth: Login incorrect: [thorsten] (from client 172.17.0.4/32 port 0 cli B8-F6-B1-EB-17-1B)
Thu Jan 3 22:52:41 2013 : Auth: Login incorrect: [thorsten] (from client 172.17.0.4/32 port 0 via TLS tunnel)
Thu Jan 3 22:52:41 2013 : Auth: Login incorrect: [thorsten] (from client 172.17.0.4/32 port 0 cli B8-F6-B1-EB-17-1B)
Thu Jan 3 22:52:48 2013 : Auth: Login incorrect: [thorsten] (from client 172.17.0.4/32 port 0 via TLS tunnel)
Thu Jan 3 22:52:48 2013 : Auth: Login incorrect: [thorsten] (from client 172.17.0.4/32 port 0 cli B8-F6-B1-EB-17-1B)
Thu Jan 3 22:53:01 2013 : Auth: Login incorrect: [thorsten] (from client 172.17.0.4/32 port 0 via TLS tunnel)
Thu Jan 3 22:53:01 2013 : Auth: Login incorrect: [thorsten] (from client 172.17.0.4/32 port 0 cli B8-F6-B1-EB-17-1B)
Thu Jan 3 22:53:09 2013 : Auth: Login incorrect: [thorsten] (from client 172.17.0.4/32 port 0 via TLS tunnel)
Thu Jan 3 22:53:09 2013 : Auth: Login incorrect: [thorsten] (from client 172.17.0.4/32 port 0 cli B8-F6-B1-EB-17-1B)
Thu Jan 3 22:53:39 2013 : Auth: Login incorrect: [thorsten] (from client 172.17.0.4/32 port 0 via TLS tunnel)
Thu Jan 3 22:53:39 2013 : Auth: Login incorrect: [thorsten] (from client 172.17.0.4/32 port 0 cli B8-F6-B1-EB-17-1B)
Thu Jan 3 22:56:03 2013 : Auth: Login incorrect: [thorsten] (from client 172.17.0.4/32 port 0 via TLS tunnel)
Thu Jan 3 22:56:03 2013 : Auth: Login incorrect: [thorsten] (from client 172.17.0.4/32 port 0 cli B8-F6-B1-EB-17-1B)
Thu Jan 3 22:56:10 2013 : Auth: Login incorrect: [thorsten] (from client 172.17.0.4/32 port 0 via TLS tunnel)
Thu Jan 3 22:56:10 2013 : Auth: Login incorrect: [thorsten] (from client 172.17.0.4/32 port 0 cli B8-F6-B1-EB-17-1B)
(http://dl.dropbox.com/u/42143374/Foto%2003.01.13%2022%2056%2000.png)
(http://dl.dropbox.com/u/42143374/Foto%2003.01.13%2022%2056%2014.png)
(http://dl.dropbox.com/u/42143374/2013-01-03-231040_1280x1024_scrot.png)
-
I am seeing similar things. On another linux machine install radtest (included in freeradius-utils). Add that machines IP address to the list of radius clients and add a shared secret. Radtest has a command line like this:
radtest username password radius_server_ip 0 shared_secret
I bet it will authenticate.
-
Here is what mine looks like with password logging turned on. First group is from the AP and second group is radtest on my workstation. There is definitely a problem in how this is getting parsed.
Thu Jan 3 22:54:56 2013 : Auth: Login incorrect: [dhoff/<via Auth-Type = EAP>] (from client 192.168.0.6/32 port 45 cli d857ef8e3e5d)
Thu Jan 3 22:55:02 2013 : Auth: Login incorrect: [dhoff/<via Auth-Type = EAP>] (from client 192.168.0.6/32 port 45 cli d857ef8e3e5d)
Thu Jan 3 22:55:28 2013 : Auth: Login OK: [dhoff/my_password] (from client 192.168.0.219/32 port 0)
Thu Jan 3 22:55:37 2013 : Auth: Login OK: [dhoff/my_password] (from client 192.168.0.219/32 port 0)
Thu Jan 3 22:55:39 2013 : Auth: Login OK: [dhoff/my_password] (from client 192.168.0.219/32 port 0)
-
I have opened ticket #5946 on this. In the meantime I will keep digging.
-
The client (in this case the iPad), needs to be configure to negotiate using EAP TTLS CHAP.
-
How can I set this up on the I-Pad - I thougt this will be done automatically as before with Zentyal 2.2.
-
Can you countercheck my other posting below - there is also an auth-error: http://forum.zentyal.org/index.php/topic,13598.0.html
-
I am having the same problem as thorsten. What is really weird is everything appears to be setup the same as on the 2.2 system. Looking into the radius.conf doesn't yield any differences either. I must confess a lack of experience troubleshooting radius problems. Anyone have an idea here?
-
Digging into this a little further, when using radtest and not specifying an authentication method it works fine. When specifying ms-chap as would come from my AP it fails. I have verified that it is not related to certificates by substituting a known good (from zentyal 2.2) set it still behaves the same. Re pointing the proxy.conf file to the ldap server on the 2.2 system results in good authentications even with ms-chap.
<EDIT> I stand corrected here. I neglected to use the right server when performing this test. It doesn't work as I said </EDIT>
My reading on the internet tells me that not all password hashes are created equal when dealing with EAP. Certain hash types can't be used with all authentication types see here http://deployingradius.com/documents/protocols/compatibility.html (http://deployingradius.com/documents/protocols/compatibility.html). I have narrowed this down to the authentication segment and it seems to be specific to the way the password is stored. I would like to have a developer or someone more knowledgeable than me prove or disprove it.
Anyone?
-
Update-
I changed all of the config files of freeradius on Zentyal 3 to point to the ldap server on my previous Zentyal 2.2 install. Now I can authenticate through the AP as expected. So in summary:
It has nothing to do with certificates (swapped from working system with no effect)
Using another ldap server makes the problem go away.
Using PAP authentication works with the Zentyal 3 ldap server.
The fact pattern brings me back to the password storage and how it is hashed as the likely suspect. The last test I can perform to confirm my beliefs is to :
create a test user.
change the password hash in ldap for that user to a type that is compatible with ms-chap and try it.
Thoughts?
BTW sorry for flailing around last night. At least I found my errors in testing and was able to correct my testing methods. I am sure of my results to this point.
-
Can't you see any clear error message or code in syslog if you increase LDAP log level.
Well, I don't know whether you have to increase log level for "std" or "Samba" LDAP, you may have to try both ???
-
I have stopped the radius server and restarted in debug mode (freeradius -X) . I am watching the process stream directly during testing. Another thought occured to me, looking in /etc/freeradius/modules under zentyal 3 the server= line uses a variable substitution. I am wondering if the variable is pointing to port 389 when it should be pointing to 390. I am learning as I go on this.
-
If you increase LDAP log level on both standard and Samba LDAP servers, you will easily see in syslog which one is requested from Radius server (I hope)
-
Christian, I am able to verify by the ldap info contained in /etc/modules/ldap that it is pointing at the one on 390. Using Apache Studio I can verify that the password is hashed with kerberos 5. Where does that leave me? I am certain from watching the radius server in debug mode that it correctly get through the authorization section but does not get through the authentication section. Jury rig things so that the radius server asks the old ldap server and everything works correctly. What, besides password could be the problem?
-
If LDAP authentication is wrong, you should see LDAP err 49 in syslog.
Again (sorry for being heavy on this point), increase LDAP log level so that you can check LDAP request and result and determine if error is due to LDAP, password or something else.
-
Where exactly would I make these adjustments at? I am convinced of my findings at this point but am willing to take direction if you can.
-
You have to change olcloglevel attribute from "0" to "256" in order to get verbose log.
this attribute is attached to cn=config entry.
Have a look here (http://forum.zentyal.org/index.php/topic,12730.msg52729.html#msg52729).
You can apply this change either using command line or LDAP graphic interface (which is more convenient). Apache Directory Studio is one of the various tools you may use.
Looking closely at LDAP content is not something expected for basic Zentyal user but it helps a lot especially during this "tuning & debugging" phase.
-
There is no CN=config
-
yes there is one ;) trust me 8)
the point is that you have to change your baseDN and point to cn=config instead of standard basedDN as displayed in Zentyal interface.
LDAP server hosts at least 2 root entries:
- one is cn=config (which contains LDAP config, name is quite self-explanatory)
- one is dc=yourdomain or something like this, containing your entries (accounts, groups ...)
-
I understood you Christian. I get an error when I try that (error 49 - invalid credentials) I have tried:
this is my Root cn=zentyal,dc=rapheal,dc=no-ip,dc=com and this works
my base is dc=rapheal,dc=no-ip,dc=com
my config should be cn=config,dc=rapheal,dc=no-ip,dc=com
in addition I tried cn=config,cn=zentyal,dc=rapheal,dc=no-ip,dc=com
Where is my mistake?
-
your base must be cn=config
no more nor less ;)
-
Hi Christian,
I do not understand some parts of the link on LDAP you quoted:
Have a look here (http://forum.zentyal.org/index.php/topic,12730.msg52729.html#msg52729).
ICHAT writes below, that the firewall may block port 390, but port 390 is blocked by default from Zentyal (clean installation). I did not change that and I remember that it was also blocked within Zentyal 2.2.
Additonally, where do I need to change CN=config, which is the path / file?
Another stupid question: for me, proxy and SSO (Zarafa) is blocked, but the computer is domain member and a valid user is logged on: It does request a password I can not satisfy. Same / Similar for Proxy: Zentyal simply blockes everything.
THX
Thorsten
-
your base must be cn=config
no more nor less ;)
Sorry, no dice. Same error.
-
from command line (on Zentyal server, SSH e.g. ;) ), try something like this:
ldapsearch -h localhost -p 390 -b 'cn=config' -x -D cn=ebox,dc=yourhost,dc=yourdomain -w ebox_passwordand let us know what you see.
On my 2.2 Zentyal server, it works (on port 389)
-
Same result. I tried a few variations just to make sure.
-
:o :o
I curently don't have time to restart and test with Zentyal 3.0 but I'm very very surprised you don't find cn=config entry.
This one is mandatory.
When you report "same result", what is this result ?
- no such object (error code 32) or something else?
-
christian, you aren't the only one with limits to their time. I think we have beaten this horse long enough trying to deny that there is an issue with radius/ldap.
ldap_bind: Invalid credentials (49)
-
However this is (was) surprising that you can't access cn=config.
Clearer now: your credential is either wrong or not accepted.
With Zentyal 3.0, DN (D parameter in ldapsearch command) to be used looks like:
cn=zentyal,dc=yourdomain,dc=com, local or whatever you named it
-
But christian, the same password works when viewing the root dn so it is not the password portion of the credentials. It therefore must be the supplied ldap database string ( I am not sure of the nomenclature here). I personally am satisfied that there is an error in the way radius is being handled in 3.0. I have a high confidence that it is authentication not authorization related based on watching the requests be processed by radius. My reading gives me indications that how the password is hashed matters depending on which authentication mechanism you use. I think it is high time a developer steps in and either says "you are full of it and here's why" or "oops, we will address that" . As I said earlier in the thread, I could create a dummy user and manually change their password hash in ldap to prove my point.
-
Half_Life,
sorry for being penetrant would you mind to install proxy service or Zarafa SSO on the system you are in trouble with radius: please countercheck if both do work if the client is within the correspondend domain.
THX
Thorsten
-
Proxy SSO has been discussed at length as problematic, though it seems that the developers were able to get it to work. For example, see this rather lengthy discussion:
http://forum.zentyal.org/index.php/topic,12010.0.html
Since I don't use Zarafa, I don't know if there is a common issue with proxy SSO or not.
-
Hi Sam,
Thanks, but I think that those two problems are linked together somehow - this is just instinct, and not related to any knowledge or facts.
Also there was no solution in that threat :o
THX
Thorsten
-
Also there was no solution in that threat :o
Right, although the developers said they could eventually confirm it to be working. I didn't get it working and put the effort off for another time. In my case the test client machine wasn't fetching time sync from Zentyal so I can't say I exhausted all the possibilites. I just had to move on to other things. :(
-
Hi Sam,
do you have any contact to the developers? I hope it helps if they see that someone else has the same problem. I sometimes fear that lots of problems are related to 64 bit while 32 bit is more relieable. Also, if I change to standard hardward, some problems do not even appear I have on my server hardware. But this is really strange as my server software runs on "real" server hardware - at least this specially dedicated hardware I expect an error free installation, but it is not
Best regards
Thorsten
-
Hi Thorsten,
I don't have contact with the developers outside the usual channels--here, the bug tracker, IRC. But I think the developers are aware that problems exist and I think it's correct to say that they've been working on it. My sense is that integrating Samba 4 into Zentyal has created problems that are non-trivial to solve, at least within the 3.0 architecture.
Since I don't have any spare 64-bit server hardware all my 3.0 testing has been on a spare 32-bit server. In the early days I even ran eBox on standard PC desktop hardware in production, and later Zentyal on both 32-bit and 64-bit server hardware from a variety of vendors (whitebox, Dell, Cisco). I say all that just to say that I've never encountered anything like you describe despite running eBox and Zentyal on those different types of hardware. For me the software generally seems hardware agnostic. Maybe it's the relatively simple setups I've deployed that spared me difficulties.
-
Sam,
+1
I've also installed Zentyal on both 32 and 64 bits platform and never faced any difference. I do understand that some glitches may occur but very few due to architecture. The main current issue is around Samba 4 integration for sure. This one is a technical one. Once solved, Zentyal team will face another one that is to decide where they want to go and what is the right design for this.
Do they want to target Microsoft SMB landscape and therefore rely on Samba 4 strategy, thus drop their own LDAP server and follow Samba 4 roadmap or do they target something else, better integrated to medium to large businesses, also meaning capability to interact with orher - external - repositories.
for the time being, I'm fine with 2.2 ;)
-
For me, the radius issue will stop me from rolling 3.0 into production. Everything that I use has worked. Next week I have a deadline to meet for a coding project so I won't be doing any science projects at work. The home system is currently on 3.0 with radius frankensteined to use the 2.2 ldap server. Small scale I can afford to maintain 2 password databases. I don't want to do this in a larger environment.
@thorsten - I will get to this but understand I don't use those features normally at home so there is no "apples to apples" comparison.
-
Christian, are you ready to pick up the lesson now that the lowly student has found his error :D? A lack of understanding of ApacheStudio configuration and probably a typo when we went to the command line led me astray. I can get into the cn=config directory now.
-
So, you can read and modify cn=config. Very good because this is (one of) the way to modify loglevel and investigate this Radius/LDAP potential error.
-
This is a good authenticate:
Feb 8 22:08:43 zentyal3 slapd[5856]: conn=91460 op=48 SRCH base="" scope=0 deref=2 filter="(cn=*)"
Feb 8 22:08:43 zentyal3 slapd[5856]: conn=91460 op=48 SEARCH RESULT tag=101 err=0 nentries=0 text=
Feb 8 22:08:43 zentyal3 slapd[5856]: conn=91460 op=49 SRCH base="dc=rapheal,dc=no-ip,dc=com" scope=2 deref=2 filter="(objectClass=posixAccount)"
Feb 8 22:08:43 zentyal3 slapd[5856]: conn=91460 op=49 SEARCH RESULT tag=101 err=0 nentries=11 text=
Feb 8 22:08:43 zentyal3 slapd[5856]: conn=91460 op=50 SRCH base="" scope=0 deref=2 filter="(cn=*)"
Feb 8 22:08:43 zentyal3 slapd[5856]: conn=91460 op=50 SEARCH RESULT tag=101 err=0 nentries=0 text=
Feb 8 22:08:43 zentyal3 slapd[5856]: conn=91460 op=51 SRCH base="dc=rapheal,dc=no-ip,dc=com" scope=2 deref=2 filter="(objectClass=zentyalGroup)"
Feb 8 22:08:43 zentyal3 slapd[5856]: conn=91460 op=51 SEARCH RESULT tag=101 err=0 nentries=7 text=
This is a bad one:
1:41:22 zentyal3 slapd[5856]: conn=91371 op=14 SRCH base="cn=Wireless,ou=Groups,dc=rapheal,dc=no-ip,dc=com" scope=0 deref=0 filter="(cn=wireless)"
Feb 8 21:41:22 zentyal3 slapd[5856]: conn=91371 op=14 SRCH attr=dn
Feb 8 21:41:22 zentyal3 slapd[5856]: conn=91371 op=14 SEARCH RESULT tag=101 err=0 nentries=1 text=
Feb 8 21:41:22 zentyal3 slapd[5856]: conn=91371 op=15 SRCH base="dc=rapheal,dc=no-ip,dc=com" scope=2 deref=0 filter="(uid=dhoff)"
Feb 8 21:41:22 zentyal3 slapd[5856]: conn=91371 op=15 SRCH attr=radiusNASIpAddress radiusExpiration acctFlags userPassword dBCSPwd sambaNtPassword sambaLmPassword ntPassword lmPassword radiusCallingStationId radiusCalledStationId radiusSimultaneousUse radiusAuthType radiusCheckItem radiusTunnelPrivateGroupId radiusTunnelMediumType radiusTunnelType radiusReplyMessage radiusLoginLATPort radiusPortLimit radiusFramedAppleTalkZone radiusFramedAppleTalkNetwork radiusFramedAppleTalkLink radiusLoginLATGroup radiusLoginLATNode radiusLoginLATService radiusTerminationAction radiusIdleTimeout radiusSessionTimeout radiusClass radiusFramedIPXNetwork radiusCallbackId radiusCallbackNumber radiusLoginTCPPort radiusLoginService radiusLoginIPHost radiusFramedCompression radiusFramedMTU radiusFilterId radiusFramedRouting radiusFramedRoute radiusFramedIPNetmask radiusFramedIPAddress radiusFramedProtocol radiusServiceType radiusReplyItem sasdefaultloginsequence
Feb 8 21:41:22 zentyal3 slapd[5856]: conn=91371 op=15 SEARCH RESULT tag=101 err=0 nentries=1 text=
Feb 8 21:41:22 zentyal3 slapd[5856]: conn=91371 op=16 SRCH base="dc=rapheal,dc=no-ip,dc=com" scope=2 deref=0 filter="(uid=dhoff)"
Feb 8 21:41:22 zentyal3 slapd[5856]: conn=91371 op=16 SRCH attr=dn
Feb 8 21:41:22 zentyal3 slapd[5856]: conn=91371 op=16 SEARCH RESULT tag=101 err=0 nentries=1 text=
Feb 8 21:41:22 zentyal3 slapd[5856]: conn=91371 op=17 SRCH base="dc=rapheal,dc=no-ip,dc=com" scope=2 deref=0 filter="(&(cn=wireless)(&(objectClass=posixGroup)(?member=dhoff)))"
Feb 8 21:41:22 zentyal3 slapd[5856]: conn=91371 op=17 SRCH attr=dn
Feb 8 21:41:22 zentyal3 slapd[5856]: conn=91371 op=17 SEARCH RESULT tag=101 err=0 nentries=0 text=
Feb 8 21:41:22 zentyal3 slapd[5856]: conn=91371 op=18 SRCH base="uid=dhoff,ou=Users,dc=rapheal,dc=no-ip,dc=com" scope=0 deref=0 filter="(objectClass=*)"
Feb 8 21:41:22 zentyal3 slapd[5856]: conn=91371 op=18 SRCH attr=memberOf
Feb 8 21:41:22 zentyal3 slapd[5856]: conn=91371 op=18 SEARCH RESULT tag=101 err=0 nentries=1 text=
Feb 8 21:41:22 zentyal3 slapd[5856]: conn=91371 op=19 SRCH base="cn=Wireless,ou=Groups,dc=rapheal,dc=no-ip,dc=com" scope=0 deref=0 filter="(cn=wireless)"
Feb 8 21:41:22 zentyal3 slapd[5856]: conn=91371 op=19 SRCH attr=dn
Feb 8 21:41:22 zentyal3 slapd[5856]: conn=91371 op=19 SEARCH RESULT tag=101 err=0 nentries=1 text=
Oh guru of the ldap what say you?
-
Real gurus stay quite and silent :P
Joke aside, these log extracts tell us very few.
Let me translate it, having in mind that both are only extract, thus you have a truncated view ;) although my post will be a long one
the "good" authentication:
- step 48: to me a very strange one :o client searches RootDSE (because base="") for entry matching (cn=*)
none is found but this is expected because there is no such entry in RootDSE. We can elaborate on this later.
- step 49: search for all entries in dc=rapheal.... being "posixaccount". 11 are found
- step 50: again this strange RootDSE search ::)
- step 51: search for entries being "zentyalgroup": 7 are found
That's it... is it enough to correlate with "good authentication" ? I don't think so, let's see the "wrong authentication" ;)
- step 14: search for cn=wireless within cn=wireless,ou=groups,dc=rapheal... and retrieve "dn".
to me this is another very strange sequence: as rdn IS cn=wireless, result of such search MUST return entry used as search base, therefore this is, to me again, totally useless. Anyway...
- step 15: standard search command ;) (all entries matching "uid=dhoff"). Expected result is "1" and indeed there is one and only one found ;D so far so good but here again I would like to spend hours discussing what is retrieved once entry is found. Retrieve radius related attributes is perfectly fine. Retrieving password related attributes is not acceptable. If such password can be retrieved using LDAP command (mean read) then you are exposed to brute force attack. look at this search. It retrieves "userpassword" (std LDAP password), dbcspwd (account's LAN manager pwd), "sambaNtPassword", "sambaLmPassword", "ntPassword", "lmPassword". I really wonder why ???
- step 16: same as step 15, retrieving only DN, goal being to point to this (found) entry.
- step 17: I've to admit that I don't understand this search syntax :-[ Reason is that I don't know about the "?" logical operator in this search filter:
filter="(&(cn=wireless)(&(objectClass=posixGroup)(?member=dhoff)))"
it looks like searching for posixgroup entries (here thus "group") called wireless (cn=wireless) and having dhoff as member but (?member=...) as far as I know, is not described in any LDAP related RFC. Something specific to OpenLDAP ? I doubt...
anyway, as expected, not such entry is found :)
- step 18: search uid=dhoff entry in order to retrieve groups this entry is member of. no special comment here
- step 19: 100% similar to step 14. To me, meaning less
is it enough to state that authentication fails ? For sure no but this shows some "interesting" (somehow) behaviour.
Does it help ? I doubt :-[
I would like Zentyal team to comment on the "?" within the search filter however ;)
-
I could make the whole record available if you really want it. I have a stripped out copy (grep slapd syslog >test.res) but it is quite large.
The ? operand that you spend time talking about is in the authorization segment as best I can tell (wireless group) and I had already observed that authorization was working via Radius. It was authentication that was failing.
-
Log extract sent via email. There is some clutter in it still due to Samba chatter.
-
Received. Already investigating ;)
-
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))) :o none is found :D
- 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 8) 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 :o none are found
- search for all entries matching "obkectclass=zentyalgroup" 7 are found
- search for entry containing any "cn" attribute in RootDSE :o 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.
-
Here is what came back
#!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.
-
hummm, port is supposed to be 390 isn't it?
-
any news?
Several updates were performed, but no one solved the problem so far.
Best regards
Thorsten
-
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.
-
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
-
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.
-
Hi Half_Life,
do you remember the thread solving the radius issue?
Thanks
Thorsten
-
Try here http://forum.zentyal.org/index.php/topic,12863.0/topicseen.html (http://forum.zentyal.org/index.php/topic,12863.0/topicseen.html)
-
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
-
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.
-
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.