Weitere APIs und Protokolle

SIP2

SIP2 (Session Initiation Protocol) ist ein Protokoll für die Kommunikation zwischen Geräten.

Im Kontext von Koha wird SIP2 für die Kommunikation zwischen den Selbstverbuchungsgeräten (SC) und dem automatischen Ausleihsystem (auch ACS genannt und in diesem Fall der Server mit Koha) verwendet.

Die SIP2-Kommunikation besteht aus Anfragen (requests) und Antworten (responses).

Die Selbstverbuchungsgeräte sind an sich „dumm“ und schicken Anfragen an den Koha-Server, der die Logik für die betreffende Anfrage ausführt und eine Antwort zurück an den Client des Selbstverbuchungsgeräts schickt, der diese an den Benutzer weitergibt.

Warnung

Sicherheitshinweis für die Verwendung des SIP2-Service: Damit die SIP2-Kommunikation über das Internet auf sichere Weise erfolgt, müssen Sie sicherstellen, dass ein VPN oder Stunnel verwendet wird.

Konfiguration von SIP2

Tipp

Im Koha-Wiki finden Sie hilfreiche Tipps:

Koha SIP2 server set up und`SIP2 configuration <https://wiki.koha-community.org/wiki/SIP2_configuration>`_.

Wenn Sie Koha über die Debian-Pakete installiert haben, dann ist die Konfiguration von SIP2 relativ einfach, folgen Sie einfach den folgenden Schritten:

1. In your terminal (in the root Koha directory) write in: sudo koha-enable-sip <instancename>

2. Now you need to configure the SIP2 settings, to do this you need to edit the SIPconfig.xml file which exists in the /etc/koha/sites/<instancename>/ directory. You will need to edit this file as root because it contains passwords (to do so write ‘sudo’ at the start of your command).

Z.B. sudo vi /etc/koha/sites/<instancename>/SIPconfig.xml

Bemerkung

Wichtiger Hinweis: Es gibt drei Bereiche in der Datei SIPconfig.xml die geändert werden müssen. Diese sind: service, account und institution.

Service

2.1 Ändern Sie den Port am Anfang der Datei SIPconfig.xml (gekennzeichnet mit der Nummer 1 im folgenden Screenshot), so dass dieselbe IP-Adresse wie weiter unten in der Datei, gekennzeichnet mit Nummer 2, verwendet wird.

Bemerkung

Stellen Sie sicher, dass für die beiden Portnummern nicht der gleiche Port verwendet wird, da ein Port nicht für zwei verschiedene Services verwendet werden kann. Wenn Sie die Ports festlegen, wählen Sie einen Port mit einer höheren Nummer (über 1000), da alle Ports unter 1000 Root-Berechtigungen erfordern.

image1122

Account

Die Konten, die Sie in der Datei SIPconfig.xml definieren, sind die Konten die den SIP2-Service verwenden würden. Sie legen also fest, wer SIP2-Befehle senden und empfangen kann.

Warnung

Die Kontoinformation, die Sie hier angeben, muss auch in der Koha-Datenbank existieren, d.h. Sie müssen einen Benutzer in der Dienstoberfläche von Koha anlegen, der den gleichen Benutzernamen und das gleiche Passwort hat (stellen Sie sicher, dass Sie ihnen die Berechtigung circulate zuweisen) als das Benutzerkonto, das Sie in die Datei SIPconfig.xml schreiben.

Bemerkung

Es wird dringend empfohlen, dass Sie nur in Koha-Benutzerkonten mit der Berechtigung circulate schreiben.

Der Grund, warum wir wollen, dass SIP2-Benutzer nur die Berechtigung ref:circulate <permission-circulate-label> und nicht die :ref:`superlibrarian <permission-superlibrarian-label>`haben, liegt darin, dass SIP2-Benutzer im Falle einer Kompromittierung des Systems weniger Zugriff auf vertrauliche Benutzerdaten haben.

