ActiveSync credential separation and disabled users

[Jeroen van Meeuwen (Kolab Systems)]

On 2013-02-09 20:34, Onno Hensgen wrote:
>> If the use-case is a hosted environment where individuals only get
>> their own basic @hotmail.com-style mailbox (and no sharing folders
>> between users is required), then an NGINX proxy in front of a bunch 
>> of
>> standalone IMAP servers would do the trick.
>> 
>> If the use-case is to host all employee's mailboxes for a large
>> organization, it is clear that one Cyrus IMAP server may not suffice.
>> But, since one employee should be able to share its folders with any
>> other employee, and since that other employee very likely has its
>> mailbox on a different Cyrus IMAP server, one would need to run a 
>> Cyrus
>> IMAP Murder (of any kind of topology) in order to make sure that the
>> client IMAP connection is proxied to the IMAP server that the 
>> targeted
>> folder resides on (and not merely the IMAP server the user's INBOX
>> resides on).
> 
> I played the last day with NGINX and found out, it allows to define
> the imap server to use on a per-user basis. You can use an attribute
> like the mailHost in the ldap directory to choose the correct server.
> But as far as I understand, that only allows to transparently scale
> horizontal but still no sharing folders between servers, right?
> 

You're right, it does not proxy to the mailserver of the mailbox being 
selected. You could, though, run a unified murder topology and have the 
IMAP server itself proxy the connection through to the correct server 
for the IMAP folder selected.

> If one can live with the disadvantages (we for example won't need to
> scale for a long time, we have 25 users right now...), I found the
> NGINX stuff pretty straight forward to configure.
> On the other hand I never tried the Cyrus Murder deployment. But as 
> far as I can tell, the
> charm of the NGINX solution for me is, that I do not have to touch the
> existing imap server in any way to achieve what I want.
> 

That, of course, is entirely reasonable and also the most 
straight-forward solution.

>> (&(objectClass=kolabInetOrgPerson)(nsRoleDn=cn=external-imap-user,dc=example,dc=org))
>> 
>> I think the means to achieve what you want are readily available in 
>> the
>> form of roles.
> 
> Nice! Thats much easier and I can configure with the kolab-webadmin. 
> Thanks!
> 

You're welcome!

>> I would definitely appreciate your notes and thoughts!
> 
> I started a documentation on my progress and published it here for
> now. I also wrote a bit about our use-case and deployment.
> 
> https://server.hensgen.net/docs/Kolab3-nginx
> 

Thanks, I've saved it locally and I'll see what I can do with this 
during my travel tomorrow.

>>>> Said IMAP frontend(s) - you would hit these specifically from the
>>>> ActiveSync web-servers only - can use a different LDAP attribute
>>>> (than
>>>> userPassword) using a fast_bind(), or not use LDAP at all (and
>>>> instead
>>>> do sasldb2, or SQL, or ...).
> 
> The IMAP proxy works now and respects the user roles. I'm searching
> how I can tell syncroton to use that imap proxy (same host, different
> port). I found some stuff in /usr/share/kolab-syncroton, but the
> config files are shared with roundcube mail. So is it safe to use an
> actual copy of the config and change
> 
>     $rcmail_config['default_port'] = 143;
> 
> in main.inc.php?
> 

That, or supply a main.inc.php to syncroton that 
@include_once('/etc/roundcubemail/main.inc.php');, then override the 
settings you need.

Also worth noting is that the actual host being used is a per-user 
setting - see the imap_host column of the roundcubemail.users table. In 
a more distributed fashion, you would spoof 'imap.domain.tld' to point 
to 'nginx-frontend.domain.tld' by means of split DNS / /etc/hosts.

> Or is there a more elegant way?
> 

Other then;

- making the system multi-homed,
- spawning imapd processes on different bind addresses (see 
/etc/cyrus.conf), and
- with different configuration to allow for the authentication to occur 
in plaintext (-C /etc/imapd-plaintext.conf),
- configuring nginx to use a.b.c.d:143 while the world uses the 
z.y.x.w:143/993,

there isn't much more of an elegant way, yet, I'm afraid. I take it you 
are blocking regular users from using port 143 for IMAP access in order 
to prevent plaintext credentials going over the wire without transport 
layer security?

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08