Re: [squid-users] Advice: ntlm_auth from samba4 or negotiate_wrapper ?

On 16/07/2013 5:02 a.m., Michele Bergonzoni wrote:
> I would like to hear your advice about kerberos auth configuration on
> a new installation.
>
> This will be an installation with two redundant Linux based servers,
> clients will be mostly windows joined to active directory, with AD
> users logged in. The main focus of the installation is authentication
> and per-group or per-user policy.
>
> I would like to keep user experience as simple as possible, avoiding
> authentication dialogs whenever possible. Basic authentication with
> cleartext credentials should be avoided in this installation. ntlm
> fallback is OK.

Popups you are trying to avoid is a browser feature. It is 100% up to
the client to use the password manager and/or operating system settings
which prevent it being needed.
Nothing you do with Squid will prevent it if they have their settings
tuned to require it. Squid simply requires credentilas to be delivered
by the browser, single-sign-on works just as silently and easily (from a
UX perspective) with Basic auth as with NTLM. The only reason to avoid
Basic is its low security level and NTLM has security holes that make it
almost equally low.

>
> I see that for windows AD authentication, kerberos and negotiate seem
> to be the modern choice. My confusion begins where the squid wiki says:
>
> Authentication helpers which perform the grunt work:
> - ntlm_auth from Samba 4 with the --helper-protocol=gss-spnego parameter
> - negotiate_wrapper or squid_kerb_auth by Markus Moeller
>
> I did a few tests with ntlm_auth from samba4, and it seems to work,
> with some residual problems with firefox and PCs not joined in the
> domain, and an extra authentication popup at the beginning from IE.
>
> I didn't get to the point of having a working negotiate_wrapper /
> squid_kerb_auth config, being still confusing about hostnames,
> principals, redundancy, failover, ntlm fallback with winbindd.
>
> So before I dig into the details of what I'm seeing, I am wondering if
> maybe one of the two alternatives has became a "de facto" standard
> over the other, and so I should study and test it alone, or if they
> are both actively deployed, and so I should study and test both to see
> what fits better to me.

LM is a security protocol with lots of different mechanisms added over
the years. The last two mechanisms added in the 1990's and were labeled
NTLMv1 and NTLMv2, and the whole system has collectively become known as
"NTLM" due to marketing abstractions.

Kerberos is a newer mechanism designed a lot more like SSL with client
certificates and is a lot more secure in a several ways. It is also
designed to work a lot more efficiently by having the client
pre-assigned a keytab/certificate/token and avoid the horrible setup
handshakes NTLM does in order to send the client a token. It also uses
the "Negotiate" auth mechanism in HTTP instead of the "NTLM" one - but
both Kerberos and NTLM can be transmitted over the "Negotiate" mechanism
and the Squid tool negtiate_wrapper is used to identify which one the
client is using.

If you have a choice pick Negotiate/Kerberos. But there is still
software out there that only supports NTLM so that will determine
whether or not you can do entirely without it. Some such as IE will try
to use Negotiate/NTLM which requires the negotiate_wrapper helper to be
used by Squid.

The Squid helpers tools:

* The negotiate_wrapper tool provided by Squid supports splitting
Negotiate auth traffic between a pair of NTLM-only and Kerberos-only
helpers. It does not do any auth itself but maintains the stateful
session links between client and sub-helper.

* The ntlm_auth / ntlm_smb_lm_auth provided by Squid only does old LM
mechanisms and NTLMv1 would "work" because it allowed automatic
down-grade of the security level to one of those broken (8-bit
security!) mechanisms. We prefer people *not* use these anymore since
the old mechanisms are highly dangerous nowdays and can literally be
broken in real-time.

* The ntlm_auth tool provided by Samba supports proper NTLMv1, NTLMv2
and maybe Kerberos. It also seems to prefer upgrading clients to using
NTLMv2 security extensions when possible. The Samba developers have a
focus on MS software systems and interoperating with them so their tool
is prefered by most for use with ActiveDirectory, and will often have
the best compatibility with newer MS changes to AD.

* The negotiate_kerberos_auth helper provided by Squid only supports
Kerberos. It seems to be best for dealing with Kerberos authentication
in non-AD systems as it is built using the same public libraries for
Kerberos that such systems are themselves usually built against (almost
guaranteed compatibility).

Hope this clarifies everything for you.
Amos
Received on Tue Jul 16 2013 - 09:31:59 MDT