[squid-users] NTLM problem with Internet explorer/windows

[Antero Prazeres]

Hello,
I need some help with this issue as I am out of ideas and I don¹t find any
similar issues on your lists/emails/faqs.
I am using a server with CentOS6 and Squid 3.1.10 as a proxy. One of my
teams needs to access to ISS 7 trough Squid for test and development
purposes using only NTLM. Squid server is accessing the AD and credentials
are working. All tests performed with Wbinfo are successful. The access to
the IIS ntlm site is successful from Firefox and Safari, all returning the
message ³you are authenticated using NTLM². I try to perform the same test
on several machines with Windows 7 and Internet Explorer, most of them 11,
and don¹t work. GPO was altered on the windows for NTLM, ISS site is
requesting NTLM with extended protection and kernel=mode authentication
off.

Somebody as any ideas please??

Thank you

Best regards

Antero Prazeres



This email and any attachments may contain confidential and proprietary 
information of Blackboard that is for the sole use of the intended recipient. 
If you are not the intended recipient, disclosure, copying, re-distribution or 
other use of any of this information is strictly prohibited. Please immediately 
notify the sender and delete this transmission if you received this email in 
error.

Re: [squid-users] NTLM Auth helper issue

[Kinkie]

Hi Eric,
  you probably want to ask this question to the Samba lists. Squid
only uses ntlm_auth services..

On Tue, Oct 22, 2013 at 6:52 PM, Eric Vanderveer
 wrote:
> Hi everyone when trying to run /usr/bin/ntlm_auth
> --helper-protocol=squid-2.5-basic domain+user password all it does is
> just hang and does not give me an OK response.  I have checked the
> winbind logs and can't see anything.  Any ideas?
>
> Thanks
> Eric Vanderveer



-- 
/kinkie

[squid-users] NTLM Auth helper issue

[Eric Vanderveer]

Hi everyone when trying to run /usr/bin/ntlm_auth
--helper-protocol=squid-2.5-basic domain+user password all it does is
just hang and does not give me an OK response.  I have checked the
winbind logs and can't see anything.  Any ideas?

Thanks
Eric Vanderveer

Re: [squid-users] NTLM - Squid X Samba4

[Amos Jeffries]

On 2/10/2013 8:11 a.m., Aecio Alves wrote:

Good afternoon!

Is there an alternative integrated authentication squid with Samba4, 
and NTLM?


I need to do that authentication is integrated with Windows 
authentication, when the user makes a log on the domain.


Squid supports this kind of integration with Samba4?

I've done it with version 3 of the Samba.

What information do you need to help me?
Can anyone help me?


Possibly the Samba team can. There have been a number of people finding 
sudden problems after only upgrading Samba and thus the ntlm_auth helper 
that comes from it.


This is all that has been reported or identified about it so far:

Hi.

Recently I stepped on a bug in ntlm_auth helper from samba4 suite, 
guys in the samba team confirmed the possible bug with string 
formatting and possibly a missing '\0' delimiter at some point and 
requested more info, but in the same time they seem not being in the 
mood of explaining how to use ntlm_auth with two protocols - 
squid-2.5-ntlmssp/ntlmssp-client-1. The only thing I understood - is 
that using these two protocols it's possible to debug the 
authentication sequence, but I lack the documentation. I hope you guys 
could point me at right direction.


Thanks.
Eugene.



As you may be aware Squid is a community project. So unless someone is 
able to spend the time digging deeper this is likely where things will stay.



Not that this will solve the problem of Samba4 NTLM being a bit broken 
anyone still using NTLM needs to be aware of and take a good think about 
this article:

http://blogs.technet.com/b/authentication/archive/2006/04/07/ntlm-s-time-has-passed.aspx

Amos

[squid-users] NTLM - Squid X Samba4

[Aecio Alves]

Good afternoon!

Is there an alternative integrated authentication squid with Samba4, and 
NTLM?


I need to do that authentication is integrated with Windows 
authentication, when the user makes a log on the domain.


Squid supports this kind of integration with Samba4?

I've done it with version 3 of the Samba.

What information do you need to help me?
Can anyone help me?

Thank you.

Aécio

Re: [squid-users] NTLM Authenticator Statistics 3.3.5

[Amos Jeffries]

On 1/10/2013 1:50 p.m., Kris Glynn wrote:

Thanks, I will look at upgrading but these are Production servers and I notice 
quite a few changes from 3.3.x to 3.4 so I might need to do something about it 
in the meantime.

My idea of a fix is the following to perhaps run every 48hours...

for pid in `/usr/bin/squidclient -p 8080 mgr:ntlmauthenticator |grep RS |awk 
'{print $3}'`; do kill $pid; done

Am I correct in saying that I can kill any pid with flag "RS" from the 
mgr:ntlmauthenticator output?


Well the R means that the helepr os locked by a client connection id-way 
through the authentication handshake. It is a legitimate state to be in 
when the rotate or any other reason shutdown is scheduled, but should 
have completed within a few seconds, maybe a minute if your AD or client 
is acting very slowly.


If you don't mind breaking any legitimate client connections that is an 
option. I suggest you wait a full minute after any rotate or reconfigure 
to minimize the problems though.


Amos

RE: [squid-users] NTLM Authenticator Statistics 3.3.5

[Kris Glynn]

Thanks, I will look at upgrading but these are Production servers and I notice 
quite a few changes from 3.3.x to 3.4 so I might need to do something about it 
in the meantime.

My idea of a fix is the following to perhaps run every 48hours...

for pid in `/usr/bin/squidclient -p 8080 mgr:ntlmauthenticator |grep RS |awk 
'{print $3}'`; do kill $pid; done

Am I correct in saying that I can kill any pid with flag "RS" from the 
mgr:ntlmauthenticator output?


Regards

- Kris Glynn: (07) 3295 3987 - 0434602997

-Original Message-
From: Amos Jeffries [mailto:squ...@treenet.co.nz]
Sent: Monday, 30 September 2013 6:00 PM
To: squid-users@squid-cache.org
Subject: Re: [squid-users] NTLM Authenticator Statistics 3.3.5

On 30/09/2013 8:26 p.m., Kris Glynn wrote:
> Thanks Amos, that explains helper activity in the cache.log around rotate 
> time.
>
> When the problem occurred I didn't run a mgr:ntlmauthenticators report
> but on one of the proxies just now it has 77 shutting down state and
> report is here - http://pastebin.com/jhaFeW9H
>
>
>
> Regards
>
> - Kris Glynn: (07) 3295 3987 - 0434602997
>
> -Original Message-
> From: Amos Jeffries [mailto:squ...@treenet.co.nz]
> Sent: Monday, 30 September 2013 5:17 PM
> To: squid-users@squid-cache.org
> Subject: Re: [squid-users] NTLM Authenticator Statistics 3.3.5
>
> On 30/09/2013 7:26 p.m., Kris Glynn wrote:
>> Getting back to the initial problem.. I first discovered it when users 
>> reported they couldn't authenticate to one of the proxies, when I logged 
>> into the squid server the cache.log was full of errors like "WARNING: 
>> external ACL 'ldap_group' queue overload. Using stale result" - when I dug 
>> further I noticed at the top of the cache.log (after the nightly squid -k 
>> rotate) it had entries such as "ipcCreate: fork: (12) Cannot allocate memory 
>> WARNING: Cannot run '/usr/bin/ntlm_auth' process." And "helperOpenServers: 
>> Starting 1/50 'ext_wbinfo_group_acl' processes ipcCreate: fork: (12) Cannot 
>> allocate memory WARNING: Cannot run '/usr/lib64/squid/ext_wbinfo_group_acl' 
>> process. " - it seemed odd to me that a squid -k rotate would either 
>> restart/stop/start helpers. Shouldn't a squid -k rotate leave helpers alone 
>> when it's just instructing squid to rotate the logs?
> The helpers are logging to cache.log via stderr. They need to be restarted to 
> connect to the new cache.log once it has been rotated.
>
> What does the mgr:ntlmauthenticators report show about the NTLM helpers when 
> this is going on?

Okay this looks like you are hitting bug 3643. Where Safari (and any other 
clients behaving the same) could cause the helpers to get stuck in R / Reserved 
state.

This is fixed in 3.4, but unfortuately the fix requires a few background design 
changes so is not in 3.3. Are you able to use the latest daily snapshot of 3.4 
(labeled r12997 or later).

Amos
The content of this e-mail, including any attachments, is a confidential 
communication between Virgin Australia Airlines Pty Ltd (Virgin Australia) or 
its related entities (or the sender if this email is a private communication) 
and the intended addressee and is for the sole use of that intended addressee. 
If you are not the intended addressee, any use, interference with, disclosure 
or copying of this material is unauthorized and prohibited. If you have 
received this e-mail in error please contact the sender immediately and then 
delete the message and any attachment(s). There is no warranty that this email 
is error, virus or defect free. This email is also subject to copyright. No 
part of it should be reproduced, adapted or communicated without the written 
consent of the copyright owner. If this is a private communication it does not 
represent the views of Virgin Australia or its related entities. Please be 
aware that the contents of any emails sent to or from Virgin Australia or its 
related entities may be periodically monitored and reviewed. Virgin Australia 
and its related entities respect your privacy. Our privacy policy can be 
accessed from our website: www.virginaustralia.com

Re: [squid-users] NTLM Authenticator Statistics 3.3.5

[Amos Jeffries]

On 30/09/2013 8:26 p.m., Kris Glynn wrote:

Thanks Amos, that explains helper activity in the cache.log around rotate time.

When the problem occurred I didn't run a mgr:ntlmauthenticators report but on 
one of the proxies just now it has 77 shutting down state and report is here - 
http://pastebin.com/jhaFeW9H



Regards

- Kris Glynn: (07) 3295 3987 - 0434602997

-Original Message-
From: Amos Jeffries [mailto:squ...@treenet.co.nz]
Sent: Monday, 30 September 2013 5:17 PM
To: squid-users@squid-cache.org
Subject: Re: [squid-users] NTLM Authenticator Statistics 3.3.5

On 30/09/2013 7:26 p.m., Kris Glynn wrote:

Getting back to the initial problem.. I first discovered it when users reported they couldn't authenticate to 
one of the proxies, when I logged into the squid server the cache.log was full of errors like "WARNING: 
external ACL 'ldap_group' queue overload. Using stale result" - when I dug further I noticed at the top 
of the cache.log (after the nightly squid -k rotate) it had entries such as "ipcCreate: fork: (12) 
Cannot allocate memory WARNING: Cannot run '/usr/bin/ntlm_auth' process." And "helperOpenServers: 
Starting 1/50 'ext_wbinfo_group_acl' processes ipcCreate: fork: (12) Cannot allocate memory WARNING: Cannot 
run '/usr/lib64/squid/ext_wbinfo_group_acl' process. " - it seemed odd to me that a squid -k rotate 
would either restart/stop/start helpers. Shouldn't a squid -k rotate leave helpers alone when it's just 
instructing squid to rotate the logs?

The helpers are logging to cache.log via stderr. They need to be restarted to 
connect to the new cache.log once it has been rotated.

What does the mgr:ntlmauthenticators report show about the NTLM helpers when 
this is going on?


Okay this looks like you are hitting bug 3643. Where Safari (and any 
other clients behaving the same) could cause the helpers to get stuck in 
R / Reserved state.


This is fixed in 3.4, but unfortuately the fix requires a few background 
design changes so is not in 3.3. Are you able to use the latest daily 
snapshot of 3.4 (labeled r12997 or later).


Amos

RE: [squid-users] NTLM Authenticator Statistics 3.3.5

[Kris Glynn]

Thanks Amos, that explains helper activity in the cache.log around rotate time.

When the problem occurred I didn't run a mgr:ntlmauthenticators report but on 
one of the proxies just now it has 77 shutting down state and report is here - 
http://pastebin.com/jhaFeW9H



Regards

- Kris Glynn: (07) 3295 3987 - 0434602997

-Original Message-
From: Amos Jeffries [mailto:squ...@treenet.co.nz]
Sent: Monday, 30 September 2013 5:17 PM
To: squid-users@squid-cache.org
Subject: Re: [squid-users] NTLM Authenticator Statistics 3.3.5

On 30/09/2013 7:26 p.m., Kris Glynn wrote:
> Getting back to the initial problem.. I first discovered it when users 
> reported they couldn't authenticate to one of the proxies, when I logged into 
> the squid server the cache.log was full of errors like "WARNING: external ACL 
> 'ldap_group' queue overload. Using stale result" - when I dug further I 
> noticed at the top of the cache.log (after the nightly squid -k rotate) it 
> had entries such as "ipcCreate: fork: (12) Cannot allocate memory WARNING: 
> Cannot run '/usr/bin/ntlm_auth' process." And "helperOpenServers: Starting 
> 1/50 'ext_wbinfo_group_acl' processes ipcCreate: fork: (12) Cannot allocate 
> memory WARNING: Cannot run '/usr/lib64/squid/ext_wbinfo_group_acl' process. " 
> - it seemed odd to me that a squid -k rotate would either restart/stop/start 
> helpers. Shouldn't a squid -k rotate leave helpers alone when it's just 
> instructing squid to rotate the logs?

The helpers are logging to cache.log via stderr. They need to be restarted to 
connect to the new cache.log once it has been rotated.

What does the mgr:ntlmauthenticators report show about the NTLM helpers when 
this is going on?

Amos
The content of this e-mail, including any attachments, is a confidential 
communication between Virgin Australia Airlines Pty Ltd (Virgin Australia) or 
its related entities (or the sender if this email is a private communication) 
and the intended addressee and is for the sole use of that intended addressee. 
If you are not the intended addressee, any use, interference with, disclosure 
or copying of this material is unauthorized and prohibited. If you have 
received this e-mail in error please contact the sender immediately and then 
delete the message and any attachment(s). There is no warranty that this email 
is error, virus or defect free. This email is also subject to copyright. No 
part of it should be reproduced, adapted or communicated without the written 
consent of the copyright owner. If this is a private communication it does not 
represent the views of Virgin Australia or its related entities. Please be 
aware that the contents of any emails sent to or from Virgin Australia or its 
related entities may be periodically monitored and reviewed. Virgin Australia 
and its related entities respect your privacy. Our privacy policy can be 
accessed from our website: www.virginaustralia.com

Re: [squid-users] NTLM Authenticator Statistics 3.3.5

[Amos Jeffries]

On 30/09/2013 7:26 p.m., Kris Glynn wrote:

Getting back to the initial problem.. I first discovered it when users reported they couldn't authenticate to 
one of the proxies, when I logged into the squid server the cache.log was full of errors like "WARNING: 
external ACL 'ldap_group' queue overload. Using stale result" - when I dug further I noticed at the top 
of the cache.log (after the nightly squid -k rotate) it had entries such as "ipcCreate: fork: (12) 
Cannot allocate memory WARNING: Cannot run '/usr/bin/ntlm_auth' process." And "helperOpenServers: 
Starting 1/50 'ext_wbinfo_group_acl' processes ipcCreate: fork: (12) Cannot allocate memory WARNING: Cannot 
run '/usr/lib64/squid/ext_wbinfo_group_acl' process. " - it seemed odd to me that a squid -k rotate 
would either restart/stop/start helpers. Shouldn't a squid -k rotate leave helpers alone when it's just 
instructing squid to rotate the logs?


The helpers are logging to cache.log via stderr. They need to be 
restarted to connect to the new cache.log once it has been rotated.


What does the mgr:ntlmauthenticators report show about the NTLM helpers 
when this is going on?


Amos

RE: [squid-users] NTLM Authenticator Statistics 3.3.5

[Kris Glynn]

They are all Vmware VM's - 2VCPU and 4GB of RAM each - they authenticate, 
authorize (based on wbinfo AD group lookups) and cache and yes you are correct 
in saying adding another squid instance is as easy as cloning the VM and adding 
to the F5 pool.

Each Datacenter is within 8km's of the majority of uses, we have 1Gig uplink 
from the users to proxies.

Getting back to the initial problem.. I first discovered it when users reported 
they couldn't authenticate to one of the proxies, when I logged into the squid 
server the cache.log was full of errors like "WARNING: external ACL 
'ldap_group' queue overload. Using stale result" - when I dug further I noticed 
at the top of the cache.log (after the nightly squid -k rotate) it had entries 
such as "ipcCreate: fork: (12) Cannot allocate memory WARNING: Cannot run 
'/usr/bin/ntlm_auth' process." And "helperOpenServers: Starting 1/50 
'ext_wbinfo_group_acl' processes ipcCreate: fork: (12) Cannot allocate memory 
WARNING: Cannot run '/usr/lib64/squid/ext_wbinfo_group_acl' process. " - it 
seemed odd to me that a squid -k rotate would either restart/stop/start 
helpers. Shouldn't a squid -k rotate leave helpers alone when it's just 
instructing squid to rotate the logs?

2013/09/24 00:00:23 kid1| storeDirWriteCleanLogs: Starting...
2013/09/24 00:00:28 kid1| 65536 entries written so far.
2013/09/24 00:00:35 kid1|131072 entries written so far.
2013/09/24 00:00:40 kid1|196608 entries written so far.
2013/09/24 00:00:45 kid1|262144 entries written so far.
2013/09/24 00:00:48 kid1|327680 entries written so far.
2013/09/24 00:00:51 kid1|393216 entries written so far.
2013/09/24 00:00:55 kid1|458752 entries written so far.
2013/09/24 00:00:59 kid1|524288 entries written so far.
2013/09/24 00:01:02 kid1|589824 entries written so far.
2013/09/24 00:01:05 kid1|655360 entries written so far.
2013/09/24 00:01:07 kid1|720896 entries written so far.
2013/09/24 00:01:08 kid1|   Finished.  Wrote 759594 entries.
2013/09/24 00:01:08 kid1|   Took 44.19 seconds (17189.28 entries/sec).
2013/09/24 00:01:08 kid1| logfileRotate: stdio://var/log/squid/access.log
2013/09/24 00:01:08 kid1| Rotate log file stdio://var/log/squid/access.log
2013/09/24 00:01:08 kid1| helperOpenServers: Starting 10/60 'ntlm_auth' 
processes
2013/09/24 00:01:08 kid1| ipcCreate: fork: (12) Cannot allocate memory
2013/09/24 00:01:08 kid1| WARNING: Cannot run '/usr/bin/ntlm_auth' process.
2013/09/24 00:01:08 kid1| ipcCreate: fork: (12) Cannot allocate memory

When I looked into it further that's when I noticed all of the old 
/usr/bin/ntlm_auth processes still running from months back and 
/usr/bin/squidclient -p 8080 mgr:ntlmauthenticator reporting that 140+ were in 
"shutting down state" - stopping squid did not stop all of the ntlm_auth 
processes so I had to killall -9 ntlm_auth and then start squid back up again.


Regards

- Kris Glynn: (07) 3295 3987 - 0434602997

-Original Message-
From: Eliezer Croitoru [mailto:elie...@ngtech.co.il]
Sent: Monday, 30 September 2013 3:43 PM
To: squid-users@squid-cache.org
Subject: Re: [squid-users] NTLM Authenticator Statistics 3.3.5

Hey Kris,

Well it's not such a small setup after all.
I do not know what is the size of these machines but I assume they have more 
then just one single core to work fine.
I am not sure about the next suggestion yet since I do not know if the proxy is 
for cache also or just plain authentication.
I can assume that these machines can be configured for SMP or mulch-instances 
on the same machine.
since you do have the F5 in place adding another so called "instance" of squid 
is only a matter of adding another lan IP to the squid machine and the IP to 
the F5.
it can balance the traffic in the process level a bit more then you are might 
be doing now.
it's not rocket science since lots of information is missing.

A small question:
The mentioned problem is in the period of these 10 days and the service is just 
reviving itself each time?? like in the logs?
The network distance between the clients and the DATACENTER since it's critical 
for smooth operation..
Notice that each authentication takes up some traffic so a keep_alive is better 
to be used to lower the network load of it.

Let say the server is getting 200 requests in one peak of load it means
200 incoming FD then 200 stdin\out operations 200 new connections towards the 
auth server\service, about 200 new outgoing connections in the case of a non 
cached object..
You can imagine what is the load on the servers if there is 3k requests per 
minute..

Eliezer

On 09/30/2013 08:23 AM, Kris Glynn wrote:
> Hi Eliezer,
>
> I am using 60 because it seemed to me that I needed that many. I am actually 
> running 4 x squid 3.3.5 - two in each data center. They are distribute

Re: [squid-users] NTLM Authenticator Statistics 3.3.5

[Eliezer Croitoru]

Hey Kris,

Well it's not such a small setup after all.
I do not know what is the size of these machines but I assume they have
more then just one single core to work fine.
I am not sure about the next suggestion yet since I do not know if the
proxy is for cache also or just plain authentication.
I can assume that these machines can be configured for SMP or
mulch-instances on the same machine.
since you do have the F5 in place adding another so called "instance" of
squid is only a matter of adding another lan IP to the squid machine and
the IP to the F5.
it can balance the traffic in the process level a bit more then you are
might be doing now.
it's not rocket science since lots of information is missing.

A small question:
The mentioned problem is in the period of these 10 days and the service
is just reviving itself each time?? like in the logs?
The network distance between the clients and the DATACENTER since it's
critical for smooth operation..
Notice that each authentication takes up some traffic so a keep_alive is
better to be used to lower the network load of it.

Let say the server is getting 200 requests in one peak of load it means
200 incoming FD then 200 stdin\out operations 200 new connections
towards the auth server\service, about 200 new outgoing connections in
the case of a non cached object..
You can imagine what is the load on the servers if there is 3k requests
per minute..

Eliezer

