Schlagwort: kopano

Installation: Kopano der „neue“ Stern am Groupwarehimmel – Teil 3

11 Kommentare

Und weiter gehts… Teil 1 und Teil 2 der Kopanoinstallation sollten erledigt sein. Aktuell sind die Verbindungen, die zu Kopano aufgebaut werden noch nicht verschlüsselt, da das http-Protokoll verwendet wird.

Dies bedeutet, dass sämtliche Passwörter im Klartext über die Leitung gehen. Sehr unschön und deshalb unbedingt zu beheben!

SSL-Zertifikat

Für die Verschlüsselung der Verbindung, benötigt man ein SSL-Zertifikat. Variante 1 wäre, sich ein solches Zertifikat selbst zu erstellen. Variante 2 wäre, ein Zertifikat zu kaufen.

Variante 1 (self-signed): Kostet nichts, jedoch werden Internetbrowser und andere Endgeräte beim Verbindungsaufbau meckern.

Ein solches Zertifikat wird so zusammengebaut:

openssl genrsa -des3 -passout pass:x -out kopano.pass.key 4096
openssl rsa -passin pass:x -in kopano.pass.key -out kopano.key
rm kopano.pass.key
openssl req -new -key kopano.key -out kopano.csr

Nach Eingabe des letzten Befehles, werden einige Details abgefragt. Am Wichtigsten ist die Frage nach dem common name dieser MUSS entsprechend dem FQDN des Servers  befüllt werden, auf dem Kopano läuft.

Und nochmals in die Konsole:

openssl x509 -req -days 1095 -in kopano.csr -signkey kopano.key -out kopano.crt

Das .key-File und das .crt-File werden anschließend in die dafür vorgesehenen Ordner verschoben.

mv kopano.crt /etc/ssl/certs

 

mv kopano.key /etc/ssl/private

Apache ssl aktivieren

Kurz und schmerzlos.

a2enmod ssl
service apache2 restart
service apache2 status

vHost anpassen

Kopano + Postfix werden exklusiv auf meinem Server betrieben (es läuft sonst kein vHost). Die Konfiguration findet deshalb direkt in der /etc/apache2/sites-available/000-default.conf statt.

Grundsätzlich leite ich alle Anfragen die auf Port 80 an den Server gerichtet werden auf die HTTPS-Seite um.

Innerhalb des *.80er Virtualhost-Eintrags, richte ich eine permanente Umleitung ein:

Redirect / https://<FQDN Kopano Server>/

Danach erstelle ich im File 000-default.conf einen weiteren vHost. Dieser ist für die SSL Anfragen zuständig:

<Virtualhost *:443>
ServerName <FQDN Kopano Server>
ServerAdmin hostmaster@domain
DocumentRoot /var/www/html

 

#SSL Zertifikate
SSLEngine on
SSLCertificateFile /etc/ssl/certs/kopano.crt
SSLCertificateKeyFile /etc/ssl/private/kopano.key

 

#SSL Logging
LogLevel info ssl:warn
ErrorLog ${APACHE_LOG_DIR}/kopano_ssl_error.log
CustomLog ${APACHE_LOG_DIR}/kopano_ssl_access.log combined
</VirtualHost>

Apacheserver neu starten…

service apache2 restart

SSL-Check

Es ist an der Zeit, den URL https//:<FQDN>/webapp aufzurufen. Ist das Zertifikat self-signed, wird der Browser eine Fehlermeldung ausgeben. (Es muss eine Ausnahme erstellt werden).

Wie im Screenshot leicht erkennbar ist, wird ein Zertifikatsfehler angezeigt (hier im IE). Dieser Fehler wird durch das self-signed Zertifikat ausgelöst. Die Verbindung ist dennoch verschlüsselt!

SSL-Variante 2 – Ein Zertifikat von einer CA kaufen. Die Implementierung eines gekauften SSL Zertifikates, läuft im Großen und Ganzen gleich ab, wie bei Einbindung eines self-signed Zertifikates.

Gegebenenfalls muss jedoch noch ein Rootzertifikat eingebunden werden, dass von der jeweiligen CA bezogen werden kann.

Bsp:

SSLCaCertificateFile /etc/ssl/certs/RootZertifikat.crt

