design for storing trusted domain passwords in ldap

[Rafal Szczesniak]

On Wed, Jan 17, 2007 at 02:51:06PM +0100, Michael Adam wrote:
> Hi,
> 
> Volker committed my patch of adding trusted domain functions
> ({get,set,del}-trusteddom-pw and enum-trusteddoms) to pdb_interface.
> Now as a next step I want to add implementations of these
> functions to pdb_ldap, thus allowing for distribution of trusted
> domain passwords from pdc to bdcs.
> 
> This rises a design question I would like to have some opinions
> about before proceeding to far.
> 
> There is already an object class 'sambaTrustPassword', that is
> currently unused and is commented as "Trust password for trust
> relationships (any kind)". The definition is as follows:
> 
> objectclass ( 1.3.6.1.4.1.7165.2.2.14 NAME 'sambaTrustPassword' SUP top STRUCTURAL
>         DESC 'Samba Trust Password'
>         MUST ( sambaDomainName $ sambaNTPassword $ sambaTrustFlags )
>         MAY ( sambaSID $ sambaPwdLastSet ))
> 
> I think it is definitely a good idea to have the trusted domain
> passwords as objects of their own (as opposed to having them
> attached to the sambaDomain as attributes).

I remember it was the original idea, to store trust password in passdb
backend (ldap, among others), but I don't remember the reason why
it was left in secrets.tdb. I'm glad the idea returned :)

> I would have the SID of the trusted domain as a mandatory
> attribute. 
> I don't see a use for sambaTrustFlags here.

I believe it was thought as a way of telling interdomain trust password
from domain (membership) trust password. Since these two have a little
chance of coexist at the same time, this design was also discarded in
favour of storing passwords under different keys in .tdb file. Although,
I thought the design with password flag telling the relationship type
was more generic.

> Furthermore, it might be useful to have the own domain name as 
> an attribute in addition to the trusted domain name, thus 
> facilitating searches. 

Agreed.

> This would result in the following addition to the samba schema:
> 
> attributetype ( 1.3.6.1.4.1.7165.2.1.68 NAME 'sambaTrustedDomainName'
>         DESC 'Windows NT domain which the own domain trusts'
>         EQUALITY caseIgnoreMatch
>         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
> 
> ##
> ## Trust password for trusted domains
> ##
> objectclass ( 1.3.6.1.4.1.7165.2.2.15 NAME 'sambaTrustedDomainPassword' SUP top STRUCTURAL
>         DESC 'Samba Trusted Domain Password'
>         MUST ( sambaDomainName $
>                sambaTrustedDomainName $ sambaSID $
>                sambaNTPassword )
>         MAY ( sambaPwdLastSet ))
> 
> Attached, find a patch with these changes to the schema file.
> 
> Are there any opinions about this?

As I said, I'm glad the idea returned. I worked on this code :)


cheers,
-- 
Rafal Szczesniak
Samba Team member  http://www.samba.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.samba.org/archive/samba-technical/attachments/20070117/97a6c331/attachment.bin