On 09/30/2013 08:23 AM, Kris Glynn wrote:
> Hi Eliezer,
> 
> I am using 60 because it seemed to me that I needed that many. I am actually 
> running 4 x squid 3.3.5 - two in each data center. They are distributed by a 
> browser PAC file and each of the two in each data center are load balanced by 
> a Bigip F5 Load balancer. The PAC file points at the 2 x F5 Vips.
> 
> As for keepalive, no reason that it is off, I will turn it on and see how it 
> goes. Also, Kerberos isn't far off, it's implemented and tested running 
> through the F5 load balancer so I just have to enable it. My Test environment 
> is running squid 3.3.9 and Kerberos works well.
> 
> Each of the 4 proxies have been up for 10days without a restart and averages 
> around..
> 
> 3000 request/per min (/usr/bin/squidclient -p 8080 mgr:info | grep "HTTP 
> requests per minute")
> 3500 clients accessing cache (/usr/bin/squidclient -p 8080 mgr:info | grep 
> "Number of clients accessing cache")
> 2500 open files (/usr/bin/squidclient -p 8080 mgr:info | grep "Number of file 
> desc currently in use")
> 600 usernames in NTLM username cache (/usr/bin/squidclient mgr:username_cache 
> |grep AUTH | wc -l)
> 
> -Original Message-
> From: Eliezer Croitoru [mailto:elie...@ngtech.co.il]
> Sent: Monday, 30 September 2013 2:40 PM
> To: squid-users@squid-cache.org
> Subject: Re: [squid-users] NTLM Authenticator Statistics 3.3.5
> 
> Hey Kris,
> 
> I am just wondering why do you nedd 60 children at all??
> I am not sure what is the reason for what you are seeing but you need to make 
> sure that all squid instances are off.
> If you can test it and shutdown the squid instance and all subprocess that 
> are forked.. and then on a clean startup see the cache.log..
> it will give more info.
> I would ask "why do not use keep_alive??" it is there for a reason..
> if it's such a loaded system I would upper the startup from 15 to 30 and the 
> idle to 15.. and would try to use keep_alive on.
> 
> if you want to make sure about the ntlm_auth I would say that you can add a 
> debug flag but it will probably will flood the logs..
> 
> A kerberous migration is possible??
> since it's a 2.5 compatible I assume it's not that simple?
> 
> Eliezer
> 
> On 09/30/2013 07:07 AM, Kris Glynn wrote:
>> Hi,
>>
>> I've noticed after a while the number of /usr/bin/ntlm_auth processes in 
>> "shutting down state" tends to increase and never actually shutdown/decrease.
>>
>> It is configured like so..
>>
>> auth_param ntlm program /usr/bin/ntlm_auth
>> --helper-protocol=squid-2.5-ntlmssp
>> auth_param ntlm children 60 startup=15 idle=10 auth_param ntlm
>> keep_alive off
>>
>>  I've found an occurrence where a squid -k rotate was performed
>> (performed daily via cron) and helperOpenServers tried to start
>> processes and logged the below. When I logged into the squid server
>> many many old ntlm_auth processes were running (over 140+ in shutting
>> down state)
>>
>> Is it normal for a squid -k rotate to spawn helpers? Should I be scheduling 
>> a squid restart to occur every x days and perhaps killall -9 ntlm_auth at 
>> the same time or does anyone have any suggestions as to why 
>> /us

RE: [squid-users] NTLM Authenticator Statistics 3.3.5

[Kris Glynn]

Hi Eliezer,

I am using 60 because it seemed to me that I needed that many. I am actually 
running 4 x squid 3.3.5 - two in each data center. They are distributed by a 
browser PAC file and each of the two in each data center are load balanced by a 
Bigip F5 Load balancer. The PAC file points at the 2 x F5 Vips.

As for keepalive, no reason that it is off, I will turn it on and see how it 
goes. Also, Kerberos isn't far off, it's implemented and tested running through 
the F5 load balancer so I just have to enable it. My Test environment is 
running squid 3.3.9 and Kerberos works well.

Each of the 4 proxies have been up for 10days without a restart and averages 
around..

3000 request/per min (/usr/bin/squidclient -p 8080 mgr:info | grep "HTTP 
requests per minute")
3500 clients accessing cache (/usr/bin/squidclient -p 8080 mgr:info | grep 
"Number of clients accessing cache")
2500 open files (/usr/bin/squidclient -p 8080 mgr:info | grep "Number of file 
desc currently in use")
600 usernames in NTLM username cache (/usr/bin/squidclient mgr:username_cache 
|grep AUTH | wc -l)

-Original Message-
From: Eliezer Croitoru [mailto:elie...@ngtech.co.il]
Sent: Monday, 30 September 2013 2:40 PM
To: squid-users@squid-cache.org
Subject: Re: [squid-users] NTLM Authenticator Statistics 3.3.5

Hey Kris,

I am just wondering why do you nedd 60 children at all??
I am not sure what is the reason for what you are seeing but you need to make 
sure that all squid instances are off.
If you can test it and shutdown the squid instance and all subprocess that are 
forked.. and then on a clean startup see the cache.log..
it will give more info.
I would ask "why do not use keep_alive??" it is there for a reason..
if it's such a loaded system I would upper the startup from 15 to 30 and the 
idle to 15.. and would try to use keep_alive on.

if you want to make sure about the ntlm_auth I would say that you can add a 
debug flag but it will probably will flood the logs..

A kerberous migration is possible??
since it's a 2.5 compatible I assume it's not that simple?

Eliezer

On 09/30/2013 07:07 AM, Kris Glynn wrote:
> Hi,
>
> I've noticed after a while the number of /usr/bin/ntlm_auth processes in 
> "shutting down state" tends to increase and never actually shutdown/decrease.
>
> It is configured like so..
>
> auth_param ntlm program /usr/bin/ntlm_auth
> --helper-protocol=squid-2.5-ntlmssp
> auth_param ntlm children 60 startup=15 idle=10 auth_param ntlm
> keep_alive off
>
>  I've found an occurrence where a squid -k rotate was performed
> (performed daily via cron) and helperOpenServers tried to start
> processes and logged the below. When I logged into the squid server
> many many old ntlm_auth processes were running (over 140+ in shutting
> down state)
>
> Is it normal for a squid -k rotate to spawn helpers? Should I be scheduling a 
> squid restart to occur every x days and perhaps killall -9 ntlm_auth at the 
> same time or does anyone have any suggestions as to why /usr/bin/ntlm_auth 
> processes with Flags "RS" increase over time when not restarting squid?
>
> 2013/09/24 00:00:23 kid1| storeDirWriteCleanLogs: Starting...
> 2013/09/24 00:00:28 kid1| 65536 entries written so far.
> 2013/09/24 00:00:35 kid1|131072 entries written so far.
> 2013/09/24 00:00:40 kid1|196608 entries written so far.
> 2013/09/24 00:00:45 kid1|262144 entries written so far.
> 2013/09/24 00:00:48 kid1|327680 entries written so far.
> 2013/09/24 00:00:51 kid1|393216 entries written so far.
> 2013/09/24 00:00:55 kid1|458752 entries written so far.
> 2013/09/24 00:00:59 kid1|524288 entries written so far.
> 2013/09/24 00:01:02 kid1|589824 entries written so far.
> 2013/09/24 00:01:05 kid1|655360 entries written so far.
> 2013/09/24 00:01:07 kid1|720896 entries written so far.
> 2013/09/24 00:01:08 kid1|   Finished.  Wrote 759594 entries.
> 2013/09/24 00:01:08 kid1|   Took 44.19 seconds (17189.28 entries/sec).
> 2013/09/24 00:01:08 kid1| logfileRotate:
> stdio://var/log/squid/access.log
> 2013/09/24 00:01:08 kid1| Rotate log file
> stdio://var/log/squid/access.log
> 2013/09/24 00:01:08 kid1| helperOpenServers: Starting 10/60
> 'ntlm_auth' processes
> 2013/09/24 00:01:08 kid1| ipcCreate: fork: (12) Cannot allocate memory
> 2013/09/24 00:01:08 kid1| WARNING: Cannot run '/usr/bin/ntlm_auth' process.
> 2013/09/24 00:01:08 kid1| ipcCreate: fork: (12) Cannot allocate memory
> 2013/09/24 00:01:08 kid1| WARNING: Cannot run '/usr/bin/ntlm_auth' process.
> 2013/09/24 00:01:08 kid1| ipcCreate: fork: (12) Cannot allocate memory
> 2013/09/24 00:01:08 kid1| WARNING: Cannot run '/usr/bin/ntlm_auth' process.
> 2013/09/24 00:01:08 kid1| ipcC

Re: [squid-users] NTLM Authenticator Statistics 3.3.5

[Eliezer Croitoru]

Hey Kris,

I am just wondering why do you nedd 60 children at all??
I am not sure what is the reason for what you are seeing but you need to
make sure that all squid instances are off.
If you can test it and shutdown the squid instance and all subprocess
that are forked.. and then on a clean startup see the cache.log..
it will give more info.
I would ask "why do not use keep_alive??" it is there for a reason..
if it's such a loaded system I would upper the startup from 15 to 30 and
the idle to 15.. and would try to use keep_alive on.

if you want to make sure about the ntlm_auth I would say that you can
add a debug flag but it will probably will flood the logs..

A kerberous migration is possible??
since it's a 2.5 compatible I assume it's not that simple?

Eliezer

On 09/30/2013 07:07 AM, Kris Glynn wrote:
> Hi,
> 
> I've noticed after a while the number of /usr/bin/ntlm_auth processes in 
> "shutting down state" tends to increase and never actually shutdown/decrease.
> 
> It is configured like so..
> 
> auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
> auth_param ntlm children 60 startup=15 idle=10
> auth_param ntlm keep_alive off
> 
>  I've found an occurrence where a squid -k rotate was performed (performed 
> daily via cron) and helperOpenServers tried to start processes and logged the 
> below. When I logged into the squid server many many old ntlm_auth processes 
> were running (over 140+ in shutting down state)
> 
> Is it normal for a squid -k rotate to spawn helpers? Should I be scheduling a 
> squid restart to occur every x days and perhaps killall -9 ntlm_auth at the 
> same time or does anyone have any suggestions as to why /usr/bin/ntlm_auth 
> processes with Flags "RS" increase over time when not restarting squid?
> 
> 2013/09/24 00:00:23 kid1| storeDirWriteCleanLogs: Starting...
> 2013/09/24 00:00:28 kid1| 65536 entries written so far.
> 2013/09/24 00:00:35 kid1|131072 entries written so far.
> 2013/09/24 00:00:40 kid1|196608 entries written so far.
> 2013/09/24 00:00:45 kid1|262144 entries written so far.
> 2013/09/24 00:00:48 kid1|327680 entries written so far.
> 2013/09/24 00:00:51 kid1|393216 entries written so far.
> 2013/09/24 00:00:55 kid1|458752 entries written so far.
> 2013/09/24 00:00:59 kid1|524288 entries written so far.
> 2013/09/24 00:01:02 kid1|589824 entries written so far.
> 2013/09/24 00:01:05 kid1|655360 entries written so far.
> 2013/09/24 00:01:07 kid1|720896 entries written so far.
> 2013/09/24 00:01:08 kid1|   Finished.  Wrote 759594 entries.
> 2013/09/24 00:01:08 kid1|   Took 44.19 seconds (17189.28 entries/sec).
> 2013/09/24 00:01:08 kid1| logfileRotate: stdio://var/log/squid/access.log
> 2013/09/24 00:01:08 kid1| Rotate log file stdio://var/log/squid/access.log
> 2013/09/24 00:01:08 kid1| helperOpenServers: Starting 10/60 'ntlm_auth' 
> processes
> 2013/09/24 00:01:08 kid1| ipcCreate: fork: (12) Cannot allocate memory
> 2013/09/24 00:01:08 kid1| WARNING: Cannot run '/usr/bin/ntlm_auth' process.
> 2013/09/24 00:01:08 kid1| ipcCreate: fork: (12) Cannot allocate memory
> 2013/09/24 00:01:08 kid1| WARNING: Cannot run '/usr/bin/ntlm_auth' process.
> 2013/09/24 00:01:08 kid1| ipcCreate: fork: (12) Cannot allocate memory
> 2013/09/24 00:01:08 kid1| WARNING: Cannot run '/usr/bin/ntlm_auth' process.
> 2013/09/24 00:01:08 kid1| ipcCreate: fork: (12) Cannot allocate memory
> 2013/09/24 00:01:08 kid1| WARNING: Cannot run '/usr/bin/ntlm_auth' process.
> 2013/09/24 00:01:08 kid1| ipcCreate: fork: (12) Cannot allocate memory
> 2013/09/24 00:01:08 kid1| WARNING: Cannot run '/usr/bin/ntlm_auth' process.
> 2013/09/24 00:01:08 kid1| ipcCreate: fork: (12) Cannot allocate memory
> 2013/09/24 00:01:08 kid1| WARNING: Cannot run '/usr/bin/ntlm_auth' process.
> 2013/09/24 00:01:08 kid1| ipcCreate: fork: (12) Cannot allocate memory
> 2013/09/24 00:01:08 kid1| WARNING: Cannot run '/usr/bin/ntlm_auth' process.
> 2013/09/24 00:01:08 kid1| ipcCreate: fork: (12) Cannot allocate memory
> 2013/09/24 00:01:08 kid1| WARNING: Cannot run '/usr/bin/ntlm_auth' process.
> 2013/09/24 00:01:08 kid1| ipcCreate: fork: (12) Cannot allocate memory
> 2013/09/24 00:01:08 kid1| WARNING: Cannot run '/usr/bin/ntlm_auth' process.
> 2013/09/24 00:01:08 kid1| ipcCreate: fork: (12) Cannot allocate memory
> 2013/09/24 00:01:08 kid1| WARNING: Cannot run '/usr/bin/ntlm_auth' process.
> 2013/09/24 00:01:08 kid1| helperOpenServers: Starting 1/10 'ntlm_auth' 
> processes
> 2013/09/24 00:01:08 kid1| ipcCreate: fork: (12) Cannot allocate memory
> 2013/09/24 00:01:08 kid1| WARNING: Cannot run '/usr/bin/ntlm_auth' process.
> 2013/09/24 00:01:08 kid1| helperOpenServers: Starting 1/50 
> 'ext_wbinfo_group_acl' processes
> 2013/09/24 00:01:08 kid1| ipcCreate: fork: (12) Cannot allocate memory
> 
> mgr:ntlmauthenticator
> 
> NTLM Authenticator Statistics:
> program: /usr/bin/ntlm_auth
> number active: 40 of 60 (77 shutting down)
> requests sent: 9021339
> rep

[squid-users] NTLM Authenticator Statistics 3.3.5

[Kris Glynn]

Hi,

I've noticed after a while the number of /usr/bin/ntlm_auth processes in 
"shutting down state" tends to increase and never actually shutdown/decrease.

It is configured like so..

auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 60 startup=15 idle=10
auth_param ntlm keep_alive off

 I've found an occurrence where a squid -k rotate was performed (performed 
daily via cron) and helperOpenServers tried to start processes and logged the 
below. When I logged into the squid server many many old ntlm_auth processes 
were running (over 140+ in shutting down state)

Is it normal for a squid -k rotate to spawn helpers? Should I be scheduling a 
squid restart to occur every x days and perhaps killall -9 ntlm_auth at the 
same time or does anyone have any suggestions as to why /usr/bin/ntlm_auth 
processes with Flags "RS" increase over time when not restarting squid?

2013/09/24 00:00:23 kid1| storeDirWriteCleanLogs: Starting...
2013/09/24 00:00:28 kid1| 65536 entries written so far.
2013/09/24 00:00:35 kid1|131072 entries written so far.
2013/09/24 00:00:40 kid1|196608 entries written so far.
2013/09/24 00:00:45 kid1|262144 entries written so far.
2013/09/24 00:00:48 kid1|327680 entries written so far.
2013/09/24 00:00:51 kid1|393216 entries written so far.
2013/09/24 00:00:55 kid1|458752 entries written so far.
2013/09/24 00:00:59 kid1|524288 entries written so far.
2013/09/24 00:01:02 kid1|589824 entries written so far.
2013/09/24 00:01:05 kid1|655360 entries written so far.
2013/09/24 00:01:07 kid1|720896 entries written so far.
2013/09/24 00:01:08 kid1|   Finished.  Wrote 759594 entries.
2013/09/24 00:01:08 kid1|   Took 44.19 seconds (17189.28 entries/sec).
2013/09/24 00:01:08 kid1| logfileRotate: stdio://var/log/squid/access.log
2013/09/24 00:01:08 kid1| Rotate log file stdio://var/log/squid/access.log
2013/09/24 00:01:08 kid1| helperOpenServers: Starting 10/60 'ntlm_auth' 
processes
2013/09/24 00:01:08 kid1| ipcCreate: fork: (12) Cannot allocate memory
2013/09/24 00:01:08 kid1| WARNING: Cannot run '/usr/bin/ntlm_auth' process.
2013/09/24 00:01:08 kid1| ipcCreate: fork: (12) Cannot allocate memory
2013/09/24 00:01:08 kid1| WARNING: Cannot run '/usr/bin/ntlm_auth' process.
2013/09/24 00:01:08 kid1| ipcCreate: fork: (12) Cannot allocate memory
2013/09/24 00:01:08 kid1| WARNING: Cannot run '/usr/bin/ntlm_auth' process.
2013/09/24 00:01:08 kid1| ipcCreate: fork: (12) Cannot allocate memory
2013/09/24 00:01:08 kid1| WARNING: Cannot run '/usr/bin/ntlm_auth' process.
2013/09/24 00:01:08 kid1| ipcCreate: fork: (12) Cannot allocate memory
2013/09/24 00:01:08 kid1| WARNING: Cannot run '/usr/bin/ntlm_auth' process.
2013/09/24 00:01:08 kid1| ipcCreate: fork: (12) Cannot allocate memory
2013/09/24 00:01:08 kid1| WARNING: Cannot run '/usr/bin/ntlm_auth' process.
2013/09/24 00:01:08 kid1| ipcCreate: fork: (12) Cannot allocate memory
2013/09/24 00:01:08 kid1| WARNING: Cannot run '/usr/bin/ntlm_auth' process.
2013/09/24 00:01:08 kid1| ipcCreate: fork: (12) Cannot allocate memory
2013/09/24 00:01:08 kid1| WARNING: Cannot run '/usr/bin/ntlm_auth' process.
2013/09/24 00:01:08 kid1| ipcCreate: fork: (12) Cannot allocate memory
2013/09/24 00:01:08 kid1| WARNING: Cannot run '/usr/bin/ntlm_auth' process.
2013/09/24 00:01:08 kid1| ipcCreate: fork: (12) Cannot allocate memory
2013/09/24 00:01:08 kid1| WARNING: Cannot run '/usr/bin/ntlm_auth' process.
2013/09/24 00:01:08 kid1| helperOpenServers: Starting 1/10 'ntlm_auth' processes
2013/09/24 00:01:08 kid1| ipcCreate: fork: (12) Cannot allocate memory
2013/09/24 00:01:08 kid1| WARNING: Cannot run '/usr/bin/ntlm_auth' process.
2013/09/24 00:01:08 kid1| helperOpenServers: Starting 1/50 
'ext_wbinfo_group_acl' processes
2013/09/24 00:01:08 kid1| ipcCreate: fork: (12) Cannot allocate memory

mgr:ntlmauthenticator

NTLM Authenticator Statistics:
program: /usr/bin/ntlm_auth
number active: 40 of 60 (77 shutting down)
requests sent: 9021339
replies received: 9021339
queue length: 0
avg service time: 0 msec


Below is output from mgr:info at the same time the above mgr:ntlmauthenticator 
was run..

Squid Object Cache: Version 3.3.5
Start Time: Wed, 18 Sep 2013 04:48:06 GMT
Current Time:   Mon, 30 Sep 2013 03:50:02 GMT
Connection information for squid:
Number of clients accessing cache:  3540
Number of HTTP requests received:   47586765
Number of ICP messages received:0
Number of ICP messages sent:0
Number of queued ICP replies:   0
Number of HTCP messages received:   0
Number of HTCP messages sent:   0
Request failure ratio:   0.00
Average HTTP requests per minute since start:   2763.2
Average ICP messages per minute since start:0.0
Select loop called: 1816815750 times, 0.569 ms avg
Cache information for squid:
Hits as % of all requests:  5min: 13.2%, 60min: 17.0%

Re: [squid-users] NTLM connection pinning (passthrough) not working on squid 3.1.20

[Amos Jeffries]

On 14/09/2013 3:15 a.m., John/SML wrote:

Hi,

When I upgraded from squid 2.7 to squid 3.1 on Debian 7.1.0, it is found
that the NTLM connection pinning (NTLM passthrough) not working any
longer.

I hope someone could inform the status of NTLM connection pinning, whether
I should upgrade to 3.3 or downgrade to 2.7.


Try a upgrade first. You can still downgrade to 2.7 if you have to later.

Amos

[squid-users] NTLM connection pinning (passthrough) not working on squid 3.1.20

[John/SML]

Hi,

When I upgraded from squid 2.7 to squid 3.1 on Debian 7.1.0, it is found 
that the NTLM connection pinning (NTLM passthrough) not working any 
longer. 

I hope someone could inform the status of NTLM connection pinning, whether 
I should upgrade to 3.3 or downgrade to 2.7.

Thanks a lot.

John Mok 

Re: [squid-users] NTLM Authentication Win XP

[Amos Jeffries]

On 29/06/2013 12:16 p.m., Eric Vanderveer wrote:

I have an Ubuntu 12.04.2 LTS running DG and Squid I have no problems
with surfing on Win 7 but XP always prompts for a user and pass and
will never accept anything I give it. I get this toward the end of the
negotiation in my cache.log file.

negotiate_wrapper: received type 120 NTLM token
2013/06/28 20:15:01| negotiate_wrapper: Return 'NA = NT_STATUS_UNSUCCESSFUL


I am out of ideas. Anyone?


Type 120 is weird. NTLM tokens come in type 1 (client request), type 2 
(proxy/server challenge) and type 3 (client credentials).


This has been seen before. I suspect that it means your AD backed (or 
the client) is using NTLMv2 with encrypted security extensions. That 
does not matter to Squid, but may matter to the negotiate_wrapper script 
which need to decode the token to decide which helper they go to.


Amos

[squid-users] NTLM Authentication Win XP

[Eric Vanderveer]

I have an Ubuntu 12.04.2 LTS running DG and Squid I have no problems
with surfing on Win 7 but XP always prompts for a user and pass and
will never accept anything I give it. I get this toward the end of the
negotiation in my cache.log file.

negotiate_wrapper: received type 120 NTLM token
2013/06/28 20:15:01| negotiate_wrapper: Return 'NA = NT_STATUS_UNSUCCESSFUL


I am out of ideas. Anyone?
Thanks

Eric Vanderveer

Re: [squid-users] ntlm and yahoo messenger

[Peter Benko]

On Sat, May 04, 2013 at 10:48:43PM +0530, Prathyush wrote:
> HI,
> 
> Yahoo messenger not working in squid with ntlm auth .
> Any suggestions ? or how I can make it work
> 

In the past I had the same problem with Negotiate authentication.
The final solution was to disable authentication for the following
domains/IPs:
.yahoo.com
.yimg.com
66.196.64.0/18

HTH.

-- 
Peter Benko

Re: [squid-users] ntlm and yahoo messenger

[Amos Jeffries]

On 5/05/2013 5:18 a.m., Prathyush wrote:

HI,

Yahoo messenger not working in squid with ntlm auth .
Any suggestions ? or how I can make it work


It would be a good idea to figure out what the problem actually is first.

* Does YahooMessenger support NTLM at all?
* Does the OS YahooMessenger is being run on Support NTLM at all ? (note 
that Windows XP was the last OS system that supported NTLM out of the box).
* Is squid configured in a way that enables NTLM to work? (persistent 
connections enabled with both clients and servers)

* What version of Squid?
* Is Squid configured with NTLM authentication and how? or is Squid just 
relaying it somewhere else?


... and lots more.

Amos

[squid-users] ntlm and yahoo messenger

[Prathyush]

HI,

Yahoo messenger not working in squid with ntlm auth .
Any suggestions ? or how I can make it work



--
Regards,
Prathyush

Re: [squid-users] NTLM passthu

[Alexandre Chappaz]

Hi,

In fact I made a wrong manipulation while appling the patch.
When applied correctly, the provided patch does fix the pinning
problem and the authentaction to IIS works.

thanks
Alex

2012/10/11 Wolfgang Breyha :
> Alexandre Chappaz wrote, on 11.10.2012 15:57:
>> Applied the patch on both 3.2.1 and 3.2.2 . Same result.
>> I'll post on your bug report.
>>
>> In the meantime, is there some additional info that could help to debug?
>
> At least I can't help in this matter because my knowledge about squid source
> code is still very limited. I thought I understood all the stuff about pinning
> and ntlm/negotiate passthrough. It was enough to "fix" our troubles, but
> obviously not to fix yours;-) I currently do not have the spare time to debug
> any further. Sorry.
>
> Greetings, Wolfgang
> --
> Wolfgang Breyha  | http://www.blafasel.at/
> Vienna University Computer Center | Austria
>

Re: [squid-users] NTLM passthu

[Wolfgang Breyha]

Alexandre Chappaz wrote, on 11.10.2012 15:57:
> Applied the patch on both 3.2.1 and 3.2.2 . Same result.
> I'll post on your bug report.
> 
> In the meantime, is there some additional info that could help to debug?

At least I can't help in this matter because my knowledge about squid source
code is still very limited. I thought I understood all the stuff about pinning
and ntlm/negotiate passthrough. It was enough to "fix" our troubles, but
obviously not to fix yours;-) I currently do not have the spare time to debug
any further. Sorry.

Greetings, Wolfgang
-- 
Wolfgang Breyha  | http://www.blafasel.at/
Vienna University Computer Center | Austria

Re: [squid-users] NTLM passthu

[Alexandre Chappaz]

Applied the patch on both 3.2.1 and 3.2.2 . Same result.
I'll post on your bug report.

In the meantime, is there some additional info that could help to debug?


2012/10/11 Wolfgang Breyha :
> Alexandre Chappaz wrote, on 11.10.2012 15:42:
>> Yes I have seen this bug and applied the patch right now.
>>
>> with patch applied, behavior is a bit different :
>>
>> after asking for credentials, I get a connexion reset.
>
> Did you use 3.2.2 or 3.2.1? My patch is for 3.2.1. Don't know if it still
> works on 3.2.2.
>
> If it doesn't work on 3.2.1 either it's bad because this is not trivial to 
> debug.
>
> Maybe you want to comment on my bugreport that my patch doesn't fix it for 
> you.
>
> Greetings, Wolfgang
> --
> Wolfgang Breyha  | http://www.blafasel.at/
> Vienna University Computer Center | Austria
>

Re: [squid-users] NTLM passthu

[Wolfgang Breyha]

Alexandre Chappaz wrote, on 11.10.2012 15:42:
> Yes I have seen this bug and applied the patch right now.
> 
> with patch applied, behavior is a bit different :
> 
> after asking for credentials, I get a connexion reset.

Did you use 3.2.2 or 3.2.1? My patch is for 3.2.1. Don't know if it still
works on 3.2.2.

If it doesn't work on 3.2.1 either it's bad because this is not trivial to 
debug.

Maybe you want to comment on my bugreport that my patch doesn't fix it for you.

Greetings, Wolfgang
-- 
Wolfgang Breyha  | http://www.blafasel.at/
Vienna University Computer Center | Austria

Re: [squid-users] NTLM passthu

[Alexandre Chappaz]

Yes I have seen this bug and applied the patch right now.

with patch applied, behavior is a bit different :

after asking for credentials, I get a connexion reset.

and from access log :

1349962782.169  9 10.XXX.XXX.XXX TCP_MISS/401 436 GET
http://www.si-diamant.fr/ - HIER_DIRECT/94.124.232.64 -




2012/10/11 Wolfgang Breyha :
> Alexandre Chappaz wrote, on 11.10.2012 14:45:
>> Is this a regression? Shoudl I file a bug?
>
> There already is a bug and a proposed fix
> http://bugs.squid-cache.org/show_bug.cgi?id=3655
>
> Greetings, Wolfgang
> --
> Wolfgang Breyha  | http://www.blafasel.at/
> Vienna University Computer Center | Austria
>

Re: [squid-users] NTLM passthu

[Wolfgang Breyha]

Alexandre Chappaz wrote, on 11.10.2012 14:45:
> Is this a regression? Shoudl I file a bug?

There already is a bug and a proposed fix
http://bugs.squid-cache.org/show_bug.cgi?id=3655

Greetings, Wolfgang
-- 
Wolfgang Breyha  | http://www.blafasel.at/
Vienna University Computer Center | Austria

[squid-users] NTLM passthu

[Alexandre Chappaz]

Hi,

since upgrade from 3.1.20 to 3.2.1, we are facing a problem regarding
access to a IIS server with authentication :

the popup asking for credentials keeps poping out and make the
browsing impossibe.
I observed the same behavior with latest 3.2.2 version (r11676 ).

On the contrary, using 3.1.20 and same config, everything is fine.


Is this a regression? Shoudl I file a bug?

Thanks
Alex

[squid-users] NTLM Authentication Issues

[Baird, Josh]

Hi,

Running squid-2.6STABLE-6.el5 (RHEL5) here.  Trying to configure NTLM 
authentication.  I successfully configured krb/samba and have verified 
successful authentication using:

$ /usr/bin/ntlm_auth --username=jbaird
password:
NT_STATUS_OK: Success (0x0)

I can also enumerate groups and users successfully using "wbinfo -u" and 
"wbinfo -g"

However, when I add the squid-2.5-basic helper to ntlm_auth, I receive "ERR":

$ /usr/bin/ntlm_auth --helper-protocol=squid-2.5-basic
na+jbaird 
ERR

I believe this is causing my squid configuration to fail:


# NTLM configuration
auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 30
acl NTLMUsers proxy_auth REQUIRED
http_access allow all NTLMUsers


Does anyone have any tips on how to troubleshoot?  Should I be using a 
different helper-protocol for ntlm_auth?

Thanks,

Josh

Re: [squid-users] NTLM auth to remote server fails through squid

[Amos Jeffries]

On 18.07.2012 02:07, Peter Olsson wrote:

On Tue, Jul 17, 2012 at 02:43:44PM +1200, Amos Jeffries wrote:

On 17.07.2012 07:35, Peter Olsson wrote:
> Hello!
>
> On Mon, Jul 16, 2012 at 09:03:00PM +0300, Eliezer Croitoru wrote:
>> On 7/16/2012 7:05 PM, Peter Olsson wrote:
>> > We're trying to connect to a remote server that
>> > requires authentication. This works fine when
>> > we place the browser client on the Internet, but
>> > when we place the browser client behind squid the
>> > authentication popup just returns without accepting
>> > the login.
>> can you please be more specific about the topology?
>
> My test setup is very easy. Just a single squid server
> in plain proxy mode, using two network interfaces.
> One interface towards Internet, the other running a
> private network.
>
> I have a single PC client connected to the private interface
> in the squid server. There is no connection from the private
> network to the Internet without passing through the squid proxy.
>
> The squid server is running 3.2.0.18, with the default
> squid.conf installed by the 3.2.0.18 tarball. Only differences
> from default squid.conf are my added visible_hostname and
> changed http_port from 3128 to 80.

Why?
  visible_hostname defaults to the machine system hostname.


