Crazy ideas about Kerberos, NTLM and PACs... (was NTLMSSP...)
lukeh at PADL.COM
Mon Nov 19 00:19:35 GMT 2001
>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
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
Luke Howard | lukehoward.com
PADL Software | www.padl.com
More information about the samba-technical