Clarification regarding Samba 3.x and Heimdal integration

[Vinayak Hegde]

Andrew,
 thanks for the clarifications.

Regards,
Vinayak

>>> 
From: Andrew Bartlett <abartlet at samba.org>
To:Vinayak Hegde <hvinayak at novell.com>
Date: 11/07/05 4:57 pm
Subject: Re: Clarification regarding Samba 3.x and Heimdal integration
CC:<samba-technical at samba.org>, Lars Mueller <lmuelle at suse.de>
On Sun, 2005-11-06 at 22:59 -0700, Vinayak Hegde wrote:
> Hi Andrew,
>  Now that the LDAP back-end for MIT Kerberos is almost ready, I
would
> like to work on the integration of Samba 3.x and MIT Kerberos.
> In that respect, I have studied how Heimdal is integrated with Samba
> and following is my understanding. Please correct me if anything is
> incorrect:

This looks pretty much correct.

> ======  Summary of Samba 3.x and Heimdal Integration  START =====
> 
> The integration of Samba and Heimdal with OpenLDAP as the database
> back-end is mainly to use the Samba account password, if present on
the
> Directory Tree, by the Heimdal Kerberos.
> 
> If the object is comprising of sambaSamAccount class, it is a samba
> account and if it is having a krb5KDCEntry class, then it is a
Heimdal
> entry.
> Samba user's account will mandatorily have uid as one of the
attributes
> and sambaNTPassword as optinal (will have no value if smb password
is
> not set) attribute.
> 
> The following are the mapped attributes that Heimdal principal uses
> from the samba account:
> krb5PrincipalName  <-->  uid
> krb5ValidEnd       <-->  sambaKickoffTime
> krb5PassowrdEnd    <-->  sambaPwdMustChange
> krb5Key (rc4-hmac-md5 = 23) <-->  sambaNTPassword
> 
> for eg, if uid=sambauser1, then the derived krbprincname will be
> sambauser1 at REALM1.
> 
> While storing the kerberos keys in Heimdal, the following logic is
> used:
> a. convert the given password to key (str2key)
> b. if the entry is a samba account and the encryption type is 23
> (rc4-hmac-md5), then
>      b.1 convert the key to hex format
>      b.2 store that hex value in sambaNTPassword attribute (Replace)
>      b.3 delete the sambaLMPassword attribute value (most probably,
> this is done to indicate samba code that the passwd has been
changed)

We could generate an LM hash, but it would be incorrect to leave it
alone.  With the code structure, it was easiest to delete it.

>    else
>      store the key into krb5Key attribute of the entry
> 
> A reverse logic is applied for reading the key from the LDAP store.
> 
> In summary, If the supported enctype is 23, then if entry is the
samba
> account, then use sambaNTPassword to store/get the information.
> 
> ======  Summary of Samba 3.x and Heimdal Integration  END =====
> 
> 
> I did not get how Heimdal honours the Samba login and account
policies?
> Which are the attributes are involved in that?
> Could you please explain me about that in more detail?

This is where things get more painful.  Basically, the Heimdal support
is incomplete.  A complete solution would do all the work that
auth_sam
does in the account_ok() routine.  Allowed-workstations makes no
sense,
and logon hours is dodgy for kerberos, which leaves only bad password
counts.  Heimdal isn't setup for that kind of lockout, so it was
omitted.   I am working in Samba4 to allow that kind of lockout, by
the
addition of further hdb hooks.

Andrew Bartlett

-- 
Andrew Bartlett                               
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net