Markus, I understand your advice but I wanted to clarify the last paragraph also. If I have already used Samba to join my machine to the domain and want to have the Samba service still running to permit shares for Squid administration and other things, do you mean use the msktutil tool to create another NEW computer account solely for the purpose of Squid authentication; if so does this require a DNS entry etc. The example on the Squid Wiki re: Kerberos suggests: 'Create keytab for HTTP/fqdn with msktutil. (If used together with samba net join use another computer name than the hostname used by net join)'. That means having two computer accounts - I'm a bit unsure of the best way to have Samba running and create an independent 'method' for Squid authentication given that Samba modifies its computer account and throws the KVNO out for the exported Keytab.. ? Any ideas of pointers would be great. Nick On 09/04/2010 08:16, "Markus Moeller" <huaraz@xxxxxxxxxxxxxxxx> wrote: Hi Bilal, What you do is a possible option, but has in my view 3 problems. 1) In a large enterprise you really do not want additional user accounts without password expiry as you have to have a process in place to recertify them regularly 2) It means when the administrator leaves you have to change all passwords of keytab accounts as it might be otherwise a backdoor 3) Do not use DES it is deprecated in Windows 7 /2008 and will be in the next MIT/Heimdal releases The msktutil tool creates in comparision a Computer account and it does it from your Unix machine, and therefore does not have the overhead of transfering keytabs around. And as I described in my other post you can control access to OUs so that Unix administrators can use msktutil. Regards Markus "GIGO ." <gigoz@xxxxxxx> wrote in message news:SNT134-w588E173F39449195CA6126B9150@xxxxxxxxxx Hi Markus/Nick, I have chosen the following method of creating the keytab can you give me your advice/expereince regarding it. 1. I have created a user account for SPN in Active directory with password never expires and preauthentication not required checked. squidLhr-proxy Pwd: XXXXX C:\Program Files\Support Tools> setspn -A HTTP/squidLhr-proxy.v.mcb.com.pk squidLhr-proxy Creating keytab: ktpass -out c:\squidLhr-proxy.keytab -princ HTTP/squidLhr-proxy.v.com.pk@xxxxxxxxxxxxxxxx -mapUser V\squidLhr-proxy -mapOp set -pass * -crypto DES-CBC-MD5 -pType KRB_NT_PRINCIPAL regards, Bilal ---------------------------------------- > To: squid-users@xxxxxxxxxxxxxxx > From: huaraz@xxxxxxxxxxxxxxxx > Date: Thu, 8 Apr 2010 20:08:10 +0100 > Subject: Re: Re: Re: SSO with Active Directory-Squid Clients > > Hi Nick, > > Did you use samba to create the keytab. I have seen that if you use samba > for more then squid (e.g. cifs, winbind, etc) it will update regularly the > AD entry and key for the host/fqdn principal which is the same as for > HTTP/fqdn. I usually use msktutil and create a second AD entry called > -HTTP to be independent of samba which usually uses > . > > Regards > Markus > > "Nick Cairncross" wrote in message > news:C7E35DA9.1EB06%Nick.Cairncross@xxxxxxxxxxxxxxxxxx > Bilal, > > I'm working on much the same thing, with added Apple Mac just to > complicate > things. My aim is to create an SSO environment for all my Windows, OSX and > nix machines. I want to use Kerberos as my primary authentication as IE7 > and > FF onwards are moving that way..but for my situation some browsers or > applications do not support this and I must also use NTLM. However, Opera > on my Macs seems to not like either and prefers Basic.. It's been a > struggle > to get each element to work but not impossible. > > I have found that all Negotiate/Kerberos supporting browsers have worked > extremely well with the helper developed by Markus. Many of the > authentication breaking elements have disappeared when compared to my Blue > Coat and ISA experiences. Those machines joined to the domain using > browsers > that support Neg/Kerb work seamlessly with Kerberos - FF and IE - and pass > through credentials. Mac Safari relies on NTLM and prompts as such. Mac > Opera prompts for Basic. Therefore if you're just Windows I would answer > fairly confidently that your question 1 answer is Yes. > > Users not on the domain would be prompted for credentials. I haven't > tested > this and depending on which helper you are using (Samba or Squids) and > whether you're joined to the domain I believe Negotiate should fall back > to > NTLM and work providing you supply a valid domain user/pass! So the answer > to 2 would be 'depends..' :) > > As for the issue of not being to able to use Squid at all and taking into > account what I said earlier, then yes there could be a scenario where > Squid > will not work for your users. However, it is less of a problem in just > Windows. It's all about testing your various Windows configurations, apps > and browsers until you are sure you have covered the conceivable setups of > all your users. > Finally, I have been struggling against an issue where my KVNO Keytab > increments in AD and gets out of sync with the exported version making > Squid > un-useable until it's regenerated. Have you experienced this? Happy to > discuss any of this off list or on. > > Cheers, > Nick > > > > On 08/04/2010 04:06, "GIGO ." wrote: > > > > If i select negotiate/Kerberos as authentication protocol for my Squid on > Linux and configure no FallBack Authentication.what would be the > consequence > ? > > > > 1. Isnt it that all of my users who have logged into Active Directory and > where browser is supported will be able to use squid? > > > > 2. Only those users who will try to use squid from a workgroup giving > their > domain passoword (domainname/userid) will fail as there will be no > fallback > aviablable. > > > > 3. Is there any other scenario in which these users will not be able to > use > squid? > > > > I would be really thankful if you guide me further as i am failing to > understand why a fallback authentication is necessary if it is. What could > be the scenario when windows clients have no valid TGT even if they are > login to the domain? I hope you can understand me and help me to clear my > self. > > > regards, > > Bilal Aslam > > > > > > > > > > ---------------------------------------- >> To: squid-users@xxxxxxxxxxxxxxx >> From: huaraz@xxxxxxxxxxxxxxxx >> Date: Wed, 7 Apr 2010 20:17:20 +0100 >> Subject: Re: Re: Re: SSO with Active Directory-Squid >> Clients >> >> Sorry I knew that but forgot to mention that I was talking about the Unix >> version. >> >> Thank you >> Markus >> >> "Guido Serassio" wrote in message >> news:58FD293CE494AF419A59EF7E597FA4E64002FA@xxxxxxxxxxxxxxxxxxxxxxxxxxxx >> Hi Markus, >> >>> If you have a Windows client and the proxy send WWW-Proxy-Authorize: >>> Negotiate the Windows client will try first to get a Kerberos ticket >> and >>> if that succeeds sends a Negotiate response with a Kerberos token to >> the >>> proxy. >>> If the Windows client fails to get a Kerberos ticket the client will >> send >>> a Negotiate response with a NTLM token to the proxy. Unfortunately >> there> is yet no squid helper which can handle both a >> Negotiate/Kerberos response >>> and a Negotiate/NTLM response (although maybe the samba ntlm helper >> can).> So there is a fallback when you use Negotiate, but it has some >> caveats. >> >> This is not true when Squid is running on Windows: the Windows native >> Negotiate Helper can handle both Negotiate/Kerberos and Negotiate/NTLM >> responses. >> >> Regards >> >> >> Guido Serassio >> Acme Consulting S.r.l. >> Microsoft Gold Certified Partner >> VMware Professional Partner >> Via Lucia Savarino, 1 10098 - Rivoli (TO) - ITALY >> Tel. : +39.011.9530135 Fax. : +39.011.9781115 >> Email: guido.serassio@xxxxxxxxxxxxxxxxx >> WWW: http://www.acmeconsulting.it >> >> > _________________________________________________________________ > Hotmail: Trusted email with powerful SPAM protection. > https://signup.live.com/signup.aspx?id=60969 > > > ** 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 > > _________________________________________________________________ Hotmail: Trusted email with Microsoft's powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969 ** 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
