The use of %LOGIN requires currently present and valid user credentials
just to test this ACL.
Thanks Amos, now I can cache the IP/username association, but I am
afraid I found a bug in the ext_user_regex acl type.
The long story is that I misunderstood the important difference among:
* The username used in %LOGIN, proxy_auth and proxy_auth_regex ACLs
* The username used in %EXT_LOGIN, ext_user and ext_user_regex ACLs
* The username used in ident and ident_regex ACLs, if still used.
And the fact that in access.log there appears to be whatever is available.
Now I changed my conf to replace all ACLs from proxy_auth* to ext_user*,
and I am using "pre" and "post" this way:
external_acl_type pre_short ttl=0 concurrency=0 children=3 %SRC
/usr/local/squid-3.4.3/shortcircuit -d pre
acl pre_short external pre_short
external_acl_type post_short ttl=0 concurrency=0 children=3 %SRC %LOGIN
/usr/local/squid-3.4.3/shortcircuit -d post
acl post_short external post_short
# first http_access line
http_access allow !pre_short !post_short
The shortcircuit script works this way when called with "pre":
* If IP is in cache, return OK user=<user>
* return ERR otherwise
And when called with "post":
* store IP/user in cache
* return OK user=<user>
So my original problem is solved. Thanks Amos!
But the fun is not over, since ext_user_regex seems to match not like a
regex, but like a string, i.e. ext_user_regex seems to be really ext_user.
With this conf I get a 403:
acl authanystr ext_user_regex .*
http_access allow !pre_short !post_short
http_access allow authanystr
http_access deny all
With debug ALL,9 I see (let me obfuscate my real domain name with "DOMN"):
...
2014/02/06 13:15:53.702| external_acl.cc(798) aclMatchExternal:
acl="pre_short"
2014/02/06 13:15:53.702| cbdata.cc(510) cbdataReferenceValid:
cbdataReferenceValid: 0x24c1f28
2014/02/06 13:15:53.702| external_acl.cc(893) aclMatchExternal: entry =
{ date=1391688953, result=ALLOWED tag= log= }
2014/02/06 13:15:53.702| external_acl.cc(895) aclMatchExternal: entry
user=DOMN\mbergonz
2014/02/06 13:15:53.702| external_acl.cc(901) aclMatchExternal:
pre_short = ALLOWED
2014/02/06 13:15:53.702| Acl.cc(177) matches: checked: pre_short = 1
2014/02/06 13:15:53.702| InnerNode.cc(88) resumeMatchingAt: checked:
!pre_short = 0
2014/02/06 13:15:53.702| InnerNode.cc(88) resumeMatchingAt: checked:
http_access#1 = 0
2014/02/06 13:15:53.702| Acl.cc(157) matches: checking http_access#2
2014/02/06 13:15:53.702| Acl.cc(157) matches: checking authanystr
2014/02/06 13:15:53.702| UserData.cc(72) match: aclMatchUser: user is
DOMN\mbergonz, case_insensitive is 0
2014/02/06 13:15:53.702| UserData.cc(73) match: Top is 0x24292d0,
Top->data is .*
2014/02/06 13:15:53.702| UserData.cc(90) match: aclMatchUser: returning
0,Top is 0x24292d0, Top->data is .*
2014/02/06 13:15:53.702| Acl.cc(177) matches: checked: authanystr = 0
2014/02/06 13:15:53.702| Acl.cc(177) matches: checked: http_access#2 = 0
...
With this conf, it works:
acl bergonz ext_user_regex DOMN\mbergonz
http_access allow !pre_short !post_short
http_access allow bergonz
http_access deny all
I am definitely not proficient in C++. I tried to compare
src/acl/UserData.cc
and
src/acl/ExtUser.cc
and the only thing I can say is that ExtUser.cc is so much smaller...
Maybe I should report this as a bug?
If you are using short-circuit to make different credentials re-use a
NTLM username then you need to be aware that the connection persistence
required by NTLM is not enforced, and more importantly the client and
server connections are not pinned/linked together
Thank you for pointing out that connections probably won't get pinned in
my setup. I will experiment.
What I am trying to achieve is to have people user Firefox with squid3
from PCs not in the active directory. Now this users are constantly
prompted for proxy credentials even if credentials are saved in Firefox.
Last time I checked (months ago), this happened also with negotiate.
This is obviously a bug in Firefox (IE and Chrome on the same PCs work
fine) that I'm trying to cirmumvent with squid. With squid2 I can set
authenticate_ip_shortcirctuit_ttl and the problem almost disappears.
Another (dubious) result that I'm trying to achieve is that the
occasional braindead program that makes http requests but cannot use
ntlm_auth (or any auth) to the proxy, can be fixed with "Just open
google and then immediately the program".
I am aware that all this is not what people like you (and me) call
"security", but in this (not uncommon) environment the alternative is a
captive portal, which is worse, or an expensive commercial box
(Fortigate, Checkpoint, Cisco ASA) that asks the domain controllers (or
its logs, don't know) for login/IP associations.
Thank you again for your help,
Bergonz