Ich empfehle hier bewusst keine CA (Zertifizierungsstelle). Bitte googeln.

SSL Done! 😉

Deskapp im Einsatz

Die Standarddeskapplikaton für Emails unter MS Betriebssystemen ist Outlook. Im Arbeitsalltag ist dies (leider) annähernd selbstverständlich.

Hierbei scheint ein funktionierendes „Senden an… -> Emailempfänger“ das absolute Killerkriterium zu sein. (Zumindest meiner Erfahrung nach).

Wenn man „seinerzeit“ Zarafa mit Hilfe der Webapp verwendete und keinen Emailclient einsetzen wollte, gab es dieses Feature einfach nicht.

Aber…

Mit Kopano kam die Deskapp. Die Deskapp ist genaugenommen ein adaptierter Chromium Browser, der sämtliche Funktionen der Webapp beinhaltet.

Der Clou dabei? — „Senden an Emailempfänger“ funktioniert damit!

Bye Bye liebe Standard-Mailclients!

Download /  Einrichtung / Start der Deskapp

Wie alle anderen Komponenten auch, kann die Deskapp von https://download.kopano.io/community auf den Rechner gezogen werden.

Nach Installation und Aufruf der Deskapp, muss ein neues Profil angelegt werden.

Deskapp up and running…

Definiert als Standard-Mail-App

Kopano-Files (Einbindung Cloudspeicher)

Herunterladen und entpacken des Modules:

cd /tmp
wget https://download.kopano.io/community/files:/files-2.1.0.74-Debian_8.0-amd64.tar.gz

 

tar xvfz *.tar.gz
cd files-2.1.0.74-Debian_8.0-amd64/
dpkg -i *.deb
apt-get -f install
dpkg -i *.deb

Falls man in der Webapp angemeldet ist, bitte abmelden und erneut anmelden, damit das Modul aktiv wird. (Es sollte im oberen Bereich – blaue Leiste – mit Namen FILES aufscheinen).

Über das Menü: Einstellungen -> Files (+ Add Account), kann ein Account (z.B. von Nextcloud) eingebunden werden.

Status OK

Clouddrive eingebunden

Z-Push

Sicher kein „Unbekannter“ für Zarafauser. Z-push sorgt dafür, dass die Groupwaredaten den Weg auf das Smartphone finden. Um dies zu bewerkstelligen, emuiert es das ActiveSync Protokoll. (Und das macht es extrem gut.)

Ich gehe hier nicht auf jeden Schritt ein, da die Doku von Kopano wirklich alles abdeckt, was das z-push-Herz begehrt.

Wichtig ist u.a. folgende Info:

To encrypt data between the mobile devices and the server, it’s required to enable SSL support in the web server.

Keep in mind that some mobile devices require an official SSL certificate and don’t work with self signed certificates. For Windows Phone and Windows Mobile you might need to install the certificates on the device

Heißt soviel wie:

  • Verschlüsselte Verbindungen benötigen SSL Support (erledigt)
  • Das SSL-Zertifikat sollte ein offiziell anerkanntes SSL Zertifikat sein, da es u.U. zu Problemen mit z-push kommen kann, wenn man ein self-signed Zertifikat verwendet. (die Konfiguration in diesem Artikel, verwendet ein self-signed Zertifikat.)
  • Windows Phone / Mobile Nutzer müssen das Zertifikat eventuell auf dem Mobilgerät installieren, damit es funktioniert.
  • Mit einem offiziellen SSL-Zertifikat, gibt es keine Probleme mit z-push

Mobile Device Management (mdm)

Das letzte Modul, das ich kurz besprechen möchte ist das „Mobile Device Management“ – kurz mdm. Mittlerweile sollte klar sein, dass man das komprimierte File wieder über https://download.kopano.io/community/ beziehen kann.

Der Installationsvorgang ist bitte ebenso – wie bereits bekannt – zu vollziehen.

cd /tmp
wget https://download.kopano.io/community/mdm:/mdm-2.1.0.20_16-Debian_8.0-all.tar.gz
tar xvfz mdm-2.1.0.20_16-Debian_8.0-all.tar.gz

cd mdm-2.1.0.20_16-Debian_8.0-all
dpkg -i *.deb
apt-get -f install
dpkg -i *.deb

