Hmm. I'm just using chrome as a client, so the same client as for http/s. There is no authentications on the ftp server itself (example ftp://ftp.epson.com/), its anonymous. So that scenario should just work, since as you note the client->squid should negotiate as usual. On 17 April 2013 09:53, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: > On 17/04/2013 6:56 p.m., Sean Boran wrote: >> >> Hi, >> >> Kerberos is authenticating http/s traffic for me from certain client >> addresses just fine. >> However ftp is being rejected, does the browser+squid not auth ftp in >> the same way as http? >> >> If ftp does work with kerberos, is there a way (ACL) that ftp traffic >> can be excluded from kerberos auth? >> >> Thanks in advance, >> >> Sean > > > FTP protocol only supports a form of Basic authentication. So Squid maps FTP > server authentication to www-auth headers as Basic scheme. > > The link between client and Squid is of course HTTP and can use the full > range of HTTP schemes normally. > > The two levels of authentication, client->server and client->squid are > completely independent so the client can login with Negotiate/Kerberos to > the proxy and Basic to the FTP server simultaeneously. The main problems are > lack of proper HTTP support (or just Kerberos support) in FTP clients which > claim to support HTTP proxies. > > Amos >