Wenn das ACS oder der SC kompromittiert werden, bedeutet die Tatsache, dass alle SIP2-Benutzer nur über die Berechtigung circulate verfügen, so dass ein Eindringling nur über das Terminal und nicht über die Weboberfläche (die mit superlibrarian verfügbar wäre) auf die Daten der Benutzer zugreifen könnte. Es geht also einfach darum, Ihre Benutzer zu schützen.

image1119

Definition der Werte unter Accounts:

  1. Login id: Dies ist der Benutzername. - Passen Sie dies entsprechend an

  2. Password: Dies ist das Passwort des Konto. - Passen Sie dies entsprechend an

  3. Delimiter: Das Trennzeichen für Kontoinformationen. - Belassen Sie die Voreinstellung

  4. error-detect - Als Standard belassen

  5. Institution: Dies ist das Bibliothekskürzel der Bibliothek, zu der dieser Benutzer gehört. HINWEIS: Diese institution muss weiter unten im Bereich für institution der Datei SIPconfig.xml definiert sein und in der Koha-Datenbank existieren, d.h. Sie müssen eine Bibliothek mit dem gleichen Bibliothekskürzel über die Dienstoberfläche in Koha anlegen.

  6. encoding: Dies ist der Standard, der für die Codierung der Daten verwendet wird

  7. Terminator: Dies muss dem Wert für den Terminator des SIP-Servers entsprechen. - Ändern Sie dies nur, wenn Sie den Wert für Ihren SIP2-Server kennen.

Sie können auch zusätzliche Benutzerfelder zu den SIP2-Profilen im folgenden Format hinzufügen:

<patron_attribute field=“XX“ code=“CODE1“ /> <patron_attribute field=“XY“ code=“CODE2“ /> <patron_attribute field=“XZ“ code=“CODE3“ />

Institution

Die institution, die Sie hier definieren, müssen einer Bibliothek entsprechen, die in Koha angelegt wurde.

Warnung

Stellen Sie sicher, dass alle weiter oben unter accounts genannten institutions auch im Bereich für institution der Datei SIPconfig.xml definiert werden.

image1120

Definition der Werte unter Institutions:

  1. Institution id: The branchcode of the library. - Modify this accordingly.

    Must be the same as created in Koha and the account area.

  2. Implementation: Definiert, welcher Code ausgeführt wird. - Belassen Sie die Voreinstellung

  3. Policy: Policy defines the permitted SIP2 commands allowed from SC’s in this institution.

For example: renewal=”true” means that SC’s at that institution have permission to send renewal item SIP2 commands.

  1. Starting SIP2

Simply write in the command:

sudo koha-start-sip <instancename>

Bemerkung

Jetzt haben Sie einen laufenden SIP2-Server.

Bemerkung

Optional können Sie das Sortierverfahren mit den Systemeinstellungen UseLocationAsAQInSIP und SIP2SortBinMapping konfigurieren.

SIP2 verwenden

SIP2 ist ein Kommunikationsprotokoll. Die SIP2-Nachrichten sind entweder Anfragen (requests) oder Antworten (responses). Der SC schickt eine Nachricht an den ACS, der eine Logik ausführt und das Ergebnis an den SC als Antwort schickt.

Die Anfragen enthalten Argumente, Daten die der ACS in seinen Funktionen für die Erfüllung seiner Aufgaben, wie die Durchführung eine Verlängerung, verwendet.

SIP2-Befehle

Wenn Sie SIP2 händisch verwenden/testen möchten, dann müssen Sie Nachrichten über das Linux-Terminal schreiben und empfangen.

Um Nachrichten an den SIP2-Server senden und empfangen zu können, müssen Sie Telnet verwenden, um eine SIP2-Verbindung aufzubauen. Sie müssen dabei die Portnummer angeben, die Telnet verwenden soll.

