http-proxy SSO (single sign on) zentyal 3.0 - problem

[txsastre]

Hi there, I'm testing zentyal 3.0 final

I'm testing http-proxy, and everything I tried work fine, except the SSO, when I activate it, it does not work as it should, in fact it does not uses any ACL, only the "any" that is set to "deny", so they cannot navigate anywhere.

The client machines were Win XP, logged to the zentyal domain.

Do I need to install anything else on the server or client desktops ?

thank you.

[Sam Graf]

Maybe you can help me understand how this is supposed to work, txsastre.

The proxy is not transparent. I don't have Samba installed so there is no domain. (And even if I did have Samba installed, I am testing 3.0 from a Windows 7 Starter netbook so could not join a domain anyway.)

I can authenticate fine (over and over, of course) and browse according the the access rules fine until I activate SSO. At that point I cannot authenticate at all, and that is the end of the road.

This seems to me not how it ought to work, but my ignorance could be the problem.

[txsastre]

Maybe you can help me understand how this is supposed to work, txsastre.

The proxy is not transparent. I don't have Samba installed so there is no domain. (And even if I did have Samba installed, I am testing 3.0 from a Windows 7 Starter netbook so could not join a domain anyway.)

I can authenticate fine (over and over, of course) and browse according the the access rules fine until I activate SSO. At that point I cannot authenticate at all, and that is the end of the road.

This seems to me not how it ought to work, but my ignorance could be the problem.

Hi Sam.

Well my test is slightly different, because I've created an domain, so my windows XP machines are in it. So when they start and log in the domain, I thought that the SSO should "catch"  user and password credentials so when I open the navigator (firefox, iexplorer) my user should have access to where I set in the proxy configurations.  But it does not work, as I can see in the proxy log, there is no "user" only a "-" (and sometimes, nothing at all). And that's how I suppose the SSO should work, maybe I am wrong after all.

It only works if I disable the SSO option in the proxy, but, I have to write again user and password when the navigator opens.

By the way I think that if you use SSO and then try to connect with an machine or user that is not in the domain, I think that it should use the last rule in the proxy settings or maybe you can add a rule for "guests". But that's only my guess.

[christian]

If I understand well your explanation, it looks like there is not "link" between authentication and authorization.
BTW I'm going to discuss this during the summit: the right sequence, following IAA logic, is to Identify, Authenticate then Authorize. This supposes that authorization back-end is able to maintain relationship establish at authentication step. When everything is done in LDAP, this is pretty easy (one single protocol, one single repository) but with Kerberos, it requires to pay extra attention.
Perhaps Zentyal dev team could explain to us what they do here 

[Sam Graf]

Thanks for the perspective, txsastre. There is at least one ticket describing the problem (in the case of a domain-attached computer), so I'm sure things will get cleared up eventually. The possibility that a machine must join the domain for the proxy to work as hoped (with SSO) concerns me, especially in the case where the file sharing module is not needed or wanted.

Sounds like an interesting discussion, christian. It's good that there are members of the community who have an in-depth understanding of such things.

[txsastre]

Ok, I've read the ticket and is exactly what's happening.

I will keep an eye on it. Hope it gets solved soon.

Thanks !

[christian]

I'm matching what Sam describes: no domain (I don't like the idea of having shared files on server acting as internet gateway) but proxy. I could obviously deploy another internal Zentyal server for file sharing (BTW, I also would like this server to be my MDA if I'm obliged to maintain 2 Zentyal servers) but with such design, I don't understand yet how all this stuff is going to interact, especially regarding authentication (Kerberos) and authorization (LDAP).

If goal is "only" to replace Win server, then current design makes sense, however not all users want to have their infrastructure designed like if done by MCSE 

[Sam Graf]

See that the ticket is closed and that the fix was pending the release of an updated proxy module. Just updated to HTTP Proxy 3.0.1 and am not yet able to use SSO at all. The only way I can authenticate from a Windows 7 machine is with the proxy's SSO feature disabled.

Perhaps I'm missing something?

[txsastre]

hi there. I've have updated to 3.0.1 and the same results also added the problem to the ticket. And asked to re-open it.

http://trac.zentyal.org/ticket/5097#comment:7

[Sam Graf]

...the same results...

So your scenario is still Windows XP machines joined to the domain and proxy SSO is not yet not working? Since I'm uncertain if the developers intend for the proxy SSO feature to work in conjunction with Samba, I'm not sure how to properly test the feature.

In my case, Samba isn't installed so there is no domain. Further, my Windows test machine is running Windows 7 Starter (a netbook) so can't join a domain. It may be that the proxy's SSO feature simply can't work under my test setup.

[txsastre]

yes, my scenario is very simple.

1 server zentyal Domain, and a few XP client in this domain.

When I log into de domain, I can see the shared folders and only access to where I have permissions, but when I open the browser (configured to user the proxy and SSO enabled) it does not work.

I have only 3 rules, 1 users, 1 admins

When I disable SSO, when I open the navigator it ask me for an user / password and it works ok. but when I enable SSO, it does not work, it always shows me an error "access denied to cache"

so, if I see the log file I can see that there is no user name given, so I can assume the proxy does not know who is trying to access, so it denies everything.

Data                              Amfitrió                       Usuari      Adreça URL     ...
2012-10-30 09:22:50    192.168.200.230        -         http://safebrowsing.clients.google.com/s...

[txsastre]

Hi there.

I've been testing a lot the proxy and I think that it should work, it does not work.

as I've explaided here
http://forum.zentyal.org/index.php/topic,12010.msg52630.html#msg52630

domain samba, and machines XP properly configured, assigned groups to the proxy and enabled SSO in proxy.

Once the users are login in the domain, the proxy always deny me "access to object http://www.google.es/search? denied without permission". When I look the log, I can see that there is no user trying to access, only a "-" where it should be the user.

If I disable the SSO it asks me user and name and it works, and also I can see it in the log

Should it be working as I expecting, or maybe is not designed this way ?

Thank you.

[christian]

but why do you create new topic to discuss further the existing one 

[txsastre]

ok, my fault

You can merge/delete it if you want.

but the question is still the same.

[Sam Graf]

It would be nice to have some definitive clarification on how the Zentyal feature set is intended to work.

• Does the HTTP proxy SSO feature require that Zentyal also be a PDC?
• If so, would it be possible to expose the proxy's SSO feature only in cases where the Samba module is installed, to reduce confusion?
• If not, what exactly does Zentyal expect the server configuration to look like for the proxy's SSO to work?

I understand completely the potential validity of a tracker comment like "I close this since it seems to be a configuration/operation problem," but if there is confusion out here about how the feature is supposed to work, the effectiveness of a bug hunt is reduced. So a little clarification would make it more likely that our expectations of the feature are correct, helping us to decide if Zentyal's very reproducible behavior in this case is a feature or a bug.