2FA und OpenLDAP mit Argon2 als Passwordhash

Posted on 19. Juni 2021 by Stefan

Im letzten Artikel ging es um die Einrichtung von TOTP für die Authentifizierung. In dem Artikel habe ich auf das OpenLDAP-Modul pw-totp gesetzt, da es auf den ersten Blick recht einfach einzurichten war. Ist es auch, nur habe ich dann erfahren, dass das Modul alt ist und nicht mehr genutzt werden soll, besser sei es das Modul otp zu nutzen, das neu ist und im OpenLDAP 2.5 bereitgestellt wird. Dann macht es Sinn auch gleich eine gute Verschlüsselung der Passwörter einzubringen. Der Tipp war, die Argon2-Verschlüsselung zu nutzen, das von OpenLDAP in der Version 2.5 voll unterstützt wird. Also, alles wieder auf Anfang und das ganze neu Eingerichtet. Als Grundlage für den OpenLDAP habe ich dieses mal Debian Experimental (Danke Roland für den Tipp) genutzt, denn da ist die Version 2.5.5 schon vorhanden. Also jeder der das hier nachbauen will, ist nicht mehr auf den Bau des OpenLDAP angewiesen. Leider ist das Module autoca hier nicht enthalten, sprich die Einrichtung der Client-Zertifikate aus dem letzten Artikel klappt hier noch nicht.

Als Pakete habe ich installiert:

  • slapd
  • ldap-utils
  • argon2

Debian generiert sofort eine dynamische Konfiguration für den OpenLDAP, auf die ich auch aufgesetzt habe. Mein erst Schritt war dann den Passwordhash {ARGON2} einzurichten. Dafür wird das entsprechende Modul im OpenLDAP benötigt. Mit der folgenden LDIF-Datei wird das Modul geladen:

dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: {1}argon2.la

Anschließend kann der Passwordhash mit der folgenden LDIF-Datei gesetzt werden:

dn: olcDatabase={-1}frontend,cn=config
changetype: modify
add: olcPasswordHash
olcPasswordHash: {ARGON2}

Wichtig ist hier, dass der Passwordhash in der Datenbank {-1}frontend,cn=config eingetragen wird und nicht direkt in cn=config.

Nach dem jetzt der OpenLDAP-Server den Passwordhash kennt, soll jetzt als erstes das Passwort des rootdn umgestellt werden. Durch die Umstellung des Passworts des rootdn können Sie auch gleich testen, ob die Authentifizierung mittels eines Argon2-Passworts funktioniert. Das folgende Listing zeigt die Änderung des Passworts:

dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcRootPW
olcRootPW: {ARGON2}$argon2i$v=19$m=4096,t=3,p=

1$MTIzNDU2Nzg5$t0cMsY/yM7a2wxx

btHWiTtEso2cW2iKrsOHvVCa0+A

Aber warum jetzt Argon2 und nicht mehr SSHA oder PBKDF2 als Passwordhash? Bei diesen Passwordhashes kann, mit relativ preiswerter Hardware ein Brute-Force Angriff auf die Passwörter durchgeführt werden. Oft werden hierfür Grafikprozessoren benutzt. Was dieser preiswerten und schnellen Hardware aber fehlt, ist Arbeitsspeicher. Da kommt dann Argon2 ins Spiel, denn Argon2 erzeugt große Vektoren im Arbeitsspeicher, wie viel Speicher dafür benötigt wird, kann beim erzeugen des Passworts festgelegt werden. Mehr zu Argon2 gibt es hier. Zu beschreiben, wie jetzt welche Parameter beim erzeugen eines Passworts gesetzt werden sollten, würde den Rahmen hier sprengen. Ein guter Einstig zu dem Thema finden Sie hier.

Das Passwort für den rootdn wurde von mir mit den Standardwerten von Argon2 erzeugt. Das Passwort habe ich mit dem folgenden Kommando erzeugt:

echo -n „geheim“ | argon2 „123455678“ -e

Das Passwort ist später „geheim“, „12345678“ ist der salt-Wert für den Passwordhash.

Jetzt können Sie, mittels „ldapsearch -x -D cn=admin,dc=example,dc=net -W -LLL“ den LDAP-Baum abfragen. Wenn das klappt, funktioniert auch der Passwordhash in Argon2.

Um die Passwörter in Argons2 und später auch TOTP testen zu können, habe ich eine OU „ou=users,dc=example,dc=net“ angelegt in der alle neuen Benutzer abgelegt werden. Den ersten Benutzer sehen Sie in der folgenden LDIF-Datei:

dn: cn=u1,ou=users,dc=example,dc=net
objectClass: posixAccount
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
loginShell: /bin/bash
homeDirectory: /home/u1
uid: u1
uidNumber: 10010
gidNumber: 10000
sn: u
givenName: 1
userPassword: {ARGON2}$argon2i$v=19$m=4096,t=3,p=

1$MTIzNDU2Nzg5$t0cMJsY/yM7a2w

xxbtHWiTtEso2cW2iKrsOHvVCa0+A
cn: u1

Nach dem Anlegen des Benutzers können sie auch hier wieder mit ldapsearch testen, ob eine Authentifizierung mit dem Argon2-Passwort möglich ist. Damit ist der erste Schritt zur zwei-Faktoren-Authentifizierung mit sicherem Passwort schon abgeschlossen.

Jetzt kommt der zweite Teil, Einrichten von TOTP mit dem neuen OpenLDAP-Modul otp.la. Das Modul muss als erstes geladen werden, dafür sehen Sie hier die folgenden LDIF-Datei:

dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: {2}otp.la

Jetzt tragen Sie noch mittels einer LDIF-Datei das Overlay in die Objektdatenbank ein:

dn: olcOverlay=otp,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig

Achten Sie bei der Nummerierung der Datenbank auf Ihre Konfiguration.

Die manpage zu slapo-otp beschreibt zwar alle Parameter die benötigt werden genau, aber wie jetzt welcher Parameter zu setzen ist, fehlt ganz. Was sagen Entwickler dazu? „Wieso Dokumentation, steht doch alles im Quellcode!“ Im folgenden Listing sehen Sie die Konfiguration für TOTP:

dn: ou=users,dc=example,dc=net
changetype: modify
add: objectClass
objectClass: oathTOTPParams
–
add: oathOTPLength
oathOTPLength: 6
–
add: oathHMACAlgorithm
# choose SHA1, algorithm OIDs are specified in RFC 8018
oathHMACAlgorithm: 1.2.840.113549.2.7
–
add: oathTOTPTimeStepPeriod
oathTOTPTimeStepPeriod: 30
–
add: oathTOTPTimeStepWindow
oathTOTPTimeStepWindow: 3

Hier werden für die OU ou=users,dc=example,dc=net drei Parameter gesetzt:
– oathOTPLength: 6 (Die Länge des OTP-Tokens für den zweiten Faktor)
– oathHMACAlgorithm: 1.2.840.113549.2.7 (Der ODI für den Verschlüsselungsalgorithmus)
– oathTOTPTimeStepPeriod: 30 (Die Dauer der Gültigkeit des Tokens)
– oathTOTPTimeStepWindow: 3 (maximales Gültigkeitsfenster hier 3*30 Sekunden)

Dieses sind die Standardwerte, die auch vom Googleauthenticator und freeOTP+ genutzt werden.

Die Parameter werden immer eine OU zugewiesen und könne anschließend an die Benutzer übergeben werden.

Jetzt wird ein sharedkey für die Errechnung des Tokens benötigt, die folgenden Kommandos erstellen eine Datei mit einem sharedkey im data-Format:

  • $ touch sharedkey
    $ chmod 600 sharedkey
    $ openssl rand 20 > sharedkey
    $ base32 sharedkey
    7XNAA3KOAFGUTBSPWUGTNC6OSKMRKANW

Das Ergebnis ist der Schlüssel der in die entsprechende App, z.B. Googleauthenticator, eingetragen werden muss, aus der dann der sechs-Stellige Token generiert wird.

Jetzt fehlt nur noch die Anpassung des Benutzers. Dazu erzeugen Sie eine LDIF-Datei mit dem folgenden Inhalt:

dn: cn=u1,ou=users,dc=example,dc=net
changetype: modify
add: objectClass
objectClass: oathTOTPToken
–
add: oathTOTPParams
oathTOTPParams: ou=users,dc=example,dc=net
–
add: oathSecret
oathSecret:< file:///root/sharedkey
–
add: objectClass
objectClass: oathTOTPUser
–
add: oathTOTPToken
oathTOTPToken: cn=u1,ou=users,dc=example,dc=net

Damit wird das Benutzerobjekt um die benötigten Parameter erweitert. Damit der Benutzer den Schlüssel nicht von Hand in die App eintragen muss, kann aus dem Schlüssel ein QR-Code erzeugt werden, der dann einfach mit der App gescanned werden kann.

Ist der Schlüssel eingetragen, kann der erste Test mit dem Benutzer durchgeführt werden. Einfach ein:

ldapsearch -x -D cn=u1,ou=users,dc=example,dc=net“ -W -LLL

Ausführen. Bei der Fragen nach dem Passwort geben Sie als erstes das Passwort ein, unmittelbar im Anschluss den sechs-Stelligen Token, z.B „geheim123456“ Ohne Leer- oder Trennzeichen.