Diese Information finden Sie im Bereich service am Anfang der Datei SIPconfig.xml (suchen Sie nach der Portnummer wie durch den Pfeil im Screenshot hervorgehoben).

image1121

  1. Schreiben Sie auf der Kommandozeile

    telnet localhost <portnumber>

    d.h. telnet localhost 8023

  2. Geben Sie nun den Benutzernamen und das Passwort ein, die in einem der Konten in der Datei SIPconfig.xml festgelegt sind.

  3. Now you are connected to the SIP2 server you can start writing and sending request commands. The connection to the SIP2 server does time out fast so if haven’t finished writing and receiving commands simply write in: telnet localhost <portnumber> to restart the SIP2 connection.

Syntax der SIP2-Befehle

Jeder SIP2-Befehlt hat ein zweistelliges numerisches Präfix, das festlegt, was der Befehlt tut.

Z.B. Um Informationen zu einem Benutzer zu erhalten, beginnen Sie den Befehl mit dem Präfix 63. Die Antwort des Servers enthält ebenfalls ein korrespondierendes numerisches Präfix.

Unten sehen Sie ein Beispiel für eine SIP2-Anfrage nach Benutzerinformationen (in diesem Beispiel einem Koha-Benutzerkonto mit dem Benutzernamen „joe“, Passwort „joes“ und Ausweisnummer „y76t5r43“, der in der Dienstoberfläche angelegt wurde).

Additionally a library with the branchcode of ‘WEL’ has been created in the Koha staff interface and is also defined in the institution area of the SIPconfig.xml file:

image1123

Das Format der SIP2-Anfrage ist:

image1124

Bemerkung

Die Zusammenfassung besteht aus 10 Zeichen. Wenn ein Y in der Zusammenfassung steht, können Sie sowohl eine Zusammenfassung, als auch eine detailliertere Ausgabe erhalten.

Der Wert in <YYYYMMDD> <HHMMSS> ist die aktuelle Zeitangabe, durch Freilassen von 4 Zeichen zwischen YYYYMMDD und HHMMSS ist erkenntlich, dass es sich um eine Angabe in lokaler Zeit und nicht um UTC handelt.

Bemerkung

In diesem Handbuch werden wenn möglich Buchstabencodes für die verschiedenen Felder verwendet, um die verschiedenen SIP2-Nachrichtenfelder zu beschreiben, z.B. AO<institutionid>.

Diese Buchstabencodes können in den SIP2-Befehlen in der Linuxkonsole verwendet werden, aber stellen Sie sicher, dass, wenn Sie die Werte in den Feldern (Werte in den <>) ersetzen, Sie die spitzen Klammern entfernen.

SIP2-Nachrichten:

Benutzer sperren

Dies verwendet das Präfix 01 für die Anfrage und 24 für die Antwort.

Anfrage:

image1125

Bemerkung

Karte einbehalten ist ein Feld mit einem Zeichen, entweder „Y“ oder „N“, das dem ACS mitteilt, dass eine Karte vom Selbstverbucher einbehalten wurde.

Antwort:

image1126

Bemerkung

<patronstatus> ist ein 14 Zeichen langer Wert. Der Wert Y in der Zeichenkette bedeutet wahr (true). Jede Position in dieser Zeichenkette (beginnend mit 0) hat einen einzelnen entsprechenden Wert (Y oder N).

Z.b. ein Y an Position 1 (zweiter Wert der Zeichenkette) bedeutet, dass der Benutzer keine Verlängerungen durchführen kann.

Exemplare zurückgegeben

Dies verwendet in der Anfrage (Nachricht an den ACS) das Präfix 09 und die Antwort verwendet 10 (gesendet an den SC).

Anfrage:

image1127

