[squid-users] Question about proxy_auth
Hello all, I have written an external auth helper which returns OK user=external username in case of a positive authentication result. I would think that I could use this external username - which in case of LDAP authentication would be the user's DN - in other external_acl_type acls as the %EXT_USER format. I've now learnt that I've misunderstood this but I am still wondering if something like this can be done? Regards, Khaled
Re: [squid-users] empty basic/digest realm
The reason is simple. My auth helper reads values (realm:password or only password) from a certain LDAP attribute, matches one of these values and then uses the match to compute H(A1). Now, we have customers whose LDAP attributes only store the password (in clear-text) and thus they have no realm:password combination which might be matched. Finally this leads to the assumption that the associated realm is empty and thus the need for an empty realm. I don't think the intention of the authors can be a valid argument here since the RFC was created in order not to have to rely on guesses and intentions when implementing a HTTP client/server. Regards, Khaled
Re: [squid-users] empty basic/digest realm
Hi Henrik, I am not sure what your point is so I'll be trying to make my point again. First of all, the RFC specifies the realm to be a quoted-string as you can see here: realm = realm = realm-value realm-value = quoted-string In the whole RFC there is no statement that says the realm has to have a certain length. So it can also have the length 0 which translates to the empty string. I have written an auth helper which is able to cope with the empty string as a realm but Squid cannot cope with it. This is the reason for my email in the first place. The empy realm leads to an H(A1) like this: H(A1) == HEX(MD5(login :: password)) This computes to a perfectly valid MD5 hash with which IE and Firefox have no problem. I hope I have made my intentions more clear now. Regards, Khaled 2010/7/1 Henrik Nordström hen...@henriknordstrom.net: The normal digest ldap helper in plain text passord mode expects just the plain text password in ldap, without realm. If you store H(A1) value then it`s always realm specific. And to my knowledge there is no basic auth helper capable of verifying to a H(A1) value but technically it can be done regardless of what realm were used in the H(A1). If you use some other helper which expects realm:password or realm:H(A1) then it would most likely expect :H(A1) and not H(A1) if realm is empty. Keep in mind that Digest A1 value is login:realm:password. And H is HEX MD5 which makes H(A1) == HEX(MD5(login : realm : password)) So i still do not quite umderstand what yo want to accomplish with an empty realm. Regards Henrik
Re: [squid-users] empty basic/digest realm
Sorry for my late reply, Henrik. I want to be able to use an empty realm because we use Digest Auth in conjunction with an LDAP backend. In this LDAP backend the admin can specifiy combinations of realm:password or realm:H(A1). The empty realm would thus lead to either password or H(A1) standing by themselves. We want to support this latter case as well and the empty realm would make that a lot easier. Regards, Khaled 2010/6/22 Henrik Nordström hen...@henriknordstrom.net: tis 2010-06-22 klockan 00:22 +0200 skrev Khaled Blah: That's not completely true. RFC 2617 states that the realm of either digest/basic auth is a quoted string but it doesn't say that this string has to be a minimum number of characters. True, but is clearly not the intention that this should be empty. I asked why you want to use an empty realm. Regards Henrik
[squid-users] empty basic/digest realm
Hello all, I'd like to give Squid an empty realm as the realm for basic/digest authentication but Squid quits with a message similar to this: FATAL: Bungled squid.conf line xxx: auth_param digest realm. Maybe I am doing something wrong but I can't get the empty realm working. Can anyone here tell me how it's done? Thanks in advance! Regards, Khaled
[squid-users] Re: empty basic/digest realm
I just tried leaving the auth_param digest realm statement away and then squid used Squid proxy-caching web server as the realm. I am using squid 2.7. Does Squid support empty realm in versions 2.7? 2010/6/15 Khaled Blah khaled.b...@googlemail.com: Hello all, I'd like to give Squid an empty realm as the realm for basic/digest authentication but Squid quits with a message similar to this: FATAL: Bungled squid.conf line xxx: auth_param digest realm. Maybe I am doing something wrong but I can't get the empty realm working. Can anyone here tell me how it's done? Thanks in advance! Regards, Khaled
Re: [squid-users] Squid HTTP Keytab SPN question
Hi Nick, what I don't get in your question is this: if squid is already joined to your domain as squid1, why create another machine account auth1? Maybe I missed out on something. Your msktutil parameters look fine though. Regards, Khaled 2010/4/14 Nick Cairncross nick.cairncr...@condenast.co.uk: Hi, I'd like confirmation of something is possible, but first best to detail what I want: I want to use a separate computer account to authenticate my users against. I know that this requires an HTTP.keytab and computer in AD with SPN. I would like to use MKTSUTIL for this. If my proxy server is called SQUID1 and is already happily joined to the domain then I need to create a new machine account which I will call AUTH1. 1) Do I need to create a DNS entry for AUTH1 (with the same IP as SQUID1)? 2) If so, do I need just an A record? 3) I have evidently got confused over the msktutil switches and values and so I'm specifying something wrong. What have I done? See below... I used this command after a kinit myusername: msktutil -c -b CN=COMPUTERS -s HTTP/squid1.[mydomain] iz -k /etc/squid/HTTP.keytab --computer-name auth1 --upn HTTP/squid1 --server dc1 -verbose This created the computer account auth1 in the computers ou, added HTTP/squid1.mydomain to SPN and HTTP/squid1.mydom...@mydomain to the UPN. It also created the keytab HTTP.keytab. Klist reports: 2 HTTP/squid1.[mydoma...@[mydomain] 2 HTTP/squid1.[mydoma...@[mydomain] 2 HTTP/squid1.[mydoma...@[mydomain] However cache.log shows this when I then fire up me IE 2010/04/14 14:52:46| authenticateNegotiateHandleReply: Error validating user via Negotiate. Error returned 'BH gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information. No principal in keytab matches desired name' Thanks as always, Nick ** Please consider the environment before printing this e-mail ** The information contained in this e-mail is of a confidential nature and is intended only for the addressee. If you are not the intended addressee, any disclosure, copying or distribution by you is prohibited and may be unlawful. Disclosure to any party other than the addressee, whether inadvertent or otherwise, is not intended to waive privilege or confidentiality. Internet communications are not secure and therefore Conde Nast does not accept legal responsibility for the contents of this message. Any views or opinions expressed are those of the author. Company Registration details: The Conde Nast Publications Ltd Vogue House Hanover Square London W1S 1JU Registered in London No. 226900
Re: [squid-users] Creating a kerberos Service Principal.
Hi Bilal, 1. ktpass and msktutil practically do the same, they create keytabs which include the keys that squid will need to decrypt the ticket it receives from the user. However ktpass only creates a file which you will then have to securely transfer to your proxy server so that squid can access it. Using msktutil on your proxy server, you can get the same keytab without having to transfer it. Thus, msktutil saves you some time and hassle. AFAIR both need Administrator rights, which means the account used for ktpass/msktutil needs to be a member of the Administrator group. 2. To answer this question, one would need more information about your network and your setup. Basically, mixing any other authentication method with Kerberos is not a good idea. That's because if the other method is insecure or less secure an attacker who gains access to a user's credentials will be able to impersonate that user against Kerberos and those be able to use ALL services that this user has access to. In any case DO NOT use basic auth with Kerberos in a public, set-up. That's a recipe for disaster. Digest auth and NTLM (v2) might be suitable but these are in fact less secure than Kerberos and thus not preferrable. One down-side to Kerberos is that it's an all-or-nothing service, either you use Kerberos and only Kerberos or you risk security breaches in any mixed situation. HTH Khaled 2010/4/6 GIGO . gi...@msn.com: Dear All, Please guide me in regard to SSO setup with Active Directory(No winbind/Samba). I have the following questions in this regard. 1. Creating a Kerberos service principal and keytab file that is used by the Squid what is the effective method? Difference between using Ktpass vs Msktutil package? What rights would i be required in Active Directory and if none then why so? 2. How to configure the fallback Authentication scheme if Kerberos fails? Ldap authentication using basic looks to be an option but isnt it less secure? is there a better approach possible. regards, Bilal Aslam _ Hotmail: Powerful Free email with security by Microsoft. https://signup.live.com/signup.aspx?id=60969
Re: [squid-users] Creating a kerberos Service Principal.
I forgot this link to an Example configuration: http://wiki.squid-cache.org/ConfigExamples/Authenticate/Kerberos 2010/4/8 Khaled Blah khaled.b...@googlemail.com: Hi Bilal, 1. ktpass and msktutil practically do the same, they create keytabs which include the keys that squid will need to decrypt the ticket it receives from the user. However ktpass only creates a file which you will then have to securely transfer to your proxy server so that squid can access it. Using msktutil on your proxy server, you can get the same keytab without having to transfer it. Thus, msktutil saves you some time and hassle. AFAIR both need Administrator rights, which means the account used for ktpass/msktutil needs to be a member of the Administrator group. 2. To answer this question, one would need more information about your network and your setup. Basically, mixing any other authentication method with Kerberos is not a good idea. That's because if the other method is insecure or less secure an attacker who gains access to a user's credentials will be able to impersonate that user against Kerberos and those be able to use ALL services that this user has access to. In any case DO NOT use basic auth with Kerberos in a public, set-up. That's a recipe for disaster. Digest auth and NTLM (v2) might be suitable but these are in fact less secure than Kerberos and thus not preferrable. One down-side to Kerberos is that it's an all-or-nothing service, either you use Kerberos and only Kerberos or you risk security breaches in any mixed situation. HTH Khaled 2010/4/6 GIGO . gi...@msn.com: Dear All, Please guide me in regard to SSO setup with Active Directory(No winbind/Samba). I have the following questions in this regard. 1. Creating a Kerberos service principal and keytab file that is used by the Squid what is the effective method? Difference between using Ktpass vs Msktutil package? What rights would i be required in Active Directory and if none then why so? 2. How to configure the fallback Authentication scheme if Kerberos fails? Ldap authentication using basic looks to be an option but isnt it less secure? is there a better approach possible. regards, Bilal Aslam _ Hotmail: Powerful Free email with security by Microsoft. https://signup.live.com/signup.aspx?id=60969
Re: [squid-users] Re: Negotiate/NTLM authentication caching
Markus and Amos, thx for your replies! But are you sure there is no caching for auth_param helpers? Because I could swear that the H(A1) at the digest hashing is only computed once. At least I think I remember it this way. Hmm, I guess I have to look at that again more closely. Regards, Khaled 2010/3/30 Amos Jeffries squ...@treenet.co.nz: Markus Moeller wrote: I may misunderstood what you said, but there is no caching of authentication for Kerberos nor Basic/Digest. I think the TTL you talk about is for authorisation. Markus Quite right. Amos Khaled Blah khaled.b...@googlemail.com wrote in message news:4a3250ab1003290408q72ec495an7d04934d527c3...@mail.gmail.com... Thx a lot for your answer, Amos! You are of course right with your concerns towards IP/TCP caching. Not a very good idea! Does the same hold true for Kerberos as well, though? I mean could it be possible to cache Kerberos authentication in a secure fashion? Thinking about what you said, I am wondering what the big difference is to Basic/Digest authentication. I mean with them squid challenges the user as well, the credentials the user's client sends are being verified by the authentication helper and that result is cached so that when the same user requests anything with the same credentials, he or she will not be re-verified with the helper's help until the TTL has passed, right? So what am I missing here? Thx in advance for any insight you can give me on this! Khaled 2010/3/28 Khaled Blah khaled.b...@googlemail.com: Thx a lot for your answer, Amos! You are of course right with your concerns towards IP/TCP caching. Not a very good idea! Does the same hold true for Kerberos as well, though? I mean could it be possible to cache Kerberos authentication in a secure fashion? Thinking about what you said, I am wondering what the big difference is to Basic/Digest authentication. I mean with them squid challenges the user as well, the credentials the user's client sends are being verified by the authentication helper and that result is cached so that when the same user requests anything with the same credentials, he or she will not be re-verified with the helper's help until the TTL has passed, right? So what am I missing here? Thx in advance for any insight you can give me on this! Khaled 2010/3/28 Amos Jeffries squ...@treenet.co.nz: Khaled Blah wrote: Hi all, I'm developing an authentication helper (Negotiate/NTLM) for squid and I am trying to understand more how squid handles this process internally. Most of all I'd like to know how and how long squid caches authentication results. I have looked at the debug logs and they show that squid seems to do less caching for Negotiate/NTLM than it does for Basic/Digest authentication. I am wondering whether I can do something about this so that a once verified user will only get his credentials re-verified after a certain time and not all during. I am grateful to any insight the list can give me. Thanks in advance! Khaled NTLM does not authenticate a user per-se. It authenticates a TCP link to a some form of account (user being only one type). Squid holds the authentication credentials for as long as the authenticated TCP link is open. It challenges the browser on any requests without supplied credentials, and re-verifies on every new link opened or change in existing credentials. Caching NTLM credentials for re-use on TCP links from specific IP addresses has always been a very risky business. As the world is now moving further towards NAT and proxy gateways a single IP address can have multiple requests from multiple clients. This makes caching NTLM credentials an even worse prospect in future than it is now or ever before. What we are doing in Squid-3 now is improving the HTTP/1.1 support which enables TCP links to be held open under more conditions than HTTP/1.0 allows and thus the length of time between credential checks to be lengthened without loosing security. I can tell you now that any patches to do with caching credentials will be given some very strict checks even to be considered for acceptance into Squid. Amos -- Please be using Current Stable Squid 2.7.STABLE8 or 3.0.STABLE25 Current Beta Squid 3.1.0.18 -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.1
Re: [squid-users] Negotiate/NTLM authentication caching
Thx a lot for your answer, Amos! You are of course right with your concerns towards IP/TCP caching. Not a very good idea! Does the same hold true for Kerberos as well, though? I mean could it be possible to cache Kerberos authentication in a secure fashion? Thinking about what you said, I am wondering what the big difference is to Basic/Digest authentication. I mean with them squid challenges the user as well, the credentials the user's client sends are being verified by the authentication helper and that result is cached so that when the same user requests anything with the same credentials, he or she will not be re-verified with the helper's help until the TTL has passed, right? So what am I missing here? Thx in advance for any insight you can give me on this! Khaled 2010/3/28 Khaled Blah khaled.b...@googlemail.com: Thx a lot for your answer, Amos! You are of course right with your concerns towards IP/TCP caching. Not a very good idea! Does the same hold true for Kerberos as well, though? I mean could it be possible to cache Kerberos authentication in a secure fashion? Thinking about what you said, I am wondering what the big difference is to Basic/Digest authentication. I mean with them squid challenges the user as well, the credentials the user's client sends are being verified by the authentication helper and that result is cached so that when the same user requests anything with the same credentials, he or she will not be re-verified with the helper's help until the TTL has passed, right? So what am I missing here? Thx in advance for any insight you can give me on this! Khaled 2010/3/28 Amos Jeffries squ...@treenet.co.nz: Khaled Blah wrote: Hi all, I'm developing an authentication helper (Negotiate/NTLM) for squid and I am trying to understand more how squid handles this process internally. Most of all I'd like to know how and how long squid caches authentication results. I have looked at the debug logs and they show that squid seems to do less caching for Negotiate/NTLM than it does for Basic/Digest authentication. I am wondering whether I can do something about this so that a once verified user will only get his credentials re-verified after a certain time and not all during. I am grateful to any insight the list can give me. Thanks in advance! Khaled NTLM does not authenticate a user per-se. It authenticates a TCP link to a some form of account (user being only one type). Squid holds the authentication credentials for as long as the authenticated TCP link is open. It challenges the browser on any requests without supplied credentials, and re-verifies on every new link opened or change in existing credentials. Caching NTLM credentials for re-use on TCP links from specific IP addresses has always been a very risky business. As the world is now moving further towards NAT and proxy gateways a single IP address can have multiple requests from multiple clients. This makes caching NTLM credentials an even worse prospect in future than it is now or ever before. What we are doing in Squid-3 now is improving the HTTP/1.1 support which enables TCP links to be held open under more conditions than HTTP/1.0 allows and thus the length of time between credential checks to be lengthened without loosing security. I can tell you now that any patches to do with caching credentials will be given some very strict checks even to be considered for acceptance into Squid. Amos -- Please be using Current Stable Squid 2.7.STABLE8 or 3.0.STABLE25 Current Beta Squid 3.1.0.18
[squid-users] Negotiate/NTLM authentication caching
Hi all, I'm developing an authentication helper (Negotiate/NTLM) for squid and I am trying to understand more how squid handles this process internally. Most of all I'd like to know how and how long squid caches authentication results. I have looked at the debug logs and they show that squid seems to do less caching for Negotiate/NTLM than it does for Basic/Digest authentication. I am wondering whether I can do something about this so that a once verified user will only get his credentials re-verified after a certain time and not all during. I am grateful to any insight the list can give me. Thanks in advance! Khaled
[squid-users] Negotiate/NTLM authentication caching
Hi all, I'm developing an authentication helper (Negotiate/NTLM) for squid and I am trying to understand more how squid handles this process internally. Most of all I'd like to know how and how long squid caches authentication results. I have looked at the debug logs and they show that squid seems to do less caching for Negotiate/NTLM than it does for Basic/Digest authentication. I am wondering whether I can do something about this so that a once verified user will only get his credentials re-verified after a certain time and not all during. I am grateful to any insight the list can give me. Thanks in advance! Khaled
[squid-users] Authentication caching
Hi all, I'm developing an authentication helper (Negotiate/NTLM) for squid and I am trying to understand more how squid handles this process internally. Most of all I'd like to know how and how long squid caches authentication results. I have looked at the debug logs and they show that squid seems to do less caching for Negotiate/NTLM than it does for Basic/Digest authentication. I am wondering whether I can do something about this so that a once verified user will only get his credentials re-verified after a certain time and not all during. I am grateful to any insight the list can give me. Thanks in advance! Khaled
[squid-users] Authentication caching
Hi all, I'm developing an authentication helper (Negotiate/NTLM) for squid and I am trying to understand more how squid handles this process internally. Most of all I'd like to know how and how long squid caches authentication results. I have looked at the debug logs and they show that squid seems to do less caching for Negotiate/NTLM than it does for Basic/Digest authentication. I am wondering whether I can do something about this so that a once verified user will only get his credentials re-verified after a certain time and not all during. I am grateful to any insight the list can give me. Thanks in advance! Khaled
[squid-users] Active Directory Single Sign-on
Hello to the list, I have searched for answers regarding this but did not find any. My question concerns RFC 4559. There it says: This mechanism is not used for HTTP authentication to HTTP proxies. Does that mean HTTP proxy authentication or the actual HTTP authentication. I am wondering whether that means that Squid cannot use SPNEGO based proxy authentication or that a client cannot HTTP authenticate to a target through a proxy. I found the RFC to be ambigous concerning this. I'd be glad if you could enlighten me concerning this question. Thanks a lot! -- Khaled Blah khaled.b...@gmx.de signature.asc Description: OpenPGP digital signature
Re: [squid-users] Active Directory Single Sign-on
Thx for your replay, Henrik! With it I think you mean Proxy Authentication, right? Sorry, if that's a trivial question for you. I just would like to clarify this. Regards, Khaled Original-Nachricht Datum: Thu, 18 Feb 2010 11:38:11 +0100 Von: Henrik Nordström hen...@henriknordstrom.net An: Khaled Blah khaled.b...@gmx.de CC: squid-users@squid-cache.org Betreff: Re: [squid-users] Active Directory Single Sign-on tor 2010-02-18 klockan 10:30 +0100 skrev Khaled Blah: This mechanism is not used for HTTP authentication to HTTP proxies. Does that mean HTTP proxy authentication or the actual HTTP authentication. I am wondering whether that means that Squid cannot use SPNEGO based proxy authentication or that a client cannot HTTP authenticate to a target through a proxy. I found the RFC to be ambigous concerning this. Squid can handle it since negotiate support was added to Squid. Firefox can handle it. Late versions of MSIE can also handle it, but at the time Microsoft wrote that document MSIE could not handle it. Regards Henrik
