[Kolab-devel] Questions and thoughts about canonification for multiple separate domains

[Mihai Badici]

On Saturday 12 March 2016 08:23:59 Timotheus Pokorra wrote:
> Hello,
> 
> We have had this discussion in the past [1]. There seem to be issues
> with authentication if you are following the HOWTO: Multi-Domain
> Support in Kolab [2].
> 
> Previously I just said that my users should only authenticate with
> their email address, which meant I could disable canonification and it
> worked fine for me. But now we want users to authenticate with just
> their userid which they are used to from a previous system.
> 
> So I had a look at the Howto for multi-domain support.
> It mentions a patch for Cyrus IMAP 2.5 "created by Kolab Systems, and
> submitted and accepted upstream, that allows the parent domain DIT
> root dn to be discovered".
> This patch was first mentioned and published on the cyrus devel
> mailing list [3].
> It has been committed to Cyrus: [4].
> And you can see it [5] as part of the current Cyrus 2.5.7 which is
> shipped with Kolab 16 and Winterfell. (Yay for a not-ahead-of-upstream
> release!!!)
> 
> The next step is to understand how the canonification is supposed to 
work.
> 
> Following the HowTo, the ldap_domain_base_dn "" is misleading. I get
> an error "LDAP search for domain failed: Invalid DN syntax". Jeroen
> suggested to leave it completely empty.
> 
> When I login on domain that is not the primary domain,
> test.test at test1.de, I see this error with journalctl -f -u
> cyrus-imapd:
> Mär 12 07:54:36 55-centos7master.kolab.pokorra.de ptloader[5213]: No
> entries found
> Mär 12 07:54:36 55-centos7master.kolab.pokorra.de imaps[4988]:
> ptload(): bad response from ptloader server: identifier not found
> Mär 12 07:54:36 55-centos7master.kolab.pokorra.de imaps[4988]: 
ptload
> completely failed: unable to canonify identifier: test.test at test1.de
> Mär 12 07:54:36 55-centos7master.kolab.pokorra.de imaps[4988]: SASL
> bad userid authenticated
> 
> I came across this bug [6] and commit [7] with the comment "Set
> inetdomainbasedn attribute value for root dns that are not the same as
> the standard dn for the configured domain name."
> In Kolab Webadmin, there is the setting for a domain: "Custom Root
> DN". This will set the inetDomainBaseDN attribute. So I edit my domain
> test1.de, and set the Custom Root DN to dc=kolab,dc=pokorra,dc=de
> which is the primary domain.
> I can verify this with ldapsearch:
> export pwd=secret
> ldapsearch -D "cn=Directory Manager" -w $pwd -b cn=kolab,cn=config
> and I see:
> # test1.de, kolab, config
> dn: associateddomain=test1.de,cn=kolab,cn=config
> associatedDomain: test1.de
> objectClass: top
> objectClass: domainrelatedobject
> objectClass: inetdomain
> inetDomainBaseDN: dc=kolab,dc=pokorra,dc=de
> 
> It seems, my test user has now disappeared, and now I create a new
> user in that domain test1.de:
> it shows primary address test2.test2 at test1.de before saving.
> After saving, it has the primary email address
> test2.test2 at kolab.pokorra.de, and secondary addresses:
> test2 at test1.de
> test2 at kolab.pokorra.de
> t.test2 at test1.de
> t.test2 at kolab.pokorra.de
> 
> In Roundcube, I can login now with these users:
> test2 at kolab.pokorra.de
> test2 at test1.de
> test2
> 
> When I want to change the password of the user, I get the message:
> "Email address 'test2.test2 at kolab.pokorra.de' not in local domain"
> When I check the users of my primary domain, I can see the test2 user 
there.
> Changing the password there also does not work: "Email address
> 'test2 at test1.de' not in local domain", even though it displays primary
> email address test2.test2 at kolab.pokorra.de
> So I guess that is not how it is supposed to work.
> 
> I also saw this open pull request from Daniel, from February 2015 [8]:
> "When using ldap_domain_* domain discovery the ldap_base variable 
gets
> replaced by the one found in the ldap result, but the variables
> ldap_member_base and ldap_group_base are not getting replaced or
> adjusted"
> Is this in anyway related to canonification?
> 
> Does canonification work for anyone with Kolab 16 or Winterfell for
> multiple domains with separate LDAP trees? Or did someone get it to
> work for Kolab 3.4?
> 
> I am thinking of an alternative, to have a method in our LDAP auth php
> code, that would take the userid, and check all domain trees for this
> userid, and return the domain name to be used as realm. I would call
> this method for Roundcube auth in [9]. For IMAP auth, I would call it
> in pykolab saslauthd [10] through the wap_client.
> Any opinions on this solution?
> 
> Is there an easy way that is just not documented properly?
> 
> Thanks for any help or suggestions,
>   Timotheus
> 

I always wondered what is the practical disadvantage of keeping all data in 
one separate container ( ex dc=kolab)  and create an ou for every 
domain. (ou=mydomain,dc=kolab)
This can eliminate the need of all those workarounds in postfix and cyrus 
search and the access can be limited using proper acl's .









Mihai Badici[1] 

--------
[1] http://mihai.badici.ro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/devel/attachments/20160312/3fbd1280/attachment-0001.html>