Bemerkung

  • <no block (Offline)> ist ein Feld mit einem Zeichen, entweder „Y“ oder „N“, welches anzeigt, ob die Transaktion offline durchgeführt wird. Da Offline-Transaktionen nicht unterstützt werden, müssen Sie „N“ angeben, wenn Sie diese Nachricht händisch testen.

  • <transactiondate> Dies ist ein 18-Zeichen langes Feld mit dem Datum im Format: JJJJMMTTZZZZHHMMSS.

ZZZZ ist die Zeitzone, um die lokale Zeit zu verwenden, können 4 Leerzeichen verwendet werden, aber wenn Sie UTC (Coordinated Universal Time) verwenden möchten, schreiben sie 3 Leerzeichen und ein Z.

Antwort:

image1128

Bemerkung

Alert type could have one of several values: 00 : Unknown

01: local hold

02: remote hold

03: ILL Transfer

04: transfer

99: Other

Wenn ein Exemplar gesichert wird, dann sollte der Wert von <resensitize> Y sein, anderenfalls ein N. Exemplare werden gesichert, um eine Meldung auszulösen, wenn jemand versucht das Exemplar zu stehlen.

Exemplare ausleihen

Diese Nachricht verwendet das Präfix 11 für die Anfrage und das Präfix 12 für die Antwort. Sie hat eine ähnliche Syntax wie der Rückgabebefehl, der oben beschrieben wird, mit Ausnahme der Präfixe.

Vormerkung - Wird eventuell noch nicht von allen Systemen unterstützt. Die Anfrage hat den Präfix 15 und die Antwort das Präfix 16.

Anfrage:

image1129

Bemerkung

<holdmode> ist ein Wert von einem Zeichen Länge. + bedeutet, eine Vormerkung eintragen, - bedeutet, eine Vormerkung stornieren und * bedeutet eine Änderung an einer Vormerkung.

Antwort:

image1130

Bemerkung

  • <ok> ist ein Wert von einem Zeichen Länge der entweder 0 (für Vormerkung nicht erlaubt oder nicht erfolgreich) oder 1 (für Vormerkung ist erlaubt und war erfolgreich) annehmen kann.

  • <available> ist ein Wert von einem Zeichen Länge, der entweder Y oder N ist. Y bedeutet, dass das Exemplar aktuell in der Bibliothek ist, während N bedeutet, dass das Exemplar aktuell entliehen/für jemand anderen vorgemerkt ist.

Exemplarinformation: Dies verwendet in der Anfrage den Präfix 17 und in der Antwort den Präfix 18

Anfrage:

image1131

Bemerkung

Lesen Sie im Rückgabebefehl (oben beschrieben) nach, was der <xact_date>-Wert ist.

Das Terminalpasswort ist optional.

Antwort:

image1132

Item status update: This uses the request message prefix of 19 and the response message prefix of 20

Anfrage:

image1133

Bemerkung

<itemproperties> ist kein Wert mit fester Länge und Sie können optional Werte wie die Grüße des Exemplars angeben und diese Werten in der Koha-Datenbank für das Exemplar gespeichert.

Antwort:

image1134

Bemerkung

<itempropertiesok> ist ein Wert mit einem Zeichen Länge, der entweder 0 oder 1 ist. 1 bedeutet, dass der in <itemproperties> angegebene Wert für ein Update des Exemplarstatus erfolgreich in der Datenbank gespeichert wurde.

Benutzerstatus

Dieser verwendet den Präfix 23 in der Anfrage und den Präfix 24 in der Antwort.

Anfrage:

image1135

Antwort:

image1136

Bemerkung

The value displayed for <patronvalidity> is Y (valid) and N (invalid). The value in the <YYYYMMDD> < HHMMSS> is the current date/time.

Der Grund für den Abstand zwischen den beiden Werten ist, dass hier lokale Zeit, statt UTC angegeben wird.

Benutzer aktivieren - Dies wird noch nicht unterstützt. Dieser Befehl verwendet das Präfix 25 in der Anfrage und 26 in der Antwort

Bemerkung

Dieser Befehl macht den Befehl zum Sperren eines Benutzers rückgängig.

