Re: [squid-users] Do windows machines *have* to join a domin to use NTLM?

From: Kinkie <gkinkie_at_gmail.com>
Date: Tue, 24 Dec 2013 23:13:05 +0100

On Tue, Dec 24, 2013 at 7:54 PM, Brian J. Murrell <brian_at_interlinx.bc.ca> wrote:
> [ Changed the subject to get down to the more basic issue ]
>
> On Tue, 2013-12-24 at 16:20 +1300, Amos Jeffries wrote:
>>
>> This is not an assumption from the documentation. NTLM protocol
>> *requires* a DC to operate.
>
> TL;DR: Do windows machines *have* to join a domain in order to use NTLM
> with Squid?

Hi,
  as far as I know, having a domain is not a strict requirement, at
least if you restrict to the less-secure NTLMv1. YMMV with NTLMv2. But
if you do, then you have to manually ensure that the authenticating
system (samba) and the user accounts on the workstations are in sync.
That's no easy task, even for a small number of workstations and of
users.

> Perhaps I mis-stated my desires. I don't mind setting up Samba as a DC.
> But surely Samba users use the same password for Samba as they do for
> other PAM based services (i.e. loging, etc.), which here, actually
> utilizes Kerberos for account access. Does Samba need the clear-text
> value of the password for creating challenges, etc. or can it leverage
> PAM and/or Kerberos? But I digress.

It is not mandatory that Samba password and Unix password be in sync.
Samba doesn't need the cleartext password, but it needs a hashed
password-equivalent which is stored in its password database.
Generally samba *tries* to keep the passwords in sync by replaying the
change-password activity to the unix password when an user invokes
smbpasswd, but it can be overridden and avoided.
It is not possible to obtain the SMB password-equivalent from the
encrypted and salted Unix password (to answer your next question)

> My only real hard requirement is to not to require the Windows users to
> "join a domain" here just to use Squid. I have no desire for the
> network infrastructure here to be the account control for these windows
> laptops as they are not within my administrative domain. Is that
> impossible? I simply want users to be able to just bring their own
> Windows machine and be able to use an existing PAM (kerberos actually)
> account and just use my Negotiate protocol offering Squid proxy.
>> Good luck. You will need to start with finding a PAM service can
>> authenticate NTLMSSP protocol. AFAIK there is no such service.
>
> I think you are misunderstanding. What I was saying is that the
> NTLM authentication mechanism documentation from
> http://wiki.squid-cache.org/ConfigExamples/Authenticate/Ntlm seems to
> assume that one already has a separate AD domain that they can join
> Samba to:
>
> workgroup = mydomain
> password server = myPDC
> security = domain
> ...
> Join the NT domain as outlined in the winbindd man page for your
> version of samba.
>
> I don't have an AD/NT domain here. Surely I can use Samba to provide
> NTLM authentication for Squid, using the account information on the
> Samba server without having to create a whole MS-Windows based NT domain
> just for Samba to join to, can't I? Is there a different NTLM example
> configuration for that? I don't see one that seems to cover just using
> Samba alone as the NTLM authentication mechanism for Squid.

You don't need a domain. You need the NTLM hashes (each user can
create theirs using smbpasswd)

>> If you do manage to find one, you will have to locate or write a NTLM
>> authentication helper for Squid to use it. The PAM helper provided
>> with Squid only supports Basic authentication.
>
> And TBH, I would be perfectly happy with Basic for these Windows users.
> Nobody is sniffing the network here. But it seems that I cannot provide
> Negotiate only to my Linux/Kerberos using users and Basic to the Windows
> users. The Windows users also end up getting offered Negotiate which is
> what opens up this whole NTLM can of worms.

No, you cannot. You can try setting up a kerberos realm and having
users authenticate against that, but I am not an expert there.

-- 
    /kinkie
Received on Tue Dec 24 2013 - 22:13:14 MST

This archive was generated by hypermail 2.2.0 : Wed Dec 25 2013 - 12:00:05 MST