[Samba] One User, One Ldap, Multiple Domains

[David Barker]

Andrew Bartlett wrote:

> On Mon, 2005-05-23 at 16:23 +0100, David Barker wrote:
> 
> 
>> Looking through the ldapsam stuff, it looks like in samba 3 a user
>> can only be a member of one domain at a time in an ldap tree.
>> 
>> attributetype ( 1.3.6.1.4.1.7165.2.1.20 NAME 'sambaSID' DESC
>> 'Security ID' EQUALITY caseIgnoreIA5Match SYNTAX
>> 1.3.6.1.4.1.1466.115.121.1.26{64} SINGLE-VALUE )
>> 
>> Does anyone know if it's safe to drop SINGLE-VALUE from sambaSid,
>> to allow one user to be in two domains at once?
>> 
>> 
> 
> The idea was (it didn't really work out as well as I would have
> liked) to have sambaSID be the unique identifier for objects in the
> ldap tree (for finding them when clients ask 'what is this sid'
> questions).
> 
> 
ahha :-)

> Why do you think you need multiple domains on one LDAP tree?
> 
> 

	For what we currently use samba for, we don't need multiple domains. We 
have created one domain using samba 2.2.x for the 22,000+ registered 
users in the central LDAP, all of which are able to login to various 
public PC's in places like our main library.

	Departments & schools in the university would like to provide desktop 
authentication, printing and shared filespace for windows desktops in 
their areas. The traditional way of doing this would be trusted domains, 
but our single big domain is too unwieldy for this - the PDC is simply 
too slow at listing all users to a windows desktop for the purpose of 
building up ACL's, etc.

	With a samba 2 schema, trusted departments could create their own 
domain with a subset of users using LDAP filters.

e.g. A domain that would only work with staff from a department could be
created with:

passdb backend = tdbsam , ldapsam_compat:ldap://ldapserver/
ldap filter = (&(uid=%u)(exeterStatus=Staff)(department="My Department"))

	We would be happy to stay with a samba 2 schema & let departments do 
this, but:

a) In the Samba how-to Chapter 10, ldapsam_compat is described as "This
option is provided primarily as a migration tool, although there is no
reason to force migration at this time. This tool will eventually be
deprecated." - This doesn't sound like it will be around forever ;-)

b) We are going to be missing out on fun things like 
"ldapsam:trusted=yes" by staying with ldapsam_compat

	I have considered multiple syncronised directories, once for each 
department using a samba 3 schema to handle the different sids, but this 
isn't possible for the number of departments we have.

	I suspect most of this will go away with samba 4 - creating a
separate samba 4 directory, and keeping it in sync with the central ldap
directory should provide enough delegation based on OU membership in an
AD'esq environment that we should be ok. :-)


Comments & thoughts would be welcomed! :-)