Anfrage:

image1137

Antwort:

image1138

Renew: This uses the request message prefix of 29 and the response message prefix of 30

Anfrage:

image1139

Bemerkung

  • <thirdpartyallowed> is a single character value which is either Y or N. If it is Y then third parties can renew items.

  • <noblock> ist ein Wert von einem Zeichen Länge, der entweder Y oder N ist. Wenn er Y ist, dann bedeutet dies, dass der Selbstverbucher offline war, als die Ausleihe/Rückgabe erfolgt ist.

  • <nbduedate> ist das Transaktionsdatum der Rückgabe/Ausleihe, während der Selbstverbucher offline war.

  • <feeacknowledged> ist ein Wert mit einem Zeichen Länder, der entweder Y oder N ist. Dieser zeigt an, ob der Benutzer die mit der Verlängerung verbundenen Gebühren akzeptiert hat.

Antwort:

image1140

Bemerkung

  • <ok> ist ein Wert mit einem Zeichen Länge, der entweder 0 oder 1 ist. Ein Wert von 1 bedeutet, dass das Exemplar erfolgreich verlängert wurde, 0 bedeutet, dass die Verlängerung nicht ausgeführt wurde.

  • <renewalok> ist ein Wert mit einem Zeichen Länge, der entweder Y oder N ist. Die Logik hinter <renewalok> ist, dass Y gesetzt wird, wenn das Exemplar bereits von diesem Benutzer entliehen ist und daher entsichert und verlängert werden sollte, während N gesetzt wird, wenn es noch nicht von diesem Benutzer entliehen ist und daher nicht verlängert werden soll.

In anderen Worten: Lasse Benutzer keine Medien verlängern, die bereits an sie entliehen sind.

Sitzung beenden

Dieser verwendet das Präfix 35 in der Anfrage und 36 in der Antwort

Anfrage:

image1141

Antwort:

image1142

Bemerkung

<success_or_failure> ist entweder Y für Erfolg oder N für Fehlschlag.

Gebühr bezahlt - Ist möglicherweise noch nicht implementiert. Dieser verwendet ein Präfix von 37 für die Anfrage und ein Präfix von 38 für die Antwort

Anfrage:

image1143

Bemerkung

  • <feetype> ist ein zweistelliges numerisches Feld mit enem Wert zwischen 01 und 99. Eine Liste der Gebührenarten finden Sie in http://multimedia.3m.com/mws/media/355361O/sip2-protocol.pdf

  • <paymenttype> ist ein zweistelliges numerisches Feld mit einem Wert zwischen 00 und 99. 00 ist Bar, 01 ist Visa und 02 ist Kreditkarte.

  • <currencytype> is a 3 alphanumeric character long value identifying the currency the fee was paid in.

Antwort:

image1144

Bemerkung

<paymentaccepted> ist ein einstelliger Wert, der entweder Y (Zahlung wurde akzeptiert) oder N (Zahlung wurde nicht akzeptiert) annehmen kann.

Benutzerinformation

Dieser verwendet das Präfix 63 in der Anfrage und 64 in der Antwort

Anfrage:

image1145

Antwort:

image1146

Bemerkung

<valid patron> ist Y für gültig und N für ungültig.

Bemerkung

<hold itemcount><overdueitemcount><chargeditemscount><fienitemscount><recallitemscount><unavaliableholdscount> sind alle vierstellige numerische Werte.

Alle verlängern

Dieser verwendet ein Präfix von 65 in der Anforderungsnachricht und 66 in der Antwortnachricht.

Anfrage:

image1147

Antwort:

image1148

Bemerkung

  • <renewedcount> ist ein vierstelliger numerischer Wert, der die Anzahl der verlängerten Exemplare angibt.

  • <unrenewedcount> hat das gleiche Format wie <renewedcount>, aber gibt die Anzahl der Exemplare an, die nicht verlängert wurden.

