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

[Luke Howard]

Andrew,

>My insane idea is as follows:

Out of insane ideas are often borne brilliant ones :-)

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

Well, this is one way to do it, but I'm not sure whether extending
the KDC into a general purpose authentication server is the way that
_I_ would choose to solve this particular problem.

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

Moving to an impersonation model is definitely a good idea, because
you have a single point of authorization. It's a bit trickier under
UNIX but, and ideally your directory server would support the NT
security model, but it is a good start.

In order to use the LDAP server as a reference monitor, the plan
is to extract the client's delegatable credentials at the beginning
of the RPC session, and use them to authenticate to the LDAP server.

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

Microsoft did document it, it's just that you can't use their documentation
to construct an implementation without violating their trade secrets :-)

The FreeDCE project has made some progress on decoding the user data
part of the PAC; the checksums are a bit trickier.

Our model is as such:

- the KDC (currently Heimdal) obtains the unsigned PAC, NDR-encoded,
  from the backend. We extended the hdb_entry ASN.1 definition
  to add an authorization data field.

- the backend, in turn, constructs the PAC by retrieving the principal
  information from LDAP and "pickles" (NDR-encodes) it. The backend
  stores principals' keys in LDAP anyway, so this is a SMOP.

- the KDC generates the server and KDC checksums (the nature of
  this is that it needs to be done in the KDC, not the backend)
  for each blob of NT 5 authorization data in the retrieved principal(*)

- the KDC returns the ticket to the client

(*) in the case of service tickets the KDC just re-signs the
authorization data

-- Luke

--
Luke Howard | lukehoward.com
PADL Software | www.padl.com