Im Administrationsmenü gibt es ferner noch die beiden Menüpunkte Druckeradministration und System.
Unter dem Menüpunkt Druckeradministration lassen sich beliebig viele "Druckbefehle" im System verwalten. Diese Befehle werden mandantenweise - zugeordnet. Unter Druckerbeschreibung wird der Namen des Druckbefehls festgelegt, der dann in der Druckerauswahl des Belegs angezeigt wird.
Unter Druckbefehl definiert man den eigentlichen Druckbefehl, der direkt auf dem Webserver ausgeführt wird, bspw. 'lpr -P meinDrucker' oder ein - kompletter Pfad zu einem Skript (/usr/local/src/kivitendo/scripts/pdf_druck_in_verzeichnis.sh). - Wird ferner noch ein optionales Vorlagenkürzel verwendet, wird dieses Kürzel bei der Auswahl der Druckvorlagendatei mit einem Unterstrich ergänzt, ist - bspw. das Kürzel 'epson_drucker' definiert, so wird beim Ausdruck eines Angebots folgende Vorlage geparst: sales_quotation_epson_drucker.tex.
Unter dem Menüpunkt System gibt es den Eintrag 'Installation sperren/entsperren'. Setz man diese Sperre so ist der Zugang zu der gesamten kivitendo Installation gesperrt.
Falls die Sperre gesetzt ist, erscheint anstelle der Anmeldemaske die Information: 'kivitendo ist momentan zwecks Wartungsarbeiten nicht zugänglich.'. -
Wichtig zu erwähnen ist hierbei noch, dass sich kivitendo automatisch 'sperrt', falls es bei einem Versionsupdate zu einem Datenbankfehler kam. Somit kann hier nicht aus Versehen - mit einem inkonsistenten Datenbestand weitergearbeitet werden.
Informationen über die Einrichtung der Benutzerauthentifizierung, + über die Verwaltung von Gruppen und weitere Einstellungen
kivitendo 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 kivitendo nur eine einzige + Datenbank, in der sowohl die Benutzerinformationen als auch die Daten + abgelegt werden.
Zusätzlich ermöglicht es kivitendo, dass die Benutzerpasswörter gegen verschiedene Authentifizierungsmethoden geprüft + werden. Dazu zählen die Authentifizierungsdatenbank, LDAP-Server sowie verschiedene Arten von HTTP-Header-basierten Methoden.
Welche Art der Passwortüberprüfung kivitendo benutzt und wie
+ kivitendo die Authentifizierungsdatenbank erreichen kann, wird in der
+ Konfigurationsdatei config/kivitendo.conf
+ festgelegt. Diese muss bei der Installation und bei einem Upgrade von
+ einer Version vor v2.6.0 angelegt werden. Eine
+ Beispielkonfigurationsdatei
+ config/kivitendo.conf.default existiert, die als
+ Vorlage benutzt werden kann.
Das Passwort, das zum Zugriff auf das Administrationsinterface
+ von kivitendo 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 kivitendo beim
+ Datenbankserver anmeldet (z.B.
+ "postgres")
password
+ Das Passwort für den Datenbankbenutzer
Die Datenbank muss noch nicht existieren. kivitendo kann sie + automatisch anlegen (mehr dazu siehe unten).
kivitendo unterstützt verschiedene Module für die Passwortüberprüfung. Welche benutzt wird, regelt der Parameter
+ module im Abschnitt [authentication].
Dieser Parameter listet die zu verwendenden Authentifizierungsmodule auf. Es muss mindestens ein Modul angegeben werden, es + können aber auch mehrere angegeben werden. Weiterhin ist es möglich, das LDAP-Modul mehrfach zu verwenden und für jede Verwendung + eine unterschiedliche Konfiguration zu nutzen, z.B. um einen Fallback-Server anzugeben, der benutzt wird, sofern der Hauptserver + nicht erreichbar ist.
Verfügbare Module sind:
+ DB: in Authentifizierungsdatenbank integrierte Benutzerverwaltung
+ ldap: Bind mit User-Objekten gegen einen oder mehrere LDAP-Server
+ http_headers: überlässt Authenfizierung vorgelagerten Proxy-Servern übernimmt Usernamen
+ aus mitgeschickten HTTP-Headern
Sollen die Benutzerpasswörter in der Authentifizierungsdatenbank geprüft werden, so muss der Parameter
+ module das Modul DB enthalten. Sofern das Modul in der Liste enthalten ist, egal an welcher
+ Position, können sowohl der Administrator als auch die Benutzer selber ihre Passwörter in kivitendo ändern.
Wenn Passwörter gegen einen oder mehrere externe LDAP- oder Active-Directory-Server geprüft werden, so muss der Parameter
+ module den Wert LDAP enthalten. In diesem Fall müssen zusätzliche Informationen über den
+ LDAP-Server im Abschnitt [authentication/ldap] angegeben werden. Das Modul kann auch mehrfach angegeben werden,
+ wobei jedes Modul eine eigene Konfiguration bekommen sollte. Der Name der Konfiguration wird dabei mit einem Doppelpunkt getrennt an
+ den Modulnamen angehängt (LDAP:Name-der-Konfiguration). Der entsprechende Abschnitt in der Konfigurationsdatei
+ lautet dann [authentication/Name-der-Konfiguration].
Die verfügbaren Parameter für die LDAP-Konfiguration lauten:
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
verify
+ Wenn Verbindungsverschlüsselung gewünscht und der Parameter tls gesetzt ist, so gibt dieser
+ Parameter an, ob das Serverzertifikat auf Gültigkeit geprüft wird. Mögliche Werte sind require (Zertifikat
+ wird überprüft und muss gültig sei; dies ist der Standard) und none (Zertifikat wird nicht
+ überpfüft).
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â.
timeout
+ Timeout beim Verbindungsversuch, bevor der Server als nicht erreichbar gilt; Standardwert: 10
+ Diese Methode der Authentifizierung überlässt einem vorgelagerten Webserver oder Proxyserver die Authentifizierung. Dazu können + SSO-Systeme wie z.B. Authelia oder Authentik zum Einsatz kommen. Die vorgelagerten Server übermitteln dann den Usernamen der + authentifizierten Person in einem speziellen HTTP-Header, der an kivitendo durchgereicht wird. Damit kivitendo nicht von + beliebigen Quellen aus mit so einem Usernamen aufgerufen werden kann, verlangt kivitendo weiterhin, dass in einem weiteren + Header ein Shared Secret übertragen wird. Dieses Secret wird vom Administrator vergeben und sollte nicht weitergegeben werden. +
+ Ãber einen weiteren Header wird wiederum gesteuert, an welchem Mandanten die Anmeldung erfolgt. Dies geschieht über die + Datenbank-ID des Mandanten. +
+ Um diese Methode zu aktivieren, muss das Authentifizierungsmodul auf HTTPHeaders gestellt werden. Zusätzlich
+ muss im Abschnitt authentication/http_headers der Parameter enabled=1 und im Abschnitt
+ authentication/http_basic der Parameter enabled=0 gesetzt werden. Die folgenden Parameter
+ müssen anschlieÃend im Abschnitt authentication/http_headers konfiguriert werden:
+
client_id_header
+ Name des Headers, in dem das vorgelagerte System die Datenbank-ID des Mandanten überträgt.
user_header
+ Name des Headers, in dem das vorgelagerte System den Namen des authentifizierten Users überträgt.
secret_header
+ Name des Headers, in dem das vorgelagerte System das Shared Secret.
secret
+ Wert des Shared Secrets selber, der vom vorgelagerten System übertragen werden muss, damit die Werte als gültig + angesehen werden.
+ Diese Methode der Authentifizierung überlässt dem Webserver (meist Apache) die Authentifizierung mittels der standardisierten + HTTP Basic Authentication (RFC 7617). Dazu muss der Webserver so konfiguriert werden, dass er für alle kivitendo-Requests vom + Webbrowser Authentifizierung verlangt. Zusätzlich muss er veranlasst werden, den angegebenen Usernamen auch an kivitendo zu + übermitteln. Dies könnte beispielhaft wie folgt aussehen: +
<Directory /path/to/kivitendo-erp> + AllowOverride All + Options ExecCGI Includes FollowSymlinks + + # Require authentication from local user file: + AuthType Basic + AuthName "kivitendo" + AuthUserFile /etc/apache2/htpasswd.kivitendo + Require valid-user + + # Pass name of authorized user to kivitendo: + SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1 +</Directory>
+ Um diese Methode zu aktivieren, muss das Authentifizierungsmodul auf HTTPHeaders gestellt werden. Zusätzlich
+ muss im Abschnitt authentication/http_basic der Parameter enabled=1 und im Abschnitt
+ authentication/http_headers der Parameter enabled=0 gesetzt werden.
+
Sollen auf einem Server mehrere kivitendo-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/kivitendo.conf vorgenommen wurden, muss
+ kivitendo die Authentifizierungsdatenbank anlegen. Dieses geschieht
+ automatisch, wenn Sie sich im Administrationsmodul anmelden, das unter
+ der folgenden URL erreichbar sein sollte:
+ http://localhost/kivitendo-erp/controller.pl?action=Admin/login +