[Kolab-devel] kolab_setup (part of Kolab bootstrap rewrite)

[Buchan Milne]

On Tue, 23 Mar 2004, Martin Konold wrote:

> Am Dienstag, 23. März 2004 13:32 schrieb Buchan Milne:
> 
> Hi,
> 
> > On Tue, 23 Mar 2004, Martin Konold wrote:
> 
> > > Description Architecture:
> > > http://kroupware.kde.org/administration-1.0-html/c24.html
> 
> > > Description of Maintainer:
> > > 	http://kroupware.kde.org/administration-1.0-html/x122.html
> 
> > > Description of Administrator:
> > > 	http://kroupware.kde.org/administration-1.0-html/x181.html
> 
> > > Last but not least there is the manager account. In contrast to the above
> > > groups (Maintainers and Adminitrators) there is only a single manager.
> 
> > My issue with this is that it needlessly pollutes the root of the LDAP
> > tree ..
> 
> Please explain. I don't understand how the above descriptions refer to you 
> point.
> 

Well, it may not be covered in the guide, but the bootstrap creates 
cn=admin,$suffix and k=kolab,$suffix, whereas it may be that a cn=admin 
exists as a group, which (assuming oe day Kolab cohabitates well with 
samba/posixaccount stuff) may already exist in an ou (ou=Group,$suffix). 
And it seems there is no reason cn=admin needs to be in suffix instead of 
an ou.

> > BTW, I have a nice set of ACLs for samba/posix (allowing samba DCs to
> > create user accounts, groups and group mappings, so allowing the use of
> > User Manager for Domains) and allowing user accounts to create shared
> > contacts, using regex-based ACLs, such as:
> 
> This is interesting. Is there also a compatible User Manager for people not 
> running Windows?
> 

Not a native client, but I think lam (lam.sourceforge.net) can manage 
group mappings directly in LDAP (with the Windows tool, it talks via RPCs 
to samba, which runs scripts - smbldap-tools - to make the mods in LDAP 
and some changes samba does on it's own)).

> > acess to dn="^(.*,)?ou=Contacts,(dc=.+,?)+$$"
> >         attrs=children,entry,inetOrgPerson
> >         by dn="uid=.*,ou=People,$2" write
> >         by * read
> >
> > I think this is a better approach as it would allow multi-domain support
> > on one LDAP tree more easily.
> 
> multi-domain is still subject to research from my side.
> 

But something that really needs to work to provide a real alternative to 
Exchange 2000/AD (especially relating to delagation of account 
management).

Regards,
Buchan