Anmeldung

Dieser verwendet das Präfix 93 in der Anfrage und 94 in der Antwort.

Anfrage:

image1149

Bemerkung

<UIDalgorithm> und <PWDalgorithm> sind einstellige Werte, die angeben, welcher Algorithmus für die Verschlüsselung von loginuserid und loginpassword verwendet werden soll.

Die Angabe 0 bedeutet, dass die Werte nicht verschlüsselt werden.

Response message: 941 is a successful login

940 is an unsuccessful login

[connection closed by foreign host.] is a unsuccessful login

Erneutes senden

Dies fordert das empfangende Gerät dazu auf, seine letzte Nachricht erneut zu schicken.

SC -> ACS für erneutes Senden ist 97

ACS -> SC für erneutes Senden ist 96

Status des ACS und SC

Dieser verwendet das Präfix 99 in der Anfrage und 98 in der Antwort.

Anfrage:

image1150

Bemerkung

The status code is one of 3 values. - 0: SC is ok

  • 1: SC is out of paper

  • 2: SC is shutting down

  • max print width is a 3 character long value which is the integer number of characters the client can print

  • Protocol version is a 4 character value in the format x.xx

Antwort:

image1151

Bemerkung

Wenn Sie die Antwort „96“ erhalten, bedeutet dies, dass die Anfrage nicht verstanden wurde oder ungültig war.

SIP2-Troubleshooting

Es ist keien Verbindung mit dem Host über das Telnet-Kommando localhost <portnumber> möglich

3 mögliche Lösungen für dieses Problem sind:

  1. Prüfen Sie die Portnummer in Ihrem Befehl in der SIPconfig.xml an der mit Nummer 1 markierten Stelle nach. D.h. In dem untenstehenden Beispiel, wäre das korrekte Kommando telnet localhost 6001, da die Portnummer 6001 ist.

  2. Prüfen Sie, ob eine userid mehr als einmal in der SIPconfig.xml-Datei definiert ist. Die userid (die dem Benutzernamen des Koha-Benutzers entspricht) darf in der SIPconfig.xml nur einmal vorkommen. Wenn die selbe userid mehrfach in der SIPconfig.xml verwendet wurde, schlägt die Verbindung über SIP2 fehlt, bevor Sie die Möglichkeit hatten sich zu authentifizieren.

  3. Prüfen Sie nach, dass der Account, der in der Datei SIPconfig.xml definiert wurde, auch in der Koha-Datenbank mit dem gleichen Benutzernamen und Passwort existiert und die Berechtigung circulate hat. Wenn Sie die Koha-Datenbank gelöscht und neu angelegt haben, nachdem das Benutzerkonto in der Dienstoberfläche von Koha und in der SIPconfig.xml angelegt wurde, dann wird dieses Benutzerkonto nicht mehr in der Koha-Datenbank existieren und muss in der Koha-Dienstoberfläche neu angelegt werden.

Um auf die SIP2-Logs in Koha zuzugreifen, navigieren Sie in das folende Verzeichnis: /var/log/koha/<instancename>

Dann lassen Sie sich die Ausgaben in sip-error.log und sip-output.log anzeigen, die genauere Informationen über den SIP2-Fehler enthalten.

  • cat sip-error.log

  • cat sip-output.og

Nützliche Linsk für SIP2-Befehle:

http://multimedia.3m.com/mws/media/355361O/sip2-protocol.pdf

LDAP

Die Anbindung von Koha an LDAP (Lightweight Directory Access Protocol) ermöglicht es, Benutzerdaten in einer zentralen Datenbank zu verwalten, auf die von der Koha-Instanz Ihrer Bibliothek aus zugegriffen wird, und über die Ihre Benutzer*innen sich auch in anderen Systemen anmelden können.

LDAP ist ein Protokoll zur Durchführung von Abfragen und Authentifizierung in Netzwerken.

