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.

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 circulate permission 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 circulate permission schreiben.

Der Grund, warum wir wollen, dass SIP2-Benutzer nur die ref:circulate permission <permission-circulate-label> und nicht die :ref:`superlibrarian permission <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 circulate permission verfügen, dass ein Eindringling nur über das Terminal und nicht über die Weboberfläche (die mit superlibrarian permission verfügbar wäre) auf die Daten der Benutzer zugreifen könnte. Es geht also einfach darum, Ihre Benutzer zu schützen.

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.

Definition der Werte unter Institutions:

1: Institution id: Das Bibliotheksküzrel der Bibliothek. - Passen Sie dies entsprechend an. Dies muss das gleiche Kürzel sein, das auch in Koha und im Bereich accounts angegeben wurde.

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.

4: Um SIP2 zu starten, schreiben Sie einfach den Befehl: 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).

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. Nun sind Sie mit dem SIP2-Server verbunden und können damit beginnen Befehle zu schreiben und abzusenden. Die Verbindung zum SIP2-Server läuft schnell in einen Timeout, um das zu verhindern, bevor Sie mit dem Schreiben und Empfangen von Befehlen fertig sind, schreiben Sie einfach:

   telnet localhost <portnumber>

   um die SIP2-Verbindung neu aufzubauen.

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).

Zusätzlich wurde eine Bibliothek mit dem Bibliohtekskürzel „WEL“ in der Koha-Dienstoberfläche angelegt und im Bereich institutions der Datei SIPconfig.xml definiert):

Das Format der SIP2-Anfrage ist:

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:

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:

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:

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:

Bemerkung

Alert kann einen von mehreren Werten annehmen: 00: Unbekannt, 01: Lokale Vormerkung, 02: Vormerkung vom anderen Standort, 03: Fernleihbestellung, 04: Transport, 99: Sonstiges

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:

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:

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:

Bemerkung

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

Das Terminalpasswort ist optional.

Antwort:

Update des Exemplarstatus: Dies verwendet in der Anfrage den Präfix 19 und in der Antwort den Präfix 20

Anfrage:

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:

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:

Antwort:

Bemerkung

Der Wert, der für <patronvalidity> angezeigt wird, ist entweder Y (gültig) oder N (ungültig). Der Wert in <YYYYMMDD> < HHMMSS> ist das aktuelle Datum und Uhrzeit.

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:

Antwort:

** Verlängern: Dieser Befehl verwendet das Präfix 29 in der Anfrage und 30 in der Antwort**

Anfrage:

Bemerkung

• <thirdpartyallowed> ist ein Wert von einem Zeichen Länge, der entweder Y oder N ist. Wenn er Y ist, dann können auch Dritte Ausleihen verlängern.

• <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:

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.

• <magneticmedia> ist ein Wert mit einem Zeichen Länge der entweder Y (für Ja) oder N (für Jein) oder U (für Unbekannt) ist.

• <mediatype> ist ein Wert von 3 Zeichen Länge. Eine Liste der möglichen Werte finden Sie in: http://multimedia.3m.com/mws/media/355361O/sip2-protocol.pdf

Sitzung beenden

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

Anfrage:

Antwort:

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:

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> ist ein dreistelliges alphanumerisches Feld, das die Währung angibt, in der eine Gebühr bezahlt wurde.

Antwort:

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:

Antwort:

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:

Antwort:

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:

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.

Antwort: 941 ist eine erfolgreiche Anmeldung. 940 ist eine fehlgeschlagene Anmeldung. [connection closed by foreign host.] ist ebenfalls eine fehlgeschlagene Anmeldung

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:

Bemerkung

Der Statuscode hat einen von 3 Werten. * 0: SC ist in Ordnung * 1: SC hat kein Papier mehr * 2: SC: fährt herunter. Die Druckbreite sind 3 Zeichen, die er Anzahl der Zeichen entspricht, die der Client drucken kann. Protokoll-Vresion ist ein 4 Zeichen langer Wert im Format x.xx

Antwort:

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 circulate permission 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 Navigieren Sie im Linux-Terminal in das Verzeichnis mit der koha-conf.xml, diese liegt entweder unter * /etc/koha/sites/<instance-name>/ ODER * /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

Hinweis zum Hostname: Der Hostname kann entweder eine alphanumerische Bezeichnung oder die IP-Adresse des LDAP-Servers sein (die Angabe der Portnummer ist optional). Die Voreinstellung ist die Portnummer von LDAPS 636 und von LDAP 389

Bemerkung

Hinweis zu den Feldern replicate und udpate: Das Feld replicate für LDAP in der koha-conf.xml erlaubt es, einen neuen Benutzer in der Koha-Datenbank anzulegen, wenn sich ein Benutzer mit seinem LDAP-Benutzernamen und -Passwort in Koha (entweder in der Dienstoberfläche oder im OPAC) anmeldet (vorausgesetzt, derselbe Benutzername und dasselbe Passwort sind nicht bereits in der Koha-Datenbank vorhanden).

Das Feld update (in der gleichen Datei) hingegen erlaubt es, Benutzerinformationen der Koha-Datenbank mit denen in der LDAP-Datenbank zu synchronisieren, d.h. wenn jemand heiratet und sich der Nachname ändert, muss der Nachname nur in der LDAP-Datenbank geändert werden und wird von dort in die Koha-Datenbank übertragen, wenn der Benutzer sich anmeldet und update auf 1 gesetzt wurde.

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:

Wenn Plack aktiviert ist, dann werden LDAP-Fehler im plack-error.log ausgegeben. Wenn Plack deaktiviert ist, dann werden die LDAP-Fehler entweder im opac-error.log (bei Anmeldung im OPAC) oder im intranet-error.log (bei Anmeldung in der Dienstoberfläche) ausgegeben. Alle drei Logdateien finden sich im folgenden Verzeichnis:

/var/log/koha/<instance>/