Das war es dann schon, jetzt können Sie nach und nach alle Benutzer auf eine zwei-Faktoren-Authentifizierung umstellen.

Damit die Anwender nicht den Schlüssel in die App eintragen müssen, ist es sinnvoll einen QR-Code aus dem Schlüssel zu erstellen, der dann eingescanned werden kann. Dazu wird das Programm qrencode benötigt. Erst wird der Text für den QR-Code erstellt und anschließend der QR-Code.

QR=“otpauth://totp/ldap:u1@example.net?secret=7XNAA3KOAFGUTBSPWUGTNC6OSKMRKANW&issuer=stka&30&digits=6&algorithm=SHA1″
echo $QR | qrencode -s9 -o u1@example.net.png

Selbstverständlich können Sie den Text für den QR-Code auch direkt an das Programm übergeben.

Das war der zweite Teil zur zwei-Faktoren-Authentifizierung. Ich denke, ein Teil wird noch kommen. Darin wird es dann wieder darum gehen, dass ganze über Ansible einzurichten.

Posted in LDAP | Tagged , , , | Leave a comment

Der Fehlerteufel hat beim letzten Artikel zugeschlagen

Posted on 8. Juni 2021 by Stefan

Leider ist mir beim erstellen des tar-Files für die Rollen ein Fehler unterlaufen, der LDAP-Server wird leider nach der Installation mit der Rolle nicht starten. Problem ist, das Attribut „olcPasswordHash“ habe ich dort (wie bei anderen Konfigurationen auch) direkt nach cn=config geschrieben, die neuen Passwordhashes wie {TOTP} müssen aber unter {-1}frontend eingetragen werden. Ich habe das entsprechende Skript geändert neu Verlinkt. Wenn Sie die Dateien schon runtergeladen haben, dann einfach erneut runterladen. Oder einfach diesem Link hier folgen, da sind auch die richtigen Dateien hinterlegt. 

Posted in Allgemein | Leave a comment

OpenLDAP 2.5 mit TOPT und autoca

Posted on 26. Mai 2021 by Stefan

Seit einiger Zeit gibt es nun endlich den OpenLDAP 2.5. Lange wurde er angekündigt. Ich habe hier die Version 2.5.4 genutzt um die beiden neuen Overlays autoca und totp einzurichten und zu testen. Da es noch keine Pakete für Debian 10 gibt, habe ich OpenLDAP aus den Quellen gebaut. Um bei späteren Versionen möglichst schnell einen Server einrichten zu können, habe ich hier wieder voll auf Ansible gesetzt. Ich habe eine neue Rolle definiert, die folgende Tasks durchführt:

  • Installation der Build-Umgebung mit allen Abhängigkeiten
  • Download der Quellen vom OpenLDAP
  • Bauen des OpenLDAP und allen benötigten Modulen
  •  Einrichten der Systemd-Skripte zum Start des OpenLDAP
  • Konfigurieren des OpenLDAP über ein Template
  • Einspielen der ersten Objekte
  • Anlegen eines simpleSecurityObjecs ldap-admin. Dieses Objekt hat alle Rechte an allen Objekten 
  • Anlegen eines simpleSecurityObjects repl-user später für die Replikation genutzt werden soll
  • Einrichten der Overlays autoca und totp

Um totp anschließend testen zu können, habe ich in der rolle openldap25 im Verzeichnis files ein Skript (create-qr.bash) abgelegt, dass den shared-key und den QR-Code für einen Benutzer erstellt.
Das Overlay autoca erzeugt für jeden Benutzer, ein Client-Zertifikat. Das Zertifikat wird bei einer Suche nach dem entsprechenden Attribut im Objekt des Benutzer abgelegt. Auch dieser Schritt wird mit dem Script durchgeführt.
 In der aktuellen Konfiguration wird lediglich die Anmeldung mit einem TOTP eingerichtet. Durch Anpassung des Passwort-Hashes ist es auch möglich, auf eine zwei Faktoren Authentifizierung umzustellen. Die Umstellung werde ich hier zu einem späteren Zeitpunkt ergänzen. 

Die benötigten Rollen um den Server einzurichten finden Sie HIER.

Posted in Allgemein | Leave a comment

Benutzer gelöscht

Posted on 5. Mai 2021 by Stefan

Ich bin heute mal durch die List der hier angemeldeten Benutzer gegangen und habe aufgeräumt. Dabei habe ich alle Konten gelöscht, deren Emaildomäne nicht auflösbar war. Auch habe ich einige Benutzer gelöscht mit kryptischen Namen und die dazu auch keinen echten Namen angegeben haben. Sollte ich jemande gelöscht haben der hier noch aktiv ließt und unter einen der Kategorien gefallen sein, dann tut es mir Leid. Bitte dann einfach neu Anmelden und eine Emailadresse verwenden die  nachvollziehbar ist, In Zukunft werde ich alle Benutzer, die sich mit einer Wegwerfadresse registrieren sofort löschen. Sonst wird das für mich zu unübersichtlich.