Konfiguration

Die zu erledigenden Anpassungen, halten sich sehr stark in Grenzen.

vim /etc/kopano/webapp/config-mdm.php

Die Datei sollte nach der Anpassung so aussehen, wobei der Wert des PLUGIN_MDM_SERVER dem FQDN des Kopanoservers entsprechen muss. (mit localhost bzw. 127.0.0.1 hat es bei mir nicht funktioniert).

Verwendung

In der Webapp -> Menü Einstellungen -> MDM, sollten spätestens nach einem Klick auf den Button „Refresh“ alle Geräte / Programme aufscheinen, die per z-push mit dem Server (Mailkonto) synchronisieren.

Mit mdm kann somit per Webapp Einfluß auf die Devicesynchronisierung genommen werden.

Schlussworte

Ich hoffe, ich konnte mit meinen 3 Artikeln zum Thema „Kopano“ einen kleinen Einblick in die Leistungsfähigkeit dieser Groupwarelösung bieten, obwohl ich nicht alle der vorhandenen Module besprochen habe.

Vielen Dank für das Interesse!

Hier gehts zu Teil 1 …

 

 

 

Installation: Kopano – der „neue“ Stern am Groupwarehimmel – Teil 2 (MTA Installation)

20 Kommentare

In Teil 1 meiner Kopanoartikelserie wurde (hoffentlich) klar, dass die Installation im Grunde genommen kein Hexenwerk ist. Kopano läuft, die Komponenten funktionieren. Aber… Ohne einen MTA  – wie zum Beispiel Postfix –  macht eine Groupware keinen Spaß!

Ziel dieses Artikels ist es, die Mailfunktionalität in Kopano zu implementieren. Damit man die Mailaccounts nicht separat anlegen muss, erhält der MTA die benötigten Daten aus der Kopanodatenbank. (= primäre Mailadresse).

Schließlich werden noch ein paar Mechanismen zur Spamabwehr eingebaut.

Dazu kommen wir jedoch später!

Kopanobenutzer, Postfix, Mailadressen… wie passt das zusammen?

Ist man Teil 1 gefolgt, befindet sich zur Zeit ein Benutzer in der Kopanodatenbank. (Benutzername: gestl, Emailadresse: daniel.gestl@it-yourself.at). Nun muss noch ein MTA her, der die Emailkommunikation übernimmt und ankommende Emails an Kopano weitergibt.

Kopano dagent

Die Kommunikationsschnittstelle zwischen dem MTA (z.B. Postfix) und Kopano bildet der sogenannte Kopano-dagent. Er „wartet“ auf eingehende Verbindungen vom MTA. Der Datenaustausch erfolgt über das LMTP (Local Mail Transfer Protocol.)

In der Standardkonfiguration, verwendet dagent den Port 2003 und wartet auf einen Verbindungsaufbau.

Die Konfiguration von dagent, kann in der Datei:

/etc/kopano/dagent.cfg

angepasst werden. Will man die Standardkonfiguration übernehmen, ist in dieser Datei jedoch nichts zu tun.

Muss es Postfix sein?

Nein, muss es nicht. Kopano ist vollkommen modular aufgebaut. Dies gilt nicht nur für die Kopanokomponenten, sondern auch für annähernd alle Komponenten, mit denen Kopano interagiert.

Da Postfix aber einfach cool ist, darf es hier auch mitspielen. 😉

Details zur Posfixkonfiguration

Postfix soll „Final Destination“ für die Emaildomain sein. Ich verwende die Domain it-yourself.at.

Sämtliche Änderungen müssen bitte in der

/etc/postfix/main.cf

vorgenommen werden.

Auskunftssperre für Postfix

Der MTA soll nich all zu viel über sich ausplaudern.

smtpd_banner = $myhostname ESMTP

Virtuelle Domains, Benutzer und Aliase

Die verwendeten Benutzerdaten sollen von Postfix als „virtual“ gehandelt werden. Wir arbeiten nicht mit lokal angelegten Benutzern!

Nicht vergessen: Die Userdaten sollen aus der Kopanodatenbank ausgelesen werden.

Unter Berücksichtigung oben erwähnter Eckdaten, wird  die Postfixkonfiguration angepasst:

virtual_alias_maps = hash:/etc/postfix/virtual
virtual_mailbox_maps = mysql:/etc/postfix/mysql-users.cf
virtual_transport = lmtp:[localhost]:2003
virtual_mailbox_domains = it-yourself.at

Danke für den Tipp betreffend [localhost]@Jörg!

 

virtual_alias_maps: Die Aliasadressen sind in dieser Konfiguraton in einer Datei zu hinterlegen. Die Datei kann so aussehen (/etc/postfix/virtual):

Nachdem die Datei gespeichert wurde, muss sie für Postfix lesbar gemacht werden:

postmap /etc/postfix/virtual

virtual_mailbox_maps: Der Dreh- und Angelpunkt! Hier wird definiert, woher Postfix die Primärmailadresse bezieht.

Der Wert mysql:/etc/postfix/mysql-users.cf verweist auf eine Datei (mysql-users.cf), in der eine MySQL-Abfrage definiert ist, die die Mailadresse aus der Kopanodatenbank ausliest.

Ebenso in der Datei zu hinterlegen, sind die MySQL-Logindaten für die Kopano-MySQL-Datenbank, da sich Postfix sonst nicht mit der Datenbank verbinden und die Abfrage ausführen kann.

 

user = kopano_usr
password = geheimespasswort
hosts = 127.0.0.1
dbname = kopano_db
query = SELECT value FROM objectproperty where propname = ‚emailaddress‘ and value = ‚%s‘;

Der Datei mysql-users.cf sollten aus Sicherheitsgründen die Rechte „600“ gesetzt werden. User und Gruppe auf root setzen!

chmod 600 /etc/postfix/mysql-users.cf

chown root:root /etc/postfix/mysql-users.cf

Danke für den Hinweis @ Heinz!

 

Was bedeutet %s in der Abfrage?

Dieser Platzhalter wird von Postfix automatisch mit der Empfängeradresse befüllt (mail to:).

Würde eine Email an daniel.gestl@it-yourself.at ergehen, dann erhält Postfix auf die Abfrage eine positive Rückmeldung. (Emailadresse vorhanden -> Die Email wird an den dagent weitergegeben)

Wenn die Abfrage keinen Rückgabewert liefert, wird die Email abgelehnt. (Sinngemäß mit: User unknown in virtual address table)

virtual_transport: Definiert, dass Postix Emails an das LMTP-Port 2003 weitergibt, sofern sie akzeptiert worden sind. D.h. Postfix übergibt die Mails an den dagent von Kopano.

Der dagent ist fähig, die Emails anhand des Benutzernamens, oder der Emailadresse dem entsprechenden Kopanouser zuzuordnen.

virtual_mailbox_domains: Für welche Domains ist der Postfixserver zuständig.

Lokale Zustellung

Keine der Emails sollen lokal zugestellt werden. Deshalb, muss der Wert für mydestination auf localhost stehen.

Die Relayingkonfiguration

Ein sehr relevantes Thema. Nur Kopanobenutzer dürfen über den Server relayen. Entweder kann die Webapp, die Deskapp, oder eine Activesyncanbindung genutzt werden (Outlook, Smartphone). Ein direkter SMTP Versand von einem beliebigen Client ist NICHT möglich!

Anmerkung: Mit Deskapp und Z-Push beschäftige ich mich in Artikel 3 der Serie.

mynetworks = 127.0.0.0/8
 smtpd_relay_restrictions = permit_mynetworks, reject_unauth_destination

smtpd_recipient_restrictions (main.cf) Achtung, die  Einrückung ist notwendig!

 smtpd_recipient_restrictions = permit_mynetworks,
                                reject_non_fqdn_recipient,
                                reject_non_fqdn_hostname,
                                reject_invalid_hostname,
                                reject_non_fqdn_recipient,
                                reject_non_fqdn_sender,
                                reject_unauth_pipelining,
                                reject_unverified_recipient

Anmerkung: Mit Deskapp und Z-Push beschäftige ich mich in Artikel 3 der Serie.

Funktionsprüfung

Nach jeder Konfigurationsänderung, müssen die betroffenen Dienste neu gestartet werden.

service postfix restart

Abgesehen davon, ist es immer eine gute Idee, den Status eines neu gestarteten Dienstes zu prüfen.

