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'. Setzt 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 +