Just for the record: From a security standpoint you should only allow as few services/daemons as possible access to the password stored in LDAP - encrypted or not. Kopano works perfectly well using LDAP bind - so imho there is no reason to allow Kopano access to the stored password.
[…] the old zarafa client had an online mode that basically worked as a terminal for whatever was stored on the server, KOE/activesync requires all data to be downloaded to the local client first.
This was absolutely great about the old client. It was possible to have a 100GB shared Mailbox for all users that was easily accessible within the office (remote access was not so great) without the need for every single client machine to have a 100GB local copy of the shared mails. Now with Kopano/Activesync every single client PC will store a local copy of those 100GB, which will then also increase the backup storage needed for each of those clients from 30GB (normal Windows Installation) to 130GB (Win10+Mails).
And now if there are synchronsation problems you have to trigger a full resync of the 100GB. Not looking forward to doing this
Summary: everything was better in the old days
(ok, not everything. Mobile use in Outlook with activesync is soooo much better than the old zarafa cached mode)
The fact that there’s no logfile suggests that KOE is not even started. That could be caused by issues with the .Net and/or VSTO runtimes. You might find some additional information in the system event viewer; Outlook log entries sometimes contain an error or similar.
Thanks. But I realized right after, that i had simply forgotten that I had to manually add the “send-as” button, I was so sure that the “send-as” button just automatically appeared once I had configured a “send-as” identity under my Setting. So, in short, all is fine, nothing wrong with Kopano, just my mind.
make the following changes to config.php of webapp
// When using a single-signon system on your webserver, but Kopano Core is on another server
// you can use https to access the Kopano server, and authenticate using an SSL certificate.
test if certificate overrides auth by loging in through webapp and giving wrong password
–> Yes, it is working.
adapt apache vhost
instead of setting up basic auth, I just hardcoded remote_user the following way SetEnv REMOTE_USER "user1"
–> I did the same test. Login with user “user1” is working. There is no “Login-window”.
test if loging still succeeds
-> it does and webapp loads completely.
–> Same for me.
If it weren’t for the fact that you can succesfully login without the basic auth I would say that there is a json parsing error in your users settings. The one way to make sure that this is not the case would be to create a new blank user and try to login with that user.
openSuse repositories: due to a malfunction of our build service we are temporarily not able to provide packages for openSuse 13.2 and 42.2. We will fix this and update the repositories when the underlying cause will be resolved.
Current version of the pre-final repository is 2.3.8beta1+0.