Die Konfigurationsmöglichkeiten von LDAP sind mächtig und erlauben es anzupassen, wie Koha und LDAP miteinander interagieren. LDAP kann so konfiguriert werden, dass neu in LDAP angelegte Konten in die Koha-Datenbank übertragen werden, zusätzlich können auch Änderungen an bestehenden LDAP-Benutzerkonten in die Koha-Datenbank übernommen werden.

Allerdings kann Koha keine Daten in den LDAP-Server synchronisieren, der Datenfluss bei LDAP läuft also nur in eine Richtung.

Auth_By_Bind ist 1, wenn ein Microsoft Windows Active Directory als Datenbank für LDAP verwendet wird.

Bevor Sie die nächsten Schritte zur Konfiguration von LDAP ausführen, benötigen Sie die folgenden Informationen von Ihrer Einrichtung

  • Die Organisation muss einen Port öffnen, um den Zugriff auf das AD von Ihrem Server aus zu erlauben.

  • Informationen für den Zugriff auf den AD-Server (IP-Adresse/Hostname, Port, SSL-Info)

  • Informationen zur Konfiguration des AD-Servers (relevante OUs, DCs, CN-Formate relativ zu Benutzernamen)

  • Mapping zwischen AD-Feldern und Koha-Feldern, inklusive der Voreinstellungen

  • Voreinstellungen für Werte, die nicht vom AD geliefert werden (z.B. Benutzertyp, Heimatbibliothek)

  • Um einen Benutzer zu authentifizieren melden wir uns ald dies an (üblich bei AD) oder verwenden wir ein Konto für das Login und prüfen dann? Für das Letztere benötigen wir die Angaben für die Anmeldung

  • Stimmen die in Koha existierenden Benutzernamen mit denen überein, die wir im AD vorfinden? Wenn ja, gut. Wenn nicht, wie gehen wir mit dubletten Benutzern um?

Schritte für die Konfiguration von LDAP mit Koha

1 In Linux terminal navigate to the directory containing the koha-conf.xml file which will either be in:

  • /etc/koha/sites/<instance-name>/

    OR

  • /etc/koha/

2 Öffnen Sie die koha-conf.xml mit Root-Berechtigung: sudo vi koha-conf.xml

3 Scrollen Sie zu der Zeile mit ‘<useldapserver>0</useldapserver>’ und ändern Sie den Eintrag zu <useldapserver>1</useldapserver>

4 Geben Sie dann in der nächsten Zeile die unten stehenden LDAP-Konfigurationen ein:

      <ldapserver id="<ldapserverid>">

      <hostname><hostname></hostname>

      <base>dc=<domaincontroller>,dc=<domaincontroller></base>

      <user>cn=<nameofuser>, dc=<domaincontroller>,dc=<domaincontroller></user> <!--This is the username of user account with permissions to query the LDAP server -->

      <pass><password></pass> <!-- This is password of the user account with permissions to query the LDAP server-->

      <replicate><either0or1></replicate> <!-- add new users from LDAP to Koha database -->

<welcome><either0or1></welcome> <!-- send new users the welcome email when added via replicate -->

      <update><either0or1></update> <!-- update existing users in Koha database -->

      <auth_by_bind><either0or1></auth_by_bind> <!-- set to 1 to authenticate by binding instead of password comparison, e.g., to use Active Directory -->

      <principal_name><principalname></principal_name> <!-- optional, for     auth_by_bind: a printf format to make userPrincipalName from koha userid        -->

      <mapping> <!-- match koha SQL field names to your LDAP record field names-->

      <firstname is="givenname"></firstname>

      <surname is="sn"></surname>

      <address is="postaladdress"></address>

      <city is="l">Athens, OH</city>    <!-- Athens,OH is the default value for
      city of all users logging into Koha -->

      <zipcode is="postalcode"></zipcode>

      <branchcode is="branch">Central</branchcode>

      <userid is="uid"></userid>

      <password is="userpassword"></password>

      <email is="mail"></email>

      <categorycode is="employeetype">EM</categorycode>

      <phone is="telephonenumber"></phone>

      </mapping>

      </ldapserver>

