NTLMSSP/GSSAPI and Heimdal, the new NTLMSSP interface

[Luke Howard]

Hi Andrew,

>So, what I want to so is to put the Samba passwords into the Kerberos
>database, and add a mechanism whereby the kerberos server keeps both
>passwords, and gains a trivial replacement for srv_netlogon_nt.c.  

Interesting idea. You can use the encryption type defined in
draft-brezak-win2k-krb-rc4-hmac-03.txt to retrieve NT hashes from
the KDC. You would need to define another string to key function
for LM hashes. 

Here is how I've got around the keeping-passwords-in-sync thing
for our XAD project:

- implemented a password notification plugin for Heimdal
  which will update the user's LM hash (dBCSPwd) and
  OpenLDAP password (userPassword) when a password is changed
  via the kpasswd protocol

- in the SAM server, update the NT hash using the kadm5
  library, and the other passwords in LDAP directly

We also store the encoded ASN.1 Kerberos keys in LDAP, so there
is a single repository for passwords even if there is some
redundancy. Thus the SAM server can decode the ASN.1, check
the key type, and (if RC4-HMAC) extract the NT hash.

Anyway, what does this have to do with GSS-API? Not much.
GSS-API deals with network authentication: initializing your
credentials cache and changing passwords is outside its
scope.

>I'm thinking that it should just be a normal kerberos authenticated &
>encrypted connection, and it should just take in challange-response pair
>and spit out the session keys and a basic status code.

Well, you can always retrieve the keys directly from the KDC 
using the kadm5 or HDB API.

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