Informationen über die Einrichtung der Benutzerauthentifizierung, - über die Verwaltung von Gruppen und weitere Einstellungen
Lx-Office verwaltet die Benutzerinformationen in einer - Datenbank, die im folgenden “Authentifizierungsdatenbank” genannt - wird. Für jeden Benutzer kann dort eine eigene Datenbank für die - eigentlichen Finanzdaten hinterlegt sein. Diese beiden Datenbanken - können, müssen aber nicht unterschiedlich sein.
Im einfachsten Fall gibt es für Lx-Office nur eine einzige - Datenbank, in der sowohl die Benutzerinformationen als auch die Daten - abgelegt werden.
Zusätzlich ermöglicht es Lx-Office, dass die Benutzerpasswörter - entweder gegen die Authentifizierungsdatenbank oder gegen einen - LDAP-Server überprüft werden.
Welche Art der Passwortüberprüfung Lx-Office benutzt und wie
- Lx-Office die Authentifizierungsdatenbank erreichen kann, wird in der
- Konfigurationsdatei config/lx_office.conf
- festgelegt. Diese muss bei der Installation und bei einem Upgrade von
- einer Version vor v2.6.0 angelegt werden. Eine
- Beispielkonfigurationsdatei
- config/lx_office.conf.default existiert, die als
- Vorlage benutzt werden kann.
Das Passwort, das zum Zugriff auf das Aministrationsinterface
- benutzt wird, wird ebenfalls in dieser Datei gespeichert. Es kann auch
- nur dort und nicht mehr im Administrationsinterface selber geändert
- werden. Der Parameter dazu heißt admin_password im
- Abschnitt [authentication].
Die Verbindung zur Authentifizierungsdatenbank wird mit den
- Parametern in [authentication/database]
- konfiguriert. Hier sind die folgenden Parameter anzugeben:
host
- Der Rechnername oder die IP-Adresse des - Datenbankservers
port
- Die Portnummer des Datenbankservers, meist 5432
db
- Der Name der Authentifizierungsdatenbank
user
- Der Benutzername, mit dem sich Lx-Office beim
- Datenbankserver anmeldet (z.B.
- "postgres")
password
- Das Passwort für den Datenbankbenutzer
Die Datenbank muss noch nicht existieren. Lx-Office kann sie - automatisch anlegen (mehr dazu siehe unten).
Lx-Office unterstützt Passwortüberprüfung auf zwei Arten: gegen
- die Authentifizierungsdatenbank und gegen einen externen LDAP- oder
- Active-Directory-Server. Welche davon benutzt wird, regelt der
- Parameter module im Abschnitt
- [authentication].
Sollen die Benutzerpasswörter in der Authentifizierungsdatenbank
- gespeichert werden, so muss der Parameter module
- den Wert DB enthalten. In diesem Fall können sowohl
- der Administrator als auch die Benutzer selber ihre Psaswörter in
- Lx-Office ändern.
Soll hingegen ein externer LDAP- oder Active-Directory-Server
- benutzt werden, so muss der Parameter module auf
- LDAP gesetzt werden. In diesem Fall müssen
- zusätzliche Informationen über den LDAP-Server im Abschnitt
- [authentication/ldap] angegeben werden:
host
- Der Rechnername oder die IP-Adresse des LDAP- oder - Active-Directory-Servers. Diese Angabe ist zwingend - erforderlich.
port
- Die Portnummer des LDAP-Servers; meist 389.
tls
- Wenn Verbindungsverschlüsselung gewünscht ist, so diesen
- Wert auf ‘1’ setzen, andernfalls auf
- ‘0’ belassen
attribute
- Das LDAP-Attribut, in dem der Benutzername steht, den der
- Benutzer eingegeben hat. Für Active-Directory-Server ist dies
- meist ‘sAMAccountName’, für andere
- LDAP-Server hingegen ‘uid’. Diese Angabe ist
- zwingend erforderlich.
base_dn
- Der Abschnitt des LDAP-Baumes, der durchsucht werden soll. - Diese Angabe ist zwingend erforderlich.
filter
- Ein optionaler LDAP-Filter. Enthält dieser Filter das Wort
- <%login%>, so wird dieses durch den vom
- Benutzer eingegebenen Benutzernamen ersetzt. Andernfalls wird
- der LDAP-Baum nach einem Element durchsucht, bei dem das oben
- angegebene Attribut mit dem Benutzernamen identisch ist.
bind_dn und
- bind_password
- Wenn der LDAP-Server eine Anmeldung erfordert, bevor er
- durchsucht werden kann (z.B. ist dies bei
- Active-Directory-Servern der Fall), so kann diese hier angegeben
- werden. Für Active-Directory-Server kann als
- ‘bind_dn’ entweder eine komplette LDAP-DN wie
- z.B. ‘cn=Martin
- Mustermann,cn=Users,dc=firmendomain’ auch nur der
- volle Name des Benutzers eingegeben werden; in diesem Beispiel
- also ‘Martin Mustermann’.
Sollen auf einem Server mehrere Lx-Office-Installationen
- aufgesetzt werden, so müssen die Namen der Session-Cookies für alle
- Installationen unterschiedlich sein. Der Name des Cookies wird mit dem
- Parameter cookie_name im Abschnitt
- [authentication]gesetzt.
Diese Angabe ist optional, wenn nur eine Installation auf dem - Server existiert.
Nachdem alle Einstellungen in
- config/lx_office.conf vorgenommen wurden, muss
- Lx-Office die Authentifizierungsdatenbank anlegen. Dieses geschieht
- automatisch, wenn Sie sich im Administrationsmodul anmelden, das unter
- der folgenden URL erreichbar sein sollte:
In diesem Abschnitt wird die Konfiguration des Apache-Webservers + beschrieben. kivitendo wird mittels FastCGI/FCGI ausgeführt.
Es ist empfehlenswert, SSL einzusetzen, um die Daten per HTTPS
+ verschlüsselt zwischen Browser und Webserver über das Netzwerk zu
+ übertragen. Eine Möglichkeit dazu ist das Erstellen eines self-signed
+ SSL Zertifikates, was unter Debian/Ubuntu durch Installieren des Pakets
+ ssl-cert geschehen kann.
Der Zugriff auf den Installationspfad von kivitendo im Dateisystem
+ muss in der Apache Webserverkonfigurationsdatei eingestellt werden,
+ welche beim Starten des Webservers eingelesen wird. Wird SSL/HTTPS
+ eingesetzt, so ist dies die Datei default-ssl.conf,
+ für unverschlüsseltes HTTP ist es die Datei
+ 000-default.conf.
Bitte konsultieren Sie die Dokumentation des Apache-Webservers und + Ihres Betriebssystems. Es kann erforderlich sein, das SSL-Modul und die + Webserverkonfigurationsdatei zu aktivieren:
a2enmod ssl +a2ensite default-ssl
Unter Fedora und openSUSE müssen weiterhin in der Firewall die + Ports 80 (HTTP) bzw. 443 (HTTPS) geöffnet werden.
Mit FastCGI wird der kivitendo-Programmcode beim Start des + Webservers einmal geladen und danach wird nur die eigentliche + Programmlogik ausgeführt.
Zuerst muss das FastCGI-Modul aktiviert werden. Dies kann + unter Debian/Ubuntu z.B. mit folgendem Befehl geschehen:
a2enmod fcgid
Die Konfiguration für die Verwendung von kivitendo mit FastCGI
+ erfolgt durch Einfügen von Alias-
+ und Directory-Direktiven. Dabei wird zwischen
+ dem Installationspfad von kivitendo im Dateisystem
+ ("/path/to/kivitendo-erp") und der URL
+ unterschieden, unter der kivitendo im Webbrowser erreichbar ist
+ ("/url/for/kivitendo-erp").
Folgender Konfigurationsschnipsel funktioniert mit + mod_fcgid:
AliasMatch ^/url/for/kivitendo-erp/[^/]+\.pl /path/to/kivitendo-erp/dispatcher.fcgi +Alias /url/for/kivitendo-erp/ /path/to/kivitendo-erp/ +FcgidMaxRequestLen 10485760 + +<Directory /path/to/kivitendo-erp> + AllowOverride All + Options ExecCGI Includes FollowSymlinks + Require all granted +</Directory> + +<DirectoryMatch /path/to/kivitendo-erp/users> + Require all denied +</DirectoryMatch>
Hierdurch wird nur ein zentraler Dispatcher gestartet. Alle + Zugriffe auf die einzelnen Scripte werden auf diesen umgeleitet. + Dadurch, dass zur Laufzeit öfter mal Scripte neu geladen werden, + gibt es hier kleine Performance-EinbuÃen.
Seit mod_fcgid-Version 2.3.6 gelten sehr kleine Grenzen für + die maximale GröÃe eines Requests. Mit folgender Zeile wird diese + Grenze hochgesetzt:
FcgidMaxRequestLen 10485760
+ Aufgrund von aktuellen (Mitte 2020) Sicherheitswarnungen für git basierte Webanwendungen ist die mitausgelieferte .htaccess + restriktiver geworden und verhindert somit das Auslesen von git basierten Daten. + Für debian/ubuntu muss das Modul mod_rewrite einmalig so aktiviert werden: +
a2enmod rewrite
+ Alternativ und für Installationen ohne Apache ist folgender Artikel interessant: + git-lücke. + Anstelle des dort beschriebenen DirectoryMatch für Apache2 würden wir etwas weitergehend auch noch das Verzeichnis config miteinbeziehen + sowie ferner auch die Möglichkeit nicht ausschlieÃen, dass es in Unterverzeichnissen auch noch .git Repositories geben kann. + Die Empfehlung für Apache 2.4 wäre damit: +
+ <DirectoryMatch "/(\.git|config)/"> + Require all denied + </DirectoryMatch>
+ +
Für einen deutlichen Sicherheitsmehrwert sorgt die Ausführung + von kivitendo nur über https-verschlüsselten Verbindungen, sowie + weiteren Zusatzmassnahmen, wie beispielsweise Basic Authentication. Die + Konfigurationsmöglichkeiten sprengen allerdings den Rahmen dieser + Anleitung, hier ein Hinweis auf einen entsprechenden Foreneintrag + (Stand Sept. 2015) und einen aktuellen (Stand Mai 2017) + SSL-Konfigurations-Generator.
Aufgrund des OpenSource Charakters ist kivitendo nicht "out of the box" sicher. + Organisatorisch empfehlen wir hier die enge Zusammenarbeit mit einem kivitendo Partner der auch in der +Lage ist weiterführende Fragen in Bezug auf Datenschutz und Datensicherheit zu beantworten. +Unabhängig davon empfehlen wir im Webserver Bereich die Aktivierung und Konfiguration des Moduls modsecurity für den Apache2, damit +XSS und SQL-Injections verhindert werden.
Als Idee hierfür sei dieser Blog-Eintrag genannt: + + Test Apache2 modsecurity for SQL Injection.