Crazy ideas about Kerberos, NTLM and PACs... (was NTLMSSP...)

[Andrew Bartlett]

"Mayers, Philip J" wrote:
> 
> The Win2K encryption types were created so users didn't have to change their
> passwords on upgrade of a domain from NT4 to Win2k - that's all. They don't
> really help you here (except in so far as the KDC will also need to store
> the NT hash). I've hypothesised a complete removal of the auth methods and
> code into an external (core system) library, so SASL, mod_auth_ntlm and
> others could call into a single point - winbind might be a good place...
> Hey, wait, netlogond... (not wishing to start architecture wars again :o)
> 
> I'm not sure I understand your suggestion. According to my copy of Luke's
> book (hi Luke!), you're talking about NetLogon-on-the-cheap. Now, the
> question then is, what's wrong with the existing NetLogon? Security or
> implementation costs?

Well, I need one server that can authenticate:

- Native kerberos (I use this quite a bit now, its quite handy even just
within the server, and I need a distributed network authentication
system in any case).

- NT4 Domain logons (Vital, most of my machines are NT4 clients, and I
need to move them to domain logons to my domain - instead of other NT4
domains)

- HTTP MD5 Digest (otherwise I need to run NTLM-over-HTTP if I want
non-cleartext proxy authentication, and I would like to allow for non-MS
clients...)

- SSH and standard cleartext logins, including HTTPS cleartext.

This is what is leading me to creating a simple authentication server,
and creating a Samba authentication module to talk to it.  To keep
things simple, I wanted to follow the kerberos lead and to
authentication, not authorisation and therefore not deal with groups or
the like.

Similarly, I am *sick* of 'password sync' issues.  I want to implement a
single place all other servers will proxy their password change requests
to.  That way I can update all my passwords at once, without having to
hack each and every program to update each and every authentication
token type.

I also want to avoid an RPC based server, simply becouse every time I
get near RPC packets I stuff up, so I wanted somthing simpiler...

> Security: I'm guessing (although I'm by no means certain) that MSRPC can be
> GSSAPI-secured and authenticated in Win2K, and therefore we're going to have
> to make such an implementation to be Win2K compatible. Given that, and the
> superior security of GSSAPI, why not just implement the NetLogon channel
> over GSSAPI/MSRPC?
>
> Or implementation costs - the confusing one. If you're describing a member
> server talking to a PDC, then you'll have to implement this channel for
> compatibility reasons, and the fewer code paths the better. If on the other
> hand you're describing a PDC talking to a non-local SAM, I need to point out
> two things:
> 
> 1) That's hugely insecure, not to mention fault-intolerant, if not done
> right... Although you mention TCP hijacking, which isn't an issue (i.e.
> can't be done) with most GSSAPI mechanisms if they secure the connection.

I mention TCP session hijacking as it refers to the NT4 clients
accessing the Samba server, where the TGT would be stored.  The remote
TGT storage makes session hijacking a risk, because then they can access
resources with that TGT (but only though the Samba server).

> 2) The PDC *must* be able to be a KDC for Win2K-native clients - and that
> requires a local SAM, or some horrible hackery like a *remote* LDAP Kerberos
> backend. Ugh!

That's the kind of thing I'm proposing...
 
> As you can tell, I personally am of the opinion that SAM backends should be
> local, but if they're not, then I'm of the opinion they should be readable
> data stores, not protocol speakers - e.g. Kerberised PostgreSQL, GSSAPI/SASL
> secured LDAP, etc. - it's perfectly secure to pass NT and LM hashes over
> such connections. *However*, a secure, remote KDC backend becomes hard,
> because it has to issue a ticket for itself to talk to the LDAP server - not
> impossible, but I know of no KDCs that can do such a thing (IIRC, Heimdal's
> LDAP support is via local Unix sockets).

I was thinking to avoid keeping the passwords/keys in LDAP at all, and
keep them in the kerberos database.  This avoids having a
part-public/part-private database.

The security aspect that concerns me is the addiction that Samba has to
its raw hashes.  I'm working to drastically reduce the parts of Samba
that get the *raw* hashes in the first place.   I would like to place
the raw hashes on a SECURE, separate server away from my multi-user PDC,
in line with what people have said about kerberos for years.  In the end
I'll probably have to lump Samba on the same machine, but I think me
more abstraction we can get here the better.

Why should samba have to have a 'root password' to the LDAP server to
function in an LDAP environment? 

I have already abstracted Samba's authenticaion subsystem well away from
the password backend, and this should allow us to use a *Samba* protocol
between itself (as a member server this time) and the password store,
and use LDAP for the user information part of the equation in the same
kind of way nss_ldap works.  (Using a samba protocol allows us to avoid
the use of an undocumented MS protocol that we can't extend to our
needs).