Since this is a test server that moves around occasionally,
I don't usually have anything in it's /etc/hosts. This seems
to upset squid, which gives this error:
WARNING: Could not determine this machines public hostname.
(It's a FreeBSD 9.0 if that matters.)


/etc/hosts is not related.

There is /etc/hostname config which is required to be set to some value 
on every Internet server machine. This is mandatory and is required to 
be a DNS resolvable domain name whioch reverse-resolves to the same 
name. It MAY be a single label which require appending a domain or 
search value from /etc/resolv.conf as well - which Squid tries.


The only reason visible_hostname needs setting is when you have broken 
the most basic connectivity requirements for Internet machines.
 NP: /etc/hosts is just a quick way to ensure the /etc/hostname meets 
those resolvable requirements even when DNS is broken or unavailable.




> There is no transparency or
> routing between interfaces configured in the squid server,
> just plain proxy from inside to outside.
>
> The external server I'm trying to reach is on the Internet.
> If I try to connect to this server through squid, I don't
> get authenticated. If I however move the PC client to the
> Internet, so it doesn't pass through squid, the authentication
> to the external server works fine.

There is a growing collection of known MS software which cannot 
handle

the HTTP/1.0<->HTTP1/.1 gateway nature of Squid-3.1 series. But this
should not be an issue with 3.2 series.

Please update to the latest beta though before doing more testing.
3.2.0.20 is out and the latest snapshot has some relevant bug fixes.

3.2 would be best to test with since it provide a full HTTP header
trace at "debug_options 11,2". Those header trace will be the best
starting point to track this down.


Now I run Squid 3.2.0.18-20120717-r11615. Configuration is default
except that I have added debug_options 11,2 at the top of squid.conf.

Same problem in IE 9, three auth popups and then the browser error 
page:

You are not authorized to view this page
HTTP Error 401.1

One thing I forgot to mention yesterday is that there is a rather
long wait (about 20-30 seconds) before the first auth popup.
Then there is a shorter wait (a couple of seconds) for the second
popup, and the third popup comes up immediately after the second
has been entered.

I don't see anything strange in cache.log, what should I look for?


Some lines that say "HTTP Client Request"..."HTTP Server Request" 
..."HTTP Server Reply" ... "HTTP Client Reply" ... with TCP connection 
details and each followed by a dump of the HTTP message headers. These 
four sets of headers form one transaction.


There will be multiple transactions for each popup on NTLM.



Or can I post the debug to the list or in private email?


If you wish. Make sure its a test account for the credentials though if 
it goes to the list - we may need the actual auth tokens un-obfuscated 
to check its syntax and details.



It's about 600 lines in total for the three failed auth attempts.



Amos

Re: [squid-users] NTLM auth to remote server fails through squid

[Peter Olsson]

On Tue, Jul 17, 2012 at 02:43:44PM +1200, Amos Jeffries wrote:
> On 17.07.2012 07:35, Peter Olsson wrote:
> > Hello!
> >
> > On Mon, Jul 16, 2012 at 09:03:00PM +0300, Eliezer Croitoru wrote:
> >> On 7/16/2012 7:05 PM, Peter Olsson wrote:
> >> > We're trying to connect to a remote server that
> >> > requires authentication. This works fine when
> >> > we place the browser client on the Internet, but
> >> > when we place the browser client behind squid the
> >> > authentication popup just returns without accepting
> >> > the login.
> >> can you please be more specific about the topology?
> >
> > My test setup is very easy. Just a single squid server
> > in plain proxy mode, using two network interfaces.
> > One interface towards Internet, the other running a
> > private network.
> >
> > I have a single PC client connected to the private interface
> > in the squid server. There is no connection from the private
> > network to the Internet without passing through the squid proxy.
> >
> > The squid server is running 3.2.0.18, with the default
> > squid.conf installed by the 3.2.0.18 tarball. Only differences
> > from default squid.conf are my added visible_hostname and
> > changed http_port from 3128 to 80.
> 
> Why?
>   visible_hostname defaults to the machine system hostname.

Since this is a test server that moves around occasionally,
I don't usually have anything in it's /etc/hosts. This seems
to upset squid, which gives this error:
WARNING: Could not determine this machines public hostname.
(It's a FreeBSD 9.0 if that matters.)

>   port 80 is likely to have interference from any number of firewall, 
> IDS or other software digging its fingers into the traffic.

80 for historic reasons, and there are no firewalls or other
in the way.

But to keep to default configuration as much as possible,
I have now reverted to 3128 and added the server to /etc/hosts.

> > There is no transparency or
> > routing between interfaces configured in the squid server,
> > just plain proxy from inside to outside.
> >
> > The external server I'm trying to reach is on the Internet.
> > If I try to connect to this server through squid, I don't
> > get authenticated. If I however move the PC client to the
> > Internet, so it doesn't pass through squid, the authentication
> > to the external server works fine.
> 
> There is a growing collection of known MS software which cannot handle 
> the HTTP/1.0<->HTTP1/.1 gateway nature of Squid-3.1 series. But this 
> should not be an issue with 3.2 series.
> 
> Please update to the latest beta though before doing more testing. 
> 3.2.0.20 is out and the latest snapshot has some relevant bug fixes.
> 
> 3.2 would be best to test with since it provide a full HTTP header 
> trace at "debug_options 11,2". Those header trace will be the best 
> starting point to track this down.

Now I run Squid 3.2.0.18-20120717-r11615. Configuration is default
except that I have added debug_options 11,2 at the top of squid.conf.

Same problem in IE 9, three auth popups and then the browser error page:
You are not authorized to view this page
HTTP Error 401.1

One thing I forgot to mention yesterday is that there is a rather
long wait (about 20-30 seconds) before the first auth popup.
Then there is a shorter wait (a couple of seconds) for the second
popup, and the third popup comes up immediately after the second
has been entered.

I don't see anything strange in cache.log, what should I look for?
Or can I post the debug to the list or in private email?
It's about 600 lines in total for the three failed auth attempts.

Thanks!

Peter Olsson

Re: [squid-users] NTLM auth to remote server fails through squid

[Amos Jeffries]

On 17/07/2012 7:22 p.m., Warren Baker wrote:


On Tue, Jul 17, 2012 at 4:43 AM, Amos Jeffries > wrote:




Please update to the latest beta though before doing more testing.
3.2.0.20 is out and the latest snapshot has some relevant bug fixes.


I'm only seeing 3.2.0.18 and 3 daily auto-generated releases on 
http://www.squid-cache.org/Versions/v3/3.2/ . Am i missing something?


Sorry. Been time-travelling.  Confusing 3.1.20 and 3.2 series.

I meant to refer you to the latest daily snapshot of 3.2.

Amos

Re: [squid-users] NTLM auth to remote server fails through squid

[Warren Baker]

On Tue, Jul 17, 2012 at 4:43 AM, Amos Jeffries  wrote:
>
> Please update to the latest beta though before doing more testing. 3.2.0.20 
> is out and the latest snapshot has some relevant bug fixes.
>

I'm only seeing 3.2.0.18 and 3 daily auto-generated releases on
http://www.squid-cache.org/Versions/v3/3.2/ . Am i missing something?


thanks

-- 
.warren

Re: [squid-users] NTLM auth to remote server fails through squid

[Amos Jeffries]

On 17.07.2012 07:35, Peter Olsson wrote:

Hello!

On Mon, Jul 16, 2012 at 09:03:00PM +0300, Eliezer Croitoru wrote:

On 7/16/2012 7:05 PM, Peter Olsson wrote:
> We're trying to connect to a remote server that
> requires authentication. This works fine when
> we place the browser client on the Internet, but
> when we place the browser client behind squid the
> authentication popup just returns without accepting
> the login.
can you please be more specific about the topology?


My test setup is very easy. Just a single squid server
in plain proxy mode, using two network interfaces.
One interface towards Internet, the other running a
private network.

I have a single PC client connected to the private interface
in the squid server. There is no connection from the private
network to the Internet without passing through the squid proxy.

The squid server is running 3.2.0.18, with the default
squid.conf installed by the 3.2.0.18 tarball. Only differences
from default squid.conf are my added visible_hostname and
changed http_port from 3128 to 80.


Why?
 visible_hostname defaults to the machine system hostname.
 port 80 is likely to have interference from any number of firewall, 
IDS or other software digging its fingers into the traffic.




There is no transparency or
routing between interfaces configured in the squid server,
just plain proxy from inside to outside.

The external server I'm trying to reach is on the Internet.
If I try to connect to this server through squid, I don't
get authenticated. If I however move the PC client to the
Internet, so it doesn't pass through squid, the authentication
to the external server works fine.


There is a growing collection of known MS software which cannot handle 
the HTTP/1.0<->HTTP1/.1 gateway nature of Squid-3.1 series. But this 
should not be an issue with 3.2 series.


Please update to the latest beta though before doing more testing. 
3.2.0.20 is out and the latest snapshot has some relevant bug fixes.


3.2 would be best to test with since it provide a full HTTP header 
trace at "debug_options 11,2". Those header trace will be the best 
starting point to track this down.


Amos

Re: [squid-users] NTLM auth to remote server fails through squid

[Peter Olsson]

Hello!

On Mon, Jul 16, 2012 at 09:03:00PM +0300, Eliezer Croitoru wrote:
> On 7/16/2012 7:05 PM, Peter Olsson wrote:
> > We're trying to connect to a remote server that
> > requires authentication. This works fine when
> > we place the browser client on the Internet, but
> > when we place the browser client behind squid the
> > authentication popup just returns without accepting
> > the login.
> can you please be more specific about the topology?

My test setup is very easy. Just a single squid server
in plain proxy mode, using two network interfaces.
One interface towards Internet, the other running a
private network.

I have a single PC client connected to the private interface
in the squid server. There is no connection from the private
network to the Internet without passing through the squid proxy.

The squid server is running 3.2.0.18, with the default
squid.conf installed by the 3.2.0.18 tarball. Only differences
from default squid.conf are my added visible_hostname and
changed http_port from 3128 to 80. There is no transparency or
routing between interfaces configured in the squid server,
just plain proxy from inside to outside.

The external server I'm trying to reach is on the Internet.
If I try to connect to this server through squid, I don't
get authenticated. If I however move the PC client to the
Internet, so it doesn't pass through squid, the authentication
to the external server works fine.

Thanks!

Peter Olsson

> it's kind of fog to me.
> if you can out up some IP's for the devices and network relationship 
> will be very helpful.
> if you can attach squid.conf it will be more efficient.
> 
> 
> > What could be the reason for this auth failure?
> > What debug values should I use?
> >
> > NB: This is not about authenticating to the proxy server,
> > we allow proxy connections from inside without authentication.
> > The question is about authenticating to an external server
> > that is out of our control.
> please describe more the position of the client and server,
> proxy and server.
> 
> Eliezer
> 
> >
> > Thanks!
> >
> 
> 
> -- 
> Eliezer Croitoru
> https://www1.ngtech.co.il
> IT consulting for Nonprofit organizations
> eliezer  ngtech.co.il
> 

-- 
Peter Olssonp...@leissner.se

Re: [squid-users] NTLM auth to remote server fails through squid

[Eliezer Croitoru]

On 7/16/2012 7:05 PM, Peter Olsson wrote:

We're trying to connect to a remote server that
requires authentication. This works fine when
we place the browser client on the Internet, but
when we place the browser client behind squid the
authentication popup just returns without accepting
the login.

can you please be more specific about the topology?
it's kind of fog to me.
if you can out up some IP's for the devices and network relationship 
will be very helpful.

if you can attach squid.conf it will be more efficient.



What could be the reason for this auth failure?
What debug values should I use?

NB: This is not about authenticating to the proxy server,
we allow proxy connections from inside without authentication.
The question is about authenticating to an external server
that is out of our control.

please describe more the position of the client and server,
proxy and server.

Eliezer



Thanks!




--
Eliezer Croitoru
https://www1.ngtech.co.il
IT consulting for Nonprofit organizations
eliezer  ngtech.co.il

[squid-users] NTLM auth to remote server fails through squid

[Peter Olsson]

We're trying to connect to a remote server that
requires authentication. This works fine when
we place the browser client on the Internet, but
when we place the browser client behind squid the
authentication popup just returns without accepting
the login.

I have tried Squid 3.1.19 and 3.2.0.18. Browsers are
IE 9 and Firefox 13.

Here is an extract of the HTTP Server reply:
Connection: Keep-Alive
Server: Microsoft-IIS/6.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM

The squid configuration in the test server is default,
except that I have added visible_hostname and changed
http_port to 80.

What could be the reason for this auth failure?
What debug values should I use?

NB: This is not about authenticating to the proxy server,
we allow proxy connections from inside without authentication.
The question is about authenticating to an external server
that is out of our control.

Thanks!

-- 
Peter Olssonp...@leissner.se

[squid-users] NTLM auth fails, Authentication pop-up keeps showing up but also fails! Squid

[Mike]

Hi all,

Has the subject says, I'm having problems with NTLM in *some* users, the
logs show this when I request the page

At first I tough this was related to a problem in some Windows 7 Laptops
that don't have the reg key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa  - DWORD 
LmCompatibilityLevel -> set to 1 to use LM NTLM and NTLMv2.

The key was missing in the 2 laptops giving me the problem, but adding
it and rebooting didn't solve the problem

When the user opens IE/site (ntlm auth) I see this on cache.log:

NTLMSSP challenge
2012/07/13 11:23:11.043| ConnStateData::swanSong: FD 33
Got 'YR
TlRMTVNTUAADGAAYAJQYABgArAoACgBYGgAaAGIYABgAfADEBYKIogYBsR0PHKcl6C2DGcPhZg1gFNMQqUMAQQBMAEUATQBDAGEAcgBsAGEAQwBhAHIAdgBhAGwAaABvAFcARABMAEgAUAA2ADMAMABOAEwAMAAyAJ3X1msrdlsCAL0k3O/g5/bRhTcU9HDH3PpqgbCc4abP4w=='
from squid (length: 267).
got NTLMSSP packet:
got NTLMSSP command 3, expected 1
NTLMSSP NT_STATUS_INVALID_PARAMETER
2012/07/13 11:23:11.256| ConnStateData::swanSong: FD 33


This is when I send the "basic auth"
Got 'YR TlRMTVNTUAABB4IIogAGAbEdDw==' from
squid (length: 59).
got NTLMSSP packet:
Got NTLMSSP neg_flags=0xa2088207
  NTLMSSP_NEGOTIATE_UNICODE
  NTLMSSP_NEGOTIATE_OEM
  NTLMSSP_REQUEST_TARGET
  NTLMSSP_NEGOTIATE_NTLM
  NTLMSSP_NEGOTIATE_ALWAYS_SIGN
  NTLMSSP_NEGOTIATE_NTLM2
  NTLMSSP_NEGOTIATE_VERSION
  NTLMSSP_NEGOTIATE_128
  NTLMSSP_NEGOTIATE_56
NTLMSSP challenge
2012/07/13 11:23:33.226| ConnStateData::swanSong: FD 13
Got 'YR
TlRMTVNTUAADGAAYAJQYABgArAoACgBYGgAaAGIYABgAfADEBYKIogYBsR0P0dxfDL0xcw63QgT5XihRs0MAQQBMAEUATQBDAGEAcgBsAGEAQwBhAHIAdgBhAGwAaABvAFcARABMAEgAUAA2ADMAMABOAEwAMAAyAHncwjOdiQMNAGh+wPIBTsJQcYCTWvqvSQWmEPgrgyxOnw=='
from squid (length: 267).
got NTLMSSP packet:
got NTLMSSP command 3, expected 1
NTLMSSP NT_STATUS_INVALID_PARAMETER
2012/07/13 11:23:39.436| ConnStateData::swanSong: FD 13
2012/07/13 11:23:40.451| ConnStateData::swanSong: FD 13

More info about my setup:

squid -v
Squid Cache: Version 3.1.19
configure options:  '--sysconfdir=/usr/pkg/etc/squid'
'--localstatedir=/var/squid' '--datarootdir=/usr/pkg/share/squid'
'--enable-auth=basic,digest,ntlm' '--enable-cachemgr-hostname=localhost'
'--enable-delay-pools' '--enable-icmp'
'--enable-removal-policies=lru,heap' '--enable-poll'
'--enable-storeio=ufs diskd' '--with-aio'
'--disable-strict-error-checking' '--enable-icap-client'
'--with-default-user=squid' '--with-pidfile=/var/run/squid.pid'
'--enable-ipf-transparent' '--enable-carp' '--enable-snmp'
'--enable-ssl' '--with-openssl=/usr'
'--enable-basic-auth-helpers=getpwnam MSNT NCSA YP PAM'
'--enable-digest-auth-helpers=password'
'--enable-ntlm-auth-helpers=fakeauth'
'--enable-external-acl-helpers=ip_user unix_group' '--prefix=/usr/pkg'
'--build=x86_64--netbsd' '--host=x86_64--netbsd' '--mandir=/usr/pkg/man'
'build_alias=x86_64--netbsd' 'host_alias=x86_64--netbsd' 'CC=gcc'
'CFLAGS=-O2 -I/usr/include' 'LDFLAGS=-L/usr/lib -Wl,-R/usr/lib
-Wl,-R/usr/pkg/lib' 'LIBS=' 'CPPFLAGS=-I/usr/include' 'CXX=c++'
'CXXFLAGS=-O2 -I/usr/include'
--with-squid=/scratch/www/squid31/work/squid-3.1.19
--enable-ltdl-convenience

Samba Version 3.6.5

OS: netbsd-6, samba and squid installed from pkgsrc



Note: I do not have kerbuerus auth set up, because this is no easy task
on netbsd, I still need to research on this.

Re: [squid-users] NTLM and Kerberos with IE6

[Amos Jeffries]

On 30/06/2012 11:36 p.m., Navas wrote:

Hi,

I have setup squid authentication with Kerberos to the 2003 Active
Directory. I could test it successfully to all browsers but failed in IE6.
So I used following squid.conf to get NTLM auth for IE6

#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
#auth_param negotiate program  /usr/sbin/squid_kerb_auth -d
auth_param negotiate program /usr/local/bin/negotiate_wrapper -d --ntlm
/usr/bin/ntlm_auth --diagnostics --helper-protocol=squid-2.5-ntlmssp
--domain=SYSNET.LOCAL --kerberos /usr/sbin/squid_kerb_auth -d -s
GSS_C_NO_NAME
auth_param negotiate children 10
auth_param negotiate keep_alive on

### pure ntlm authentication
auth_param ntlm program /usr/bin/ntlm_auth --diagnostics
--helper-protocol=squid-2.5-ntlmssp --domain=SYSNET.LOCAL
auth_param ntlm children 10
auth_param ntlm keep_alive off
acl auth proxy_auth REQUIRED

But the question is it need separate configuration as in ### pure ntlm
authentication for specifically for NTLM?
Is it never work with first entries only which supposed to be worked with
both NTLM and Kerberos ?


Yes it needs to be a seprate configuration for IE6 and older software 
which only supports "pure" NTLM.


The newer software will know that NTLM can be reponded using 
Negotiate/NTLM. But then you would not have had problems with negotiate 
to start with if they were doing that properly.


Amos

[squid-users] NTLM and Kerberos with IE6

[Navas]

Hi,

I have setup squid authentication with Kerberos to the 2003 Active
Directory. I could test it successfully to all browsers but failed in IE6.
So I used following squid.conf to get NTLM auth for IE6

#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
#auth_param negotiate program  /usr/sbin/squid_kerb_auth -d
auth_param negotiate program /usr/local/bin/negotiate_wrapper -d --ntlm
/usr/bin/ntlm_auth --diagnostics --helper-protocol=squid-2.5-ntlmssp
--domain=SYSNET.LOCAL --kerberos /usr/sbin/squid_kerb_auth -d -s
GSS_C_NO_NAME
auth_param negotiate children 10
auth_param negotiate keep_alive on

### pure ntlm authentication
auth_param ntlm program /usr/bin/ntlm_auth --diagnostics
--helper-protocol=squid-2.5-ntlmssp --domain=SYSNET.LOCAL
auth_param ntlm children 10
auth_param ntlm keep_alive off
acl auth proxy_auth REQUIRED

But the question is it need separate configuration as in ### pure ntlm
authentication for specifically for NTLM?
Is it never work with first entries only which supposed to be worked with
both NTLM and Kerberos ? 

Thanks,

Br
abusam

Re: [squid-users] NTLM and persistent connections reverse proxy 3.1.20

[Amos Jeffries]

On 11/06/2012 8:11 p.m., James Harper wrote:

I'm having some problems with reverse proxy and NTLM authentication. 
Specifically, the connection to the client is not persisted which I believe 
invalidates the NTLM authentication protocol. I've added a source port number 
to the logs which shows that it is indeed creating a new connection for each 
request. There seems to have been a bit of mailing list activity about similar 
problems but nothing exactly the same and none of the suggested solutions work. 
My config (hostnames and IP's removed) is this:

https_port IPADDRESS:443 accel cert=/etc/squid3/apps..com.au.pem 
defaultsite=apps..com.au connection-auth=on
cache_peercom1..local parent 443 0 proxy-only no-query no-digest 
originserver login=PROXYPASS name=com1 ssl sslflags=DONT_VERIFY_PEER
cache_peerweb1..local parent 80 0 proxy-only no-query no-digest 
front-end-https=on connection-auth=on originserver login=PROXYPASS name=web1
cache_peersvr6..local parent 80 0 no-query no-digest originserver 
login=PROXYPASS name=svr6


Try it with "login=PASS" instead of "login=PROXYPASS".

see http://wiki.squid-cache.org/ConfigExamples/Reverse/ExchangeRpc

Amos

[squid-users] NTLM and persistent connections reverse proxy 3.1.20

[James Harper]

I'm having some problems with reverse proxy and NTLM authentication. 
Specifically, the connection to the client is not persisted which I believe 
invalidates the NTLM authentication protocol. I've added a source port number 
to the logs which shows that it is indeed creating a new connection for each 
request. There seems to have been a bit of mailing list activity about similar 
problems but nothing exactly the same and none of the suggested solutions work. 
My config (hostnames and IP's removed) is this:

https_port IPADDRESS:443 accel cert=/etc/squid3/apps..com.au.pem 
defaultsite=apps..com.au connection-auth=on
cache_peer com1..local parent 443 0 proxy-only no-query no-digest 
originserver login=PROXYPASS name=com1 ssl sslflags=DONT_VERIFY_PEER
cache_peer web1..local parent 80 0 proxy-only no-query no-digest 
front-end-https=on connection-auth=on originserver login=PROXYPASS 
name=web1
cache_peer svr6..local parent 80 0 no-query no-digest originserver 
login=PROXYPASS name=svr6
acl dst_apps dstdomain apps..com.au
acl exchange_path urlpath_regex ^\/owa$ fast
acl exchange_path urlpath_regex ^\/owa\/.* fast
acl exchange_path urlpath_regex ^\/Microsoft-Server-ActiveSync\/.* fast
acl rpc_path urlpath_regex ^\/rpc\/.* fast
acl mantis_path urlpath_regex ^\/mantis$ fast
acl mantis_path urlpath_regex ^\/mantis\/.* fast
never_direct allow dst_apps
cache_peer_access com1 allow dst_apps exchange_path
cache_peer_access com1 deny all
cache_peer_access web1 allow dst_apps rpc_path
cache_peer_access web1 deny all
cache_peer_access svr6 allow dst_apps mantis_path
cache_peer_access svr6 deny all
http_access allow dst_apps
acl manager proto cache_object
acl localhost src 127.0.0.1/32 ::1
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
acl SSL_ports port 443
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
http_access deny all
http_port 3128
logformat squidextra %ts.%03tu %6tr %>a %Ss/%03>Hs %p %h] [%>ha] [%https://apps..com.au/rpc/rpcproxy.dll? - FIRST_UP_PARENT/web1 
text/plain 55928 - [Cache-Control: no-cache\r\nConnection: 
Keep-Alive\r\nPragma: 
ResourceTypeUuid=44e265dd-7daf-42cd-8560-3cdb6e7a2729\r\nAccept: 
application/rpc\r\nUser-Agent: MSRPC\r\nContent-Length: 0\r\nHost: 
apps..com.au\r\nAuthorization: NTLM \r\n] [Cache-Control: 
no-cache\r\nConnection: Keep-Alive\r\nPragma: 
ResourceTypeUuid=44e265dd-7daf-42cd-8560-3cdb6e7a2729\r\nAccept: 
application/rpc\r\nUser-Agent: MSRPC\r\nContent-Length: 0\r\nHost: 
apps..com.au\r\nAuthorization: NTLM \r\n] [HTTP/1.1 401 
Unauthorized\r\nContent-Type: text/plain\r\nServer: 
Microsoft-IIS/7.5\r\nWWW-Authenticate: NTLM \r\nWWW-Authenticate: 
Negotiate\r\nWWW-Authenticate: Basic 
realm="apps..com.au"\r\nX-Powered-By: ASP.NET\r\nDate: Mon, 11 Jun 2012 
07:38:40 GMT\r\nContent-Length: 13\r\n\r]
1339400327.572  1 IPADDRESS TCP_MISS/401 410 RPC_IN_DATA 
https://apps..com.au/rpc/rpcproxy.dll? - FIRST_UP_PARENT/web1 
text/plain 55929 - [Cache-Control: no-cache\r\nConnection: 
Keep-Alive\r\nPragma: 
ResourceTypeUuid=44e265dd-7daf-42cd-8560-3cdb6e7a2729\r\nAccept: 
application/rpc\r\nUser-Agent: MSRPC\r\nContent-Length: 1073741824\r\nHost: 
apps..com.au\r\nAuthorization: NTLM \r\n] [Cache-Control: 
no-cache\r\nConnection: Keep-Alive\r\nPragma: 
ResourceTypeUuid=44e265dd-7daf-42cd-8560-3cdb6e7a2729\r\nAccept: 
application/rpc\r\nUser-Agent: MSRPC\r\nContent-Length: 1073741824\r\nHost: 
apps..com.au\r\nAuthorization: NTLM \r\n] [HTTP/1.1 401 
Unauthorized\r\nContent-Type: text/plain\r\nServer: 
Microsoft-IIS/7.5\r\nWWW-Authenticate: Negotiate\r\nWWW-Authenticate: 
NTLM\r\nWWW-Authenticate: Basic realm="apps..com.au"\r\nX-Powered-By: 
ASP.NET\r\nDate: Mon, 11 Jun 2012 07:38:40 GMT\r\nContent-Length: 13\r\n\r]
1339400327.801  1 IPADDRESS TCP_MISS/401 699 RPC_OUT_DATA 
https://apps..com.au/rpc/rpcproxy.dll? - FIRST_UP_PARENT/web1 
text/plain 55930 - [Cache-Control: no-cache\r\nConnection: 
Keep-Alive\r\nPragma: ResourceTypeUuid=44e265dd-7daf-42cd-8560-3cdb6e7a2729, 
SessionId=8a60d4da-0aa9-4b27-9f4f-9b1e614fbc42\r\nAccept: 
application/rpc\r\nUser-Agent: MSRPC\r\nContent-Length: 0\r\nHost: 
apps..com.au\r\nAuthorization: NTLM \r\n] [Cache-Control: 
no-cache\r\nConnection: Keep-Alive\r\nPragma: 
ResourceTypeUuid=44e265dd-7daf-42cd-8560-3cdb6e7a2729, 
SessionId=8a60d4da-0aa9-4b27-9f4f-9b1e614fbc42\r\nAccept: 
application/rpc\r\nUser-Agent: MSRPC\r\nContent-Length: 0\r\nHost: 
apps..com.au\r\nAuthorization: NTLM \r\n] [HTTP/1.1 401 
Unauthorized\r\nContent-Type: text/plain\r\nServer: 
Microsoft-IIS/7.5\r\nWWW-Authenticate: NTLM \r\nWWW-Authenticate: 
Negotiate\r\nWWW-Authenticate: Basic 
realm="apps..com.au"\r\nX-Powered-By: ASP.NET\r\nDate: Mon, 11 Jun 2012 
07:38:40 GMT\r\nContent-Length: 13\r\n\r]
1339400328.029  1 IPADDRESS TCP_MISS/401 410 RPC_OUT_DATA 
https://apps..com.au/rpc/rpcproxy.dll? - FIRST_UP_PARENT/web1 
text/plain 55931 - [Cache-C

Re: [squid-users] ntlm children

[Amos Jeffries]

On 31/05/2012 1:46 a.m., Usuário do Sistema wrote:

Hello guys, I'm with the same issue that I had some moth ago sometimes
my squid can't authenticate. follows the log from cache. log

2012/05/29 10:41:44| WARNING: up to 20 pending requests queued
2012/05/29 10:41:44| Consider increasing the number of
ntlmauthenticator processes to at least 40 in your config file

I wonder if I need grow my parameter "auth_param ntlm children". about
5 moth ago I've grown it from 5 to 20 because the same problem. until
now has been resolved.
but the problem seems come back so I wonder if there is other thing
that might to be the cause ?!?!

follow my parameter in the squid.conf

auth_param ntlm program /usr/bin/ntlm_auth becomex/srv-ad1
--helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 20
auth_param basic program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-basic
auth_param basic children 20
auth_param basic realm Controle de acesso a Internet
auth_param basic credentialsttl 2 hours

there might  are others things beyond these parameter "ntlm children" ?


There are a few things. In no particular order they are:

 increasing TCP connection persistence,
 increasing the number of helpers (children) as suggested by Squid.
 decreasing lag for Winbind lookups,
 decreasing the amount of client traffic (hahaha)
 decreasing the number of auth requests needed by Squid (ie polishing 
squid.conf access rules)

 migrating to Negotiate/Kerberos protocol

Amos

[squid-users] ntlm children

[Usuário do Sistema]

Hello guys, I'm with the same issue that I had some moth ago sometimes
my squid can't authenticate. follows the log from cache. log

2012/05/29 10:41:44| WARNING: up to 20 pending requests queued
2012/05/29 10:41:44| Consider increasing the number of
ntlmauthenticator processes to at least 40 in your config file

I wonder if I need grow my parameter "auth_param ntlm children". about
5 moth ago I've grown it from 5 to 20 because the same problem. until
now has been resolved.
but the problem seems come back so I wonder if there is other thing
that might to be the cause ?!?!

follow my parameter in the squid.conf

auth_param ntlm program /usr/bin/ntlm_auth becomex/srv-ad1
--helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 20
auth_param basic program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-basic
auth_param basic children 20
auth_param basic realm Controle de acesso a Internet
auth_param basic credentialsttl 2 hours

there might  are others things beyond these parameter "ntlm children" ?

thanks

Re: [squid-users] NTLM, non-domain machines and keep-alive

[Harry Mills]

Hi Anders,

Thanks for the suggestion. If only all software was written to support 
standards properly! I have implemented quite a few noauth acls for those 
broken applications (often Anti-Virus updaters, and iDevice Apps) and 
they are working well. Interestingly, for some requests (often destined 
for apple.com, or icloud) we see tens of requests a second being 
answered with a 407 by squid. The client app just keesp hammering away 
irrespective of the returned error Anyway - I digress!


The problem we have is we are at a school where we need to authenticate 
web access for logging, and for applying appropriate policies to groups 
of users. For domain member machines this works very well - but for non 
domain machines we can't seem to limit the authentication requests (pop 
up auth box) to just a single prompt, and keep getting 3 in a row before 
the authentication succeeds. I would love to know if anyone else has 
come across this before (we see it on Windows XP, Windows 7, IE7, IE8, 
IE9 and Chrome).


Regards

Harry

On 09/05/2012 11:06, anders.lars...@tieto.com wrote:

Hi!

I did a acl noauth for dst domains and noauth for src with hosts/urls that wont 
work with auth :/

acl noauth dstdom_regex -i "/etc/squid/noauth_dstdom/noauth"

acl client srcdom_regex -i "/etc/squid/noauth/client"


this line before the "acl domainusers proxy_auth REQUIRED"
http_access allow noauth client


// Anders

  * Systemadmin Unix/Linux/Vmware
  * Tieto
  * Kyrkgatan 60
  * 831 34 ÖSTERSUND
  * Växel:+46 (0)10 481 98 00
  * Fax:  +46 (0)10 481 98 10
  * Tel:  +46 (0)10 481 02 20
  * Mobil:+46 (0)70 656 42 64
  * Mail: anders.lars...@tieto.com
  **

    Debian is they way to salvation 

   ---  How Hard Can It Be ---

-Original Message-
From: Harry Mills [mailto:ha...@mad-cat.co.uk]
Sent: den 9 maj 2012 11:06
To: squid-users@squid-cache.org
Subject: Re: [squid-users] NTLM, non-domain machines and keep-alive

Hi,

I am still unsure why IE and Chrome would pop up an authentication box 3
times (rather than just once) when they are not a member of the domain.
I would certainly expect a box to pop up - but why three times?!

When I was testing with just NTLM as the authentication mechanism I set:

auth_param ntlm keep-alive off

This solved the 3-popup problem and IE just pops up one authentication box.

We are now using the negotiate_wrapper around Kerberos and NTLM, which
is working very well - except we still have the multi-authentication
boxes popping up for non-domain windows machines.

Can I set the same parameter for negotiate:

auth_param negotiate keep-alive off

or will have undesirable effects on Negotiate mechanism?

If this is not a solution, is there another area I should be looking at
as to why we are getting 3 popup boxes in a row when non-domain machines
try to authenticate with Squid?

Regards

Harry


On 20/04/2012 19:29, Harry Mills wrote:

Hi,

Firstly, thank you Amos for helping out here. I am finding it rather
frustrating because I have enough knowledge on this subject get myself
into trouble, but not enough to get myself back out of it!

On 20/04/2012 14:58, Amos Jeffries wrote:

On 20/04/2012 12:03 a.m., Harry Mills wrote:

Hi,

I have upgraded our squid to version 3.1.19 but I am still seeing the
repeated popup box issue with non-domain member machines (windows
machines).



Well, yes. Lookup the requriements for NTLM with actual security
enabled. #1 on the list is "join the client machine to domain" or some
wording to that effect.


This can be very frustrating! The problems I am facing are really caused
by the fact that Windows clients, when presented with "negotiate" as an
authentication option will choose NTLM when they are not members of the
domain. This would be fine if they simply popped up a box *once* for the
credentials, but having to type DOMAIN\username and a password three
times before you are allowed access is difficult to explain to end users!


NTLM and its relative are domain-based authentication protocols, with a
centralized controller system. You are trying to make machines outside
the domain with no access to the DC secrets able to generate tokens
based on those secrets.

It used to "work" for NTLMv1 because it has a failure recovery action
which drops back to LM protocol which is frighteningly like Basic auth
protocol without any domain secrets to validate the machine is allowed
to be logged in with. None of the modern software permits that LM mode
to be used anymore without some manual security disabling.


I realise something has changed because our previous ( 4 years older )
squid with NTLM worked in exactly the way I would have expected. NTLM
working for all domain machines, and a *single* popup authentication box
for those clients which were not domain members - to be honest, I always
assumed that the sin

RE: [squid-users] NTLM, non-domain machines and keep-alive

[Anders.Larsson]

Hi!

I did a acl noauth for dst domains and noauth for src with hosts/urls that wont 
work with auth :/

acl noauth dstdom_regex -i "/etc/squid/noauth_dstdom/noauth"

acl client srcdom_regex -i "/etc/squid/noauth/client"


this line before the "acl domainusers proxy_auth REQUIRED"
http_access allow noauth client


// Anders

 * Systemadmin Unix/Linux/Vmware
 * Tieto
 * Kyrkgatan 60
 * 831 34 ÖSTERSUND
 * Växel:+46 (0)10 481 98 00
 * Fax:  +46 (0)10 481 98 10
 * Tel:  +46 (0)10 481 02 20
 * Mobil:+46 (0)70 656 42 64
 * Mail: anders.lars...@tieto.com
 **
  
   Debian is they way to salvation 
  
  ---  How Hard Can It Be ---

-Original Message-
From: Harry Mills [mailto:ha...@mad-cat.co.uk] 
Sent: den 9 maj 2012 11:06
To: squid-users@squid-cache.org
Subject: Re: [squid-users] NTLM, non-domain machines and keep-alive

Hi,

I am still unsure why IE and Chrome would pop up an authentication box 3 
times (rather than just once) when they are not a member of the domain. 
I would certainly expect a box to pop up - but why three times?!

When I was testing with just NTLM as the authentication mechanism I set:

auth_param ntlm keep-alive off

This solved the 3-popup problem and IE just pops up one authentication box.

We are now using the negotiate_wrapper around Kerberos and NTLM, which 
is working very well - except we still have the multi-authentication 
boxes popping up for non-domain windows machines.

Can I set the same parameter for negotiate:

auth_param negotiate keep-alive off

or will have undesirable effects on Negotiate mechanism?

If this is not a solution, is there another area I should be looking at 
as to why we are getting 3 popup boxes in a row when non-domain machines 
try to authenticate with Squid?

Regards

Harry


On 20/04/2012 19:29, Harry Mills wrote:
> Hi,
>
> Firstly, thank you Amos for helping out here. I am finding it rather
> frustrating because I have enough knowledge on this subject get myself
> into trouble, but not enough to get myself back out of it!
>
> On 20/04/2012 14:58, Amos Jeffries wrote:
>> On 20/04/2012 12:03 a.m., Harry Mills wrote:
>>> Hi,
>>>
>>> I have upgraded our squid to version 3.1.19 but I am still seeing the
>>> repeated popup box issue with non-domain member machines (windows
>>> machines).
>>>
>>
>> Well, yes. Lookup the requriements for NTLM with actual security
>> enabled. #1 on the list is "join the client machine to domain" or some
>> wording to that effect.
>
> This can be very frustrating! The problems I am facing are really caused
> by the fact that Windows clients, when presented with "negotiate" as an
> authentication option will choose NTLM when they are not members of the
> domain. This would be fine if they simply popped up a box *once* for the
> credentials, but having to type DOMAIN\username and a password three
> times before you are allowed access is difficult to explain to end users!
>
>> NTLM and its relative are domain-based authentication protocols, with a
>> centralized controller system. You are trying to make machines outside
>> the domain with no access to the DC secrets able to generate tokens
>> based on those secrets.
>>
>> It used to "work" for NTLMv1 because it has a failure recovery action
>> which drops back to LM protocol which is frighteningly like Basic auth
>> protocol without any domain secrets to validate the machine is allowed
>> to be logged in with. None of the modern software permits that LM mode
>> to be used anymore without some manual security disabling.
>
> I realise something has changed because our previous ( 4 years older )
> squid with NTLM worked in exactly the way I would have expected. NTLM
> working for all domain machines, and a *single* popup authentication box
> for those clients which were not domain members - to be honest, I always
> assumed that the single authentication box was the browser falling back
> to Basic auth because it couldn't use NTLM.
>
>>> Domain member machines authenticate perfectly via NTLM, but non-domain
>>> member machines (Windows XP, Windows 7) pop up a password box three
>>> times before accepting the credentials.
>>>
>>> I have removed all the authentication directives _except_ the NTLM one
>>> to simplify the troubleshooting.
>>>
>>> If I asked Internet Explorer to save the credentials then the
>>> authentication works fine and I get no further popup boxes. Chrome is
>>> the same - as is Firefox, although interestingly Firefox will only
>>> authenticate if the credentials have been stored. If they have not
&

Re: [squid-users] NTLM, non-domain machines and keep-alive

[Harry Mills]

Hi,

I am still unsure why IE and Chrome would pop up an authentication box 3 
times (rather than just once) when they are not a member of the domain. 
I would certainly expect a box to pop up - but why three times?!


When I was testing with just NTLM as the authentication mechanism I set:

auth_param ntlm keep-alive off

This solved the 3-popup problem and IE just pops up one authentication box.

We are now using the negotiate_wrapper around Kerberos and NTLM, which 
is working very well - except we still have the multi-authentication 
boxes popping up for non-domain windows machines.


Can I set the same parameter for negotiate:

auth_param negotiate keep-alive off

or will have undesirable effects on Negotiate mechanism?

If this is not a solution, is there another area I should be looking at 
as to why we are getting 3 popup boxes in a row when non-domain machines 
try to authenticate with Squid?


Regards

Harry


On 20/04/2012 19:29, Harry Mills wrote:

Hi,

Firstly, thank you Amos for helping out here. I am finding it rather
frustrating because I have enough knowledge on this subject get myself
into trouble, but not enough to get myself back out of it!

On 20/04/2012 14:58, Amos Jeffries wrote:

On 20/04/2012 12:03 a.m., Harry Mills wrote:

Hi,

I have upgraded our squid to version 3.1.19 but I am still seeing the
repeated popup box issue with non-domain member machines (windows
machines).



Well, yes. Lookup the requriements for NTLM with actual security
enabled. #1 on the list is "join the client machine to domain" or some
wording to that effect.


This can be very frustrating! The problems I am facing are really caused
by the fact that Windows clients, when presented with "negotiate" as an
authentication option will choose NTLM when they are not members of the
domain. This would be fine if they simply popped up a box *once* for the
credentials, but having to type DOMAIN\username and a password three
times before you are allowed access is difficult to explain to end users!


NTLM and its relative are domain-based authentication protocols, with a
centralized controller system. You are trying to make machines outside
the domain with no access to the DC secrets able to generate tokens
based on those secrets.

It used to "work" for NTLMv1 because it has a failure recovery action
which drops back to LM protocol which is frighteningly like Basic auth
protocol without any domain secrets to validate the machine is allowed
to be logged in with. None of the modern software permits that LM mode
to be used anymore without some manual security disabling.


I realise something has changed because our previous ( 4 years older )
squid with NTLM worked in exactly the way I would have expected. NTLM
working for all domain machines, and a *single* popup authentication box
for those clients which were not domain members - to be honest, I always
assumed that the single authentication box was the browser falling back
to Basic auth because it couldn't use NTLM.


Domain member machines authenticate perfectly via NTLM, but non-domain
member machines (Windows XP, Windows 7) pop up a password box three
times before accepting the credentials.

I have removed all the authentication directives _except_ the NTLM one
to simplify the troubleshooting.

If I asked Internet Explorer to save the credentials then the
authentication works fine and I get no further popup boxes. Chrome is
the same - as is Firefox, although interestingly Firefox will only
authenticate if the credentials have been stored. If they have not
been stored (using IE remember password) it plain refuses to
authenticate at all (no popup boxes or anything).


Wow strange behaviour from Firefox, do they have a bug report about this?


I have not come across one, but will check and present one if not.


The others are correct for a non-domain machine. When connected to a
domain the machine can validate that the requested NTLM domain/realm is
the same as the machien login one and use that for single-sign-on.
Without an existing domain login or pre-stored domain credentials to use
it is only to be expected the browser asks for popup to be filled out by
the user.


I realise the popup is necessary as there are no domain credentials to
use, my confusion was that it pops up three times, my (probably
confused) logic is that it should only need to ask once!


I am more than happy to work through this myself, but have exhausted
all my ideas. Could some one point me in the right direction?


While keep-alive / persistent connections *is* mandatory for NTLM to
work. The "auth_param ntlm keep-alive off" setting is a kind of special
adaptation to keep-alive, which sends the challenge signalling NTLM then
drops the connection. Forcing the client to open a new connection and
start it with the auth handshake requests. Once the handshake is started
the normal persistence settings take over.

It is a bit nasty and somewhat confusing. But thats the best we can do
with certain softw

Re: [squid-users] NTLM not working with HTTPS pages

[Amos Jeffries]

On 27/04/2012 5:08 a.m., Wladner Klimach wrote:

Amos,

did you receive my e-mail? I really need to fix this problem. I've
been struggling for months to build a proxy solution and now the only
problem is this. So if you could point me some direction of what to do
I would appreciate.


There is nothing we can do about this.

The client software is pushing data into the CONNECT tunnel before the 
NTLM handshake is completed, and sending RST in order to clear the 
channel when it gets the handshake stage-2 response back.  NTLM requires 
that connections MUST be kept alive between stage 1 and stage 3 of the 
handshake.


The client is just broken, it is already handling state knowledge that 
NTLM is present and what stage the handshake is at, there is no reason 
to send data on that second CONNECT and NTLM requires it not to.


Amos



Regards,

Wladner

2012/4/25 Wladner Klimach:

Amos,

I've made the capture as you said. I can see the CONNECT request from
the client and later the 407 Proxy Authentication Required, but after
that with no reason the client close the connection with a RST flag.
I'm sending you the file so that you can see the whole data flow. Can
you see something wrong at this captured data?

Regards,

Wladner

2012/4/20 Amos Jeffries:

On 21/04/2012 4:01 a.m., Wladner Klimach wrote:

Amos,

what could be causing this? When I desable NTLM authentication or when
I use Kerberos all access go just fine, but when only NTLM is able I
can't get access to https pages and I get in the logs TCP_DENIED/407.
How can I debug it?


You need to locate and identify what request headers are being denied.

The easiest way with 3.1 is a packet dump with full packet bodies ("tcpdump
-s0 ..."). Then base-64 decode the www-authenticate headers from the client
and check the type codes. NTLM has "NTLMSSPI" then a binary type number 1, 2
or 3.

The NTLM flow should be:

  client: makes request (no auth)
  Squid: emits 407 with NTLM advertised as available
  squid: [optionally closes the connection (due to "auth_param ntlm
keep-alive off" hack)]
  client: repeat request with type-1 NTLM proxy-auth header
  squid: 407 with type-2 NTLM proxy-auth header
  client: repeat request with type-3 NTLM proxy-auth header
  squid: HTTP response
  client: [optionally make other requests with type-3 NTLM proxy-auth header]
  connection closes.


If you find connections opening and starting immediately with type-3 token
that is Kerberos or broken NTLM from the client.


Amos



regards

2012/4/20 Amos Jeffries:

On 21/04/2012 1:15 a.m., Harry Mills wrote:

Hi Wladner,

I don't think this is causing your problems, but I think you need to
change the following:

Instead of:

http_access deny CONNECT !Safe_ports

try:

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Also, on the last two lines of your included config you have:

acl AUTENTICADO proxy_auth REQUIRED
http_access allow AUTENTICADO


This is one of several correct proxy-auth configurations.



I simply have:

http_access allow proxy_auth

I have no idea if this will help, but worth giving it a try perhaps?


?? for that to work you require this somewhere above your http_access
rule
...

  acl proxy_auth proxy_auth REQUIRED

or some other definition for an ACL *label* "proxy_auth".

Amos

Re: [squid-users] NTLM not working with HTTPS pages

[Amos Jeffries]

On 21/04/2012 4:01 a.m., Wladner Klimach wrote:

Amos,

what could be causing this? When I desable NTLM authentication or when
I use Kerberos all access go just fine, but when only NTLM is able I
can't get access to https pages and I get in the logs TCP_DENIED/407.
How can I debug it?


You need to locate and identify what request headers are being denied.

The easiest way with 3.1 is a packet dump with full packet bodies 
("tcpdump -s0 ..."). Then base-64 decode the www-authenticate headers 
from the client and check the type codes. NTLM has "NTLMSSPI" then a 
binary type number 1, 2 or 3.


The NTLM flow should be:

 client: makes request (no auth)
 Squid: emits 407 with NTLM advertised as available
 squid: [optionally closes the connection (due to "auth_param ntlm 
keep-alive off" hack)]

 client: repeat request with type-1 NTLM proxy-auth header
 squid: 407 with type-2 NTLM proxy-auth header
 client: repeat request with type-3 NTLM proxy-auth header
 squid: HTTP response
 client: [optionally make other requests with type-3 NTLM proxy-auth 
header]

 connection closes.


If you find connections opening and starting immediately with type-3 
token that is Kerberos or broken NTLM from the client.



Amos



regards

2012/4/20 Amos Jeffries:

On 21/04/2012 1:15 a.m., Harry Mills wrote:

Hi Wladner,

I don't think this is causing your problems, but I think you need to
change the following:

Instead of:

http_access deny CONNECT !Safe_ports

try:

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Also, on the last two lines of your included config you have:

acl AUTENTICADO proxy_auth REQUIRED
http_access allow AUTENTICADO


This is one of several correct proxy-auth configurations.



I simply have:

http_access allow proxy_auth

I have no idea if this will help, but worth giving it a try perhaps?


?? for that to work you require this somewhere above your http_access rule
...

  acl proxy_auth proxy_auth REQUIRED

or some other definition for an ACL *label* "proxy_auth".

Amos

Re: [squid-users] NTLM, non-domain machines and keep-alive

[Harry Mills]

Hi,

Firstly, thank you Amos for helping out here. I am finding it rather 
frustrating because I have enough knowledge on this subject get myself 
into trouble, but not enough to get myself back out of it!


On 20/04/2012 14:58, Amos Jeffries wrote:

On 20/04/2012 12:03 a.m., Harry Mills wrote:

Hi,

I have upgraded our squid to version 3.1.19 but I am still seeing the
repeated popup box issue with non-domain member machines (windows
machines).



Well, yes. Lookup the requriements for NTLM with actual security
enabled. #1 on the list is "join the client machine to domain" or some
wording to that effect.


This can be very frustrating! The problems I am facing are really caused 
by the fact that Windows clients, when presented with "negotiate" as an 
authentication option will choose NTLM when they are not members of the 
domain. This would be fine if they simply popped up a box *once* for the 
credentials, but having to type DOMAIN\username and a password three 
times before you are allowed access is difficult to explain to end users!



NTLM and its relative are domain-based authentication protocols, with a
centralized controller system. You are trying to make machines outside
the domain with no access to the DC secrets able to generate tokens
based on those secrets.

It used to "work" for NTLMv1 because it has a failure recovery action
which drops back to LM protocol which is frighteningly like Basic auth
protocol without any domain secrets to validate the machine is allowed
to be logged in with. None of the modern software permits that LM mode
to be used anymore without some manual security disabling.


I realise something has changed because our previous ( 4 years older ) 
squid with NTLM worked in exactly the way I would have expected. NTLM 
working for all domain machines, and a *single* popup authentication box 
for those clients which were not domain members - to be honest, I always 
assumed that the single authentication box was the browser falling back 
to Basic auth because it couldn't use NTLM.



Domain member machines authenticate perfectly via NTLM, but non-domain
member machines (Windows XP, Windows 7) pop up a password box three
times before accepting the credentials.

I have removed all the authentication directives _except_ the NTLM one
to simplify the troubleshooting.

If I asked Internet Explorer to save the credentials then the
authentication works fine and I get no further popup boxes. Chrome is
the same - as is Firefox, although interestingly Firefox will only
authenticate if the credentials have been stored. If they have not
been stored (using IE remember password) it plain refuses to
authenticate at all (no popup boxes or anything).


Wow strange behaviour from Firefox, do they have a bug report about this?


I have not come across one, but will check and present one if not.


The others are correct for a non-domain machine. When connected to a
domain the machine can validate that the requested NTLM domain/realm is
the same as the machien login one and use that for single-sign-on.
Without an existing domain login or pre-stored domain credentials to use
it is only to be expected the browser asks for popup to be filled out by
the user.


I realise the popup is necessary as there are no domain credentials to 
use, my confusion was that it pops up three times, my (probably 
confused) logic is that it should only need to ask once!



I am more than happy to work through this myself, but have exhausted
all my ideas. Could some one point me in the right direction?


While keep-alive / persistent connections *is* mandatory for NTLM to
work. The "auth_param ntlm keep-alive off" setting is a kind of special
adaptation to keep-alive, which sends the challenge signalling NTLM then
drops the connection. Forcing the client to open a new connection and
start it with the auth handshake requests. Once the handshake is started
the normal persistence settings take over.

It is a bit nasty and somewhat confusing. But thats the best we can do
with certain software.


Thank you for that explanation - it is confusing! All I really want to 
achieve is single-signon for the domain members, and a *single* password 
popup for non-domain members.


Thank you again for your help.

Regards

Harry



Amos

Re: [squid-users] NTLM not working with HTTPS pages

[Wladner Klimach]

Amos,

what could be causing this? When I desable NTLM authentication or when
I use Kerberos all access go just fine, but when only NTLM is able I
can't get access to https pages and I get in the logs TCP_DENIED/407.
How can I debug it?

regards

2012/4/20 Amos Jeffries :
> On 21/04/2012 1:15 a.m., Harry Mills wrote:
>>
>> Hi Wladner,
>>
>> I don't think this is causing your problems, but I think you need to
>> change the following:
>>
>> Instead of:
>>
>> http_access deny CONNECT !Safe_ports
>>
>> try:
>>
>> http_access deny !Safe_ports
>> http_access deny CONNECT !SSL_ports
>>
>> Also, on the last two lines of your included config you have:
>>
>> acl AUTENTICADO proxy_auth REQUIRED
>> http_access allow AUTENTICADO
>
>
> This is one of several correct proxy-auth configurations.
>
>
>>
>> I simply have:
>>
>> http_access allow proxy_auth
>>
>> I have no idea if this will help, but worth giving it a try perhaps?
>
>
> ?? for that to work you require this somewhere above your http_access rule
> ...
>
>  acl proxy_auth proxy_auth REQUIRED
>
> or some other definition for an ACL *label* "proxy_auth".
>
> Amos

Re: [squid-users] NTLM, non-domain machines and keep-alive

[Amos Jeffries]

On 20/04/2012 12:03 a.m., Harry Mills wrote:

Hi,

I have upgraded our squid to version 3.1.19 but I am still seeing the 
repeated popup box issue with non-domain member machines (windows 
machines).




Well, yes. Lookup the requriements for NTLM with actual security 
enabled. #1 on the list is "join the client machine to domain" or some 
wording to that effect.


NTLM and its relative are domain-based authentication protocols, with a 
centralized controller system. You are trying to make machines outside 
the domain with no access to the DC secrets able to generate tokens 
based on those secrets.


It used to "work" for NTLMv1 because it has a failure recovery action 
which drops back to LM protocol which is frighteningly like Basic auth 
protocol without any domain secrets to validate the machine is allowed 
to be logged in with. None of the modern software permits that LM mode 
to be used anymore without some manual security disabling.



Domain member machines authenticate perfectly via NTLM, but non-domain 
member machines (Windows XP, Windows 7) pop up a password box three 
times before accepting the credentials.


I have removed all the authentication directives _except_ the NTLM one 
to simplify the troubleshooting.


If I asked Internet Explorer to save the credentials then the 
authentication works fine and I get no further popup boxes. Chrome is 
the same - as is Firefox, although interestingly Firefox will only 
authenticate if the credentials have been stored. If they have not 
been stored (using IE remember password) it plain refuses to 
authenticate at all (no popup boxes or anything).


Wow strange behaviour from Firefox, do they have a bug report about this?

The others are correct for a non-domain machine. When connected to a 
domain the machine can validate that the requested NTLM domain/realm is 
the same as the machien login one and use that for single-sign-on. 
Without an existing domain login or pre-stored domain credentials to use 
it is only to be expected the browser asks for popup to be filled out by 
the user.




I am more than happy to work through this myself, but have exhausted 
all my ideas. Could some one point me in the right direction?


While keep-alive / persistent connections *is* mandatory for NTLM to 
work. The "auth_param ntlm keep-alive off" setting is a kind of special 
adaptation to keep-alive, which sends the challenge signalling NTLM then 
drops the connection. Forcing the client to open a new connection and 
start it with the auth handshake requests. Once the handshake is started 
the normal persistence settings take over.


It is a bit nasty and somewhat confusing. But thats the best we can do 
with certain software.


Amos

Re: [squid-users] NTLM not working with HTTPS pages

[Amos Jeffries]

On 21/04/2012 1:15 a.m., Harry Mills wrote:

Hi Wladner,

I don't think this is causing your problems, but I think you need to 
change the following:


Instead of:

http_access deny CONNECT !Safe_ports

try:

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Also, on the last two lines of your included config you have:

acl AUTENTICADO proxy_auth REQUIRED
http_access allow AUTENTICADO


This is one of several correct proxy-auth configurations.



I simply have:

http_access allow proxy_auth

I have no idea if this will help, but worth giving it a try perhaps?


?? for that to work you require this somewhere above your http_access 
rule ...


 acl proxy_auth proxy_auth REQUIRED

or some other definition for an ACL *label* "proxy_auth".

Amos

Re: [squid-users] NTLM not working with HTTPS pages

[Harry Mills]

Hi Wladner,

I don't think this is causing your problems, but I think you need to 
change the following:


Instead of:

http_access deny CONNECT !Safe_ports

try:

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Also, on the last two lines of your included config you have:

acl AUTENTICADO proxy_auth REQUIRED
http_access allow AUTENTICADO

I simply have:

http_access allow proxy_auth

I have no idea if this will help, but worth giving it a try perhaps?

Regards

Harry


On 19/04/2012 19:49, Wladner Klimach wrote:

Hello,

I'm using NTLM scheme like this:


auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 30 startup=5 idle=5
auth_param ntlm keep_alive on

And it is working fine except for https pages. Here is my basic squid.conf:


acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
acl localhost src 127.0.0.1/32 ::1
acl manager proto cache_object

acl SSL_ports port 443
acl SSL_ports port 1863
acl SSL_ports port 563
acl SSL_ports port 465
acl SSL_ports port 995
acl Safe_ports port 80  # http
acl Safe_ports port 21  # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 563 # https
acl Safe_ports port 465 # https
acl Safe_ports port 995 # https
acl Safe_ports port 70  # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl CONNECT method CONNECT

http_access deny CONNECT !Safe_ports
http_access allow manager localhost
http_access deny manager
http_access deny to_localhost

follow_x_forwarded_for allow localhost
acl AUTENTICADO proxy_auth REQUIRED
http_access allow AUTENTICADO

regards,

Wladner

[squid-users] NTLM not working with HTTPS pages

[Wladner Klimach]

Hello,

I'm using NTLM scheme like this:


auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 30 startup=5 idle=5
auth_param ntlm keep_alive on

And it is working fine except for https pages. Here is my basic squid.conf:


acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
acl localhost src 127.0.0.1/32 ::1
acl manager proto cache_object

acl SSL_ports port 443
acl SSL_ports port 1863
acl SSL_ports port 563
acl SSL_ports port 465
acl SSL_ports port 995
acl Safe_ports port 80  # http
acl Safe_ports port 21  # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 563 # https
acl Safe_ports port 465 # https
acl Safe_ports port 995 # https
acl Safe_ports port 70  # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl CONNECT method CONNECT

http_access deny CONNECT !Safe_ports
http_access allow manager localhost
http_access deny manager
http_access deny to_localhost

follow_x_forwarded_for allow localhost
acl AUTENTICADO proxy_auth REQUIRED
http_access allow AUTENTICADO

regards,

Wladner

Re: [squid-users] NTLM, non-domain machines and keep-alive

[Harry Mills]

Hi,

I have upgraded our squid to version 3.1.19 but I am still seeing the 
repeated popup box issue with non-domain member machines (windows machines).


Domain member machines authenticate perfectly via NTLM, but non-domain 
member machines (Windows XP, Windows 7) pop up a password box three 
times before accepting the credentials.


I have removed all the authentication directives _except_ the NTLM one 
to simplify the troubleshooting.


If I asked Internet Explorer to save the credentials then the 
authentication works fine and I get no further popup boxes. Chrome is 
the same - as is Firefox, although interestingly Firefox will only 
authenticate if the credentials have been stored. If they have not been 
stored (using IE remember password) it plain refuses to authenticate at 
all (no popup boxes or anything).


I am more than happy to work through this myself, but have exhausted all 
my ideas. Could some one point me in the right direction?


Regards

Harry

On 05/04/2012 17:19, Harry Mills wrote:

Hi,

I have been trying to iron our a few issues we are having with NTLM
authentication on our network for machines which are not domain members:

Windows 2008R2 AD domain
RHEL 6.1
squid-3.1.10-1
samba-3.5.6-86
Internet Explorer 7,8

We are in the process of moving to Kerberos authentication, and the test
squid we have running is working well, however, when presented with the
negotiate option for auth, IE will choose NTLM rather than basic when it
is not a member of the domain.

I have reduced the config for squid down to just offering NTLM
authentication to help me debug an issue with pop up boxes. I have also
written a wrapper around the ntlm_auth binary to strace the calls being
made when it is being executed.

NTLM authentication works without issue for domain members, however IE
(and Chrome) will both popup an authentication required box three times
before accepting the DOMAIN\Username and password.

Checking the wrapper around ntlm_auth, the process is only called by
squid after the last of the three authentication prompts is submitted by
the browser. Squid issues the expected two 407s to the browser which
appears to cause the browser to pop up the authentication window each
time, and on the third submission authentication succeeds.

The odd thing is, if I turn off keep-alive for ntlm in the squid.conf
then I still see the 407s being issued by squid, but I only get a single
authentication pop up from the browser, which when submitted with the
correct credentials is immediately accepted and authentication succeeds.

I am clearly missing something, because it states quite clearly that
NTLM _requires_ keep alive sockets as it is a connection orientated
mechanism, so perhaps my turning off keep-alive causes a basic-auth
fallback within ntlm_auth?

Is there a reason that IE presents 3 authentication boxes before
accepting credentials from a non-domain machine. If there is a reason,
is there a solution?

One thought I have had is that the majority of non-domain members will
be on a specific VLAN, and therefore have a specific IP subnet. Is it
possible to offer a different range of authentication options to the
clients based on a subnet acl, e.g. Kerb/NTLM for machines on
domain-member VLANS and just basic for guests (non-domain members)?

Regards,

Harry

Re: Fwd: [squid-users] NTLM not working

[Amos Jeffries]

On 12.04.2012 10:16, Wladner Klimach wrote:

On 11/04/2012 21:15, Wladner Klimach wrote:


That's the options I pointed for authetincation:

'--enable-auth=basic,digest,ntlm,negotiate'
 
'--enable-basic-auth-helpers=LDAP,MSNT,NCSA,PAM,SMB,YP,getpwnam,multi-domain-NTLM,SASL,DB,POP3,squid_radius_auth'

'--enable-ntlm-auth-helpers=smb_lm,no_check,fakeauth'
 '--enable-digest-auth-helpers=password,ldap,eDirectory'
 '--enable-negotiate-auth-helpers=squid_kerb_auth'
 
'--enable-external-acl-helpers=ip_user,ldap_group,session,unix_group,wbinfo_group'


What am I missing?





Take a step back. Please post *all* of the auth_param lines from your 
config.



What I am reading from your earlier mail is:

 * you saying "auth_param Negotiate ..." is setup. BUT ... cache.log 
making no mention of it.


 * cache.log saying "auth_param Basic ..." was setup and working.

 * cache.log saying "auth_param NTLM ..." is not setup.




From a compilation perspective you don't appear to be missing
anything, but as I said I am not really familiar with that area -
perhaps someone else with more knowledge can confirm?

I presume the squid process has permissions to read from
winbindd_privileged (in /var/lib/samba/ on my setup). I would expect
to see other errors in your logs if there was a permission problem
though.

Have you tried just a plain ntlm_auth authenticator to see if that 
works?:


auth_param ntlm program /usr/bin/ntlm_auth
--helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 3
auth_param ntlm keep_alive on

Can you post your entire squid.conf?




Amos

Fwd: [squid-users] NTLM not working

[Wladner Klimach]

On 11/04/2012 21:15, Wladner Klimach wrote:
>
> That's the options I pointed for authetincation:
>
> '--enable-auth=basic,digest,ntlm,negotiate'
>  '--enable-basic-auth-helpers=LDAP,MSNT,NCSA,PAM,SMB,YP,getpwnam,multi-domain-NTLM,SASL,DB,POP3,squid_radius_auth'
> '--enable-ntlm-auth-helpers=smb_lm,no_check,fakeauth'
>  '--enable-digest-auth-helpers=password,ldap,eDirectory'
>  '--enable-negotiate-auth-helpers=squid_kerb_auth'
>  '--enable-external-acl-helpers=ip_user,ldap_group,session,unix_group,wbinfo_group'
>
> What am I missing?


>From a compilation perspective you don't appear to be missing
anything, but as I said I am not really familiar with that area -
perhaps someone else with more knowledge can confirm?

I presume the squid process has permissions to read from
winbindd_privileged (in /var/lib/samba/ on my setup). I would expect
to see other errors in your logs if there was a permission problem
though.

Have you tried just a plain ntlm_auth authenticator to see if that works?:

auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 3
auth_param ntlm keep_alive on

Can you post your entire squid.conf?


Harry

> 2012/4/11 Harry Mills:
>>
>> On 11/04/2012 19:52, Wladner Klimach wrote:
>>>
>>>
>>> Here is what I got from wbinfo:
>>>
>>> wbinfo -t
>>> checking the trust secret via RPC calls succeeded
>>>
>>> And I can list all the groups with wbinfo -g.
>>>
>>> Here is ntlm_auth run:
>>>
>>> /usr/bin/ntlm_auth --username=P_7501
>>> password:
>>> NT_STATUS_OK: Success (0x0)
>>
>>
>>
>> That looks like you have all the winbind-related bits working!
>>
>>
>>> Look what I've got from cache.log with degub_options 29,9 actived:
>>>
>>> 2012/04/11 15:46:49.629| authenticateValidateUser: Validating
>>> Auth_user request '0'.
>>> 2012/04/11 15:46:49.629| authenticateValidateUser: Auth_user_request was
>>> NULL!
>>> 2012/04/11 15:46:49.629| authenticateAuthenticate: broken auth or no
>>> proxy_auth header. Requesting auth header.
>>> 2012/04/11 15:46:49.629| authenticateFixHeader: headertype:38 authuser:0
>>> 2012/04/11 15:46:49.629| basic/auth_basic.cc(217) fixHeader: Sending
>>> type:38 header: 'Basic realm="Squid proxy-caching web server"'
>>> 2012/04/11 15:46:49.629| authenticateFixHeader: Configured scheme ntlm
>>> not Active
>>>
>>> Looks like ntlm is not an option to squid. Could it be the lack of the
>>> compilation option --with-winbind-auth-challenge??
>>
>>
>>
>> That does look like squid may not have the right compile-time options. I am
>> afraid that isn't an area I am overly-familiar with, but I think there are
>> quite a few options you need to configure. The options we use (which I think
>> are relevant) are:
>>
>> --enable-auth="basic,digest,ntlm,negotiate"
>>
>> --enable-basic-auth-helpers="LDAP,MSNT,NCSA,PAM,SMB,YP,getpwnam,multi-domain-NTLM,SASL,DB,POP3,squid_radius_auth"
>>
>> --enable-ntlm-auth-helpers="smb_lm,no_check,fakeauth"
>>
>> --enable-external-acl-helpers="ip_user,ldap_group,session,unix_group,wbinfo_group"
>>
>> As I say, it's not really my area, but it would be worth checking that you
>> have similar options. --with-winbind-auth-challenge isn't used in my setup.
>>
>>
>> Harry
>>
>>
>>> 2012/4/11 Harry Mills:


 On 11/04/2012 17:56, Wladner Klimach wrote:
>
>
>
> Hi people,
>
> I'm having some problem to implement NTLM at my squid box. I've
> followed the documentation guides but for some unknown reason isn't
> still working. Here is my squid.conf ( authentication portion only):
>
>
> auth_param negotiate program
> /squid-3.2.0.16/helpers/negotiate_auth/wrapper/negotiate_wrapper_auth
> -d --ntlm /usr/bin/ntlm_auth  --helper-protocol=squid-2.5-ntlmssp
> --kerberos
>
> /usr/src/redhat/BUILD/squid-3.1.18/helpers/negotiate_auth/squid_kerb_auth/squid_kerb_auth
>  -s HTTP/grazina2.redecamara.camara.gov.br
> auth_param negotiate children 30 startup=10 idle=10
> auth_param negotiate keep_alive on
>
>
> As you can see I'm using the wrapper helper offered by squid-3.2, but
> my squid box is the squid-3.1. The Kerberos scheme works just fine. So
> how can I debug it? I really need NTLM too in order to authenticate
> users that access some old sites that don't handle kerberos. I really
> hope you guys can help me overtaking this issue.
>
> Regards,
>
> Wladner




 Hi Wladner,

 It may be useful to get the plain ntlm auth helper working on its own
 first.
 Once that is working, you can then re-enable the negotiate wrapper.

 I am not sure how much of the NTLM auth tests you have done. Have you
 tested
 that winbind is running and communicating with the domain? You can test
 that
 the basics are in place with wbinfo -t to check the shared secret, or
 wbinfo
 -u which should return a list of all your domain users.

 What happens if you run

Re: [squid-users] NTLM not working

[Harry Mills]

On 11/04/2012 19:52, Wladner Klimach wrote:

Here is what I got from wbinfo:

wbinfo -t
checking the trust secret via RPC calls succeeded

And I can list all the groups with wbinfo -g.

Here is ntlm_auth run:

/usr/bin/ntlm_auth --username=P_7501
password:
NT_STATUS_OK: Success (0x0)


That looks like you have all the winbind-related bits working!


Look what I've got from cache.log with degub_options 29,9 actived:

2012/04/11 15:46:49.629| authenticateValidateUser: Validating
Auth_user request '0'.
2012/04/11 15:46:49.629| authenticateValidateUser: Auth_user_request was NULL!
2012/04/11 15:46:49.629| authenticateAuthenticate: broken auth or no
proxy_auth header. Requesting auth header.
2012/04/11 15:46:49.629| authenticateFixHeader: headertype:38 authuser:0
2012/04/11 15:46:49.629| basic/auth_basic.cc(217) fixHeader: Sending
type:38 header: 'Basic realm="Squid proxy-caching web server"'
2012/04/11 15:46:49.629| authenticateFixHeader: Configured scheme ntlm
not Active

Looks like ntlm is not an option to squid. Could it be the lack of the
compilation option --with-winbind-auth-challenge??


That does look like squid may not have the right compile-time options. I 
am afraid that isn't an area I am overly-familiar with, but I think 
there are quite a few options you need to configure. The options we use 
(which I think are relevant) are:


--enable-auth="basic,digest,ntlm,negotiate"

--enable-basic-auth-helpers="LDAP,MSNT,NCSA,PAM,SMB,YP,getpwnam,multi-domain-NTLM,SASL,DB,POP3,squid_radius_auth"

--enable-ntlm-auth-helpers="smb_lm,no_check,fakeauth"

--enable-external-acl-helpers="ip_user,ldap_group,session,unix_group,wbinfo_group"

As I say, it's not really my area, but it would be worth checking that 
you have similar options. --with-winbind-auth-challenge isn't used in my 
setup.



Harry


2012/4/11 Harry Mills:

On 11/04/2012 17:56, Wladner Klimach wrote:


Hi people,

I'm having some problem to implement NTLM at my squid box. I've
followed the documentation guides but for some unknown reason isn't
still working. Here is my squid.conf ( authentication portion only):


auth_param negotiate program
/squid-3.2.0.16/helpers/negotiate_auth/wrapper/negotiate_wrapper_auth
-d --ntlm /usr/bin/ntlm_auth  --helper-protocol=squid-2.5-ntlmssp
--kerberos
/usr/src/redhat/BUILD/squid-3.1.18/helpers/negotiate_auth/squid_kerb_auth/squid_kerb_auth
  -s HTTP/grazina2.redecamara.camara.gov.br
auth_param negotiate children 30 startup=10 idle=10
auth_param negotiate keep_alive on


As you can see I'm using the wrapper helper offered by squid-3.2, but
my squid box is the squid-3.1. The Kerberos scheme works just fine. So
how can I debug it? I really need NTLM too in order to authenticate
users that access some old sites that don't handle kerberos. I really
hope you guys can help me overtaking this issue.

Regards,

Wladner



Hi Wladner,

It may be useful to get the plain ntlm auth helper working on its own first.
Once that is working, you can then re-enable the negotiate wrapper.

I am not sure how much of the NTLM auth tests you have done. Have you tested
that winbind is running and communicating with the domain? You can test that
the basics are in place with wbinfo -t to check the shared secret, or wbinfo
-u which should return a list of all your domain users.

What happens if you run ntlm auth directly:

ntlm_auth  --username=

Is there anything in your debug log which might give a little more
information about what isn't working?

Regards,

Harry

Re: [squid-users] NTLM not working

[Wladner Klimach]

Here is what I got from wbinfo:

wbinfo -t
checking the trust secret via RPC calls succeeded

And I can list all the groups with wbinfo -g.

Here is ntlm_auth run:

/usr/bin/ntlm_auth --username=P_7501
password:
NT_STATUS_OK: Success (0x0)

Look what I've got from cache.log with degub_options 29,9 actived:

2012/04/11 15:46:49.629| authenticateValidateUser: Validating
Auth_user request '0'.
2012/04/11 15:46:49.629| authenticateValidateUser: Auth_user_request was NULL!
2012/04/11 15:46:49.629| authenticateAuthenticate: broken auth or no
proxy_auth header. Requesting auth header.
2012/04/11 15:46:49.629| authenticateFixHeader: headertype:38 authuser:0
2012/04/11 15:46:49.629| basic/auth_basic.cc(217) fixHeader: Sending
type:38 header: 'Basic realm="Squid proxy-caching web server"'
2012/04/11 15:46:49.629| authenticateFixHeader: Configured scheme ntlm
not Active

Looks like ntlm is not an option to squid. Could it be the lack of the
compilation option --with-winbind-auth-challenge??

2012/4/11 Harry Mills :
> On 11/04/2012 17:56, Wladner Klimach wrote:
>>
>> Hi people,
>>
>> I'm having some problem to implement NTLM at my squid box. I've
>> followed the documentation guides but for some unknown reason isn't
>> still working. Here is my squid.conf ( authentication portion only):
>>
>>
>> auth_param negotiate program
>> /squid-3.2.0.16/helpers/negotiate_auth/wrapper/negotiate_wrapper_auth
>> -d --ntlm /usr/bin/ntlm_auth  --helper-protocol=squid-2.5-ntlmssp
>> --kerberos
>> /usr/src/redhat/BUILD/squid-3.1.18/helpers/negotiate_auth/squid_kerb_auth/squid_kerb_auth
>>  -s HTTP/grazina2.redecamara.camara.gov.br
>> auth_param negotiate children 30 startup=10 idle=10
>> auth_param negotiate keep_alive on
>>
>>
>> As you can see I'm using the wrapper helper offered by squid-3.2, but
>> my squid box is the squid-3.1. The Kerberos scheme works just fine. So
>> how can I debug it? I really need NTLM too in order to authenticate
>> users that access some old sites that don't handle kerberos. I really
>> hope you guys can help me overtaking this issue.
>>
>> Regards,
>>
>> Wladner
>
>
> Hi Wladner,
>
> It may be useful to get the plain ntlm auth helper working on its own first.
> Once that is working, you can then re-enable the negotiate wrapper.
>
> I am not sure how much of the NTLM auth tests you have done. Have you tested
> that winbind is running and communicating with the domain? You can test that
> the basics are in place with wbinfo -t to check the shared secret, or wbinfo
> -u which should return a list of all your domain users.
>
> What happens if you run ntlm auth directly:
>
> ntlm_auth  --username=
>
> Is there anything in your debug log which might give a little more
> information about what isn't working?
>
> Regards,
>
> Harry

Re: [squid-users] NTLM not working

[Harry Mills]

On 11/04/2012 17:56, Wladner Klimach wrote:

Hi people,

I'm having some problem to implement NTLM at my squid box. I've
followed the documentation guides but for some unknown reason isn't
still working. Here is my squid.conf ( authentication portion only):


auth_param negotiate program
/squid-3.2.0.16/helpers/negotiate_auth/wrapper/negotiate_wrapper_auth
-d --ntlm /usr/bin/ntlm_auth  --helper-protocol=squid-2.5-ntlmssp
--kerberos 
/usr/src/redhat/BUILD/squid-3.1.18/helpers/negotiate_auth/squid_kerb_auth/squid_kerb_auth
  -s HTTP/grazina2.redecamara.camara.gov.br
auth_param negotiate children 30 startup=10 idle=10
auth_param negotiate keep_alive on


As you can see I'm using the wrapper helper offered by squid-3.2, but
my squid box is the squid-3.1. The Kerberos scheme works just fine. So
how can I debug it? I really need NTLM too in order to authenticate
users that access some old sites that don't handle kerberos. I really
hope you guys can help me overtaking this issue.

Regards,

Wladner


Hi Wladner,

It may be useful to get the plain ntlm auth helper working on its own 
first. Once that is working, you can then re-enable the negotiate wrapper.


I am not sure how much of the NTLM auth tests you have done. Have you 
tested that winbind is running and communicating with the domain? You 
can test that the basics are in place with wbinfo -t to check the shared 
secret, or wbinfo -u which should return a list of all your domain users.


What happens if you run ntlm auth directly:

ntlm_auth  --username=

Is there anything in your debug log which might give a little more 
information about what isn't working?


Regards,

Harry

[squid-users] NTLM not working

[Wladner Klimach]

Hi people,

I'm having some problem to implement NTLM at my squid box. I've
followed the documentation guides but for some unknown reason isn't
still working. Here is my squid.conf ( authentication portion only):


auth_param negotiate program
/squid-3.2.0.16/helpers/negotiate_auth/wrapper/negotiate_wrapper_auth
-d --ntlm /usr/bin/ntlm_auth  --helper-protocol=squid-2.5-ntlmssp
--kerberos 
/usr/src/redhat/BUILD/squid-3.1.18/helpers/negotiate_auth/squid_kerb_auth/squid_kerb_auth
 -s HTTP/grazina2.redecamara.camara.gov.br
auth_param negotiate children 30 startup=10 idle=10
auth_param negotiate keep_alive on


As you can see I'm using the wrapper helper offered by squid-3.2, but
my squid box is the squid-3.1. The Kerberos scheme works just fine. So
how can I debug it? I really need NTLM too in order to authenticate
users that access some old sites that don't handle kerberos. I really
hope you guys can help me overtaking this issue.

Regards,

Wladner

[squid-users] NTLM, non-domain machines and keep-alive

[Harry Mills]

Hi,

I have been trying to iron our a few issues we are having with NTLM 
authentication on our network for machines which are not domain members:


Windows 2008R2 AD domain
RHEL 6.1
squid-3.1.10-1
samba-3.5.6-86
Internet Explorer 7,8

We are in the process of moving to Kerberos authentication, and the test 
squid we have running is working well, however, when presented with the 
negotiate option for auth, IE will choose NTLM rather than basic when it 
is not a member of the domain.


I have reduced the config for squid down to just offering NTLM 
authentication to help me debug an issue with pop up boxes. I have also 
written a wrapper around the ntlm_auth binary to strace the calls being 
made when it is being executed.


NTLM authentication works without issue for domain members, however IE 
(and Chrome) will both popup an authentication required box three times 
before accepting the DOMAIN\Username and password.


Checking the wrapper around ntlm_auth, the process is only called by 
squid after the last of the three authentication prompts is submitted by 
the browser. Squid issues the expected two 407s to the browser which 
appears to cause the browser to pop up the authentication window each 
time, and on the third submission authentication succeeds.


The odd thing is, if I turn off keep-alive for ntlm in the squid.conf 
then I still see the 407s being issued by squid, but I only get a single 
authentication pop up from the browser, which when submitted with the 
correct credentials is immediately accepted and authentication succeeds.


I am clearly missing something, because it states quite clearly that 
NTLM _requires_ keep alive sockets as it is a connection orientated 
mechanism, so perhaps my turning off keep-alive causes a basic-auth 
fallback within ntlm_auth?


Is there a reason that IE presents 3 authentication boxes before 
accepting credentials from a non-domain machine. If there is a reason, 
is there a solution?


One thought I have had is that the majority of non-domain members will 
be on a specific VLAN, and therefore have a specific IP subnet. Is it 
possible to offer a different range of authentication options to the 
clients based on a subnet acl, e.g. Kerb/NTLM for machines on 
domain-member VLANS and just basic for guests (non-domain members)?


Regards,

Harry

RE: [squid-users] ntlm and kerberos

[Anders.Larsson]

Ok i did the migration yesterday from ntlm to kerberos :) went very smth..

One other thing is there a way to set logging for kerberos so I can see failed 
auth against AD ? 
And what do u recommend in children ? I got 15 now.
We got 4000 users in domain

The main issue that I moved from ntlm was that we had some issues with sistes 
that had to exclude in auth.. because java.. and that some users got problem 
with auth popup login in their IE.. they just needed to type user and password 
then it worked..

But now we still have the issue with popup for some users.. like 30 users.. 
very strange behavior.



 * Systemadmin Unix/Linux/Vmware
 * Tieto
 * Kyrkgatan 60
 * 831 34 ÖSTERSUND
 * Växel:+46 (0)10 481 98 00
 * Fax:  +46 (0)10 481 98 10
 * Tel:  +46 (0)10 481 02 20
 * Mobil:+46 (0)70 656 42 64
 * Mail: anders.lars...@tieto.com
 **
  
   Debian is they way to salvation 
  
  ---  How Hard Can It Be ---


-Original Message-
From: Amos Jeffries [mailto:squ...@treenet.co.nz] 
Sent: den 3 april 2012 13:17
To: squid-users@squid-cache.org
Subject: Re: [squid-users] ntlm and kerberos

On 3/04/2012 7:26 p.m., Anders.Larsson wrote:
> Hi!
>
> Im using at the moment ntlm to auth to AD, I got a test server that are using 
> Kerberos..
> Now I want to change the prod machine to use Kerberos to.. is there a way to 
> have both auth directives in conf ?

Yes. Simply put them both in.
http://wiki.squid-cache.org/Features/Authentication#Can_I_use_different_authentication_mechanisms_together.3F

>
> I want to take it in steps so I have to create a acl for src ip/hosts..
> But how do I do the point out witch auth so it uses the acl for Kerberos..??
> Possible ?

Not possible unfortunately. The clients software decides.

Amos

Re: [squid-users] ntlm and kerberos

[Amos Jeffries]

On 3/04/2012 7:26 p.m., Anders.Larsson wrote:

Hi!

Im using at the moment ntlm to auth to AD, I got a test server that are using 
Kerberos..
Now I want to change the prod machine to use Kerberos to.. is there a way to 
have both auth directives in conf ?


Yes. Simply put them both in.
http://wiki.squid-cache.org/Features/Authentication#Can_I_use_different_authentication_mechanisms_together.3F



I want to take it in steps so I have to create a acl for src ip/hosts..
But how do I do the point out witch auth so it uses the acl for Kerberos..??
Possible ?


Not possible unfortunately. The clients software decides.

Amos

[squid-users] ntlm and kerberos

[Anders.Larsson]

Hi!

Im using at the moment ntlm to auth to AD, I got a test server that are using 
Kerberos..
Now I want to change the prod machine to use Kerberos to.. is there a way to 
have both auth directives in conf ?

I want to take it in steps so I have to create a acl for src ip/hosts..  
But how do I do the point out witch auth so it uses the acl for Kerberos..??
Possible ?
 
Im using squid 2.7 stable9

Regards Anders

 
  
   Debian is they way to salvation 
  
  ---  How Hard Can It Be ---

[squid-users] NTLM Passthrough - Windows 7 and 2008 clients

[Momo]

Hi,

I'm in the folloqing setup with Squid 2.7STABLE3 :

Client ---> Squid ---> NTLM enabled proxy with transparent auth ---> Internet

I use the following configuration directives to achieve this:

cache_peer 172.17.86.27 parent 8080 0 proxy-only no-query default
no-digest login=PASS
persistent_connection_after_error on
never_direct allow all

My clients are member of an active directory domain, and get
authenticated transparently (no auth pop-up) through my squid server .
It works correctly with windows XP/2000/2003 clients, but i'm facing a
problem that occurs only on 2008/ SEVEN clients:
I get intempestive login pop-ups with these clients on some websites,
especially when browsing the following page :
https://www-304.ibm.com/support/docview.wss?uid=swg27017522

If I look at my NTLM enabled proxy logs, i can see for each error the
following entries :

httpproxy[15164]: [0xb1366f38] auth_adir_auth_crap_callback
(auth_adir.c:883) Authorization denied (NT_STATUS_WRONG_PASSWORD)

After that, and because our password policy locks accounts after 3
auth failures, the user is locked out.

I already tried to force on client side " Send only NTLMv2 responses "
and disable 128Bit encryption enforcement, but no luck.

if anybody has a clue...
Thank you.

Re: [squid-users] NTLM passthru authentication

[Amos Jeffries]

On 8/03/2012 8:18 p.m., kimi ge(巍俊葛) wrote:

Hi,

Can someone take a look at it the following issue which I ran into?
Here is the details:
Outline: squid 2.6 as the reverse-proxy for IIS (SharePoint) site.
IIS uses the NTLM  authentication.

Regarding the squid document, squid 2.6+ or squid 3.1+ support
NTLM passthru authentication by Connection Pinning.

My problem is it always shows the 404 error code.
No NTLM prompt window is shown.


404 means URL does not exist. Nothing to do with authentication at all.

There is something funky happening though.



16.178.121.18  my desktop IP
  192.57.84.244  squid reverse proxy IP
16.173.232.237  IIS(SharePoint) site.

Red Hat Enterprise Linux Server release 5.7 (Tikanga) (64bit)
/usr/sbin/squid -v
Squid Cache: Version 2.6.STABLE21

The following packets are captured by tshark.


Hint: next time use "follow TCP stream" to obtain a human-readable trace 
of the packets.


As you can clearly see the connections are persistent but there is no 
NTLM involved below...


Client makes a request (no credentials at all)

  4   0.260075 16.178.121.18 ->  192.57.84.244 HTTP GET /SitePages/Square.aspx 
HT
TP/1.1

  00 50 56 ac 00 c6 00 22 0c d5 bc 00 08 00 45 00   .PV"..E.
0010  02 63 3a 5b 40 00 76 06 29 48 10 b2 79 12 c0 39   .c:[@.v.)H..y..9
0020  54 f4 fd 41 00 50 e8 0d e1 a6 eb ce 13 68 50 18   T..A.P...hP.
0030  40 b0 01 21 00 00 47 45 54 20 2f 53 69 74 65 50   @..!..GET /SiteP
0040  61 67 65 73 2f 53 71 75 61 72 65 2e 61 73 70 78   ages/Square.aspx
0050  20 48 54 54 50 2f 31 2e 31 0d 0a 41 63 63 65 70HTTP/1.1..Accep
0060  74 3a 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f 78   t: application/x
0070  2d 6d 73 2d 61 70 70 6c 69 63 61 74 69 6f 6e 2c   -ms-application,
0080  20 69 6d 61 67 65 2f 6a 70 65 67 2c 20 61 70 70image/jpeg, app
0090  6c 69 63 61 74 69 6f 6e 2f 78 61 6d 6c 2b 78 6d   lication/xaml+xm
00a0  6c 2c 20 69 6d 61 67 65 2f 67 69 66 2c 20 69 6d   l, image/gif, im
00b0  61 67 65 2f 70 6a 70 65 67 2c 20 61 70 70 6c 69   age/pjpeg, appli
00c0  63 61 74 69 6f 6e 2f 78 2d 6d 73 2d 78 62 61 70   cation/x-ms-xbap
00d0  2c 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f 76 6e   , application/vn
00e0  64 2e 6d 73 2d 65 78 63 65 6c 2c 20 61 70 70 6c   d.ms-excel, appl
00f0  69 63 61 74 69 6f 6e 2f 76 6e 64 2e 6d 73 2d 70   ication/vnd.ms-p
0100  6f 77 65 72 70 6f 69 6e 74 2c 20 61 70 70 6c 69   owerpoint, appli
0110  63 61 74 69 6f 6e 2f 6d 73 77 6f 72 64 2c 20 2a   cation/msword, *
0120  2f 2a 0d 0a 41 63 63 65 70 74 2d 4c 61 6e 67 75   /*..Accept-Langu
0130  61 67 65 3a 20 65 6e 2d 55 53 0d 0a 55 73 65 72   age: en-US..User
0140  2d 41 67 65 6e 74 3a 20 4d 6f 7a 69 6c 6c 61 2f   -Agent: Mozilla/
0150  34 2e 30 20 28 63 6f 6d 70 61 74 69 62 6c 65 3b   4.0 (compatible;
0160  20 4d 53 49 45 20 37 2e 30 3b 20 57 69 6e 64 6fMSIE 7.0; Windo
0170  77 73 20 4e 54 20 36 2e 31 3b 20 57 4f 57 36 34   ws NT 6.1; WOW64
0180  3b 20 54 72 69 64 65 6e 74 2f 34 2e 30 3b 20 53   ; Trident/4.0; S
0190  4c 43 43 32 3b 20 2e 4e 45 54 20 43 4c 52 20 32   LCC2; .NET CLR 2
01a0  2e 30 2e 35 30 37 32 37 3b 20 2e 4e 45 54 20 43   .0.50727; .NET C
01b0  4c 52 20 33 2e 35 2e 33 30 37 32 39 3b 20 2e 4e   LR 3.5.30729; .N
01c0  45 54 20 43 4c 52 20 33 2e 30 2e 33 30 37 32 39   ET CLR 3.0.30729
01d0  3b 20 4d 65 64 69 61 20 43 65 6e 74 65 72 20 50   ; Media Center P
01e0  43 20 36 2e 30 3b 20 49 6e 66 6f 50 61 74 68 2e   C 6.0; InfoPath.
01f0  32 3b 20 2e 4e 45 54 34 2e 30 43 3b 20 41 73 6b   2; .NET4.0C; Ask
0200  54 62 50 54 56 2f 35 2e 31 34 2e 31 2e 32 30 30   TbPTV/5.14.1.200
0210  30 37 29 0d 0a 41 63 63 65 70 74 2d 45 6e 63 6f   07)..Accept-Enco
0220  64 69 6e 67 3a 20 67 7a 69 70 2c 20 64 65 66 6c   ding: gzip, defl
0230  61 74 65 0d 0a 48 6f 73 74 3a 20 75 6b 77 74 73   ate..Host: ukwts
0240  76 75 6c 78 33 38 30 2e 65 6c 61 62 73 2e 65 64   vulx380.elabs.ed
0250  73 2e 63 6f 6d 0d 0a 43 6f 6e 6e 65 63 74 69 6f   s.com..Connectio
0260  6e 3a 20 4b 65 65 70 2d 41 6c 69 76 65 0d 0a 0d   n: Keep-Alive...
0270  0a.


I guess you configured cache_peer with the new login=PASSTHRU setting 
from squid-3.2


Squid obediently attaches Basic authentication username "PASSTHRU" and 
passes on the request ...



  9   0.535519 192.57.84.244 ->  16.173.232.237 HTTP GET /SitePages/Square.aspx 
H
TTP/1.0

  00 22 0c d5 bc 00 00 50 56 ac 00 c6 08 00 45 00   .".PV.E.
0010  03 1f 2b 09 40 00 40 06 fe 07 c0 39 54 f4 10 ad   ..+.@.@9T...
0020  e8 ed ab ef 00 50 85 f2 0a aa 8e d3 03 b1 80 18   .P..
0030  00 2e c2 8a 00 00 01 01 08 0a 79 b6 22 c6 0a 26   ..y."..&
0040  cb c0 47 45 54 20 2f 53 69 74 65 50 61 67 65 73   ..GET /SitePages
0050  2f 53 71 75 61 72 65 2e 61 73 70 78 20 48 54 54   /Square.aspx HTT
0060  50 2f 31 2e 30 0d 0a 41 63 63 65 70 74 3a 20 61   P/1.0..Accept: a
0070  70 70 6c 69 63 61 74 69 6f 6e 2f 78 2d 6d 73 2d   pplication/x-ms-
0080  61 70 70 6c 69 63 61 74 69 6f 6e 2c 20 69 6d 61   applic

[squid-users] NTLM passthru authentication

[巍俊葛]

Hi,

Can someone take a look at it the following issue which I ran into?
Here is the details:
Outline: squid 2.6 as the reverse-proxy for IIS (SharePoint) site.
IIS uses the NTLM  authentication.

Regarding the squid document, squid 2.6+ or squid 3.1+ support
NTLM passthru authentication by Connection Pinning.

My problem is it always shows the 404 error code.
No NTLM prompt window is shown.

16.178.121.18  my desktop IP
 192.57.84.244  squid reverse proxy IP
16.173.232.237  IIS(SharePoint) site.

Red Hat Enterprise Linux Server release 5.7 (Tikanga) (64bit)
/usr/sbin/squid -v
Squid Cache: Version 2.6.STABLE21

The following packets are captured by tshark.

 1   0.00 16.178.121.18 -> 192.57.84.244 TCP 64833 > http [SYN] Seq=0 Win=8
192 Len=0 MSS=1380 WS=2

  00 50 56 ac 00 c6 00 22 0c d5 bc 00 08 00 45 00   .PV"..E.
0010  00 34 3a 59 40 00 76 06 2b 79 10 b2 79 12 c0 39   .4:Y@.v.+y..y..9
0020  54 f4 fd 41 00 50 e8 0d e1 a5 00 00 00 00 80 02   T..A.P..
0030  20 00 e9 2e 00 00 02 04 05 64 01 03 03 02 01 01d..
0040  04 02 ..

 2   0.16 192.57.84.244 -> 16.178.121.18 TCP http > 64833 [SYN, ACK] Seq=0
Ack=1 Win=5840 Len=0 MSS=1460 WS=7

  00 22 0c d5 bc 00 00 50 56 ac 00 c6 08 00 45 00   .".PV.E.
0010  00 34 00 00 40 00 40 06 9b d2 c0 39 54 f4 10 b2   .4..@.@9T...
0020  79 12 00 50 fd 41 eb ce 13 67 e8 0d e1 a6 80 12   y..P.A...g..
0030  16 d0 f2 c2 00 00 02 04 05 b4 01 01 04 02 01 03   
0040  03 07 ..

 3   0.258861 16.178.121.18 -> 192.57.84.244 TCP 64833 > http [ACK] Seq=1 Ack=1
 Win=66240 Len=0

  00 50 56 ac 00 c6 00 22 0c d5 bc 00 08 00 45 00   .PV"..E.
0010  00 28 3a 5a 40 00 76 06 2b 84 10 b2 79 12 c0 39   .(:Z@.v.+...y..9
0020  54 f4 fd 41 00 50 e8 0d e1 a6 eb ce 13 68 50 10   T..A.P...hP.
0030  40 b0 09 b5 00 00 ff ff ff ff ff ff   @...

 4   0.260075 16.178.121.18 -> 192.57.84.244 HTTP GET /SitePages/Square.aspx HT
TP/1.1

  00 50 56 ac 00 c6 00 22 0c d5 bc 00 08 00 45 00   .PV"..E.
0010  02 63 3a 5b 40 00 76 06 29 48 10 b2 79 12 c0 39   .c:[@.v.)H..y..9
0020  54 f4 fd 41 00 50 e8 0d e1 a6 eb ce 13 68 50 18   T..A.P...hP.
0030  40 b0 01 21 00 00 47 45 54 20 2f 53 69 74 65 50   @..!..GET /SiteP
0040  61 67 65 73 2f 53 71 75 61 72 65 2e 61 73 70 78   ages/Square.aspx
0050  20 48 54 54 50 2f 31 2e 31 0d 0a 41 63 63 65 70HTTP/1.1..Accep
0060  74 3a 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f 78   t: application/x
0070  2d 6d 73 2d 61 70 70 6c 69 63 61 74 69 6f 6e 2c   -ms-application,
0080  20 69 6d 61 67 65 2f 6a 70 65 67 2c 20 61 70 70image/jpeg, app
0090  6c 69 63 61 74 69 6f 6e 2f 78 61 6d 6c 2b 78 6d   lication/xaml+xm
00a0  6c 2c 20 69 6d 61 67 65 2f 67 69 66 2c 20 69 6d   l, image/gif, im
00b0  61 67 65 2f 70 6a 70 65 67 2c 20 61 70 70 6c 69   age/pjpeg, appli
00c0  63 61 74 69 6f 6e 2f 78 2d 6d 73 2d 78 62 61 70   cation/x-ms-xbap
00d0  2c 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f 76 6e   , application/vn
00e0  64 2e 6d 73 2d 65 78 63 65 6c 2c 20 61 70 70 6c   d.ms-excel, appl
00f0  69 63 61 74 69 6f 6e 2f 76 6e 64 2e 6d 73 2d 70   ication/vnd.ms-p
0100  6f 77 65 72 70 6f 69 6e 74 2c 20 61 70 70 6c 69   owerpoint, appli
0110  63 61 74 69 6f 6e 2f 6d 73 77 6f 72 64 2c 20 2a   cation/msword, *
0120  2f 2a 0d 0a 41 63 63 65 70 74 2d 4c 61 6e 67 75   /*..Accept-Langu
0130  61 67 65 3a 20 65 6e 2d 55 53 0d 0a 55 73 65 72   age: en-US..User
0140  2d 41 67 65 6e 74 3a 20 4d 6f 7a 69 6c 6c 61 2f   -Agent: Mozilla/
0150  34 2e 30 20 28 63 6f 6d 70 61 74 69 62 6c 65 3b   4.0 (compatible;
0160  20 4d 53 49 45 20 37 2e 30 3b 20 57 69 6e 64 6fMSIE 7.0; Windo
0170  77 73 20 4e 54 20 36 2e 31 3b 20 57 4f 57 36 34   ws NT 6.1; WOW64
0180  3b 20 54 72 69 64 65 6e 74 2f 34 2e 30 3b 20 53   ; Trident/4.0; S
0190  4c 43 43 32 3b 20 2e 4e 45 54 20 43 4c 52 20 32   LCC2; .NET CLR 2
01a0  2e 30 2e 35 30 37 32 37 3b 20 2e 4e 45 54 20 43   .0.50727; .NET C
01b0  4c 52 20 33 2e 35 2e 33 30 37 32 39 3b 20 2e 4e   LR 3.5.30729; .N
01c0  45 54 20 43 4c 52 20 33 2e 30 2e 33 30 37 32 39   ET CLR 3.0.30729
01d0  3b 20 4d 65 64 69 61 20 43 65 6e 74 65 72 20 50   ; Media Center P
01e0  43 20 36 2e 30 3b 20 49 6e 66 6f 50 61 74 68 2e   C 6.0; InfoPath.
01f0  32 3b 20 2e 4e 45 54 34 2e 30 43 3b 20 41 73 6b   2; .NET4.0C; Ask
0200  54 62 50 54 56 2f 35 2e 31 34 2e 31 2e 32 30 30   TbPTV/5.14.1.200
0210  30 37 29 0d 0a 41 63 63 65 70 74 2d 45 6e 63 6f   07)..Accept-Enco
0220  64 69 6e 67 3a 20 67 7a 69 70 2c 20 64 65 66 6c   ding: gzip, defl
0230  61 74 65 0d 0a 48 6f 73 74 3a 20 75 6b 77 74 73   ate..Host: ukwts
0240  76 75 6c 78 33 38 30 2e 65 6c 61 62 73 2e 65 64   vulx380.elabs.ed
0250  73 2e 63 6f 6d 0d 0a 43 6f 6e 6e 65 63 74 69 6f   s.com..Connectio
0260  6e 3a 20 4b 65 65 70 2d 41 6c 69 76 65 0d 0a 0d   n: Keep-Alive...
0270  0a.

 5   0.260125 192.57.84.244 

[squid-users] ntlm/kerberos alternative with netware

[E.S. Rosenberg]

Hi,
For our windows computers we run a mostly AD environment except for
one faculty that is using Novell NetWare, for all other locations we
have switched to NTLM authentication (and are hoping to 'upgrade' that
to krb5 soon), non domain computers can also work in this setup just
that they are generally confronted with several authentication dialogs
on browser start.

As far as I can tell this is due to the browser instantly firing of
several requests and getting back a 407 on each and displaying a
password dialog for each 407.

Either way since we have some trust issues vis-a-vis the NetWare
'domain' it might be a good idea if the users from there are
automatically authenticated and don't enter their general passwords
(the usernames are the same), so I am trying to find out if there is
some secure kerberos like method that works with NetWare.

Thanks,
Eli

Re: [squid-users] NTLM with a fall back to anonymous

[Jason Fitzpatrick]

Hi Henrik..

it is never easy is it ;0)

Looks like I will be maintaining whitelists for the foreseeable future!

Thanks for the reply

Jay

2012/2/4 Henrik Nordström :
> lör 2012-02-04 klockan 13:23 + skrev Jason Fitzpatrick:
>
>> I was hoping that if a client failed to authenticate then it would be
>> forwarded to the upstream and fall under what ever the default (un
>> authorized) ruleset is, known risky sites etc would be getting
>> filtered there,
>
> Unfortunately HTTP do not work in that way.
>
> Clients not supporting authentication sends requests without any
> credentials at all. Proxies (and servers) wanting to see authentication
> then rejects the request with an error "authentication required"
> challenging the client to present valid credentials.
>
> Clients supporting authentication also starts out by sending the request
> without any credentials at all like above. The difference is only how
> the client reacts to the received error. If the client supports
> authentication then it collects the needed user credentials and retries
> the same request but with user credentials this time.
>
> If the credentials is invalid then the authentication fails, which in
> most cases results in the exact same error as above to challenge the
> user to enter the correct credentials.
>
> Regards
> Henrik
>



--

"The only difference between saints and sinners is that every saint
has a past while every sinner has a future. "
— Oscar Wilde

Re: [squid-users] NTLM with a fall back to anonymous

[Henrik Nordström]

lör 2012-02-04 klockan 13:23 + skrev Jason Fitzpatrick:

> I was hoping that if a client failed to authenticate then it would be
> forwarded to the upstream and fall under what ever the default (un
> authorized) ruleset is, known risky sites etc would be getting
> filtered there,

Unfortunately HTTP do not work in that way.

Clients not supporting authentication sends requests without any
credentials at all. Proxies (and servers) wanting to see authentication
then rejects the request with an error "authentication required"
challenging the client to present valid credentials.

Clients supporting authentication also starts out by sending the request
without any credentials at all like above. The difference is only how
the client reacts to the received error. If the client supports
authentication then it collects the needed user credentials and retries
the same request but with user credentials this time.

If the credentials is invalid then the authentication fails, which in
most cases results in the exact same error as above to challenge the
user to enter the correct credentials.

Regards
Henrik

Re: [squid-users] NTLM with a fall back to anonymous

[Jason Fitzpatrick]

Hi Amos,,

Yet again thanks for a very complete reply!

Our problem is that the upstream system is the one with all the
content filtering on it, and I have started creating a whitelist for
the known destinations but it is quickly going to become unmanageable.

I was hoping that if a client failed to authenticate then it would be
forwarded to the upstream and fall under what ever the default (un
authorized) ruleset is, known risky sites etc would be getting
filtered there,

Jay

On 4 February 2012 12:02, Amos Jeffries  wrote:
> On 5/02/2012 12:30 a.m., Jason Fitzpatrick wrote:
>>
>> Morning all..
>>
>> I have a requirement to have my squid servers authenticate users
>> before forwarding requests to an upstream server which does content
>> filtering based on the X-Forwarded headers in the requests and all
>> seems to be working quite well so far, (internal traffic is routed via
>> the squids without the need to authenticate)
>>
>> I do have one issue though, clients that are unable to authenticate
>> (windows update / Java updates etc) and want to set up the system so
>> that it will attempt to authenticate the user, and if the
>> authentication fails the request is routed regardless
>>
>> Is such a thing possible? I have tried all sorts of configurations but
>> the logic to the rules still escapes me!
>
>
> This is a side case of security which seems to boggle many an admins mind.
> The core of the problem is that missing credentials is only one *sub-set* of
> all failed authentications. You cannot simply take "failed auth" and assume
> its one of the "good" software which is failing. These days it will quite
> frequently be someone malicious, possibly even forging the "good" software
> user-agent header to get access.
>
> In particular missing credentials is a type of failure indistinguishable
> from an HTTP request which has not yet even been challenged for credentials.
> HTTP is stateless so there is no way to identify two clients sharing a
> downstream proxy and one client re-trying without credentials. You must
> hard-code that distinction for the specific cases you know of, thus all the
> well published config hacks.
>
> Amos



--

"The only difference between saints and sinners is that every saint
has a past while every sinner has a future. "
— Oscar Wilde

Re: [squid-users] NTLM with a fall back to anonymous

[Amos Jeffries]

On 5/02/2012 12:30 a.m., Jason Fitzpatrick wrote:

Morning all..

I have a requirement to have my squid servers authenticate users
before forwarding requests to an upstream server which does content
filtering based on the X-Forwarded headers in the requests and all
seems to be working quite well so far, (internal traffic is routed via
the squids without the need to authenticate)

I do have one issue though, clients that are unable to authenticate
(windows update / Java updates etc) and want to set up the system so
that it will attempt to authenticate the user, and if the
authentication fails the request is routed regardless

Is such a thing possible? I have tried all sorts of configurations but
the logic to the rules still escapes me!


This is a side case of security which seems to boggle many an admins 
mind. The core of the problem is that missing credentials is only one 
*sub-set* of all failed authentications. You cannot simply take "failed 
auth" and assume its one of the "good" software which is failing. These 
days it will quite frequently be someone malicious, possibly even 
forging the "good" software user-agent header to get access.


In particular missing credentials is a type of failure indistinguishable 
from an HTTP request which has not yet even been challenged for 
credentials. HTTP is stateless so there is no way to identify two 
clients sharing a downstream proxy and one client re-trying without 
credentials. You must hard-code that distinction for the specific cases 
you know of, thus all the well published config hacks.


Amos

[squid-users] NTLM with a fall back to anonymous

[Jason Fitzpatrick]

Morning all..

I have a requirement to have my squid servers authenticate users
before forwarding requests to an upstream server which does content
filtering based on the X-Forwarded headers in the requests and all
seems to be working quite well so far, (internal traffic is routed via
the squids without the need to authenticate)

I do have one issue though, clients that are unable to authenticate
(windows update / Java updates etc) and want to set up the system so
that it will attempt to authenticate the user, and if the
authentication fails the request is routed regardless

Is such a thing possible? I have tried all sorts of configurations but
the logic to the rules still escapes me!

Thanks for any suggestions

Jay

--

"The only difference between saints and sinners is that every saint
has a past while every sinner has a future. "
— Oscar Wilde

[squid-users] NTLM woes

[walh]

Hi, 
firstly, please execuse me if this has been discussed in the past however i
am new to Squid and uncertain if this particular scenario is supported (even
after reading forums) 

I have installed squid as a simple forward caching proxy (no cache_peer'ing
or reverse proxy configuration). This is working fine for many websites on
our intranet except for 2x websites that require clients to authentication
via NTLM. 

Clients can access the NTLM sites and authenticate correctly if accessed
directly. 
Clients cannot access the NTLM sites if accessed through the squid proxy. 

I have downloaded and installed the windows binaries (2.7 and 3.0) with
default configuration. NTLM to the origin servers does not work with both
versions. 

Is this a supported function by Squid? 

I have noticed (via wireshark) that the client is closing down the TCP
connection and restarting post 401 message from Squid. 

Thank you in advance 


--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/NTLM-woes-tp4339985p4339985.html
Sent from the Squid - Users mailing list archive at Nabble.com.

[squid-users] NTLM auth for RPC over HTTPS to outlook everywhere

[Clem]

 Hello,

I've an issue with my squid 3.1.6, I use it to be a frontal of my 
exchange server, via RPC over HTTPS, the OWA works fine, but for outlook 
anywhere, I can log with outlook via basic authentification, but not NTLM.


Previsouly I was on NTLM, without squid and direct connexion on my 
exchange and that was working.


The cache.log tells me :

statusIfComplete: Request not yet fully sent "RPC_IN_DATA 
https://xx.xx.xx/rpc/rpcproxy.dll?lan_mail_server:6002";


What can I do to make the NTLM auth to work ?

Regards,

Clem
//

RE: [squid-users] NTLM Authentication

[John Sayce]

>-Original Message-
>From: Amos Jeffries [mailto:squ...@treenet.co.nz]
>Sent: 18 November 2011 04:53
>To: squid-users@squid-cache.org
>Subject: Re: [squid-users] NTLM Authentication
>
>On 18/11/2011 2:23 a.m., John Sayce wrote:
>>> On Mon, 14 Nov 2011 14:50:02 +, John Sayce wrote:
>>>> I have squid configured and working fine with ntlm authentication,
>>>> however about once a week access to the throughput will slow and I
>>>> can
>>>> be presented with access denied messages.  Restarting squid instantly
>>>> fixes the problem.  My configuration is relatively simple as bellow.
>>>> I
>>>> don't have a large user base. There's only 60 users and the problem
>>>> is
>>>> instantly gone upon restarting squid which suggests to me that it's
>>>> not simply be a problem of load as the log would suggest.  I wondered
>>>> if it was a single computer or application causing the issue but I'm
>>>> not sure how to find out.
>>>>
>>>> http_port 8080
>>>>
>>>> auth_param ntlm program c:/squid/libexec/mswin_ntlm_auth.exe
>>>> auth_param ntlm children 30
>>>> external_acl_type win_domain_group children=30 ttl=120 %LOGIN
>>>> c:/squid/libexec/mswin_check_lm_group.exe -G
>>>>
>>>> acl all src 0.0.0.0/0.0.0.0
>>>> acl nocache dstdomain "C:\squid\etc\nocache_domains.acl"
>>>> acl unauthenticatednet src "C:\squid\etc\unrestrictedaddresses.acl"
>>>> acl blocked src "C:\squid\etc\restrictedaddresses.acl"
>>>> acl inetallowgroup external win_domain_group InternetAllow
>>>> acl inetrestrictgroup external win_domain_group InternetRestricted
>>>> acl localhost src 127.0.0.1/255.255.255.255
>>>> acl localnet proxy_auth REQUIRED src 192.168.0.0/255.255.255.0
>>> The above ACL definition has never been valid.
>>>
>>> Perhapse you wanted:
>>>acl localnet src 192.168.0.0/24
>>>acl login proxy_auth REQUIRED
>>>
>>>http_access deny !localnet
>>>http_access deny !login
>>>
>>> The "deny !localnet" will prevent non-LAN users from logging in. If you
>>> can do that great. It will prevent external machines flooding your proxy
>>> with malicious login load.
>>>
>>> The "deny !login" is to do the user login quickly and reject early if
>>> they fail that. From your logs below I see 3x lookups being done, one
>>> for each group check. All of which are failing due to invalid domain
>>> name on the user credentials. Doing this "deny !login" will drop the
>>> speed loss on the failure cases by more than 60%.
>>>
>>>
>> I've implemented this.  I'd strugled to find documentation on the formating 
>> and syntax for ntlm authentication.  Thanks.
>>
>>>> acl denied_domains dstdomain "C:\squid\etc\denied_domains.acl"
>>>> acl allowed_domains dstdomain "C:\squid\etc\allowed_domains.acl"
>>>> acl allowed_addresses dst "C:\squid\etc\allowed_addresses.acl"
>>>> acl manager proto cache_object
>>>>
>>>> always_direct allow nocache
>>>> http_access allow manager monitor
>>>> http_access deny localhost
>>>> http_access deny blocked
>>>> http_access allow unauthenticatednet
>>>> http_access allow allowed_domains
>>>> http_access allow allowed_addresses
>>> NP: "allowed_addresses" requires DNS lookup. So slows every request
>>> down to find the requested domains DNS entries.
>>>
>> Allowed addresses is actually a list of ip addresses and ranges that are 
>> allowed.  I presume you mean allowed_domains >which is a list of domains 
>> that are permited?
>
>Nope I mean "allowed_addresses".  The "dst" ACL type [destinaion IP]
>does DNS lookup on the requested URL [destination domain] to find and
>match its IPs against the ACL list of IPs.
>
>
>> In the majority of cases I can change this to use ip addresses if it will 
>> improve performance.  The problem would come >that in some cases I've 
>> allowed the top level domain because I want to allow all the sub domains 
>> also, mainly for >applications that can't authenticate to get their updates. 
>>  Is there a way round this or is the best practice to put the >effort in and 
>> find the addresses for all the req

Re: [squid-users] NTLM authentica​tion to external sites using Windows 7

[Amos Jeffries]

On 19/11/2011 8:53 a.m., Øyvind Haddal wrote:

Amos,

I am having this issue on all sites with this type of authentication
(Windows security popup box), it's not specifically related to one
site.


Well, I'm sad to have to say this but be prepared for it never to work. 
This is a problem caused in one way or another by NTLM violating the 
HTTP standards and assuming things about the network that are simply not 
true once you go from a highly controlled MS-centric LAN to the 
Internet, (simple assumptions like TCP connections are always packets 
from the same user, which is not even true in LAN).


That you had it working for XP is a good sign that it might be able to 
be hacked up for Windows7.





Have tested with Wireshark when accessing one of our Sharepoint sites
with both Windows XP and 7, here's how the communication goes;

Step 1. HTTP/1,1 401 Access denied
Step 2. GET http://sharepointURL/ HTTP/1.1 , NTLMSSP_NEGOTIATE
Step 3. HTTP/1.1 401 Unauthorized , NTLMSSP_CHALLENGE
Step 4. GET http://sharepointURL/  HTTP/1.1 , NTLMSSP_AUTH, User:
hqdomain\myusername

On Windows XP through Squid, and both Windows XP and 7 directly to
Bluecoat, Step 5 will give; GET http://sharepointURL/default.aspx
HTTP/1.1 after it's performed a 301 redirect to default.aspx

On Windows 7 through Squid, I get; HTTP/1.0 401 Unauthorized, which
then prompts for re-authentication.

I'm not seeing any difference in Step 1-4, but I'm fairly new to this
and am unsure what I should be looking for, I may be missing
something.


From that the only difference is HTTP/1.0 vs HTTP/1.1.

The browser deciding to prompt instead of finish sending the credentials 
is an indication that it cannot support the NTLM version. Or the server 
is requesting credentials for a domain which the browser does not have 
any credentials for. Or the server has closed the TCP connection (NTLM 
assumes that is the same as credentials failing), in HTTP connections 
may close at any time for any number of reasons completely unrelated to 
credentials.


Amos

Re: [squid-users] NTLM authentica​tion to external sites using Windows 7

[Øyvind Haddal]

Amos,

I am having this issue on all sites with this type of authentication
(Windows security popup box), it's not specifically related to one
site.

Have tested with Wireshark when accessing one of our Sharepoint sites
with both Windows XP and 7, here's how the communication goes;

Step 1. HTTP/1,1 401 Access denied
Step 2. GET http://sharepointURL/ HTTP/1.1 , NTLMSSP_NEGOTIATE
Step 3. HTTP/1.1 401 Unauthorized , NTLMSSP_CHALLENGE
Step 4. GET http://sharepointURL/  HTTP/1.1 , NTLMSSP_AUTH, User:
hqdomain\myusername

On Windows XP through Squid, and both Windows XP and 7 directly to
Bluecoat, Step 5 will give; GET http://sharepointURL/default.aspx
HTTP/1.1 after it's performed a 301 redirect to default.aspx

On Windows 7 through Squid, I get; HTTP/1.0 401 Unauthorized, which
then prompts for re-authentication.

I'm not seeing any difference in Step 1-4, but I'm fairly new to this
and am unsure what I should be looking for, I may be missing
something.

Øyvind

On Fri, Nov 18, 2011 at 3:32 PM, Amos Jeffries  wrote:
> On 19/11/2011 2:03 a.m., Øyvind Haddal wrote:
>>
>> I am in the process of evaluating and testing a Squid configuration in
>> my environment, I have everything working the way I want except for
>> one thing; NTLM authentication with Windows 7 clients to a site in
>> another domain
>>
>> Squid proxy is configured with multiple Bluecoat proxy servers as
>> parents, which handles all the user authentication using LDAP.
>> However, I also have a requirement that users sometimes log on a site
>> located in a different domain, using personal Windows credentials for
>> that domain. This works without any problem with Windows XP clients,
>> but Windows 7 clients just keep getting the login prompt and are
>> unable to log in.
>>
>> I've configured the GPO for NTLMv1 on my domain, as suggested by other
>> threads, but this did not make any difference. All other threads I
>> have found are for issues where you want to use NTLM for Squid
>> authentication, which is not what I am trying to do.
>
> Avoid NTLMv1.  XP and later all support NTLMv2 and there is no difference
> between NTLM versions to Squid.
>
> The squid config you show is not doing anything except passing credentials
> untouched to the peers.
>
>> Hoping someone can assist or at least point me in the right direction
>> to solve this.
>
> Grab a copy of the HTTP headers in the request and replies to that website.
> Likely it is offering Negotiate support and the Windows 7 machines are
> trying to use it.
>
> Alternatively it could actually be requiring any one of a number of obsolete
> Microsoft protocols or encryption methods which all get called "NTLM" and
> have been dropped from Windows 7.
>
>
> Amos
>
>

Re: [squid-users] NTLM authentica​tion to external sites using Windows 7

[Amos Jeffries]

On 19/11/2011 2:03 a.m., Øyvind Haddal wrote:

I am in the process of evaluating and testing a Squid configuration in
my environment, I have everything working the way I want except for
one thing; NTLM authentication with Windows 7 clients to a site in
another domain

Squid proxy is configured with multiple Bluecoat proxy servers as
parents, which handles all the user authentication using LDAP.
However, I also have a requirement that users sometimes log on a site
located in a different domain, using personal Windows credentials for
that domain. This works without any problem with Windows XP clients,
but Windows 7 clients just keep getting the login prompt and are
unable to log in.

I've configured the GPO for NTLMv1 on my domain, as suggested by other
threads, but this did not make any difference. All other threads I
have found are for issues where you want to use NTLM for Squid
authentication, which is not what I am trying to do.


Avoid NTLMv1.  XP and later all support NTLMv2 and there is no 
difference between NTLM versions to Squid.


The squid config you show is not doing anything except passing 
credentials untouched to the peers.



Hoping someone can assist or at least point me in the right direction
to solve this.


Grab a copy of the HTTP headers in the request and replies to that 
website. Likely it is offering Negotiate support and the Windows 7 
machines are trying to use it.


Alternatively it could actually be requiring any one of a number of 
obsolete Microsoft protocols or encryption methods which all get called 
"NTLM" and have been dropped from Windows 7.



Amos

[squid-users] NTLM authentica​tion to external sites using Windows 7

[Øyvind Haddal]

I am in the process of evaluating and testing a Squid configuration in
my environment, I have everything working the way I want except for
one thing; NTLM authentication with Windows 7 clients to a site in
another domain

Squid proxy is configured with multiple Bluecoat proxy servers as
parents, which handles all the user authentication using LDAP.
However, I also have a requirement that users sometimes log on a site
located in a different domain, using personal Windows credentials for
that domain. This works without any problem with Windows XP clients,
but Windows 7 clients just keep getting the login prompt and are
unable to log in.

I've configured the GPO for NTLMv1 on my domain, as suggested by other
threads, but this did not make any difference. All other threads I
have found are for issues where you want to use NTLM for Squid
authentication, which is not what I am trying to do.

Hoping someone can assist or at least point me in the right direction
to solve this.


Server: Ubuntu 11.10

Squid Cache: Version 3.1.14
configure options:  '--build=x86_64-linux-gnu' '--prefix=/usr'
'--includedir=${prefix}/include' '--mandir=${prefix}/share/man'
'--infodir=${prefix}/share/info' '--sysconfdir=/etc'
'--localstatedir=/var' '--libexecdir=${prefix}/lib/squid3'
'--srcdir=.' '--disable-maintainer-mode'
'--disable-dependency-tracking' '--disable-silent-rules'
'--datadir=/usr/share/squid3' '--sysconfdir=/etc/squid3'
'--mandir=/usr/share/man' '--with-cppunit-basedir=/usr'
'--enable-inline' '--enable-async-io=8'
'--enable-storeio=ufs,aufs,diskd' '--enable-removal-policies=lru,heap'
'--enable-delay-pools' '--enable-cache-digests' '--enable-underscores'
'--enable-icap-client' '--enable-follow-x-forwarded-for'
'--enable-auth=basic,digest,ntlm,negotiate'
'--enable-basic-auth-helpers=LDAP,MSNT,NCSA,PAM,SASL,SMB,YP,DB,POP3,getpwnam,squid_radius_auth,multi-domain-NTLM'
'--enable-ntlm-auth-helpers=smb_lm,'
'--enable-digest-auth-helpers=ldap,password'
'--enable-negotiate-auth-helpers=squid_kerb_auth'
'--enable-external-acl-helpers=ip_user,ldap_group,session,unix_group,wbinfo_group'
'--enable-arp-acl' '--enable-esi' '--enable-zph-qos'
'--disable-translation' '--with-logdir=/var/log/squid3'
'--with-pidfile=/var/run/squid3.pid' '--with-filedescriptors=65536'
'--with-large-files' '--with-default-user=proxy'
'--enable-linux-netfilter' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g
-O2 -g -O2 -Wall' 'LDFLAGS=-Wl,-Bsymbolic-functions' 'CPPFLAGS='
'CXXFLAGS=-g -O2 -g -O2 -Wall'
--with-squid=/build/buildd/squid3-3.1.14


Squid.conf (IP addresses and names altered before posting public, the
rest is the same as the running configuration)

http_port 8080 ignore-cc

cache_peer Bluecoat1 parent 80 0 no-query login=PASS weight=1
cache_peer Bluecoat2 parent 80 0 no-query login=PASS weight=2

#ACL for streaming
acl streaming dstdomain "/etc/squid3/streaming.acl"

#ACL for QoS after Squid
acl lan1 src 10.200.50.0/24
acl lan2 src 10.200.60.0/24
acl lan3 src 10.200.70.0/24
acl lan4 src 10.200.80.0/24
tcp_outgoing_address 10.0.0.205 lan1
tcp_outgoing_address 10.0.0.206 lan2
tcp_outgoing_address 10.0.0.207 lan3
tcp_outgoing_address 10.0.0.208 lan4

#Suggested off when using tcp_outgoing_address
#server_persistent_connections off //Breaks external NTLM for Windows
XP clients as well when off

#Apply ACL filters
http_access deny streaming
http_access allow all
never_direct allow all

#Cache configuration
cache_mem 512 MB
maximum_object_size_in_memory 1024 KB
cache_dir ufs /var/spool/squid3 45000 16 256
max_open_disk_fds 0
minimum_object_size 0 KB
maximum_object_size 128000 KB

# Refresh patterns
refresh_pattern -i \.(gif|png|jpg|jpeg|ico)$ 10080 90% 43200
override-expire ignore-no-cache ignore-no-store ignore-private
refresh_pattern -i \.(iso|avi|wav|mp3|mp4|mpeg|swf|flv|x-flv)$ 43200
90% 432000 override-expire ignore-no-cache ignore-no-store
ignore-private
refresh_pattern -i
\.(deb|rpm|exe|zip|tar|tgz|ram|rar|bin|ppt|doc|tiff)$ 10080 90% 43200
override-expire ignore-no-cache ignore-no-store ignore-private
refresh_pattern -i \.index.(html|htm)$ 0 40% 10080
refresh_pattern -i \.(html|htm|css|js)$ 1440 40% 40320
refresh_pattern ^ftp:   144020% 10080
refresh_pattern ^gopher:14400%  1440
refresh_pattern -i (/cgi-bin/|\?) 0 0%  0

Re: [squid-users] NTLM Authentication

[Amos Jeffries]

On 18/11/2011 2:23 a.m., John Sayce wrote:

On Mon, 14 Nov 2011 14:50:02 +, John Sayce wrote:

I have squid configured and working fine with ntlm authentication,
however about once a week access to the throughput will slow and I
can
be presented with access denied messages.  Restarting squid instantly
fixes the problem.  My configuration is relatively simple as bellow.
I
don't have a large user base. There's only 60 users and the problem
is
instantly gone upon restarting squid which suggests to me that it's
not simply be a problem of load as the log would suggest.  I wondered
if it was a single computer or application causing the issue but I'm
not sure how to find out.

http_port 8080

auth_param ntlm program c:/squid/libexec/mswin_ntlm_auth.exe
auth_param ntlm children 30
external_acl_type win_domain_group children=30 ttl=120 %LOGIN
c:/squid/libexec/mswin_check_lm_group.exe -G

acl all src 0.0.0.0/0.0.0.0
acl nocache dstdomain "C:\squid\etc\nocache_domains.acl"
acl unauthenticatednet src "C:\squid\etc\unrestrictedaddresses.acl"
acl blocked src "C:\squid\etc\restrictedaddresses.acl"
acl inetallowgroup external win_domain_group InternetAllow
acl inetrestrictgroup external win_domain_group InternetRestricted
acl localhost src 127.0.0.1/255.255.255.255
acl localnet proxy_auth REQUIRED src 192.168.0.0/255.255.255.0

The above ACL definition has never been valid.

Perhapse you wanted:
   acl localnet src 192.168.0.0/24
   acl login proxy_auth REQUIRED

   http_access deny !localnet
   http_access deny !login

The "deny !localnet" will prevent non-LAN users from logging in. If you
can do that great. It will prevent external machines flooding your proxy
with malicious login load.

The "deny !login" is to do the user login quickly and reject early if
they fail that. From your logs below I see 3x lookups being done, one
for each group check. All of which are failing due to invalid domain
name on the user credentials. Doing this "deny !login" will drop the
speed loss on the failure cases by more than 60%.



I've implemented this.  I'd strugled to find documentation on the formating and 
syntax for ntlm authentication.  Thanks.


acl denied_domains dstdomain "C:\squid\etc\denied_domains.acl"
acl allowed_domains dstdomain "C:\squid\etc\allowed_domains.acl"
acl allowed_addresses dst "C:\squid\etc\allowed_addresses.acl"
acl manager proto cache_object

always_direct allow nocache
http_access allow manager monitor
http_access deny localhost
http_access deny blocked
http_access allow unauthenticatednet
http_access allow allowed_domains
http_access allow allowed_addresses

NP: "allowed_addresses" requires DNS lookup. So slows every request
down to find the requested domains DNS entries.


Allowed addresses is actually a list of ip addresses and ranges that are 
allowed.  I presume you mean allowed_domains which is a list of domains that 
are permited?


Nope I mean "allowed_addresses".  The "dst" ACL type [destinaion IP] 
does DNS lookup on the requested URL [destination domain] to find and 
match its IPs against the ACL list of IPs.




In the majority of cases I can change this to use ip addresses if it will 
improve performance.  The problem would come that in some cases I've allowed 
the top level domain because I want to allow all the sub domains also, mainly 
for applications that can't authenticate to get their updates.  Is there a way 
round this or is the best practice to put the effort in and find the addresses 
for all the required subdomains as well?



"allowed_domains" is actually the better form, since Squid can test the 
ACL quickly without locating external data in DNS. If you can convert 
allowed_addresses IP entries into allowed_domains name entries that 
would be a little faster.








http_access deny inetrestrictgroup denied_domains

Swap those ACLs order to:
  denied_domains inetrestrictgroup

That will reduce the helper lookup load on the !denied_domains cases a
bit.



I thought it might be worth mentioning that denied_domains is actually empty.  
I put it in for future use.  But I have swapped these anyhow.


Then it can never match and even better to have it ordered first and 
save testing the whole line.



http_access allow inetrestrictgroup
http_access allow inetallowgroup
http_access deny all

cache_mem 500 MB
maximum_object_size_in_memory 1 MB
cache_dir ufs c:/squid/var/cache 7000 16 512

access_log C:\squid\var\logs\access.log squid.

My cache log would seem to suggest that it's related to the ntlm
helper processes.  Eg

/mswin_check_lm_group.exe Can't find DC for local domain 'asd'

Your DC has disappeared, or some client is sending in a login domain
which is not yours.
Nothing the helpers can do about either case but reject. It does so,
after the horribly long lag it took to discover that problem.


It might be possible that there is a network issue but my dc is monitored by 
nagios and hasn't registered any issues with the checks I have in place.  I'm 
going to see if I can audit 

RE: [squid-users] NTLM Authentication

[John Sayce]

> On Mon, 14 Nov 2011 14:50:02 +, John Sayce wrote:
>> I have squid configured and working fine with ntlm authentication,
>> however about once a week access to the throughput will slow and I
>> can
>> be presented with access denied messages.  Restarting squid instantly
>> fixes the problem.  My configuration is relatively simple as bellow.
>> I
>> don't have a large user base. There's only 60 users and the problem
>> is
>> instantly gone upon restarting squid which suggests to me that it's
>> not simply be a problem of load as the log would suggest.  I wondered
>> if it was a single computer or application causing the issue but I'm
>> not sure how to find out.
>>
>> http_port 8080
>>
>> auth_param ntlm program c:/squid/libexec/mswin_ntlm_auth.exe
>> auth_param ntlm children 30
>> external_acl_type win_domain_group children=30 ttl=120 %LOGIN
>> c:/squid/libexec/mswin_check_lm_group.exe -G
>>
>> acl all src 0.0.0.0/0.0.0.0
>> acl nocache dstdomain "C:\squid\etc\nocache_domains.acl"
>> acl unauthenticatednet src "C:\squid\etc\unrestrictedaddresses.acl"
>> acl blocked src "C:\squid\etc\restrictedaddresses.acl"
>> acl inetallowgroup external win_domain_group InternetAllow
>> acl inetrestrictgroup external win_domain_group InternetRestricted
>> acl localhost src 127.0.0.1/255.255.255.255
>> acl localnet proxy_auth REQUIRED src 192.168.0.0/255.255.255.0
>
> The above ACL definition has never been valid.
>
> Perhapse you wanted:
>   acl localnet src 192.168.0.0/24
>   acl login proxy_auth REQUIRED
>
>   http_access deny !localnet
>   http_access deny !login
>
> The "deny !localnet" will prevent non-LAN users from logging in. If you
> can do that great. It will prevent external machines flooding your proxy
> with malicious login load.
>
> The "deny !login" is to do the user login quickly and reject early if
> they fail that. From your logs below I see 3x lookups being done, one
> for each group check. All of which are failing due to invalid domain
> name on the user credentials. Doing this "deny !login" will drop the
> speed loss on the failure cases by more than 60%.
>
>

I've implemented this.  I'd strugled to find documentation on the formating and 
syntax for ntlm authentication.  Thanks.

>> acl denied_domains dstdomain "C:\squid\etc\denied_domains.acl"
>> acl allowed_domains dstdomain "C:\squid\etc\allowed_domains.acl"
>> acl allowed_addresses dst "C:\squid\etc\allowed_addresses.acl"
>> acl manager proto cache_object
>>
>> always_direct allow nocache
>> http_access allow manager monitor
>> http_access deny localhost
>> http_access deny blocked
>> http_access allow unauthenticatednet
>> http_access allow allowed_domains
>> http_access allow allowed_addresses
>
> NP: "allowed_addresses" requires DNS lookup. So slows every request
> down to find the requested domains DNS entries.
>

Allowed addresses is actually a list of ip addresses and ranges that are 
allowed.  I presume you mean allowed_domains which is a list of domains that 
are permited?

In the majority of cases I can change this to use ip addresses if it will 
improve performance.  The problem would come that in some cases I've allowed 
the top level domain because I want to allow all the sub domains also, mainly 
for applications that can't authenticate to get their updates.  Is there a way 
round this or is the best practice to put the effort in and find the addresses 
for all the required subdomains as well?



> http_access deny inetrestrictgroup denied_domains
>
> Swap those ACLs order to:
>  denied_domains inetrestrictgroup
>
> That will reduce the helper lookup load on the !denied_domains cases a
> bit.
>
>

I thought it might be worth mentioning that denied_domains is actually empty.  
I put it in for future use.  But I have swapped these anyhow.

>> http_access allow inetrestrictgroup
>> http_access allow inetallowgroup
>> http_access deny all
>>
>> cache_mem 500 MB
>> maximum_object_size_in_memory 1 MB
>> cache_dir ufs c:/squid/var/cache 7000 16 512
>>
>> access_log C:\squid\var\logs\access.log squid.
>>
>> My cache log would seem to suggest that it's related to the ntlm
>> helper processes.  Eg
>>
>> /mswin_check_lm_group.exe Can't find DC for local domain 'asd'
>
> Your DC has disappeared, or some client is sending in a login domain
> which is not yours.
> Nothing the helpers can do about either case but reject. It does so,
> after the horribly long lag it took to discover that problem.
>

It might be possible that there is a network issue but my dc is monitored by 
nagios and hasn't registered any issues with the checks I have in place.  I'm 
going to see if I can audit the failed requests, which I would have hoped 
happened by default in active directory but apparently not.

> I think this is the output of checking "deny inetrestrictgroup
> denied_domains".
>
>> 2011/11/14 11:31:57| storeUfsCreate: Failed to create
>> c:/squid/var/cache/01/C2/00058467 ((13) Permission denied)
>> /mswin_check_lm_group.exe Can't find DC for local dom

Re: [squid-users] NTLM Authentication

[Amos Jeffries]

On Mon, 14 Nov 2011 14:50:02 +, John Sayce wrote:

I have squid configured and working fine with ntlm authentication,
however about once a week access to the throughput will slow and I 
can

be presented with access denied messages.  Restarting squid instantly
fixes the problem.  My configuration is relatively simple as bellow. 
I
don't have a large user base. There's only 60 users and the problem 
is

instantly gone upon restarting squid which suggests to me that it's
not simply be a problem of load as the log would suggest.  I wondered
if it was a single computer or application causing the issue but I'm
not sure how to find out.

http_port 8080

auth_param ntlm program c:/squid/libexec/mswin_ntlm_auth.exe
auth_param ntlm children 30
external_acl_type win_domain_group children=30 ttl=120 %LOGIN
c:/squid/libexec/mswin_check_lm_group.exe -G

acl all src 0.0.0.0/0.0.0.0
acl nocache dstdomain "C:\squid\etc\nocache_domains.acl"
acl unauthenticatednet src "C:\squid\etc\unrestrictedaddresses.acl"
acl blocked src "C:\squid\etc\restrictedaddresses.acl"
acl inetallowgroup external win_domain_group InternetAllow
acl inetrestrictgroup external win_domain_group InternetRestricted
acl localhost src 127.0.0.1/255.255.255.255
acl localnet proxy_auth REQUIRED src 192.168.0.0/255.255.255.0


The above ACL definition has never been valid.

Perhapse you wanted:
  acl localnet src 192.168.0.0/24
  acl login proxy_auth REQUIRED

  http_access deny !localnet
  http_access deny !login

The "deny !localnet" will prevent non-LAN users from logging in. If you 
can do that great. It will prevent external machines flooding your proxy 
with malicious login load.


The "deny !login" is to do the user login quickly and reject early if 
they fail that. From your logs below I see 3x lookups being done, one 
for each group check. All of which are failing due to invalid domain 
name on the user credentials. Doing this "deny !login" will drop the 
speed loss on the failure cases by more than 60%.




acl denied_domains dstdomain "C:\squid\etc\denied_domains.acl"
acl allowed_domains dstdomain "C:\squid\etc\allowed_domains.acl"
acl allowed_addresses dst "C:\squid\etc\allowed_addresses.acl"
acl manager proto cache_object

always_direct allow nocache
http_access allow manager monitor
http_access deny localhost
http_access deny blocked
http_access allow unauthenticatednet
http_access allow allowed_domains
http_access allow allowed_addresses


NP: "allowed_addresses" requires DNS lookup. So slows every request 
down to find the requested domains DNS entries.



http_access deny inetrestrictgroup denied_domains


Swap those ACLs order to:
 denied_domains inetrestrictgroup

That will reduce the helper lookup load on the !denied_domains cases a 
bit.




http_access allow inetrestrictgroup
http_access allow inetallowgroup
http_access deny all

cache_mem 500 MB
maximum_object_size_in_memory 1 MB
cache_dir ufs c:/squid/var/cache 7000 16 512

access_log C:\squid\var\logs\access.log squid.

My cache log would seem to suggest that it's related to the ntlm
helper processes.  Eg

/mswin_check_lm_group.exe Can't find DC for local domain 'asd'


Your DC has disappeared, or some client is sending in a login domain 
which is not yours.
Nothing the helpers can do about either case but reject. It does so, 
after the horribly long lag it took to discover that problem.


I think this is the output of checking "deny inetrestrictgroup 
denied_domains".



2011/11/14 11:31:57| storeUfsCreate: Failed to create
c:/squid/var/cache/01/C2/00058467 ((13) Permission denied)
/mswin_check_lm_group.exe Can't find DC for local domain 'asd'


Login checks repeat all over again. And fail again.

I think this is the output of checking "allow inetrestrictgroup".


/mswin_check_lm_group.exe Can't find DC for local domain 'asd'


Login checks repeat all over again. And fail yet again.

I think this is the output of checking "allow inetrestrictgroup".


2011/11/14 12:15:40| clientTryParseRequest: FD 361
(192.168.0.252:2504) Invalid Request
2011/11/14 12:26:41| sslWriteClient: FD 1062: write failure: (10054)
WSAECONNRESET, Connection reset by peer..


And the client disconnects.

"sslWriteClient" seems significant. Particularly since your config has 
no https_port.


What Squid version are you using?



And the cache authentication statistics seem to sugget the same




Well the helpers report indicates it is taking up to 25 seconds to do 
*1* login request for some clients.




What this looks like to me is either your DC disappearing for a short 
while and Squid falling under the resulting failures.


Or some client flooding Squid with the invalid domain name 'asd' with 
the same effect.


Amos

[squid-users] NTLM Authentication

[John Sayce]

I have squid configured and working fine with ntlm authentication, however 
about once a week access to the throughput will slow and I can be presented 
with access denied messages.  Restarting squid instantly fixes the problem.  My 
configuration is relatively simple as bellow. I don't have a large user base. 
There's only 60 users and the problem is instantly gone upon restarting squid 
which suggests to me that it's not simply be a problem of load as the log would 
suggest.  I wondered if it was a single computer or application causing the 
issue but I'm not sure how to find out.

http_port 8080

auth_param ntlm program c:/squid/libexec/mswin_ntlm_auth.exe
auth_param ntlm children 30
external_acl_type win_domain_group children=30 ttl=120 %LOGIN 
c:/squid/libexec/mswin_check_lm_group.exe -G

acl all src 0.0.0.0/0.0.0.0
acl nocache dstdomain "C:\squid\etc\nocache_domains.acl"
acl unauthenticatednet src "C:\squid\etc\unrestrictedaddresses.acl"
acl blocked src "C:\squid\etc\restrictedaddresses.acl"
acl inetallowgroup external win_domain_group InternetAllow
acl inetrestrictgroup external win_domain_group InternetRestricted
acl localhost src 127.0.0.1/255.255.255.255
acl localnet proxy_auth REQUIRED src 192.168.0.0/255.255.255.0
acl denied_domains dstdomain "C:\squid\etc\denied_domains.acl"
acl allowed_domains dstdomain "C:\squid\etc\allowed_domains.acl"
acl allowed_addresses dst "C:\squid\etc\allowed_addresses.acl"
acl manager proto cache_object

always_direct allow nocache
http_access allow manager monitor
http_access deny localhost
http_access deny blocked
http_access allow unauthenticatednet
http_access allow allowed_domains
http_access allow allowed_addresses
http_access deny inetrestrictgroup denied_domains
http_access allow inetrestrictgroup
http_access allow inetallowgroup
http_access deny all

cache_mem 500 MB
maximum_object_size_in_memory 1 MB
cache_dir ufs c:/squid/var/cache 7000 16 512

access_log C:\squid\var\logs\access.log squid.

My cache log would seem to suggest that it's related to the ntlm helper 
processes.  Eg

/mswin_check_lm_group.exe Can't find DC for local domain 'asd'
2011/11/14 11:31:57| storeUfsCreate: Failed to create 
c:/squid/var/cache/01/C2/00058467 ((13) Permission denied)
/mswin_check_lm_group.exe Can't find DC for local domain 'asd'
/mswin_check_lm_group.exe Can't find DC for local domain 'asd'
2011/11/14 12:15:40| clientTryParseRequest: FD 361 (192.168.0.252:2504) Invalid 
Request
2011/11/14 12:26:41| sslWriteClient: FD 1062: write failure: (10054) 
WSAECONNRESET, Connection reset by peer..
2011/11/14 12:37:12| sslReadClient: FD 370: read failure: (10053) 
WSAECONNABORTED, Software caused connection abort.
2011/11/14 12:41:31| WARNING: All ntlmauthenticator processes are busy.
2011/11/14 12:41:31| WARNING: up to 34 pending requests queued
/mswin_check_lm_group.exe Can't find DC for local domain 'asd'
/mswin_check_lm_group.exe Can't find DC for local domain 'asd'
/mswin_check_lm_group.exe Can't find DC for local domain 'asd'
2011/11/14 12:45:11| WARNING: All ntlmauthenticator processes are busy.
2011/11/14 12:45:11| WARNING: up to 30 pending requests queued
2011/11/14 12:45:11| Consider increasing the number of ntlmauthenticator 
processes to at least 60 in your config file.
2011/11/14 12:45:41| WARNING: All ntlmauthenticator processes are busy.
2011/11/14 12:45:41| WARNING: up to 36 pending requests queued
2011/11/14 12:45:41| Consider increasing the number of ntlmauthenticator 
processes to at least 66 in your config file.
2011/11/14 12:46:11| WARNING: All ntlmauthenticator processes are busy.
2011/11/14 12:46:11| WARNING: up to 42 pending requests queued
2011/11/14 12:46:11| Consider increasing the number of ntlmauthenticator 
processes to at least 72 in your config file.
/mswin_check_lm_group.exe Can't find DC for local domain 'asd'
/mswin_check_lm_group.exe Can't find DC for local domain 'asd'
/mswin_check_lm_group.exe Can't find DC for local domain 'asd'
/mswin_check_lm_group.exe Can't find DC for local domain 'asd'
/mswin_check_lm_group.exe Can't find DC for local domain 'asd'
2011/11/14 12:47:06| WARNING: All ntlmauthenticator processes are busy.
2011/11/14 12:47:06| WARNING: up to 55 pending requests queued
2011/11/14 12:47:06| Consider increasing the number of ntlmauthenticator 
processes to at least 85 in your config file.
/mswin_check_lm_group.exe Can't find DC for local domain 'asd'
/mswin_check_lm_group.exe Can't find DC for local domain 'asd'
2011/11/14 12:52:25| sslReadClient: FD 1062: read failure: (10053) 
WSAECONNABORTED, Software caused connection abort.
2011/11/14 13:13:51| clientTryParseRequest: FD 907 (192.168.0.148:1812) Invalid 
Request
2011/11/14 13:13:55| clientTryParseRequest: FD 907 (192.168.0.148:1831) Invalid 
Request
2011/11/14 13:16:50| clientTryParseRequest: FD 1454 (192.168.0.148:1874) 
Invalid Request
2011/11/14 13:16:53| clientTryParseRequest: FD 1440 (192.168.0.148:1867) 
Invalid Request
2011/11/14 13:21:07| clientTryParseRequest: FD 12

[squid-users] Re : [squid-users] Re : [squid-users] NTLM auth and ContentLength = 0

[Christian Gregoire]

>The trace you have above is Squids view of things. You need to send -d 
>to the helper itself (if available) to get the helpers view of whats 
>going on inside there.

Indeed, the client seems broken. In that case, there are extra spaces appended 
after the user name : 

[2011/08/12 17:20:30, 3] libsmb/ntlmssp.c:ntlmssp_server_auth(739)
  Got user=[expinet.colissimo  ] domain=[PICHON] 
workstation=[TSE1] len1=24 len2=24
[2011/08/12 17:20:30, 3] utils/ntlm_auth.c:winbind_pw_check(515)
  Login for user [PICHON]\[expinet.colissimo  ]@[TSE1] failed 
due to [No such user]
[2011/08/12 17:20:30, 10] utils/ntlm_auth.c:manage_squid_ntlmssp_request(781)
  NTLMSSP NT_STATUS_NO_SUCH_USER

When it's OK, I get :

[2011/08/12 17:20:28, 3] libsmb/ntlmssp.c:ntlmssp_server_auth(739)
  Got user=[expinet.colissimo] domain=[PICHON] workstation=[TSE1] len1=24 
len2=24
[2011/08/12 17:20:28, 10] libsmb/ntlmssp.c:ntlmssp_server_auth(805)
  ntlmssp_server_auth: Created NTLM2 session key.
[2011/08/12 17:20:28, 3] libsmb/ntlmssp_sign.c:ntlmssp_sign_init(338)
  NTLMSSP Sign/Seal - Initialising with flags:
[2011/08/12 17:20:28, 3] libsmb/ntlmssp.c:debug_ntlmssp_flags(63)
  Got NTLMSSP neg_flags=0xa2088205
NTLMSSP_NEGOTIATE_UNICODE
NTLMSSP_REQUEST_TARGET
NTLMSSP_NEGOTIATE_NTLM
NTLMSSP_NEGOTIATE_ALWAYS_SIGN
NTLMSSP_NEGOTIATE_NTLM2
NTLMSSP_NEGOTIATE_128
NTLMSSP_NEGOTIATE_56
[2011/08/12 17:20:28, 10] utils/ntlm_auth.c:manage_squid_ntlmssp_request(784)
  NTLMSSP OK!


Thanks a lot for your help Amos !!!

Re: [squid-users] Re : [squid-users] NTLM auth and ContentLength = 0

[Amos Jeffries]

On 11/08/11 20:55, Christian Gregoire wrote:




Check cache.log for any mentions of problems. Perhapse enable debugging
with -d on the helper to see if there is an issue with the validation.



Thanks for the tip. Indeed, I've run squid with the -X flag and got a pretty
clear error for that request, while everything's fine for the others :

[...]
2011/08/10 18:22:54.040| authenticateNTLMHandleReply: helper: '0x1d3ccc08' sent
us 'AF expinet.colissimo'
2011/08/10 18:22:54.040| authenticateNTLMHandleReply: Successfully validated
user via NTLM. Username 'expinet.colissimo'
2011/08/10 18:22:54.845| authenticateNTLMHandleReply: helper: '0x1d3ccc08' sent
us 'TT
TlRMTVNTUAACDAAMADAFgomiVcvIuzNYgBwAAHYAdgA8UABJAEMASABPAE4AAgAMAFAASQBDAEgATwBOAAEAEgBGAFcALQBNAEEAUwBUAEUAUgAEABgAcABpAGMAaABvAG4ALgBsAG8AYwBhAGwAAwAsAGYAdwAtAG0AYQBzAHQAZQByAC4AcABpAGMAaABvAG4ALgBsAG8AYwBhAGwAAA=='

2011/08/10 18:22:54.845| authenticateNTLMHandleReply: Need to challenge the
client with a server blob
'TlRMTVNTUAACDAAMADAFgomiVcvIuzNYgBwAAHYAdgA8UABJAEMASABPAE4AAgAMAFAASQBDAEgATwBOAAEAEgBGAFcALQBNAEEAUwBUAEUAUgAEABgAcABpAGMAaABvAG4ALgBsAG8AYwBhAGwAAwAsAGYAdwAtAG0AYQBzAHQAZQByAC4AcABpAGMAaABvAG4ALgBsAG8AYwBhAGwAAA=='

2011/08/10 18:22:54.854| authenticateNTLMHandleReply: helper: '0x1d3ccc08' sent
us 'AF expinet.colissimo'
2011/08/10 18:22:54.855| authenticateNTLMHandleReply: Successfully validated
user via NTLM. Username 'expinet.colissimo'
2011/08/10 18:22:57.166| authenticateNTLMHandleReply: helper: '0x1d3ccc08' sent
us 'TT
TlRMTVNTUAACDAAMADAFgomiBYi9jX1PfFAAAHYAdgA8UABJAEMASABPAE4AAgAMAFAASQBDAEgATwBOAAEAEgBGAFcALQBNAEEAUwBUAEUAUgAEABgAcABpAGMAaABvAG4ALgBsAG8AYwBhAGwAAwAsAGYAdwAtAG0AYQBzAHQAZQByAC4AcABpAGMAaABvAG4ALgBsAG8AYwBhAGwAAA=='

2011/08/10 18:22:57.166| authenticateNTLMHandleReply: Need to challenge the
client with a server blob
'TlRMTVNTUAACDAAMADAFgomiBYi9jX1PfFAAAHYAdgA8UABJAEMASABPAE4AAgAMAFAASQBDAEgATwBOAAEAEgBGAFcALQBNAEEAUwBUAEUAUgAEABgAcABpAGMAaABvAG4ALgBsAG8AYwBhAGwAAwAsAGYAdwAtAG0AYQBzAHQAZQByAC4AcABpAGMAaABvAG4ALgBsAG8AYwBhAGwAAA=='

2011/08/10 18:22:57.176| authenticateNTLMHandleReply: helper: '0x1d3ccc08' sent
us 'AF expinet.colissimo'
2011/08/10 18:22:57.176| authenticateNTLMHandleReply: Successfully validated
user via NTLM. Username 'expinet.colissimo'
2011/08/10 18:22:58.629| authenticateNTLMHandleReply: helper: '0x1d3ccc08' sent
us 'TT
TlRMTVNTUAACDAAMADAFgomi/vpkDjFtgzcAAHYAdgA8UABJAEMASABPAE4AAgAMAFAASQBDAEgATwBOAAEAEgBGAFcALQBNAEEAUwBUAEUAUgAEABgAcABpAGMAaABvAG4ALgBsAG8AYwBhAGwAAwAsAGYAdwAtAG0AYQBzAHQAZQByAC4AcABpAGMAaABvAG4ALgBsAG8AYwBhAGwAAA=='

2011/08/10 18:22:58.629| authenticateNTLMHandleReply: Need to challenge the
client with a server blob
'TlRMTVNTUAACDAAMADAFgomi/vpkDjFtgzcAAHYAdgA8UABJAEMASABPAE4AAgAMAFAASQBDAEgATwBOAAEAEgBGAFcALQBNAEEAUwBUAEUAUgAEABgAcABpAGMAaABvAG4ALgBsAG8AYwBhAGwAAwAsAGYAdwAtAG0AYQBzAHQAZQByAC4AcABpAGMAaABvAG4ALgBsAG8AYwBhAGwAAA=='

2011/08/10 18:22:58.639| authenticateNTLMHandleReply: helper: '0x1d3ccc08' sent
us 'NA NT_STATUS_NO_SUCH_USER'
2011/08/10 18:22:58.639| authenticateNTLMHandleReply: Failed validating user via
NTLM. Error returned 'NT_STATUS_NO_SUCH_USER'

The challenge might be wrongly generated by the client, though it'd be weird
given the previous ones are correct. Or, if it's still related to the POST data
length being zero, just to clear things up, do you know if it's (the POST data)
used by the challenge generation algorithm?


POST data should be irrelevant. The helper is only working with an 
failing to validate the Proxy-Authenticate header contents.



The trace you have above is Squids view of things. You need to send -d 
to the helper itself (if available) to get the helpers view of whats 
going on inside there.



What application is this? there are two bugs in those headers that need
reporting. Not related to your NTLM problems though.



It's a Windows software, I don't know which client HTTP library is used.


Darn. Oh well.

Amos
--
Please be using
  Current Stable Squid 2.7.STABLE9 or 3.1.14
  Beta testers wanted for 3.2.0.10

[squid-users] Re : [squid-users] NTLM auth and ContentLength = 0

[Christian Gregoire]

>Check cache.log for any mentions of problems. Perhapse enable debugging 
>with -d on the helper to see if there is an issue with the validation.


Thanks for the tip. Indeed, I've run squid with the -X flag and got a pretty 
clear error for that request, while everything's fine for the others :

[...]
2011/08/10 18:22:54.040| authenticateNTLMHandleReply: helper: '0x1d3ccc08' sent 
us 'AF expinet.colissimo'
2011/08/10 18:22:54.040| authenticateNTLMHandleReply: Successfully validated 
user via NTLM. Username 'expinet.colissimo'
2011/08/10 18:22:54.845| authenticateNTLMHandleReply: helper: '0x1d3ccc08' sent 
us 'TT 
TlRMTVNTUAACDAAMADAFgomiVcvIuzNYgBwAAHYAdgA8UABJAEMASABPAE4AAgAMAFAASQBDAEgATwBOAAEAEgBGAFcALQBNAEEAUwBUAEUAUgAEABgAcABpAGMAaABvAG4ALgBsAG8AYwBhAGwAAwAsAGYAdwAtAG0AYQBzAHQAZQByAC4AcABpAGMAaABvAG4ALgBsAG8AYwBhAGwAAA=='

2011/08/10 18:22:54.845| authenticateNTLMHandleReply: Need to challenge the 
client with a server blob 
'TlRMTVNTUAACDAAMADAFgomiVcvIuzNYgBwAAHYAdgA8UABJAEMASABPAE4AAgAMAFAASQBDAEgATwBOAAEAEgBGAFcALQBNAEEAUwBUAEUAUgAEABgAcABpAGMAaABvAG4ALgBsAG8AYwBhAGwAAwAsAGYAdwAtAG0AYQBzAHQAZQByAC4AcABpAGMAaABvAG4ALgBsAG8AYwBhAGwAAA=='

2011/08/10 18:22:54.854| authenticateNTLMHandleReply: helper: '0x1d3ccc08' sent 
us 'AF expinet.colissimo'
2011/08/10 18:22:54.855| authenticateNTLMHandleReply: Successfully validated 
user via NTLM. Username 'expinet.colissimo'
2011/08/10 18:22:57.166| authenticateNTLMHandleReply: helper: '0x1d3ccc08' sent 
us 'TT 
TlRMTVNTUAACDAAMADAFgomiBYi9jX1PfFAAAHYAdgA8UABJAEMASABPAE4AAgAMAFAASQBDAEgATwBOAAEAEgBGAFcALQBNAEEAUwBUAEUAUgAEABgAcABpAGMAaABvAG4ALgBsAG8AYwBhAGwAAwAsAGYAdwAtAG0AYQBzAHQAZQByAC4AcABpAGMAaABvAG4ALgBsAG8AYwBhAGwAAA=='

2011/08/10 18:22:57.166| authenticateNTLMHandleReply: Need to challenge the 
client with a server blob 
'TlRMTVNTUAACDAAMADAFgomiBYi9jX1PfFAAAHYAdgA8UABJAEMASABPAE4AAgAMAFAASQBDAEgATwBOAAEAEgBGAFcALQBNAEEAUwBUAEUAUgAEABgAcABpAGMAaABvAG4ALgBsAG8AYwBhAGwAAwAsAGYAdwAtAG0AYQBzAHQAZQByAC4AcABpAGMAaABvAG4ALgBsAG8AYwBhAGwAAA=='

2011/08/10 18:22:57.176| authenticateNTLMHandleReply: helper: '0x1d3ccc08' sent 
us 'AF expinet.colissimo'
2011/08/10 18:22:57.176| authenticateNTLMHandleReply: Successfully validated 
user via NTLM. Username 'expinet.colissimo'
2011/08/10 18:22:58.629| authenticateNTLMHandleReply: helper: '0x1d3ccc08' sent 
us 'TT 
TlRMTVNTUAACDAAMADAFgomi/vpkDjFtgzcAAHYAdgA8UABJAEMASABPAE4AAgAMAFAASQBDAEgATwBOAAEAEgBGAFcALQBNAEEAUwBUAEUAUgAEABgAcABpAGMAaABvAG4ALgBsAG8AYwBhAGwAAwAsAGYAdwAtAG0AYQBzAHQAZQByAC4AcABpAGMAaABvAG4ALgBsAG8AYwBhAGwAAA=='

2011/08/10 18:22:58.629| authenticateNTLMHandleReply: Need to challenge the 
client with a server blob 
'TlRMTVNTUAACDAAMADAFgomi/vpkDjFtgzcAAHYAdgA8UABJAEMASABPAE4AAgAMAFAASQBDAEgATwBOAAEAEgBGAFcALQBNAEEAUwBUAEUAUgAEABgAcABpAGMAaABvAG4ALgBsAG8AYwBhAGwAAwAsAGYAdwAtAG0AYQBzAHQAZQByAC4AcABpAGMAaABvAG4ALgBsAG8AYwBhAGwAAA=='

2011/08/10 18:22:58.639| authenticateNTLMHandleReply: helper: '0x1d3ccc08' sent 
us 'NA NT_STATUS_NO_SUCH_USER'
2011/08/10 18:22:58.639| authenticateNTLMHandleReply: Failed validating user 
via 
NTLM. Error returned 'NT_STATUS_NO_SUCH_USER'

The challenge might be wrongly generated by the client, though it'd be weird 
given the previous ones are correct. Or, if it's still related to the POST data 
length being zero, just to clear things up, do you know if it's (the POST data) 
used by the challenge generation algorithm?
>What application is this? there are two bugs in those headers that need 
>reporting. Not related to your NTLM problems though.


It's a Windows software, I don't know which client HTTP library is used.

Re: [squid-users] NTLM auth and ContentLength = 0

[Amos Jeffries]

On 11/08/11 00:04, Christian Gregoire wrote:

Hello,

I use Squid 3.1.9 + ICAP + ClamAV with NTLM authentication on a CentOS box. It
works pretty well, except in one particular case.

Here, the HTTP client is a third-party software on Windows, not a standard
navigator, which makes a few HTTP requests when it is launched.

Most of the requests show the NTLM challenge/response steps correctly, but not
the last one which is denied by the Squid service. The only special thing I can
see is that the content length of that request is set to zero (see the traces
and the headers below).


Maybe. I recall some talk about 0-length POST a while back. But there 
have been no patches related to it submitted yet.


I also notice that the failed attempt has a much longer blob tag than 
the successful one.


Check cache.log for any mentions of problems. Perhapse enable debugging 
with -d on the helper to see if there is an issue with the validation.




Please note: if NTLM auth is disabled on the Squid server, it works fine.


1312956350.701  0 10.1.100.5 TCP_DENIED/407 3837 POST
http://www.colis-logistique.com/expeditor/updateReference/servlet - NONE/-
text/html
1312956350.702  0 10.1.100.5 TCP_DENIED/407 4219 POST
http://www.colis-logistique.com/expeditor/updateReference/servlet - NONE/-
text/html
1312956351.543841 10.1.100.5 TCP_MISS/200 721 POST
http://www.colis-logistique.com/expeditor/updateReference/servlet
expinet.colissimo DIRECT/84.37.93.36 text/xml
1312956351.559  0 10.1.100.5 TCP_DENIED/407 3837 POST
http://www.colis-logistique.com/expeditor/updateReference/servlet - NONE/-
text/html
1312956351.560  0 10.1.100.5 TCP_DENIED/407 4219 POST
http://www.colis-logistique.com/expeditor/updateReference/servlet - NONE/-
text/html
1312956352.390830 10.1.100.5 TCP_MISS/200 720 POST
http://www.colis-logistique.com/expeditor/updateReference/servlet
expinet.colissimo DIRECT/84.37.93.36 text/xml
1312956352.407  0 10.1.100.5 TCP_DENIED/407 3837 POST
http://www.colis-logistique.com/expeditor/updateReference/servlet - NONE/-
text/html
1312956352.408  0 10.1.100.5 TCP_DENIED/407 4219 POST
http://www.colis-logistique.com/expeditor/updateReference/servlet - NONE/-
text/html
1312956353.281873 10.1.100.5 TCP_MISS/200 716 POST
http://www.colis-logistique.com/expeditor/updateReference/servlet
expinet.colissimo DIRECT/84.37.93.36 text/xml
1312956353.296  0 10.1.100.5 TCP_DENIED/407 3837 POST
http://www.colis-logistique.com/expeditor/updateReference/servlet - NONE/-
text/html
1312956353.298  0 10.1.100.5 TCP_DENIED/407 4219 POST
http://www.colis-logistique.com/expeditor/updateReference/servlet - NONE/-
text/html
1312956354.165868 10.1.100.5 TCP_MISS/200 715 POST
http://www.colis-logistique.com/expeditor/updateReference/servlet
expinet.colissimo DIRECT/84.37.93.36 text/xml
1312956354.189  0 10.1.100.5 TCP_DENIED/407 3845 POST
http://www.colis-logistique.com/expeditor/updateApplication/servlet - NONE/-
text/html
1312956354.190  0 10.1.100.5 TCP_DENIED/407 4227 POST
http://www.colis-logistique.com/expeditor/updateApplication/servlet - NONE/-
text/html
1312956355.005814 10.1.100.5 TCP_MISS/200 719 POST
http://www.colis-logistique.com/expeditor/updateApplication/servlet
expinet.colissimo DIRECT/84.37.93.36 text/xml
1312956355.016  0 10.1.100.5 TCP_DENIED/407 3773 GET
http://www.colis-logistique.com/updatesite? - NONE/- text/html
1312956355.017  0 10.1.100.5 TCP_DENIED/407 4155 GET
http://www.colis-logistique.com/updatesite? - NONE/- text/html
1312956355.579561 10.1.100.5 TCP_MISS/200 765 GET
http://www.colis-logistique.com/updatesite? expinet.colissimo DIRECT/84.37.93.36
APPLICATION/OCTET-STREAM
1312956356.570430 10.1.100.5 TCP_MISS/200 4599 POST
http://www.colis-logistique.com/expeditor/updateaccount/servlet
expinet.colissimo DIRECT/84.37.93.36 text/xml
1312956357.437769 10.1.100.5 TCP_MISS/200 720 POST
http://www.colis-logistique.com/expeditor/updateReference/servlet
expinet.colissimo DIRECT/84.37.93.36 text/xml
1312956357.452  0 10.1.100.5 TCP_DENIED/407 3837 POST
http://www.colis-logistique.com/expeditor/updateReference/servlet - NONE/-
text/html
1312956357.454  0 10.1.100.5 TCP_DENIED/407 4219 POST
http://www.colis-logistique.com/expeditor/updateReference/servlet - NONE/-
text/html
1312956358.267814 10.1.100.5 TCP_MISS/200 715 POST
http://www.colis-logistique.com/expeditor/updateReference/servlet
expinet.colissimo DIRECT/84.37.93.36 text/xml
1312956359.448  0 10.1.100.5 TCP_DENIED/407 3835 POST
http://www.colis-logistique.com/expeditor/updateReference/servlet - NONE/-
text/html< STEP 1
1312956359.449  0 10.1.100.5 TCP_DENIED/407 4217 POST
http://www.colis-logistique.com/expeditor/updateReference/servlet - NONE/-
text/html< STEP 2
1312956359.451  0 10.1.100.5 TCP_DENIED/407 4193 POST
http://www.colis-logistique.com/expeditor/updateReference/servlet - NONE/-
text/html< STILL DENIED !!

--- Headers of the 

[squid-users] NTLM auth and ContentLength = 0

[Christian Gregoire]

Hello,

I use Squid 3.1.9 + ICAP + ClamAV with NTLM authentication on a CentOS box. It 
works pretty well, except in one particular case. 

Here, the HTTP client is a third-party software on Windows, not a standard 
navigator, which makes a few HTTP requests when it is launched. 

Most of the requests show the NTLM challenge/response steps correctly, but not 
the last one which is denied by the Squid service. The only special thing I can 
see is that the content length of that request is set to zero (see the traces 
and the headers below).

Please note: if NTLM auth is disabled on the Squid server, it works fine. 


1312956350.701  0 10.1.100.5 TCP_DENIED/407 3837 POST 
http://www.colis-logistique.com/expeditor/updateReference/servlet - NONE/- 
text/html
1312956350.702  0 10.1.100.5 TCP_DENIED/407 4219 POST 
http://www.colis-logistique.com/expeditor/updateReference/servlet - NONE/- 
text/html
1312956351.543841 10.1.100.5 TCP_MISS/200 721 POST 
http://www.colis-logistique.com/expeditor/updateReference/servlet 
expinet.colissimo DIRECT/84.37.93.36 text/xml
1312956351.559  0 10.1.100.5 TCP_DENIED/407 3837 POST 
http://www.colis-logistique.com/expeditor/updateReference/servlet - NONE/- 
text/html
1312956351.560  0 10.1.100.5 TCP_DENIED/407 4219 POST 
http://www.colis-logistique.com/expeditor/updateReference/servlet - NONE/- 
text/html
1312956352.390830 10.1.100.5 TCP_MISS/200 720 POST 
http://www.colis-logistique.com/expeditor/updateReference/servlet 
expinet.colissimo DIRECT/84.37.93.36 text/xml
1312956352.407  0 10.1.100.5 TCP_DENIED/407 3837 POST 
http://www.colis-logistique.com/expeditor/updateReference/servlet - NONE/- 
text/html
1312956352.408  0 10.1.100.5 TCP_DENIED/407 4219 POST 
http://www.colis-logistique.com/expeditor/updateReference/servlet - NONE/- 
text/html
1312956353.281873 10.1.100.5 TCP_MISS/200 716 POST 
http://www.colis-logistique.com/expeditor/updateReference/servlet 
expinet.colissimo DIRECT/84.37.93.36 text/xml
1312956353.296  0 10.1.100.5 TCP_DENIED/407 3837 POST 
http://www.colis-logistique.com/expeditor/updateReference/servlet - NONE/- 
text/html
1312956353.298  0 10.1.100.5 TCP_DENIED/407 4219 POST 
http://www.colis-logistique.com/expeditor/updateReference/servlet - NONE/- 
text/html
1312956354.165868 10.1.100.5 TCP_MISS/200 715 POST 
http://www.colis-logistique.com/expeditor/updateReference/servlet 
expinet.colissimo DIRECT/84.37.93.36 text/xml
1312956354.189  0 10.1.100.5 TCP_DENIED/407 3845 POST 
http://www.colis-logistique.com/expeditor/updateApplication/servlet - NONE/- 
text/html
1312956354.190  0 10.1.100.5 TCP_DENIED/407 4227 POST 
http://www.colis-logistique.com/expeditor/updateApplication/servlet - NONE/- 
text/html
1312956355.005814 10.1.100.5 TCP_MISS/200 719 POST 
http://www.colis-logistique.com/expeditor/updateApplication/servlet 
expinet.colissimo DIRECT/84.37.93.36 text/xml
1312956355.016  0 10.1.100.5 TCP_DENIED/407 3773 GET 
http://www.colis-logistique.com/updatesite? - NONE/- text/html
1312956355.017  0 10.1.100.5 TCP_DENIED/407 4155 GET 
http://www.colis-logistique.com/updatesite? - NONE/- text/html
1312956355.579561 10.1.100.5 TCP_MISS/200 765 GET 
http://www.colis-logistique.com/updatesite? expinet.colissimo 
DIRECT/84.37.93.36 
APPLICATION/OCTET-STREAM
1312956356.570430 10.1.100.5 TCP_MISS/200 4599 POST 
http://www.colis-logistique.com/expeditor/updateaccount/servlet 
expinet.colissimo DIRECT/84.37.93.36 text/xml
1312956357.437769 10.1.100.5 TCP_MISS/200 720 POST 
http://www.colis-logistique.com/expeditor/updateReference/servlet 
expinet.colissimo DIRECT/84.37.93.36 text/xml
1312956357.452  0 10.1.100.5 TCP_DENIED/407 3837 POST 
http://www.colis-logistique.com/expeditor/updateReference/servlet - NONE/- 
text/html
1312956357.454  0 10.1.100.5 TCP_DENIED/407 4219 POST 
http://www.colis-logistique.com/expeditor/updateReference/servlet - NONE/- 
text/html
1312956358.267814 10.1.100.5 TCP_MISS/200 715 POST 
http://www.colis-logistique.com/expeditor/updateReference/servlet 
expinet.colissimo DIRECT/84.37.93.36 text/xml
1312956359.448  0 10.1.100.5 TCP_DENIED/407 3835 POST 
http://www.colis-logistique.com/expeditor/updateReference/servlet - NONE/- 
text/html < STEP 1
1312956359.449  0 10.1.100.5 TCP_DENIED/407 4217 POST 
http://www.colis-logistique.com/expeditor/updateReference/servlet - NONE/- 
text/html < STEP 2
1312956359.451  0 10.1.100.5 TCP_DENIED/407 4193 POST 
http://www.colis-logistique.com/expeditor/updateReference/servlet - NONE/- 
text/html < STILL DENIED !!

--- Headers of the HTTP session for the denied request  :

POST http://www.colis-logistique.com/expeditor/updateReference/servlet HTTP/1.1
Content-Type: application/x-www-form-urlencoded
User-Agent: TELINTRANSCOM
Host: www.colis-logistique.com
Content-Length: 0
Pragma: no-cache

HTTP/1.0 407 Proxy Authentication Required
Server: squid/3.1.9
Mime-Version: 1.0
Date: We

Re: [squid-users] NTLM-auth with computers that are not in the domain

[E.S. Rosenberg]

2011/6/28 Amos Jeffries 
>
> On 28/06/11 23:23, E.S. Rosenberg wrote:
>>
>> Hi,
>> We recently switched to an NTLM based setup and tehre is one quite
>> annoying fluke for users that are not in the domain, when they open
>> their browser they get multiple auth requests.
>
> Well. Yes. That is how NTLM is supposed to provide security better than 
> Digest. Users who don't have credentials checked by the DC can't authenticate.
>
> Or are you using the words "in the domain" in a different meaning to what 
> NTLM uses for in and out of domain? (registered with the DC "in" and not 
> registered "out" / general public machines)
I mean linux stations that authenticate against LDAP, or windows
stations that for whatever reason have local accounts instead of
domain accounts.
Regards,
Eli
>
>>
>> This is probably because the browser issues multiple requests and
>> therefor gets multiple 407s back from squid, is there any way to avoid
>> this? To make sure that the user only needs to type his/her password
>> once (if they don't make a mistake)?
>
> maybe yes, maybe no. Depends on your version of Squid. We have had people do 
> a lot of deep analysis of NTLM behaviour and fix many problems thoughout the 
> 3.1 series. Some were only fixable in 3.2 betas due to the nature of changes.
>
> The big thing to be aware of is that persistent connections is not optional. 
> They are REQUIRED.
>
> Also depends on the users system. The browser is what makes the choice to (a) 
> open that many connections at once, and (b) do the popup. NTLM credentials 
> are Single-Signon, supposedly provided to the browser by the operating 
> system. The user should not actually ever see even one popup from the 
> browser. The popup is an effort of last resort for browsers.
>
>
>>
>> For a user like me that when opening the browser is restoring tens if
>> not hunders of tabs the amount of auth requests can be quite
>> frustrating.
>
> The browser cant find your credentials from your machine login, OR the proxy 
> cannot verify them once they are handed over.
>
>>
>> A different question:
>> I shortened the shutdown_lifetime to 5 seconds (from the default 30
>> seconds) so that downtime when I change a setting that requires a
>> restart instead of a reload is shorter, is there any reason to not
>> shorten this (possibly even to 1 or 0?)?
>
> shutdown_lifetime is the amount of time Squid is allowed to spend on a full 
> save of the cache index and finishing clients requests. The smaller it is the 
> more clients see failures and the longer startup times Squid may have while 
> rebuilding a broken index from scratch before it can start operating at full 
> speed.
>
>> I can live with a download having to be done again but half the campus
>> not browsing is much less ideal...
>>
>> Thanks and regards,
>> Eli
>
> Amos
> --
> Please be using
>  Current Stable Squid 2.7.STABLE9 or 3.1.12
>  Beta testers wanted for 3.2.0.9 and 3.1.12.3

Re: [squid-users] NTLM-auth with computers that are not in the domain

[Amos Jeffries]

On 28/06/11 23:23, E.S. Rosenberg wrote:

Hi,
We recently switched to an NTLM based setup and tehre is one quite
annoying fluke for users that are not in the domain, when they open
their browser they get multiple auth requests.


Well. Yes. That is how NTLM is supposed to provide security better than 
Digest. Users who don't have credentials checked by the DC can't 
authenticate.


Or are you using the words "in the domain" in a different meaning to 
what NTLM uses for in and out of domain? (registered with the DC "in" 
and not registered "out" / general public machines)




This is probably because the browser issues multiple requests and
therefor gets multiple 407s back from squid, is there any way to avoid
this? To make sure that the user only needs to type his/her password
once (if they don't make a mistake)?


maybe yes, maybe no. Depends on your version of Squid. We have had 
people do a lot of deep analysis of NTLM behaviour and fix many problems 
thoughout the 3.1 series. Some were only fixable in 3.2 betas due to the 
nature of changes.


The big thing to be aware of is that persistent connections is not 
optional. They are REQUIRED.


Also depends on the users system. The browser is what makes the choice 
to (a) open that many connections at once, and (b) do the popup. NTLM 
credentials are Single-Signon, supposedly provided to the browser by the 
operating system. The user should not actually ever see even one popup 
from the browser. The popup is an effort of last resort for browsers.





For a user like me that when opening the browser is restoring tens if
not hunders of tabs the amount of auth requests can be quite
frustrating.


The browser cant find your credentials from your machine login, OR the 
proxy cannot verify them once they are handed over.




A different question:
I shortened the shutdown_lifetime to 5 seconds (from the default 30
seconds) so that downtime when I change a setting that requires a
restart instead of a reload is shorter, is there any reason to not
shorten this (possibly even to 1 or 0?)?


shutdown_lifetime is the amount of time Squid is allowed to spend on a 
full save of the cache index and finishing clients requests. The smaller 
it is the more clients see failures and the longer startup times Squid 
may have while rebuilding a broken index from scratch before it can 
start operating at full speed.



I can live with a download having to be done again but half the campus
not browsing is much less ideal...

Thanks and regards,
Eli


Amos
--
Please be using
  Current Stable Squid 2.7.STABLE9 or 3.1.12
  Beta testers wanted for 3.2.0.9 and 3.1.12.3

[squid-users] NTLM-auth with computers that are not in the domain

[E.S. Rosenberg]

Hi,
We recently switched to an NTLM based setup and tehre is one quite
annoying fluke for users that are not in the domain, when they open
their browser they get multiple auth requests.

This is probably because the browser issues multiple requests and
therefor gets multiple 407s back from squid, is there any way to avoid
this? To make sure that the user only needs to type his/her password
once (if they don't make a mistake)?

For a user like me that when opening the browser is restoring tens if
not hunders of tabs the amount of auth requests can be quite
frustrating.

A different question:
I shortened the shutdown_lifetime to 5 seconds (from the default 30
seconds) so that downtime when I change a setting that requires a
restart instead of a reload is shorter, is there any reason to not
shorten this (possibly even to 1 or 0?)?
I can live with a download having to be done again but half the campus
not browsing is much less ideal...

Thanks and regards,
Eli

AW: [squid-users] NTLM/Kerberos Authentication with Windows 7

[Henickl Wolfgang]

Thanks for the reply!

The major problem is, that the changes in Security Policy of Windows 7 hasn't 
changed a thing. But I will try it again, therefore my question. I am also 
unsure, because in Windows 7 a new WinHTTP Version is included, which may also 
cause problems.

Is there anything, which should be considered, configuring/activating NTLM and 
Kerberos at the same time in Squid?

Kind regards
Wolfgang 

-Ursprüngliche Nachricht-
Von: Amos Jeffries [mailto:squ...@treenet.co.nz] 
Gesendet: Donnerstag, 03. März 2011 03:56
An: squid-users@squid-cache.org
Betreff: Re: [squid-users] NTLM/Kerberos Authentication with Windows 7


 On Wed, 2 Mar 2011 13:58:04 +0100, Henickl Wolfgang wrote:
> Hello,
> I am looking for a solution of strange Problem. It seems that WinHTTP
> Programs under Windows 7 tend to use Kerberos Authentication, instead 
> of
> NTLM. The problem is, that I am working behind a Squid Proxy that is
> only configured for NTLM.
>
> Do somebody know which settings I should modify?
> Is there a setting required for "Network security: LAN Manager
> authentication level" under Windows 7?
> Are there known problems with such a configuration or any FAQs for
> troubleshooting such environments?

 Sounds like you have found the problem already. The solution is to 
 either disable the Kerberos security on Windows 7 (rendering the network 
 back down to NTLM / NT 4.0 LanManager security levels) or upgrade your 
 squid to accept Kerberos.

 The squid wiki has config tutorilas on Kerberos for Squid. It's usually 
 not too painful add in parallel with NTLM.

 Amos

Re: [squid-users] NTLM/Kerberos Authentication with Windows 7

[Amos Jeffries]

On Wed, 2 Mar 2011 13:58:04 +0100, Henickl Wolfgang wrote:

Hello,
I am looking for a solution of strange Problem. It seems that WinHTTP
Programs under Windows 7 tend to use Kerberos Authentication, instead 
of

NTLM. The problem is, that I am working behind a Squid Proxy that is
only configured for NTLM.

Do somebody know which settings I should modify?
Is there a setting required for "Network security: LAN Manager
authentication level" under Windows 7?
Are there known problems with such a configuration or any FAQs for
troubleshooting such environments?


Sounds like you have found the problem already. The solution is to 
either disable the Kerberos security on Windows 7 (rendering the network 
back down to NTLM / NT 4.0 LanManager security levels) or upgrade your 
squid to accept Kerberos.


The squid wiki has config tutorilas on Kerberos for Squid. It's usually 
not too painful add in parallel with NTLM.


Amos

[squid-users] NTLM/Kerberos Authentication with Windows 7

[Henickl Wolfgang]

Hello,
I am looking for a solution of strange Problem. It seems that WinHTTP
Programs under Windows 7 tend to use Kerberos Authentication, instead of
NTLM. The problem is, that I am working behind a Squid Proxy that is
only configured for NTLM.

Do somebody know which settings I should modify?
Is there a setting required for "Network security: LAN Manager
authentication level" under Windows 7?
Are there known problems with such a configuration or any FAQs for
troubleshooting such environments?

Kind regards
Wolfgang 

Re: [squid-users] NTLM Auth problem

[Amos Jeffries]

On Thu, 24 Feb 2011 00:59:58 +, Julian Pilfold-Bagwell wrote:

Hi All,

I have a problem with NTLM authentication on squid-2.6.STABLE21-6.el5
on CentOS 5.5.

If I run /usr/bin/ntml_auth --username=jpb --domain=BGS, it returns
success.  Samba (v3.5.6) file sharing works as does winbind's wbinfo
-, wbinfo -g, wbinfo -t so I'm fairly sure that both Samba and 
winbind

are functioning OK.

If I go to a client and try to visit a website, I get the pop up
credentials box but entering the same credentials as on the ntlm_auth
line above generates the following with the virtual XP being a VM and
the jpb-workstation being a Linux box:

[2011/02/23 22:49:05.671790,  3] 
libsmb/ntlmssp.c:65(debug_ntlmssp_flags)

  Got NTLMSSP neg_flags=0xa2088207
[2011/02/23 22:49:05.674159,  3] 
libsmb/ntlmssp.c:747(ntlmssp_server_auth)
  Got user=[bgs0001] domain=[BGS] workstation=[VIRTUAL-XP] len1=24 
len2=24
[2011/02/23 22:49:05.675008,  3] 
utils/ntlm_auth.c:598(winbind_pw_check)
  Login for user [BGS]\[bgs0001]@[VIRTUAL-XP] failed due to [Invalid 
handle]



[2011/02/23 23:03:24.838232,  3] 
libsmb/ntlmssp.c:65(debug_ntlmssp_flags)

  Got NTLMSSP neg_flags=0x00088207
[2011/02/23 23:03:24.845152,  3] 
libsmb/ntlmssp.c:747(ntlmssp_server_auth)

  Got user=[jpb] domain=[] workstation=[jpb-desktop] len1=24 len2=24
[2011/02/23 23:03:24.845972,  3] 
utils/ntlm_auth.c:598(winbind_pw_check)
  Login for user []\[jpb]@[jpb-desktop] failed due to [Invalid 
handle]
[2011/02/23 23:03:40.780692,  3] 
libsmb/ntlmssp.c:65(debug_ntlmssp_flags)

  Got NTLMSSP neg_flags=0x00088207
[2011/02/23 23:03:40.782125,  3] 
libsmb/ntlmssp.c:747(ntlmssp_server_auth)
  Got user=[jpb] domain=[bgs] workstation=[jpb-desktop] len1=24 
len2=24
[2011/02/23 23:03:40.782938,  3] 
utils/ntlm_auth.c:598(winbind_pw_check)
  Login for user [bgs]\[jpb]@[jpb-desktop] failed due to [Invalid 
handle]
[2011/02/23 23:05:13.260874,  3] 
libsmb/ntlmssp.c:65(debug_ntlmssp_flags)

  Got NTLMSSP neg_flags=0x00088207
[2011/02/23 23:05:13.262425,  3] 
libsmb/ntlmssp.c:747(ntlmssp_server_auth)

  Got user=[jpb] domain=[] workstation=[jpb-desktop] len1=24 len2=24
[2011/02/23 23:05:13.263254,  3] 
utils/ntlm_auth.c:598(winbind_pw_check)
  Login for user []\[jpb]@[jpb-desktop] failed due to [Invalid 
handle]



Given that using the ntlm_auth command directly succeeds, I'm unsure
as to whether this a problem with Samba, Squid or the interaction
between the two.  I've set the permissions on the winbind privileged
pipe to 750, created a group called winbindd_priv and added the squid
user to that group. There are no messages relating to being unable to
read from the pipe.

There are other people that have had the same problem but nothing
I've looked at has solved it yet.  Has anyone else been here?


Ensure that you are using the helper provided by Samba. The one with 
same name provided by Squid is rather broken in modern networks.


If the problem persists it is likely between the client and Samba. 
Though squid can still affect this if connection persistence is failing 
the message then would be about expected token types.


Amos

[squid-users] NTLM Auth problem

[Julian Pilfold-Bagwell]

Hi All,

I have a problem with NTLM authentication on squid-2.6.STABLE21-6.el5 on 
CentOS 5.5.


If I run /usr/bin/ntml_auth --username=jpb --domain=BGS, it returns 
success.  Samba (v3.5.6) file sharing works as does winbind's wbinfo -, 
wbinfo -g, wbinfo -t so I'm fairly sure that both Samba and winbind are 
functioning OK.


If I go to a client and try to visit a website, I get the pop up 
credentials box but entering the same credentials as on the ntlm_auth 
line above generates the following with the virtual XP being a VM and 
the jpb-workstation being a Linux box:


[2011/02/23 22:49:05.671790,  3] libsmb/ntlmssp.c:65(debug_ntlmssp_flags)
  Got NTLMSSP neg_flags=0xa2088207
[2011/02/23 22:49:05.674159,  3] libsmb/ntlmssp.c:747(ntlmssp_server_auth)
  Got user=[bgs0001] domain=[BGS] workstation=[VIRTUAL-XP] len1=24 len2=24
[2011/02/23 22:49:05.675008,  3] utils/ntlm_auth.c:598(winbind_pw_check)
  Login for user [BGS]\[bgs0001]@[VIRTUAL-XP] failed due to [Invalid 
handle]



[2011/02/23 23:03:24.838232,  3] libsmb/ntlmssp.c:65(debug_ntlmssp_flags)
  Got NTLMSSP neg_flags=0x00088207
[2011/02/23 23:03:24.845152,  3] libsmb/ntlmssp.c:747(ntlmssp_server_auth)
  Got user=[jpb] domain=[] workstation=[jpb-desktop] len1=24 len2=24
[2011/02/23 23:03:24.845972,  3] utils/ntlm_auth.c:598(winbind_pw_check)
  Login for user []\[jpb]@[jpb-desktop] failed due to [Invalid handle]
[2011/02/23 23:03:40.780692,  3] libsmb/ntlmssp.c:65(debug_ntlmssp_flags)
  Got NTLMSSP neg_flags=0x00088207
[2011/02/23 23:03:40.782125,  3] libsmb/ntlmssp.c:747(ntlmssp_server_auth)
  Got user=[jpb] domain=[bgs] workstation=[jpb-desktop] len1=24 len2=24
[2011/02/23 23:03:40.782938,  3] utils/ntlm_auth.c:598(winbind_pw_check)
  Login for user [bgs]\[jpb]@[jpb-desktop] failed due to [Invalid handle]
[2011/02/23 23:05:13.260874,  3] libsmb/ntlmssp.c:65(debug_ntlmssp_flags)
  Got NTLMSSP neg_flags=0x00088207
[2011/02/23 23:05:13.262425,  3] libsmb/ntlmssp.c:747(ntlmssp_server_auth)
  Got user=[jpb] domain=[] workstation=[jpb-desktop] len1=24 len2=24
[2011/02/23 23:05:13.263254,  3] utils/ntlm_auth.c:598(winbind_pw_check)
  Login for user []\[jpb]@[jpb-desktop] failed due to [Invalid handle]


Given that using the ntlm_auth command directly succeeds, I'm unsure as 
to whether this a problem with Samba, Squid or the interaction between 
the two.  I've set the permissions on the winbind privileged pipe to 
750, created a group called winbindd_priv and added the squid user to 
that group. There are no messages relating to being unable to read from 
the pipe.


There are other people that have had the same problem but nothing I've 
looked at has solved it yet.  Has anyone else been here?


Thanks.

Julian