Kolab 3.4 Multi-Domain and ptloader

[Brady, Mike]

On 2015-11-22 11:17, Brady, Mike wrote:
> I have a Kolab 3.1/Centos 6 Multi-Domain system that I am in the
> process of migrating to a Kolab 3.4/Centos 7 system and am having some
> problems with ptloader.
> 
> On the 3.1 system ptloader just didn't work on a Multi-Domain system
> and as per the wiki and TBits Multi-Domain scripts I have been running
> successfully for sometime with ptloader disabled.
> 
> I was under the impression that the issues with ptloader and
> Multi-Domain had bee resolved back in 3.3, but doing some testing with
> 3.4 last week suggests otherwise.
> 
> The specific problem that I am seeing is that the ptloader LDAP query,
> as shown in the dirsrv access log, has a "corrupt" ldap_base.  For
> instance I see "dc=example,dc=co,dc=n1" (that is a digit one on the
> end) instead of dc=example,dc=co,dc=nz in the query.  The query
> returns no results and causes ptloader to crash which in turn means
> that the user login fails.  If I disable ptloader as per the 3.1
> system everything seems to work just fine.
> 
> In the log for Cyrus I see
> 
> Nov 20 10:01:55 kolab00 ptloader[13550]: starting: ptloader.c,v 
> git2.5+0
> Nov 20 10:01:55 kolab00 imaplocal[13513]: ptload(): empty response
> from ptloader server
> Nov 20 10:01:55 kolab00 master[13492]: process type:SERVICE
> name:ptloader path:/usr/lib/cyrus-imapd/ptloader age:0.015s pid:13550
> signaled to death by signal 6 (Aborted)
> Nov 20 10:01:55 kolab00 master[13492]: service ptloader/unix pid 13550
> in READY state: terminated abnormally
> Nov 20 10:01:55 kolab00 imaplocal[13513]: ptload completely failed:
> unable to canonify identifier: mbrady at example.co.nz
> Nov 20 10:01:55 kolab00 imaplocal[13513]: SASL bad userid authenticated
> Nov 20 10:01:55 kolab00 imaplocal[13513]: badlogin: localhost [::1]
> PLAIN [SASL(-13): authentication failure: bad userid authenticated]
> 
> In the dirsrv access log I see
> 
> [20/Nov/2015:10:01:55 +1300] conn=858 fd=71 slot=71 connection from ::1 
> to ::1
> [20/Nov/2015:10:01:55 +1300] conn=858 op=0 BIND
> dn="uid=kolab-service,ou=Special Users,dc=example,dc=co,dc=nz"
> method=128 version=3
> [20/Nov/2015:10:01:55 +1300] conn=858 op=0 RESULT err=0 tag=97
> nentries=0 etime=0 dn="uid=kolab-service,ou=special
> users,dc=example,dc=co,dc=nz"
> [20/Nov/2015:10:01:55 +1300] conn=858 op=1 SRCH
> base="ou=People,dc=example,dc=co,dc=nz" scope=2
> filter="(&(objectClass=inetorgperson)(|(uid=mbrady)(mail=mbrady at example.co.nz)(alias=mbrady at example.co.nz)))"
> attrs="displayName mail alias nsRoleDN uid"
> [20/Nov/2015:10:01:55 +1300] conn=858 op=1 RESULT err=0 tag=101
> nentries=1 etime=0 notes=U
> [20/Nov/2015:10:01:55 +1300] conn=859 fd=72 slot=72 connection from ::1 
> to ::1
> [20/Nov/2015:10:01:55 +1300] conn=859 op=0 BIND
> dn="uid=kolab-service,ou=Special Users,dc=example,dc=co,dc=nz"
> method=128 version=3
> [20/Nov/2015:10:01:55 +1300] conn=859 op=0 RESULT err=0 tag=97
> nentries=0 etime=0 dn="uid=kolab-service,ou=special
> users,dc=example,dc=co,dc=nz"
> [20/Nov/2015:10:01:55 +1300] conn=859 op=1 SRCH
> base="cn=kolab,cn=config" scope=2
> filter="(&(objectClass=domainrelatedobject)(associatedDomain=example.co.nz))"
> attrs="associatedDomain inetDomainBaseDN"
> [20/Nov/2015:10:01:55 +1300] conn=859 op=1 RESULT err=0 tag=101
> nentries=1 etime=0
> [20/Nov/2015:10:01:55 +1300] conn=859 op=2 SRCH
> base="dc=example,dc=co,dc=n1" scope=2
> filter="(|(&(|(uid=cyrus-admin)(uid=cyrus-murderzzzz))(uid=mbrady))(&(|(uid=mbrady)(mail=mbrady at example.co.nz)(mail=mbrady@))(objectClass=kolabinetorgperson)))"
> attrs="1.1"
> [20/Nov/2015:10:01:55 +1300] conn=859 op=2 RESULT err=32 tag=101
> nentries=0 etime=0
> [20/Nov/2015:10:01:55 +1300] conn=859 op=-1 fd=72 closed - B1
> [20/Nov/2015:10:01:58 +1300] conn=858 op=2 UNBIND
> [20/Nov/2015:10:01:58 +1300] conn=858 op=2 fd=71 closed - U1
> 
> Note the dc=n1 in the second query. I ran a separate configuration
> file ptloader and put the uid=cyrus-murderzzzz to make sure that I was
> looking at the correct query.
> 
> At first I thought that it must be a configuration mistake on my part
> (wouldn't be the first time), but if it is I can't find it and it is
> only ptloader.  All the other queries look as they should.
> 
> The current Multi-Domain wiki page (
> https://docs.kolab.org/howtos/multi-domain.html) suggests to me that
> Multi-Domain should work with ptloader enabled, but the Kolab 3.4
> TBits Multi-Domain scripts still disable it.
> 
> So to the point of this email.
> 1) Is ptloader supposed to work in a Multi-Domain set up with the
> Kolab 3.4 packages?
> 2) If not, are there newer packages available somewhere that I can try?
> 
> Thanks
> 
> Mike
> _______________________________________________
> users mailing list
> users at lists.kolab.org
> https://lists.kolab.org/mailman/listinfo/users

After a very frustrating day on this, I think that I have found how to 
make it work. But I think that there maybe a bug in there somewhere.

The default set up for the parent domain DIT root dn to be discovered by 
Cyrus IMAP is

ldap_domain_base_dn: cn=kolab,cn=config
ldap_domain_filter: 
(&(objectclass=domainrelatedobject)(associateddomain=%s))
ldap_domain_name_attribute: associatedDomain
ldap_domain_scope: sub
ldap_domain_result_attribute: inetdomainbasedn

But, inetdomainbasedn is not set on any of my systems for any of my 
primary domains.

I am guessing that when this attribute is not set that the base_dn is 
derived some how from the domain name?  On my test system this worked 
without inetdomainbasedn being set, on the production system it doesn't. 
  I have no idea why.

This turned out to be fixable in Kolab Webadmin.  In Kolab 
Webadmin->Domains, for each primary domain, go to the "Other" tab and 
set the "Custom Root DN" to the appropriate base dn.  So for the above 
example "dc=example,dc=co,dc=nz".  This sets the inetdomainbasedn 
attribute.

I can now login with ptloader enabled, which is a major functional 
improvement :-)

I have more testing to do before I declare victory though.

Regards

Mike