Max number of users in proxy filter groups?

[christian]

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))

[astana]

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.

[christian]

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:

Code: [Select]

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)

[astana]

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.

[christian]

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=*" 

[astana]

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

[christian]

So I suppose my search filter is wrong 
Please check using "objectclass=*"
given what you described, you should get plenty of entries

[astana]

you mean executing this line?

Code: [Select]

ldapsearch -h 127.0.0.1 -p 390 -xLLL -b "dc=abc-astana,dc=lan" -s sub "(&(objectclass=*))"

Still returns No such object (32)

[christian]

Sorry, I meant:

Code: [Select]

ldapsearch -h 127.0.0.1 -p 390 -xLLL -b "dc=abc-astana,dc=lan" -s sub "objectclass=*"


[astana]

hate to disappoint, but that also gives the same error :/

[christian]

No disappointment at least on my side 
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

[astana]

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...

[christian]

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 
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 

[astana]

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'

[christian]

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...