Zentyal Forum, Linux Small Business Server
Zentyal Server => Installation and Upgrades => Topic started by: astana on February 15, 2013, 06:50:16 am
-
I'm using Zentyal 3 server as an AD and proxy/filtering (non transparent proxy) in a school environment.
I've set up different profiles for the different groups in the school (students/teachers/admin/IT) which was working perfectly with only a few users added.
However once all the students were added and the domain was rolled out to the entire school I found some students were denied all access to the internet.
As a temporary measure I changed the filtering to route all users through the student filter.
All users were verified as being in the correct group.
I am assuming that there were too many users in a group and the user list was being truncated (all student users are indetified with the same preceding letters and a number ID), thus some users not appearing to be in a group and therefore not being allowed access.
So far I've not managed to find in the documentation any reference to maximum numbers, and I am not sure if Zentyal generates the ACL the users in a group, or if squid understands the groups.
I'd be interested if anyone else has seen something similar or can enlighten me about this.
When I'm next at work I'm going to create sub groups for the students (10 or so students in each group) as a work around. This isn't ideal as each group will need the same web sites white/black listed.
I don't have exact numbers of students, but it's around 100ish.
Thanks for any replies.
-
All users were verified as being in the correct group.
I am assuming that there were too many users in a group and the user list was being truncated (all student users are indetified with the same preceding letters and a number ID), thus some users not appearing to be in a group and therefore not being allowed access.
I've to admit that I don't understand this sentence :-[
Could you please rephrase it for non native English ? ;D ;D
From an LDAP standpoint, there is no limitation (I mean in term of number of users per group) however, one can still execute ldapsearch restricting amount of "returned" entries.
Perhaps it's worth to increase LDAP log level and have a look ?
-
All users were verified as being in the correct group.
I am assuming that there were too many users in a group and the user list was being truncated (all student users are indetified with the same preceding letters and a number ID), thus some users not appearing to be in a group and therefore not being allowed access.
I've to admit that I don't understand this sentence :-[
Could you please rephrase it for non native English ? ;D ;D
From an LDAP standpoint, there is no limitation (I mean in term of number of users per group) however, one can still execute ldapsearch restricting amount of "returned" entries.
Perhaps it's worth to increase LDAP log level and have a look ?
Sorry for being obscure, I'm not in front of the server, and might be confusing terms :-\
The problem isn't with LDAP, all the users are accounted for and present. They can log onto the domain correctly.
The problem lies with the authentication with the proxy server (non-transparent).
The symptom of the problem was some users in one user group getting no access to the internet, even though their group did have access.
So my theory (pure speculation based on lots of experience in programming/computers in general, and little in squid/kerberos) was that Zentyal was generating an ACL of all the users in a group that then gets processed by squid.
I couldn't really run too many tests as the students needed access to the internet.
So really the question(s) could be formed as: Does Zentyal generate a list of all users in a group that then gets passed to squid, or does squid understand user groups?
Does squid have a limit on the number of characters in an ACL?
Thanks for the reply btw :D
-
Squid definitely understands LDAP and LDAP group membership and this should not come with any limitation in term of members (I did it some years ago with groups containing thousands of members).
This said, Zentyal's implementation stacks Squid and Dansguardian with which I'm less comfortable.
What would be interesting is a better view of "how these students are denied to access internet".
- What is the "error" or rather blocking message ?
- are you using kerberos authentication ?
- did you try to authenticate users but not apply any filtering policy (except than requiring authentication)
-
Squid definitely understands LDAP and LDAP group membership and this should not come with any limitation in term of members (I did it some years ago with groups containing thousands of members).
This said, Zentyal's implementation stacks Squid and Dansguardian with which I'm less comfortable.
What would be interesting is a better view of "how these students are denied to access internet".
- What is the "error" or rather blocking message ? No error, it was blocking (from memory) the message was access denied, the same error as if the user was in a group without any rule and specific group rules were created.
- are you using kerberos authentication ? Yes
- did you try to authenticate users but not apply any filtering policy (except than requiring authentication) This is sort of how it is now, except I need to apply filtering (live school environment).
Answers in red
Before the change (in a simple form) I had 2 filter properties, Teachers and Students.
I also had 2 filter groups, sending Teachers to the Teacher property and Student to the student property.
The way the configuration works it seems that once this is setup you cannot have a 'catch all' group with everyone in, so if for example I only had those 2 groups but a person from 'admin' group tried to access the internet they would be denied.
What I was seeing is certain students were being denied as if they didn't belong to the student group.
I need to have a filtering rule in place, otherwise the school would have unfettered internet access, something I'm not really allowed to do.
Also, another interesting part of the story. Before seeing lots of students unable to access the internet I had one student visit me saying his internet was not working. After verifying *everything*, recreating his account, changing his group to teacher (none of it worked), I created a new user for him, except instead of using the standard student username (3 letters then 5 digit number) I created it with firstname-lastname. Very strangely this worked correctly...
Hope this helps explain!
-
you are perhaps finger pointing something interesting... but I can't help that much with this as my 3.0 plat-form is currently not running.
Zentyal group membership is based on groupuid and not groupofuniquename, which means that members are identified within groups using their [uid] and not their [DN]. RDN in (Zentyal) LDAP is [uid]. Correlated to this, because of AD constraint, RDN in Samba LDAP is [CN]
I don't really know how synchronization between these 2 LDAP servers works but I suppose UID from Zentyal LDAP synchronizes with CN in Samba LDAP. What's about [Samaccountname] and which one is used by Kerberos... (BTW which one Kerberos as 2 kerberos servers exist in parallel)
Because of this unclear understanding, I can't help but would definitely like to investigate this further.
You are perhaps on the right track. I'll have a look in case I restart my 3.0 platform.
-
you are perhaps finger pointing something interesting... but I can't help that much with this as my 3.0 plat-form is currently not running.
Zentyal group membership is based on groupuid and not groupofuniquename, which means that members are identified within groups using their [uid] and not their [DN]. RDN in (Zentyal) LDAP is [uid]. Correlated to this, because of AD constraint, RDN in Samba LDAP is [CN]
I don't really know how synchronization between these 2 LDAP servers works but I suppose UID from Zentyal LDAP synchronizes with CN in Samba LDAP. What's about [Samaccountname] and which one is used by Kerberos... (BTW which one Kerberos as 2 kerberos servers exist in parallel)
Because of this unclear understanding, I can't help but would definitely like to investigate this further.
You are perhaps on the right track. I'll have a look in case I restart my 3.0 platform.
Not quite sure what all the abbrivations are, but I'm assuming [DN] is Display Name, which I take to be the username that one would log on with.
It seems you're saying there are 2 LDAP/Kerberos services running on a standard Zentyal 3 Server install, and they sync the relevant information between themselves using different data fields representing the user (UID->User Name)?
So that path would be host pc->http request->squid->Kerberos authentication (Which Kerberos?)->DansGuardian with a failure at the authentication phase.
Thanks again for your time replying.
-
Sorry for this acronym. I do not pay enough attention when using it.
DN stands for distinguish name. This is how LDAP uniquely identifies entries, using DIT (Directory Information Tree) and RDN (Relative Distinguish Name) so that each entriy is unique within the branch it's attached to.
For what concerns path and links between Squid, Kerberos(s) and LDAP(s), I can't comment and don't want to perform any reverse engineering. I hope Zentyal will some time issue useful documentation ;)
-
Now that I'm at work I've had a quick peek at the logs and I'm quite surpised by what I see, it may be normal or it might point to more useful information.
I looked for denied in the http proxy log under Zentyal Logs (I did check the raw log files they're not so easy to decipher)
here's one example:
2013-02-12 14:34:03 192.168.1.131 ABC20873@ABC-ASTANA.LAN http://www.google.com/favicon.ico google.com 23370 text/html Denied
Some names renamed for privacy purposes.
So here the user is recognised but denied (there were no rules to deny google.com)
But looking at ones that were accepted has no user listed, even those tests have shown that unknown users were blocked from access!
Even the most recent logs show either no user or show the local IP address, but access is permitted.
If you have any outputs or configuration requests, please let me know. I'll be able to post them on Thursday.
-
Hello Astana,
how many users do you have in the group?.
also which kind of policy is applied, allow, deny or filter?
-
Hello Astana,
how many users do you have in the group?.
also which kind of policy is applied, allow, deny or filter?
There are 4 user groups at the moment (approx numbers in brackets),
Admin (5),IT(2),Teachers(30) and Students(100)
Originally I had filters for each group, all were filter but with different permissiveness levels set.
Setup was fine until I saw students getting access denied for an unknown reason, so reduced policy to everyone->student.
Log output was from the time different policies were in place.
-
I just checked with a group with 200 users without problems.
- Have you experienced the issue yourself?.
- If not, you know what user names where affected. In that case please, note them down. We can check with a small group containing only those user names
- Finally, you know which browser used the denied users?
-
I'm not quite sure what you mean by experienced the issue myself, so will reply to possible interpretations.
My account was not affected (as domain admin and it group).
I saw the student accounts affected 1st hand.
I tried to resolve one student account (as detailed in an earlier post) and the only solution was to use their name rather than the code that all students are using.
We use 3 different browsers, Frontmotion build of FireFox, Chrome and IE. All browsers were being denied access.
I don't have access to all the blocked names, but will post that tomorrow when I am at work.
I would prefer not to list the 1st 3 letters for privacy reasons, but can PM them to you so you can complete the names.
-
Yes, by first hand i meant if you have seen yourself.
As for the user names I am looking for some uncommon character, length or something that could cause trouble
-
usernames are 3 letters followed by a 5 digit number e.g. ABC20043, there are around 100 of them, I'll post more details when I have them.
-
1 - Based on what astana wrote in the first posts, what you call "user name" (what I call "login") is made of TLA (three letters acronym) + number ID. Thus we should not have any special character.
2 - If my guess is correct, problem occurs only with HTTP and proxy authorization (authentication works)
3 - So far, there is nothing to confirm that HTTP proxy implementation is based on Kerberos. I would like astana to tell us ;)
4 - I would suggest to perform simple LDAP search to verify that account for which access to internet is denied does belong to group granted for such access (search for (&(groupname=whatever)(memberuid=failinguid))
-
1 - Based on what astana wrote in the first posts, what you call "user name" (what I call "login") is made of TLA (three letters acronym) + number ID. Thus we should not have any special character.
2 - If my guess is correct, problem occurs only with HTTP and proxy authorization (authentication works)
3 - So far, there is nothing to confirm that HTTP proxy implementation is based on Kerberos. I would like astana to tell us ;)
4 - I would suggest to perform simple LDAP search to verify that account for which access to internet is denied does belong to group granted for such access (search for (&(groupname=whatever)(memberuid=failinguid))
1. Correct
2. No comment yet as I still can not confirm problem
3. I can only assume this is the case, in the Zentyal HTTP Proxy General Tab Enable Single Sign-On (Kerberos) is checked, and when different groups were active, the user group was taken into account.
4. I have tried getting ldapsearch to work, but so far am only getting errors about mech missing or authenication problems. I really am no expert on this and failed :(
Edit: Error message is : ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
additional info: SASL(-4): no mechanism available: No worthy mechs found
Also it looks like the logs have gone at least from the Zentyal interface, I will check the logs dir and see if they are still there.
-
asatana,
If you mean LDAP log, be aware that unless you change "olcloglevel" attribute in order to increase log level, almost nothing will be stored in syslog.
You also have to know that because 2 ldap servers run in parallel, deciding which one you request in order to investigate and debug does matter.
I'm not always 100% sure myself about which one is used by which component due to lack of technical documentation from Zentyal but I believe that except for Samba (file sharing and other Windows domain related stuff), LDAP server to check listen on port 390.
Still for Kerberos this is a bit confusing :-[
Anyway, I would thus suggest that you perform search requesting port 390. account to be used here is the one shown in Zentyal admin interface if you want to get ldap admin rights.
How do you intend to search LDAP ? Using command line or using graphic interface ?
Given error you show, I suppose you were using command line.
Error is due to use of SASL because you did not look at LDAP syntax (look at -W option ;))
Using command line, you could try something like:
ldapsearch -h [zentyal IP] -p 390 -xLLL -b "[your baseDN]" -s sub "(&(cn=students)(memberuid=ABC12345))"
ABC12345 being one of the failing student's account
EDIT: added port (390)
-
I get the error: No such object (32)
When modifying the command you gave.
As the IP address I put both the network IP address as well as local host.
for base DN I entered "dc=abc-astana,dc=lan"
And for the user I entered a real user login name.
-
localhost will work only if you run this from Zentyal server itself, obviously ;)
in such case, 127.0.0.1 is fine too
Your search fails because baseDN is most likely not "dc=abc-astana,dc=lan".
Please confirm looking at LDAP settings.
... or my search filter is wrong. I didn't check closely but wrote it quickly. I'll do it to.
To determine if search filter is wrong or if you're wrong elsewhere (like naseDN), you can replace this filter with "objectclass=*" 8)
-
from Users and Groups -> LDAP Settings: TLA Changed as usual
Base DN: dc=abc-astana,dc=lan
edit, and yes was running the query from the server :)
-
So I suppose my search filter is wrong :-[
Please check using "objectclass=*"
given what you described, you should get plenty of entries
-
you mean executing this line?
ldapsearch -h 127.0.0.1 -p 390 -xLLL -b "dc=abc-astana,dc=lan" -s sub "(&(objectclass=*))"
Still returns No such object (32)
-
Sorry, I meant:
ldapsearch -h 127.0.0.1 -p 390 -xLLL -b "dc=abc-astana,dc=lan" -s sub "objectclass=*"
-
hate to disappoint, but that also gives the same error :/
-
No disappointment at least on my side ;D
I'm just wondering why you can't access this LDAP server.
I perhaps made wrong assumptions and should restart my 3.0 test platform and check twice.
Access to LDAP, at least RootDSE, is supposed to be granted to anonymous connection.
Standard configuration should also allow anonymous access to root entry (i.e. baseDN) because this is how standard LDAP authentication is supposed to work.
I don't remember whenever Zentyal followed this or not with 3.0 :-[
"objectclass=*" is the most basic search filter. I do not expect any error here ;)
So what could be wrong ?
- ldap port ? (are you really running Zentyal 3.0 with standard LDAP settings ?)
- baseDN ? you already checked this...
I'll come back to you once my 3.0 platform is running again
-
I can only assume I'm running with the standard settings. I installed the server with all the default options, and in my almost complete ignorance changed as little as possible!
Also, I had little need to change anything as everything fell into place and worked out of the box (except a few niggles we're on at the moment).
I'll not back back to work til next Tuesday...I really need to set up remote access to the server...
-
OK, I got the answer >:( >:( >:(
As I wrote in my previous post, reasons for not being able to access LDAP with such ldap filter are very few.
One is that one can't get anonymous access :o
anonymously, you can only get access to RootDSE.
Solution is to connect using root DN (something like "cn=zentyal,dc=abc-astana,dc=lan") with password you will find in LDAP settings instead of anonymous access.
This is definitely one more reason, at least for me, to not move toward 3.0 >:( >:( >:(
-
Ok, I've put back the 'bad' configuration as school hours are over and found a bad user that has no internet connection.
I made this the only user in the group (per squid.conf) and restarted the service. There was no change.
squid access.log
361443273.701 250 192.168.1.47 TCP_DENIED/403 25777 CONNECT urs.microsoft.com:443 ABC16475@ABC-ASTANA.LAN NONE/- text/html
1361443273.701 249 192.168.1.47 TCP_DENIED/403 25775 CONNECT urs.microsoft.com:443 ABCI16475@ABC-ASTANA.LAN NONE/- text/html
I also placed the user on their own line as follows:
acl grp~students proxy_auth abc16475@QSI-ASTANA.LAN
snipped from just after:
http_access allow grp~students fltr5~df~dmn17
http_access allow grp~students fltr5~df~dmn16
http_access deny grp~students fltr5~df~dmn15
http_access allow grp~students fltr5~df~dmn14
http_access allow grp~students fltr5~df~dmn13
http_access allow grp~students fltr5~df~dmn12
http_access allow grp~students fltr5~df~dmn11
http_access allow grp~students fltr5~df~dmn10
http_access allow grp~students fltr5~df~dmn9
http_access allow grp~students
Maybe of interest, dansguardian log does not register this deny.
edit: moving this user to a different acl group also changes nothing.
2nd edit:
This from syslog:
Feb 21 16:40:48 newserver smbd_audit: abc16475|192.168.1.47|connect|ok|QSI16475
Feb 21 16:40:49 newserver smbd[3381]: [2013/02/21 16:40:49.771784, 0] ../source3/auth/check_samsec.c:491(check_sam_security)
Feb 21 16:40:49 newserver smbd[3381]: check_sam_security: make_server_info_sam() failed with 'NT_STATUS_NO_SUCH_USER'
-
I don't think it has anything to do with group membership.
If I understand correctly what you wrote previously, user authenticates (well, if this is kerberos based, "thanks" to SSO, you even don't notice) but then is not authorized to access internet.
Is it because of misalignment between kerberos token (used identification) and group membership ?
Strange...
-
agreed, as I'd already tested that through the user interface.
It's just I've finally got a chance to break things again and see what shows so I thought I'd list all the tests/logs I could just in case it sheds any light on the subject!
-
Quick update.
I've setup a new test server at home in a virtual machine with the same setup as the one at work. Unfortunately it works perfectly :(
Is there any way to copy all the users and all the configurations over from the live server to the test one to see if I can reproduce in a safe enviornment?
-
You can use the import/export configuration feature for that. To avoid any surprise the receiver of the configuration must have enabled the same modules, also before saving changes check your network interfaces and make any change required for the different network location.
However, for keeping size reasonable, the categorized domains lists are not copied in the backup. I don't think that this affect your scenario.
-
Just a bump to say this is an ongoing problem, however it has morphed into no user information being presented to squid1/dansguardian/squid2 :(
I set up the same server at home in a virtual machine and could not get the authentication to break.
I then restored the config from the work server and have managed to get the problems occuring again, I'm quite happy with this progress at least.
Somehow the whole squid auth with kerberos is failing.
I'm trying to get the info from the logs, but so far no luck.
-
Hi astana,
could you check if the users having problems are defined in the file /etc/dansguardian/lists/filtergroupslist?
-
Hi astana,
could you check if the users having problems are defined in the file /etc/dansguardian/lists/filtergroupslist?
Unfortunately as I only have one list now the filtergrouplist is empty.
I'll try to set the groups up on my test server and give you feedback, but I'm not sure it will be helpful as both the live server and test server both fail to authenticate any user through the squid proxy ( I somehow went from users authenticating but some failing to authorise to none authenticating).
As soon as I can track down and fix why this is happening I'll be able to get back on track with the topic.