service postfix status

(Nicht irritieren lassen, hier ist u.a. bereits spamassassin aktiv).

Wichtig ist active (running).

Wir senden eine Email und prüfen die Webapp

Finale – Teil 2: Mit einem beliebigen Mailclient senden wir eine Email an die in  Kopano vorhandene Mailadresse. In meinem Fall ist dies daniel.gestl@it-yourself.at.

Die Email sollte – sofern alles korrekt konfiguriert ist – in der Webapp von Kopano erscheinen. (http://<FQDN oder IP>/webapp)

Perfekt, läuft!

Probleme?

Sofern Probleme auftreten, kann die Logdatei von Postfix überprüft werden.

tail -f /var/log/mail.log

= Echtzeitdarstellung der Logdatei.

Noch ein paar Worte…

Dies ist das Ende von Teil 2 der Kopanoinstallation. In Teil 3 möchte ich mich mit einigen weiteren Modulen von Kopano beschäftigen.

Ebenso ist das Aktivieren des HTTPS-Protokolles ein Thema.

Die Dokumentation

Aufgrund der Vielzahl an Möglichkeiten die diese Groupware bietet, lohnt sich auf jeden Fall ein Blick in die hervorragende Dokumentation.

Hier gehts zu Teil 3…

Kopano Webapp mit fail2ban schützen

Kommentar hinterlassen

Gerade eben stand ich vor der Aufgabe, die Kopano-Web-App mit einem fail2ban Schutz zu versehen. Fail2ban arbeitet mit regulären Ausdrücken (regular expressions). Ehrlich gesagt, habe ich davon so gut wie keine Ahnung. 🙂

Egal! Aufgegeben wird nur ein Brief…

Schließlich kam ich zu folgender Lösung.

Der Logeintrag

Im Apache-Error-Log wird bei einem fehlerhaften Loginversuch in die Webapp Folgendes protokolliert:

[Thu Mar 09 19:20:56.097859 2017] [:error] [pid 25634] [client xx.119.xxx.141:6640] Kopano WebApp user: dsafasdf: authentication failure at MAPI, referer: https://kopano.mysite.at/webapp/?logon

Der Fail2ban Filter

Da es sich bei der Fehlermeldung um eine vom „Apachen“ kreierte Fehlermeldung handelt, greife ich im Filter auf die apache-common.conf (siehe INCLUDES) zurück und baue mir folgenden Filter (failregex):

# FILE : /etc/fail2ban/filter.d/kopano-webapp-login.conf
# Fail2Ban configuration file
[INCLUDES]
before = apache-common.conf
failregex = ^%(_apache_error_client)s Kopano WebApp user: .+?(?=:): authentication failure at MAPI

ignoreregex =

Der erste Teil wertet die Clientinformationen aus, danach folgt ein normaler String Kopano Webapp user: gefolgt von einer regular expression .+?(?=:) die besagt, dass alle folgenden Zeichen bis zum nächsten Doppelpunkt als Übereinstimmung angesehen werden.

Schließlich folgt ein weiterer Doppelpunkt, der wieder als String zu sehen ist, gefolgt von weiterem Text, der dem Text im Logfile entspricht.

Update – So gehts auch: 

failregex =  ^%(_apache_error_client)s Kopano WebApp user:.* authentication failure at MAPI

Somit ist man nicht mehr auf den Doppelpunkt und die in der ersten Variante angegebene Verrenkung angewiesen.

Die Datei selbst wird unter  /etc/fail2ban/filter.d/kopano-webapp-login.conf gespeichert.

Den Filter aktivieren

Im Verzeichnis /etc/fail2ban/ ist die Datei jail.local um folgende Zeilen zu erweitern:

[kopano-webapp]
enabled = true
port = https
filter = kopano-webapp-login
logpath = /var/log/apache2/kopano_ssl_error.log

Fail2ban Bann oder fail?

Ob es wirklich richtig bannt, ist im Logfile schnell erkannt.

2017-03-09 19:20:56,586 fail2ban.actions[26156]: WARNING [kopano-webapp] Ban xx.119.xxx.141

Scheint zu klappen!

Verbesserungsvorschläge werden gerne angenommen. 😉