Posted in Allgemein | Leave a comment

Ein neues Samba-Buch entsteht

Posted on 5. Mai 2021 by Stefan

Im Januar dieses Jahres ist die aktuelle Samba-Version 4.14 erschienen, dank Louis van Belle und Björn Baumbach konnte ich vom ersten Tag an auf Pakte für Debian zugreifen und sie für die neue Auflage nutzen.

Das ist das erste Mal, dass ich in so einem frühen Stadium mit dem Schreiben eines neuen Buchs begonnen habe. Wie zu erwarten, wenn man ein Buch mit dem rc1 Release beginnt, habe ich den einen oder anderen Bug gefunden. Gerade bei ganz neuen Möglichkeiten die die neue Version bringt, hakte es dann doch noch an der einen oder anderen Stelle. Diese Bugs wurden aber alle bis zur Version 4.14.2 behoben und so sind jetzt alle von mir beschrieben Neuerungen auch produktiv nutzbar.

Durch den frühen Zugriff wird diese Auflage (die im Juli oder August erscheinen wird) die erste Auflage sein, die auf der aktuellen Samba-Version beim Erscheinen basiert.

Von Anfang an war mir klar, dass ich einige Dinge aus dem Buch nehme will, dafür aber andere Dinge neu aufgenommen werden sollen. Raus gefallen ist der gesamte Abschnitt zum Kompilieren von Samba, denn es gibt heute so viele Möglichkeiten auf aktuelle Pakete zuzugreifen, dass ein selber kompilieren nicht mehr unbedingt erforderlich ist. Durch die Komplexität der neuen Version sind die Abhängigkeiten auch so viele, dass der Abschnitt, hätte ich ihn weiter gepflegt, zu groß geworden wäre. Insgesamt sind gut 50 bis 70 Seiten komplett aus der neuen Auflage raus gefallen, aber die Auflage hat trotzdem fast 100 Seiten mehr als die letzte Auflage. Sie sehen, ich habe viele neue Dinge aufgenommen. Bei den neuen Abschnitten geht es darum bestimmte Techniken der Administration noch besser zu erklären.

Damit Sie schon einmal einen kurzen Überblick über die kommenden Änderungen erhalten, hier eine (nicht vollständige) Auflistung der neuen Inhalte:

  • Erweiterte Verwaltung  von Freigaben
  • Einrichtung der Heimatverzeichnisse via GPO
  • Einrichtung von servergespeicherten Profilen via GPO
  • Umleitung der Ordner aus Profilen via GPO
  • Einrichten der neuen GPOs für Linux-Clients
  • Recovery eine Domäne
  • Neue Möglichkeiten mit dem Kommando samba-tool
  • Einrichten einer Domäne mit mehreren Domaincontrollern mittels Ansible

Selbstverständlich wurden die bestehenden Kapitel alle überarbeitet. So ist in doch relativ kurzer Zeit eine komplett überarbeitete Auflage entstanden. Das es dieses Mal so schnell ging, hat auch was mit der derzeitigen Corona-Situation zu tun, denn dank Homeoffice hatte ich auch viel Zeit am Buch arbeiten zu können.

Ich hoffe das auch diese Auflage wieder ein Erfolg wird und wie immer, freue ich mich über Feedbacks zum Buch. Lob sowieso, Kritik aber auch, solange sie konstruktiv ist.

Jetzt heißt es warten 

Posted in Allgemein, Samba | Tagged | Leave a comment

Die neue Auflage vom Linux-Server Buch ist da

Posted on 25. April 2021 by Stefan

Im Februar 2011 ist die erste Auflage des Linux-Server Buchs erschienen. Jetzt, 10 Jahren später ist es schon die sechste Auflage. Am Anfang waren es noch gerade 900 Seiten, dieses Mal mussten wir aufpassen, dass wir nicht das Maximum von 1300 Seiten überschreiten. Es hat geklappt es sind jetzt fast genau 1300 Seiten. Viele neu Dinge sind ins Buch gekommen und noch mehr wurde überarbeitet. Von mir wurden vor allen Dingen die Kapitel zum LDAP, Kerberos und Samba komplett überarbeitet. Die wohl größte Neuerung ist, dass ich sowohl im Kapitel LDAP als auch im Kapitel Kerberos neben der statischen Konfiguration des LDAPs auch die dynamische Konfiguration beschreibe. Bleibt mir nur, Ihnen viel Spaß beim Lesen zu wünschen.

