ActiveSync credential separation and disabled users

[Onno Hensgen]

>> 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?

My plan was to block all ports except the proxied ones.
Nice hint spawning another imap process. I added an additional imapd service to the cyrus.conf, which allows plaintext login but only listens on localhost on a different port.

My activeSync disable/enable functionality could be up and running now with the nginx proxy, but:
I made a fresh install of kolab since I checked ActiveSync the last time and with my new system, it doesn't seem to work out of the box (with debian, it did somehow) - and especially I can not find any logfiles (even after adding activesync_debug to main.inc.php). I left the whole activeSync/roundcube stuff untouched and imap is working properly. Where can I look for logs or something?
When I try to access ActiveSync with a browser, I get the basic login screen, but credentials are never accepted.


About the external IMAP/SMTP stuff:
NGINX missing SSL to backend and especially not passing SMTP AUTH through to the backend sucks. One has to decide to either proxy SMTP to port 25 missing the additional security with submission port you described in (http://www.kolab.org/blog/vanmeeuwen/2012/12/06/why-kolab-groupware-uses-submission) checks or the submission port must be exposed to the WWW for all users, which is the lesser evil in my opinion because there is not much information gain with only smtps from outside.

I am thinking about another solution for the function to disable/enable external imap users (without murder setup):
Can the user_deny.db stuff somehow be connected to the LDAP tree? Because then it would be possible to spawn another imap daemon and define explicitly, which user can or cannot access.
It's really too bad, that the ldap_filter doesn't get an IP passed. As an alternative, user_deny.db could be used with sql, at least I saw that sql is an option in the docs. But I found zero examples for that...


Kind regards,
Onno