Re: [squid-users] Certain applications when using NTLM auth
On Mon, 2009-02-02 at 13:48 -0200, Henrique Machado wrote: > Morning, > > For quite some time I´ve wondered about something. > Certain applications worked perfectly with Squid in the past. > But, since we´ve integrated it with Active Directory (NTLM auth) some > applications just don´t work anymore, even if they do have > "authenticated proxy support". > What I´ve noticed about NTLM authentication with Squid is: > > 1) Application sends HTTP request (Firefox or IE, for instance) > 2) Squid receives the request and then returns HTTP code 407 to the > client (Proxy Authentication Required) > 3) The application receives the 407 code and asks the user for > authentication input (the browsers use the current logged user > credentials if inside an Active Directory domain) > 4) The application sends the authentication info > 5) Squid receives it, checks it and then does its work > > But, some applications, APT being a very simple example (and one of my > headaches) can´t ask for an input. And even configuring it to send > user´s credentials doesn´t seen to work (Squid keeps replying with > 407). Apt does not support NTLM; you need to configure 'basic' authentication as well as NTLM in squid. Cheers, Rob signature.asc Description: This is a digitally signed message part
RE: [squid-users] Certain applications when using NTLM auth
I think my original reply went only to Henrique -- > -Original Message- > From: Henrique Machado [mailto:henrique.cic...@gmail.com] > Sent: Wednesday, 04 February, 2009 07:19 > To: James Zuelow > Cc: squid-users@squid-cache.org > Subject: Re: [squid-users] Certain applications when using NTLM auth > > Okay. That worked. That really worked. APT is working perfectly. > Log´s show my user accessing and downloading. > I didn´t remove my ntlm lines, just added those u suggested. > > Now, why? I didn´t understand. > It is something that I should have remembered at the very beginning. When a browser does NTLM authentication, you'll always get one or two 407 replies before a success. That is because they're using ntlmssp negotiation. But anything that uses basic authentication (like apt) just provides the username and password right away instead of negotiating. If you look at the access log after you made the change, you'll see that apt is not generating any 407 lines at all, even though your web browser clients still are. When the basic lines were missing, squid could only authenticate using ntlmssp. Now it can do both. James
RE: [squid-users] Certain applications when using NTLM auth
> -Original Message- > From: Henrique Machado [mailto:henrique.cic...@gmail.com] > Sent: Wednesday, 04 February, 2009 07:19 > To: James Zuelow > Cc: squid-users@squid-cache.org > Subject: Re: [squid-users] Certain applications when using NTLM auth > > Okay. That worked. That really worked. APT is working perfectly. > Log´s show my user accessing and downloading. > I didn´t remove my ntlm lines, just added those u suggested. > > Now, why? I didn´t understand. > It is something that I should have remembered at the very beginning. When a browser does NTLM authentication, you'll always get one or two 407 replies before a success. That is because they're using ntlmssp negotiation. But anything that uses basic authentication (like apt) just provides the username and password right away instead of negotiating. If you look at the access log after you made the change, you'll see that apt is not generating any 407 lines at all, even though your web browser clients still are. When the basic lines were missing, squid could only authenticate using ntlmssp. Now it can do both. James
Re: [squid-users] Certain applications when using NTLM auth
Okay. That worked. That really worked. APT is working perfectly. Log´s show my user accessing and downloading. I didn´t remove my ntlm lines, just added those u suggested. Now, why? I didn´t understand. 2009/2/3 James Zuelow : > > >> -Original Message- >> From: Henrique Machado [mailto:henrique.cic...@gmail.com] >> Sent: Tuesday, 03 February, 2009 10:26 >> >> auth_param ntlm program /usr/local/samba/bin/ntlm_auth >> --helper-protocol=squid-2.5-ntlmssp >> auth_param ntlm children 30 >> > Henrique -- > > Try adding 10 basic children: > > auth_param basic program /usr/local/samba/bin/ntlm_auth > --helper-protocol=squid-2.5-basic > auth_param basic children 10 > > Then see if apt is successful. > > James ZuelowCBJ MIS (907)586-0236 > Network Specialist...Registered Linux User No. 186591 >
RE: [squid-users] Certain applications when using NTLM auth
> -Original Message- > From: Henrique Machado [mailto:henrique.cic...@gmail.com] > Sent: Tuesday, 03 February, 2009 10:26 > > auth_param ntlm program /usr/local/samba/bin/ntlm_auth > --helper-protocol=squid-2.5-ntlmssp > auth_param ntlm children 30 > Henrique -- Try adding 10 basic children: auth_param basic program /usr/local/samba/bin/ntlm_auth --helper-protocol=squid-2.5-basic auth_param basic children 10 Then see if apt is successful. James ZuelowCBJ MIS (907)586-0236 Network Specialist...Registered Linux User No. 186591
RE: [squid-users] Certain applications when using NTLM auth
> -Original Message- > From: Henrique Machado [mailto:henrique.cic...@gmail.com] > Sent: Tuesday, 03 February, 2009 10:26 > > 1233662651.716 0 192.168.1.74 TCP_DENIED/407 2451 GET > http://security.debian.org/dists/etch/updates/main/source/Sour > ces.diff/Index > - NONE/- text/html > 1233662651.761 0 192.168.1.74 TCP_DENIED/407 2463 GET > http://security.debian.org/dists/etch/updates/contrib/source/S > ources.diff/Index > - NONE/- text/html > > As you can see, only 407 answers. > Do you see how there is a dash between "Index" and "NONE"? That is where the username would be. So the apt process is not passing a username to squid. (Which explains why it can't authenticate!) It isn't a typo in the password. If I change the password in my /etc/apt/apt.conf, I get 407 denied errors, but the username is still logged. It is as if your apt installation is not reading the /etc/apt/apt.conf file. > Here's my apt.conf: > > Acquire::http::Proxy "http://me:123456@:3128/"; > > And that's it. I've got no clues at all. This looks correct. As long as the path and permissions are correct, apt should be reading it. Anyway, I think you are having a problem with apt, not with squid. Please reply off list and we'll see if we can't work it out. If it turns out to be squid after all we can post the solution back to this list. Cheers, James
Re: [squid-users] Certain applications when using NTLM auth
Sure, I was going to do that at my previous mail, but didn't had access to the Squid box that time. And by the way: Yes, you got it just right. That's exactly what's happening. Here's what I've got: auth_param ntlm program /usr/local/samba/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp auth_param ntlm children 30 acl autentica proxy_auth REQUIRED acl forbidden url_regex "path_for_list" acl whitelist dstdomain "path_for_domain_whitelist" (those are the main ACL's) http_access allow autentica whitelist http_access allow autentica !forbidden Explaining: Basically I have a list of forbidden terms (full of ugly names and some others) and a domain whitelists (for fake positives). I allow complete access to the domains in the whitelist and allow access to all URL's which don't match any term in the forbidden list. Here's some basic access.log output: 1233688830.613 0 192.168.1.149 TCP_DENIED/407 3189 GET http://www.osram.com.br/_resources/img/misc/iTop.gif - NONE/- text/html 1233688830.617 2 192.168.1.149 TCP_IMS_HIT/304 256 GET http://www.osram.com.br/_resources/img/misc/iTop.gif NONE/- image/gif First a HTTP 407, followed by the same requisition, this time authenticated. And now here's some APT access.log output: 1233662651.716 0 192.168.1.74 TCP_DENIED/407 2451 GET http://security.debian.org/dists/etch/updates/main/source/Sources.diff/Index - NONE/- text/html 1233662651.761 0 192.168.1.74 TCP_DENIED/407 2463 GET http://security.debian.org/dists/etch/updates/contrib/source/Sources.diff/Index - NONE/- text/html 1233662651.767 0 192.168.1.74 TCP_DENIED/407 2513 GET http://security.debian.org/dists/etch/updates/main/binary-i386/Packages.gz - NONE/- text/html 1233662651.773 0 192.168.1.74 TCP_DENIED/407 2525 GET http://security.debian.org/dists/etch/updates/contrib/binary-i386/Packages.gz - NONE/- text/html 1233662651.804 0 192.168.1.74 TCP_DENIED/407 2489 GET http://security.debian.org/dists/etch/updates/main/source/Sources.gz - NONE/- text/html 1233662651.808 0 192.168.1.74 TCP_DENIED/407 2501 GET http://security.debian.org/dists/etch/updates/contrib/source/Sources.gz - NONE/- text/html As you can see, only 407 answers. Here's my apt.conf: Acquire::http::Proxy "http://me:123456@:3128/"; And that's it. I've got no clues at all. Thanks again for the attention. Henrique 2009/2/3 James Zuelow : > >> -Original Message- >> From: Henrique Machado [mailto:henrique.cic...@gmail.com] >> Sent: Tuesday, 03 February, 2009 03:10 >> To: James Zuelow >> Cc: squid-users@squid-cache.org >> Subject: Re: [squid-users] Certain applications when using NTLM auth >> >> Dear James, >> >> Thanks for the attention. Yes, I´m talking about Debian APT Tool =]. >> And I´ve already configured apt.conf so to use the proxy, adding >> username and password in it, but even so it´s not working, and my >> proxy keeps returning HTTP 407. >> Tried creating a user "me" with password "123456" inside my AD domain, >> and it´s not working as well. >> Maybe something in my Squid auth configuration, but I´m not sure. >> > > Hmm. So if I understand what's going on correctly -- a normal user can > authenticate through the proxy, either automatically with IE or Firefox on a > Windows box, or else by providing a username/password for something like > Firefox on a Linux box. Correct? If so, then the apt.conf entry should be > working. > > It is easy to get strange results if the access rules are out of order. > > Can you sanitize your rules and post them? And the apt.conf file as well? >
RE: [squid-users] Certain applications when using NTLM auth
> -Original Message- > From: Henrique Machado [mailto:henrique.cic...@gmail.com] > Sent: Tuesday, 03 February, 2009 03:10 > To: James Zuelow > Cc: squid-users@squid-cache.org > Subject: Re: [squid-users] Certain applications when using NTLM auth > > Dear James, > > Thanks for the attention. Yes, I´m talking about Debian APT Tool =]. > And I´ve already configured apt.conf so to use the proxy, adding > username and password in it, but even so it´s not working, and my > proxy keeps returning HTTP 407. > Tried creating a user "me" with password "123456" inside my AD domain, > and it´s not working as well. > Maybe something in my Squid auth configuration, but I´m not sure. > Hmm. So if I understand what's going on correctly -- a normal user can authenticate through the proxy, either automatically with IE or Firefox on a Windows box, or else by providing a username/password for something like Firefox on a Linux box. Correct? If so, then the apt.conf entry should be working. It is easy to get strange results if the access rules are out of order. Can you sanitize your rules and post them? And the apt.conf file as well?
Re: [squid-users] Certain applications when using NTLM auth
Dear James, Thanks for the attention. Yes, I´m talking about Debian APT Tool =]. And I´ve already configured apt.conf so to use the proxy, adding username and password in it, but even so it´s not working, and my proxy keeps returning HTTP 407. Tried creating a user "me" with password "123456" inside my AD domain, and it´s not working as well. Maybe something in my Squid auth configuration, but I´m not sure. 2009/2/2 James Zuelow : > >> -Original Message- >> From: Henrique Machado [mailto:henrique.cic...@gmail.com] >> Sent: Monday, 02 February, 2009 06:49 >> To: squid-users@squid-cache.org >> Subject: [squid-users] Certain applications when using NTLM auth > >> But, some applications, APT being a very simple example (and one of my >> headaches) can´t ask for an input. And even configuring it to send >> user´s credentials doesn´t seen to work (Squid keeps replying with >> 407). > > You will always get 407 replies with NTLM authentication. It is just how the > protocol is designed. > >> I presume that the behavior "wait until I ask for auth credentials" is >> necessary for the complete functionality, so Squid just ignores the >> info that´s initially sent. > > Apt as in the Debian apt tool? I have a variety of Debian boxes (used to be > Sarge, now Etch and Lenny) that authenticate to squid via NTLM, and this > "just works" for me: > > Set up an /etc/apt/apt.conf file like this: > > Acquire::http::Proxy "http://username:passw...@10.11.12.13:3128/";; > > Where username and password are for a service account you create in active > directory. You can use a human's account, but the password will be in > plaintext with the apt.conf file, so I don't suggest it. Easier to create a > service account and then just tightly lock it down in AD. (All you need is > that the squid proxy can authenticate to it.) > > And of course 10.11.12.13:3128 is whatever IP address/port your Squid lives > on. > > If you've already done this and it doesn't work, maybe there's a typo. I've > used apt with NTLM for years and it has been rock solid. > > And of course if it is another apt you're talking about, none of this > applies. :) > > James >
RE: [squid-users] Certain applications when using NTLM auth
> -Original Message- > From: Henrique Machado [mailto:henrique.cic...@gmail.com] > Sent: Monday, 02 February, 2009 06:49 > To: squid-users@squid-cache.org > Subject: [squid-users] Certain applications when using NTLM auth > But, some applications, APT being a very simple example (and one of my > headaches) can´t ask for an input. And even configuring it to send > user´s credentials doesn´t seen to work (Squid keeps replying with > 407). You will always get 407 replies with NTLM authentication. It is just how the protocol is designed. > I presume that the behavior "wait until I ask for auth credentials" is > necessary for the complete functionality, so Squid just ignores the > info that´s initially sent. Apt as in the Debian apt tool? I have a variety of Debian boxes (used to be Sarge, now Etch and Lenny) that authenticate to squid via NTLM, and this "just works" for me: Set up an /etc/apt/apt.conf file like this: Acquire::http::Proxy "http://username:passw...@10.11.12.13:3128/";; Where username and password are for a service account you create in active directory. You can use a human's account, but the password will be in plaintext with the apt.conf file, so I don't suggest it. Easier to create a service account and then just tightly lock it down in AD. (All you need is that the squid proxy can authenticate to it.) And of course 10.11.12.13:3128 is whatever IP address/port your Squid lives on. If you've already done this and it doesn't work, maybe there's a typo. I've used apt with NTLM for years and it has been rock solid. And of course if it is another apt you're talking about, none of this applies. :) James
[squid-users] Certain applications when using NTLM auth
Morning, For quite some time I´ve wondered about something. Certain applications worked perfectly with Squid in the past. But, since we´ve integrated it with Active Directory (NTLM auth) some applications just don´t work anymore, even if they do have "authenticated proxy support". What I´ve noticed about NTLM authentication with Squid is: 1) Application sends HTTP request (Firefox or IE, for instance) 2) Squid receives the request and then returns HTTP code 407 to the client (Proxy Authentication Required) 3) The application receives the 407 code and asks the user for authentication input (the browsers use the current logged user credentials if inside an Active Directory domain) 4) The application sends the authentication info 5) Squid receives it, checks it and then does its work But, some applications, APT being a very simple example (and one of my headaches) can´t ask for an input. And even configuring it to send user´s credentials doesn´t seen to work (Squid keeps replying with 407). I presume that the behavior "wait until I ask for auth credentials" is necessary for the complete functionality, so Squid just ignores the info that´s initially sent. Anyway I can solve that without having to put those applications "outside the proxy"? Best regards, Henrique Cicuto Machado