Posted in Allgemein | Leave a comment

Loghost mit journald

Posted on 4. Februar 2021 by Stefan

Heute möchte ich mal zeigen, wie einfach es ist mithilfe des journald einen zentralen Loghost einzurichten.

Wie auch mit einigen der älteren Log-Daemons, lässt sich mit dem journald ein Log-Host einrichten um alle Meldungen Ihrer Server zentral an einer Stelle zu speichern. Die Übertragung der Daten wird dabei über TLS verschlüsselt, sodass ein Mitlesen mit einem Netzwerksniffer nicht möglich ist.

Für das Beispiel werde ich einen LDAP-Server als Log-Client einrichten, der seine Log-Informationen dann auf den Log-Host speichert. Auf allen Clients und dem Server installieren Sie das Paket systemd-journal-remote.

Achten Sie bei der Einrichtung des Servers darauf, dass Sie ausreichend Festplattenplatz bereitgestellt haben. Je mehr Clients die Logs dort ablegen und je länger Sie die Logs speichern wollen, um so mehr Plattenplatz wird benötigt. Damit der Server, für den Fall, dass der Plattenplatz nicht ausreicht, nicht abstürzt, lagern Sie das Verzeichnis /var auf eine eigene Partition aus. Die Standardgröße einer Log-Datei ist 8 MB, auch wenn noch keine Meldungen im Log eingetragen sind.

Im ersten Schritt aktivieren Sie den Dienst und den dazugehörigen Socket auf dem Server, über den sich die Clients verbinden. Das folgende Listing zeigt die entsprechenden Kommandos:

root@loghost:~# systemctl enable –now systemd-journal-remote.socket
Created symlink /etc/systemd/system/sockets.target.wants/systemd-
journal-remote.socket -> /lib/systemd/system/systemd-journal-remote.socket.
root@loghost:~# systemctl enable systemd-journal-remote.service

Im ersten Kommando wird der Dienst durch die Option –now sofort gestartet. Der zweite Dienst wird erst gestartet wenn Sie das TLS-Zertifikat bereitgestellt haben. Der Port, der hier verwendet wird, ist der Port 19532. Prüfen Sie mit dem Kommando ss, ob der Port geöffnet wurde.

Erstellen Sie ein Zertifikat für den Server, falls noch keins vorhanden ist.

Auf allen Clients, die sich mit dem Log-Host verbinden sollen, aktivieren Sie jetzt auch den systemd-journal-remote.service. Auch auf den Clients wird der Dienst aber noch nicht gestartet.

Einrichten des Servers

Die Konfiguration des Log-Servers finden Sie in der Datei /etc/systemd/journal-remote.conf. In der Datei sind schon bestimmte Vorgaben vorhanden, die aber alle auskommentiert sind. Im folgenden Listing sehen Sie die Datei für unser Beispiel:

[Remote]
# Seal=false
SplitMode=host
ServerKeyFile=/etc/ssl/zertifikate/loghost-key.pem
ServerCertificateFile=/etc/ssl/zertifikate/loghost-cert.pem
TrustedCertificateFile=/etc/ssl/zertifikate/demoCA/cacert.pem

Die Variablen haben die folgenden Bedeutungen:

Seal
Wenn Sie maximale Sicherheit haben wollen, was das Manipulieren der Einträge angeht, können Sie diese Variable aktivieren und auf true setzen. Dann werden die einzelnen Einträge zusätzlich signiert.

SplitMode
Alle Einträge, werden aufgrund des Hostnamen, in eigene Dateien gespeichert. Das verbessert die Übersichtlichkeit der Daten, gerade wenn Sie viele Hosts auf dem Server loggen wollen.

ServerKeyFile
Der Pfad und der der Name des Keyfiles Ihres Zertifikats.

ServerCertificateFile
Der Name und der Pfad zum Zertifikat.

TrustedCertificateFile
Der Name und Pfad zum root-Zertifikat. Ohne diese Angabe das kann die Gültigkeit der Zertifikate nicht geprüft werden.

Damit die Zertifikate auch vom Log-Daemon genutzt werden können, ist es notwendig, dass Sie die Rechte wie im folgenden Listing anpassen:

root@loghost:~# chgrp systemd-journal-remote /etc/ssl/zertifikate/loghost-*
root@loghost:~# chmod 640 /etc/ssl/zertifikate/loghost-*

Sollten Sie das Zertifikat auch noch für andere Dienste benötigen, setzen Sie die erweiterten Dateisystem-ACLs für die Gruppe.

Erst jetzt können Sie den Dienst mit dem Kommando systemctl start systemd-journal-remote.service starten. Danach ist der Log-Host bereit, die Log-Daten der Clients anzunehmen.

