[Kolab-devel] Integration of Kolab2 and Samba

Ingo Steuwer steuwer at univention.de
Wed Jun 13 21:53:50 CEST 2007


Am Dienstag, 12. Juni 2007 22:48 schrieb Martin Konold:
> Am Montag 11 Juni 2007 schrieb Ingo Steuwer:
>
> Hi Ingo,
>
> > Don't underestimate the complexity of a minimal integration. A complex
> > point are passwords: samba (or better: CIFS) needs by design it's owne t
> > hashes, so new users in Kolab nedd those hashes as well as samba has to
> > change the userpasswd if a Domain User changes its password against
> > samba. You also have to cover unique SIDs for the also needed
> > Posix-Accounts (G)IDs and primary-group-memberships. You can't cover this
> > with a "rule-based-engine" mentioned previous.
>
> I guess that your company has a lot of experience integrating Samba and
> Kolab.

mhm, think so ;)

> On the other hand I am wondering if the issues are solvable.
>
> I propose to try to solve one after the other.

just my "2 cent":

> 1. Password issues
>
> 1.1. Problem description
>
> Samba/CIFS uses its own hashes to store the user password in LDAP.
>
> 1.2 Possible solution
>
> Kolab with Samba integrated uses exclusivly Samba as a backend for
> authentification. Basically this means that SASL is not using LDAP directly
> but Samba as a backend.

Don't forget postfix which AFAIK doesn't use SASL.

> 2. SID/UID/GID Mapping issues
>
> 2.1. Problem description
>
> Samba uses the Windows concept of Security Identifiers (SID) instead of the
> Unix UID and GID. The later used to be 16bit unsigned integers and are now
> extended to 32bit unsigned integers in more recent incarnations of POSIX
> operating systems. SIDs are much longer (up to 512 bytes instead of only
> 2/4 bytes).

Samba uses both SID and UID/GID as it needs an underlying POSIX-user for each 
samba-user. This is because samba relies on the filesystem for file access 
control, which knows nothing about SIDs. Bu you may use windbind for 
automated mapping, but it may be more complex than map it by yourself.

> It is impossible to create an algorithmic bidirectional mapping between
> UID/GID and SIDs.
> Therefore Samba uses dynamically maintained maps as a workaround. This
> situation is suboptimal and causes many problems.

-> winbind.

> From looking at such a 16/32bit number it is not possible to decide if it
> is a UID or a GID.
>
> On the other hand SIDs are much more expressive and selfdescribing. When
> looking at a SID you can immediately determine if it is a user or a group.

Mhm, you need at least to search for it in LDAP, AFAIK the number alone 
follows now convention.

> In contrast to the limited UID/GID concept SIDs are _globally_ unique!
>
> 2.2. Possible solution
>
> Make Kolab totally independent from UID/GID concept. Actually the number of
> places where UID/GID is used in Kolab is very limited and not really
> needed.

This would make Kolab totally unusable in Linux-desktop szenarios which want 
to authenticate against LDAP...

Regards
Ingo Steuwer

>
> Regards,
> -- martin konold

-- 
Ingo Steuwer           Projektmanagement        steuwer at univention.de
Univention GmbH        Linux for your Business  fon: +49 421 22 232-43
Mary-Somerville-Str.1  28359 Bremen             fax: +49 421 22 232-99
                       http://www.univention.de




More information about the devel mailing list