5 Speichern und Verlassen Sie die Datei koha-conf.xml

6 Prüfen Sie, ob die LDAP-Verbindung funktioniert, über:

ldapsearch -H ldaps://host.name -s base -x -w „“ -d 1

Bemerkung

Note about hostname: Hostname can either be a alphanumerical name or it can be the LDAP server IP address (its optional to write port number).

By default the ldaps default port number is 636, whilst ldap default port number is 389.

Bemerkung

Note about the replicate and update fields:

The replicate LDAP config field for LDAP in the koha-conf.xml file allow the Koha database to be added to

with a new borrower account whenever a user logs into Koha (either the staff client or OPAC) with their LDAP username and password (assuming the same username and password does not already exist in the Koha database).

Whereas the update LDAP config field (in the same file allows) allows for user information in the LDAP database

to be synced down to the Koha database.

e.g. if someone gets married and their surname changes then the new surname only needs to be updated in the

existing LDAP database and that will be synced down to the Koha database automatically if the update configuration is set to 1.

Zu den Mapping-Feldern (in grün hervorgehoben): <city is=“l“>Athens, OH</city>

Der Spaltenname links (hervorgehoben in gelb) ist der Name der Spalte in der LDAP-Datenbank.

Der Spaltenname in den Anführungszeichen (hervorgehoben in pink) ist der Name der Spalte in der Koha-Datenbank. HINWEIS: Diese Angabe kann beliebig gewählt werden, wenn es keine entsprechende Spalte in der Koha-Datenbank gibt.

Der Wert in hellblau ist die Voreinstellung für die angegebenen Koha- und LDAP-Spalten. Im oberen Beispiel erhalten alle Benutzerdatensätze in der Koha-Datenbank in der Voreinstellung die Stadt „Athens, Oh“.

Beispiele von LDAP-Konfigurationen:

<useldapserver>1</useldapserver><!-- see C4::Auth_with_ldap for extra configs you must add if you want to turn this on -->

<ldapserver id="ldapserver" listenref="ldapserver">

<hostname>ldaps://example.co.au</hostname>

<base>ou=employees,dc=companya,dc=com,dc=au</base>

<user></user> <!-- DN, if not anonymous -->

<pass></pass> <!-- password, if not anonymous -->

<auth_by_bind>1</auth_by_bind>

<replicate>1</replicate> <!-- add new users from LDAP to Koha database -->

<update>0</update> <!-- update existing users in Koha database -->

<principal_name>ou=employees,dc=companya,dc=com,dc=au</principal_name>

<mapping>

<userid       is="uid"            ></userid>

<cardnumber   is="uid"            ></cardnumber>

<email        is="mail"           ></email>

<surname      is="sn"             ></surname>

<firstname    is="givenname"      ></firstname>

<categorycode is="1">EM</categorycode>

<branchcode   is="1">SYD</branchcode>

</mapping>

</ldapserver>

Die Werte in den Mappings variieren und hängen davon ab, was in Ihrer LDAP-Datenbank gespeichert ist. Zum Beispiel verwenden einige Organisationen nicht das Feld <userid>, sondern identifizieren den Benutzer über das Feld <email>, so dass keine <userid> ausgegeben wird.

Troubleshooting LDAP

Das Log, in das LDAP-Fehler ausgegeben werden, hängt von verschiedenen Faktoren ab:

If plack is not disabled then LDAP errors are displayed in the plack-error.log file. If plack is disabled then the location that LDAP errors are printed to is either the opac-error.log file (if the user is logging into the OPAC) or the intranet-error.log file (if the user is logging into the staff client) All of these three log files are accessible in the following directory:

/var/log/koha/<instance>/