Einrichten des Clients

Nachdem der Server im vorherigen Abschnitt eingerichtet wurde, geht es jetzt darum, den ersten Client anzubinden, der seine Log-Daten an den Log-Server schickt.

Für die Übermittlung der Daten wird ein eigener Benutzer benötigt. Legen Sie einen neuen Benutzer an, indem Sie das Kommando aus dem folgenden Listing übernehmen:

root@loghost:~# adduser –system –home /run/systemd –no-create-home \
–disabled-login –group systemd-journal-upload
Lege Systembenutzer »systemd-journal-upload« (UID 107) an …
Lege neue Gruppe »systemd-journal-upload« (GID 113) an …
Lege neuen Benutzer »systemd-journal-upload« (UID 107) mit \
Gruppe »systemd-journal-upload« an …
Erstelle Home-Verzeichnis »/run/systemd« nicht.

Bei dem neuen Benutzer handelt es sich um einen Systembenutzer, der sich nicht lokal anmelden kann. Vergeben Sie auch kein Passwort für den Benutzer.

Sorgen Sie auf dem Client dafür, dass das Zertifikat von der Gruppe systemd-journal-remote gelesen werden kann.

Auch auf dem Client folgt jetzt die Anpassung der Konfiguration, dieses Mal in der Datei /etc/systemd/journal-upload.conf. Auch auf dem Client ist die Datei schon vorhanden, aber alle Optionen sind noch auskommentiert. Im folgenden Listing sehen Sie die an mein Beispiele angepasste Datei:

[Upload]
URL=https://loghost.example.net:19532
ServerKeyFile=/etc/ssl/zertifikate/provider-stat-key.pem
ServerCertificateFile=/etc/ssl/zertifikate/provider-stat-cert.pem
TrustedCertificateFile=/etc/ssl/zertifikate/demoCA/cacert.pem

Im Unterschied zur Konfiguration des Servers, wird hier die URL angegeben, unter der der Server erreichbar ist. Die drei Zeilen für die Zertifikate sind identisch mit denen auf dem Server.

Starten Sie den Log-Daemon jetzt mit dem Kommando systemctl restart systemd-journal-upload.service auf dem Client.

Testen der Log-Umgebung

Wechseln Sie auf den Log-Server, und lassen Sie sich den Inhalt des Verzeichnisses /var/log/journal/remote anzeigen. Dort sehen Sie jetzt eine neue Datei. Ihr Name enthält den vollständigen Namens des Clients, wie er im Zertifikat genannt ist. Einen Eintrag zu meinem Beispiel sehen Sie im folgenden Listing:

root@loghost:~# ls /var/log/journal/remote/
‚remote-C=DE,ST=SH,L=St.\\x20Michel,O=Adminbuch,OU=CA\
,CN=provider-stat.example.net.journal‘

Sollten Sie, so wie im Beispiel, ein Leerzeichen im Namen des Zertifikats haben, dann wird das Leerzeichen durch die Zeichenfolge \x20 ersetzt. Der Backslash muss später, beim einlesen der Datei, zusätzlich mit einem Backslash entwertet werden, auch wenn Sie den Pfad in gerade Hochkommata setzen.

Ist die Datei vorhanden, hat alles geklappt und der Server nimmt Meldungen vom Client entgegen. Sie können jetzt warten, bis der Client eine Nachricht generiert und auf den Server überträgt. Sie können aber auch selber eine Testmeldung mit dem Kommando logger generiert,  so wie im folgenden Listing:

root@provider-stat:~# logger -p syslog.debug „Das ist ein Test vom \\
Client provider-stat“

Auf dem Log-Server können Sie jetzt das Log genau so auswerten, wie ich es in den Abschnitten vorher beschrieben habe, aber mit einen Unterschied, als Quelle geben Sie die Datei des Clients an, den Sie auswerten wollen. In folgenden Listing sehen Sie das Kommando und das Ergebnis der durch logger erzeugten Meldung:

root@loghost:~# journalctl –file=’/var/log/journal/remote/remote-C=DE\
,ST=SH,L=St.\\x20Michel,O=Adminbuch,OU=CA,CN=provider-stat.\
example.net.journal‘

Jan 11 19:48:18 provider-stat root[1081]: Das ist ein Test vom Client\ provider-stat\

So können Sie jetzt alle weiteren Clients einrichten und testen und haben damit eine zentrale Log-Umgebung geschaffen.

Posted in Allgemein | Tagged , | Leave a comment

OpenLDAP und Kerberos, es wächst zusammen was zusammen gehört

Posted on 18. Januar 2021 by Stefan