> Or am I missing something really fundamental here?
> 
> Also, I don't know if the Win2K SMB client will do delegation inside GSSAPI
> - probably not (why would it - you can't re-export SMB shares under Win2K),
> although I'll have to check. It may do for MSRPC (SQL server springs to
> mind). If not, you'll never get a ticket passed to the SMB server, so
> delegation (e.g. Kerberised NFS) is irrelevant.
> 
> Re: the PAC - be very careful. I stopped after talking to a lawyer, before I
> even started looking at the on-the-wire data. It was his opinion that
> they'll fuck you if you try to publish code, badly.
> 
> To summarise, I personally would prefer a scheme such as the following:
> 
> 1) All access to NT-type auth mechanisms (e.g. that use the LM/NT hashes)
> should be done through winbind

I'm actually implementing that (proof of concept), but there are good
reasons (over which holy wars have been fought) that this is best done
in-process... (or so I'm told).

> 2) Member winbinds(Samba)/netlogons(Win2K) talks to the PDCs.
> 3) PDC winbinds talk to the auth backends...
> 4) ...which supply sid/uid/gid services (Member SAMBAs could resolve
> sid/uid/gid to PDC Samba winbind's via a new RPC...), and NT/LM hash
> services, group memberships, etc.
> 5) ...Win2K/KDC support should mandate LDAP as a minimum (possible a cheap
> tdb - I'm not sure though), and the LDAP server should store users, secrets,
> groups, memberships, and sid/uid/gids.
> 6) ...The KDC (Heimdal/MIT) should share the same backend (if the backend is
> a .so, it could be the *same* .so provided symbols don't collide..), and
> issue tickets with PACs based on the info in the backend.
> 
> Regards,
> Phil
> 
> +------------------------------------------+
> | Phil Mayers                              |
> | Network & Infrastructure Group           |
> | Information & Communication Technologies |
> | Imperial College                         |
> +------------------------------------------+
> 
> -----Original Message-----
> From: Andrew Bartlett [mailto:abartlet at pcug.org.au]
> Sent: 19 November 2001 07:47
> To: samba-technical at samba.org
> Cc: tng-technical at lists.dcerpc.org; lkcl at samba-tng.org; Luke Howard
> Subject: Crazy ideas about Kerberos, NTLM and PACs... (was NTLMSSP...)
> 
> Luke Howard wrote:
> >
> > > ...which is why ms created draft-brezak-krb5-rc4-hmac-01.txt
> > > which uses nt hashes for authentication and encryption.
> >
> > Not _why_, I don't think. This draft defines a mechanism for
> > migrating NT hashes to Kerberos, but it doesn't encapsulate
> > the NTLM authentication exchange in Kerberos, which I think is
> > what Andrew is proposing. I can't see how the latter is possible.
> 
> My insane idea is as follows:
> 
> Samba (acting as an NT4 server, to NT4 clients) gets an attempted NTLM
> login.  Samba then contacts (via a new protocol) the extended KDC to
> obtain a challenge, and hands back the clients response.  This is done
> over a secure channel, based on the Samba server's own keytab.  This
> response includes the unencrypted TGT, session key and the first 8 bytes
> of the LM hash, which Samba then uses to access other network resources.
> 
> Reasoning:  Yes, this is insecure as all heck - TCP session hijacking is
> the problem as far as I can see - or at least as insecure as current non
> sign-and-seal communications.  However, it helps solve a particular
> problem:   Passing the security context in a standard manner to an
> arbitrary backend over the network.
> 
> For example, if we have an LDAP SAM, and we have an administrator
> updating passwords in it.  Currently in HEAD (I've not looked at TNG
> yet) we do this all by local access controls and a 'ldap root'
> password.  I think this stinks, and I would much prefer to have a LDAP
> server enforce the access controls.  This allows me to (securely) pass
> that security context over to the LDAP server, or that VFS backend, or
> that AFS filesystem etc...
> 
> I have *no* idea if I'll actually get this far - I'll probably only get
> as far as checking the password - but I wouldn't mind scouting out the
> surrounding area while I'm at it. :-)
> 
> In any case, by doing much of this work I'll hopefully prepare the way
> for (or sail on the coattails of) *real* kerberos ticket passing and the
> like in Samba, based on the real kerberos over-the-wire deal.
> 
> It also separates the list of users/groups from the password storage,
> which I something I like the idea of.
> 
> In the event we get to creating the PAC, I think this should be done via
> a simple call-back, the kerberos server should use a similar protocol to
> obtain a PAC from *any* PAC providing service, not just Samba.  The idea
> of a PAC is quite (IMHO) a nice one, its just a pity MS decided not to
> document it.
> 
> Andrew Bartlett
> 
> --
> Andrew Bartlett                                 abartlet at pcug.org.au
> Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
> Student Network Administrator, Hawker College   abartlet at hawkerc.net
> http://samba.org     http://build.samba.org     http://hawkerc.net

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net