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

Mayers, Philip J p.mayers at
Mon Nov 19 01:25:15 GMT 2001

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?

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

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.
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!

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).

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
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.


| Phil Mayers                              |
| Network & Infrastructure Group           |
| Information & Communication Technologies |
| Imperial College                         |

-----Original Message-----
From: Andrew Bartlett [mailto:abartlet at]
Sent: 19 November 2001 07:47
To: samba-technical at
Cc: tng-technical at; lkcl at; 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
Manager, Authentication Subsystems, Samba Team  abartlet at
Student Network Administrator, Hawker College   abartlet at

More information about the samba-technical mailing list