Immer wieder sehe ich  bei Kunden, dass sie zwar einen OpenLDAP-Server einsetzen, den in den meisten Fällen auch via TLS absichern, wenn es um Verbindungen zum und zwischen den OpenLDAP-Server geht, aber in den seltensten Fällen wird zusätzlich Kerberos eingesetzt um die Sicherheit zu erhöhen. Die folgenden Gründe werde dann immer angeführt:

  • Der Aufwand ist zu hoch.
  • Nur ein geringer Sicherheitsgewinn.
  • Die Pflege des Kerberos ist zu aufwendig.
  • Die Schulung der Mitarbeiter ist zu aufwendig.
  • Zu lange Einarbeitungszeiten.

Noch besser sind dann die folgenden Argumente die auch immer mal wieder auftauchen:

  • Wir nutzen doch schon TLS das muss reichen.
  • Hier kommt eh niemand rein.
  • Viel zu kompliziert.

Aber was stimmt denn nun?
Klar, Kerberos ist nicht in einem Tag gelernt, verstanden und implementiert. Die Einführung von Kerberos benötigt eine gute Planung und ausgebildete Administratoren. Aber der Sicherheitsgewinn rechtfertigt die Einführung auf jeden Fall. 

Welchen Mehrwert bietet mir Kerberos in Zusammenarbeit mit OpenLDAP? 
Da sich nicht nur Benutzer authentifizieren müssen, sondern die Authentifizierung auf Dienste und Hosts erweitert wird, steigt die Sicherheit. Denn nur System und Dienste die im Kerberos ein Konto (Principal) besitzen können sich überhaupt gegen den Kerbeors-Server authentifizieren und die Anmeldetickets (TGT) der Benutzer zur Authentifizierung nutzen. Ein weiterer wichtiger Punkt ist der, dass bei der Authentifizierung zu keiner Zeit Passwörter, seien sie verschlüsselt oder gar unverschlüsselt, über das Netzwerk übertragen werden. Der gesamte Authentifizierungsprozess findet über Tokens statt. Auch die Übertragung von Daten kann, wie zum Beispiel bei der Datenübertragung über NFS, mittels Kerberos verschlüsselt werden, so dass die Daten nicht im Netz abgefangen werden können. Auf einen kerbereisierten NFS-Server kann so auch neben der Hostauthentifizierung eine Benutzerauthentifizierung durchgeführt werden. Denn ein Benutzer der keine TGT besitzt, kann auch nicht mehr auf den NFS-Server zugreifen. Die Sicherheit im Netz steigt.
Zusammen mit Kerberos können Sie alle Abfragen an den OpenLDAP-Server mittels strong-bind durchführen und sind nicht mehr auf den simple-bind angewiesen. Der Vorteil dabei liegt ganz klar auf der Hand. Beim simple-bind ist es notwendig die Passwörter, für zum Beispiele die Replikation der OpenLDAP-Server, in Klartext in die Konfgurationsdatei zu schreiben. Bei der Verwendung von strong-bind mittels Kerberos findet die Authentifizierung bei der Replikation über Tickets statt. Der Dienst authentifiziert sich mit seinem Principal und einer verschlüsselten Keytab-Datei. So können keine Passwörter mehr aus der Konfiguration gelesen werden.
Einen ganz großen Vorteil habe ich hier noch gar nicht erwähnt: In einer vollständig kerbereisierten Umgebung geben die Benutzer nur noch einmal, bei der Anmeldung am System, ihr Passwort ein. Alle weiteren Anmeldungen an Hosts oder Services werden, automatisch und im Hintegrund, über Tickets durchgeführt. Sie erhalten eine Singel-sign-on Umgebung.
Das sind nur ein paar der Vorteile die Ihnen Kerberos bietet.

Aber Kerberos ist doch so kompliziert!
Das Verfahren wie die Authentifizierung durchgeführt wird ist schon recht komplex und Sie benötigen schon einige Zeit um die komplette Funktion des Kerberos zu verstehen. Aber muss man da alles verstehen? Verstehen Sie die vollständige Arbeitsweise vom Active Directory (Was im übrigen auch Kerberos nutzt) oder können Sie mir erklären wie die Assistentssysteme Ihres Autos funktionieren? Aber Sie fahren Auto oder :-)?
Gerade wenn Sie Kerberos zusammen mit OpenLDAP nutzen und für die Verwaltung der Objekte dann noch den LDAP Account Manger in der Pro Version einsetzen, dann ist die Verwaltung der LDAP-Umgebung einfach. Klar können Sie OpenLDAP und Kerberos auch komplett ohne grafisches Werkzeug nutzen, aber so ein grafisches Werkzeug erleichtert die Sache manchmal und lässt Ihnen die Möglichkeit Aufgaben der Benutzerverwaltung zu delegieren. Wenn Sie Kerberos zusammen mit OpenLDAP betreiben fällt auch die Replikation der Kerberos-Datenbank weg, denn alle Kerberos-Informationen liegen im LDAP und die Ausfallsicherheit realisieren Sie über die Replikation der LDAP-Server. Die Kerberos-Server verbinden sich alle gegen den LDAP und nutzen den selben Datenbestand.

