Multi-domain setup with Kolab 3.3 on CentOS 7
Sebastian Walter
mail at swalter-it.com
Mon Oct 6 11:16:31 CEST 2014
Hi Conny,
Sorry for the late reply. My config just differs by the
"ldap_domain_base_dn" directive, which is set to "cn=kolab,cn=config"
(without the quotes) in my case.
If I change it to the value from the how-to (like you did), I get the
"invalid dn" errors in the logs (as already mentioned). But still I'm
able to log in to all the domains, so I'm wondering, what is the benefit
of the setting?
Many regards, Sebastian
On 10/01/14 20:11, Cornelius Hald wrote:
> Here are the changes I did based on the default install:
>
> [root at kolab etc]# git diff b4320c010acede8287717ae60da671cb565dc0d5
> imapd.conf
> diff --git a/imapd.conf b/imapd.conf
> index baa330b..b612131 100644
> --- a/imapd.conf
> +++ b/imapd.conf
> @@ -49,3 +49,11 @@ delete_mode: delayed
> expunge_mode: delayed
> flushseenstate: 1
> postuser: shared
> +
> +# Added for multi-domain support
> +ldap_domain_base_dn: ""
> +ldap_domain_filter:
> (&(objectclass=domainrelatedobject)(associateddomain=%s))
> +ldap_domain_name_attribute: associatedDomain
> +ldap_domain_scope: sub
> +ldap_domain_result_attribute: inetdomainbasedn
>
> As I said after that I could only login to the primary domain. After
> changing ldap_domain_base_dn I could log in to both domains.
>
> Well, currently I'm using a version of imapd.conf were canonification is
> disabled completely (like with a kolab < 3.2) setup. That seems to work
> as well.
>
> Now I'm fighting with postfix, but hopefully I'll win soon :)
>
> I'm (kind of) documenting all changes using git and virtualbox
> snapshots. So hopefully later I can do a write-up, documenting all
> needed changes.
>
> Cheers,
> Conny
>
>
>
> On Tue, 2014-09-30 at 16:40 +0200, Sebastian Walter wrote:
>> This error indeed appears in my dirserv log, but I don't see any
>> problems with it (at least the users have not complained yet). I tried
>> to login to both roundcube and webadmin and it works.
>>
>> If you could post your imapd.conf contents (at least the changes) I
>> could compare them with mine...
>>
>> Cheers, Sebastian
>>
>>
>> On 09/30/14 13:42, Cornelius Hald wrote:
>>> Hi Sebastian,
>>>
>>> that's really interesting. So you're not getting errors like this:
>>> conn=29 op=4 SRCH dn="""" authzid="(null)", invalid dn
>>>
>>> Are you on CentOS as well? Maybe your distribution comes with a
>>> different version of Cyrus?
>>>
>>> What puzzles me is that we all use the same Howto but get a broad range
>>> of different results. Well, I'll do some more digging...
>>>
>>> Thanks for the input!
>>> Conny
>>>
>>>
>>> On Tue, 2014-09-30 at 10:17 +0200, Sebastian Walter wrote:
>>>> Hi Conny,
>>>>
>>>> As I'm not using the multi-admin functionality regularly
>>>> (multi-domain/single-admin instead), I'm not 100% sure but I followed
>>>> the multi-domain how-to and everything works as expected.
>>>>
>>>> The secondary domain users are able to login as well. I just tested the
>>>> admin functionality for the secondary domains, too and they are able to
>>>> create users, etc...
>>>>
>>>> Regards,
>>>> Sebastian
>>>>
>>>>
>>>>
>>>>
>>>> On 09/30/14 10:02, Cornelius Hald wrote:
>>>>> On Mon, 2014-09-29 at 20:50 +0000, Daniel Hoffend wrote:
>>>>>>> If follow the steps under 'Cyrus IMAP Changes' for Kolab 3.2 and later,
>>>>>>> I cannot log in to Roundcube with users of my secondary domain. Users
>>>>>> >from the primary domain (the one created during setup) still can log
>>>>>>> in.
>>>>>>>
>>>>>>> However if I'm using the steps described for Kolab 3.1 and older, I'm
>>>>>>> able to login those users.
>>>>>> I've encountered the same problem. IMHO the current Cyrus IMAP 2.5 isn't
>>>>>> fully able to do what roundcube does. It supports domain lookups but it
>>>>>> doesn't support the a replacement for %dc in the member_base_dn
>>>>>> definition.
>>>>>>
>>>>>> I've reported this issue in the cyrus imap bugzilla:
>>>>>> https://bugzilla.cyrusimap.org/show_bug.cgi?id=3860
>>>>>>
>>>>>> For now I would use the Kolab 3.1 way on how to configure cyrus to
>>>>>> support
>>>>>> multi-domain usage.
>>>>>>
>>>>>> P.S.: I'm using Kolab 3.3 in a multi-domain setup with this method.
>>>>> Thanks for the info! So basically my setup now works, but I'll run into
>>>>> trouble regarding group membership?
>>>>>
>>>>> So it looks like the Kolab 3.2 way is still the way to go for Kolab 3.3.
>>>>> Wonder why they wrote the documentation like it is now.
>>>>>
>>>>> Thanks!
>>>>> Conny
>>>>>
>>>>>
More information about the users
mailing list