Wie funktioniert Kerberos?
Das hier komplett zu erklären würde den Rahmen erheblich sprengen, aber trotzdem möchte ich das ganze mal versuchen recht einfach zu erklären:
Jeder Teilnehmer an der Authentifizierung über Kerberos benötigt einen Prinicipal mit einem Credential (Passwort) in der Datenbank. Bei Benutzern ist es das Passwort, das der Benutzer bei der Anmeldung angeben muss,  Hosts und Services könne schlecht selber ein Passwort eingeben, sie bekommen eine Keytab-Datei mit einem verschlüsselten Passwort. So können sich alle  Teilnehmer gegen den Kerberos-Server authentifizieren. Ein Benutzer der sich Angemeldet hat, erhält vom Kerberos-Server ein Ticket (TGT). Dieses Ticket hat nur eine begrenze Gültigkeit. Wenn der Benutzer jetzt auf einen Dienst eines anderen Server zugreifen möchte, wird der Service, der sich ja auch gegen den Kerberos authentifiziert hat, das Ticket anfordern. Im Hintergrund wird das TGT an den Service übertragen, da der Service dem Kerberos-Server vertraut und das TGT vom Kerberos-Server ausgestellt wurde, vertraut der Service dem TGT und fragt nicht mehr den Kerberos-Server. Nach der erfolgreichen Anmeldung übermittelt der Service eine Service-Ticket an den Client des Benutzers. Das Ticket wird dort gespeichert und bei einem weiteren Zugriff überträgt der Client das Service-Ticket, da das Service-Ticket vom Kerberos-Server erstellt wurde, vertraut der Client dem Service-Ticket. 
Klar, der gesamte Prozess ist etwas komplizierter (wie ihr ABS im Auto) aber um die Funktion annähernd zu erklären, denke ich, reicht es aus.

Fazit:
Keine Angst vor Kerberos

Posted in LDAP | Leave a comment

Jetzt auch mit Videokonferenz

Posted on 17. Dezember 2020 by Stefan

Ab sofort kann ich Schulungen und Consulting auch via Videokonferenz anbieten. Dank mailbox.org geschieht das ganze DSGVO-konform und ohne zusätzliche Software, einfach über einen Browser. Verwendet wird dort die opensource Lösung jitsi. Bis zu 9 Teilnehmern sind möglich. Alle meine Themen können durchgeführt werden. Für bis zu vier Teilnehmern kann ich auch die Schulungsumgebung einrichten und via SSH bereitstellen.

Posted in Allgemein | Leave a comment

Kurze Einführung in Business Intelligence von checkmk

Posted on 2. Dezember 2020 by Stefan

Heute geht es mal um ein ganz anderes Thema, um checkmk. Wer bereits checkmk einsetzt wird vielleicht schon mal über das WATO-Modul Business Intelligence (BI) gestolpert sein. Für die, die sich noch nie mit dem Thema auseinandergesetzt haben, soll dieses kleine Beispiel sein.

Mit BI können Sie zusammenhängende Dienste in Abhängigkeit bringen und das Gesamtergebnis darstellen.

Stellen Sie sich vor, Sie betreiben eine Webseite die über mehrer Webserver bereitgestellt wird, zusätzlich kommen noch mehrere Datenbank-Server im Cluster dazu. Jede einzelne Komponente, sprich Sever, kann bei einem Ausfall die Bereitstellung der Webseite nicht unterbrechen. Alle Dienste sind redundant ausgelegt. Fällt also einer von drei Webserver und zusätzlich noch einer von drei Datenbankserver aus, kann der Service „Webseite“ immer noch bereitgestellt werden. Diese Abhängigkeiten können mit BI abgebildet werden. In dem kleinen Beispiel (die Anleitung finden Sie hier) sehen Sie, wie Sie die Internetverbindung Ihres Unternehmens mit BI darstellen können und wie Sie die Darstellung auch dafür nutzen können beim Ausfall des Internets eine Meldung zu erzeugen.

In der aktuellen Version gibt es zwar eine einfachere Lösung der Überprüfung des Internets, aber darum solle es hier nicht gehen. Dieser Artikel soll Ihnen BI an Hand eines kleine Beispiels näherbringen.

Viele Spaß beim Ausprobieren

Posted in checkmk | Leave a comment