Debian 12 Samba DC und NTP

Bei der Einrichtung eines Samba Domaincontrollers wird immer auch ein Zeitserver benötigt, bei diesem holen sich die Windows-Clients die aktuelle Zeit. In meinem Buch (und auch an anderen Stellen) wird dafür meist der ntp genutzt. Leider gibt es ein Problem mit Debian 12 und ntp in Verbindung mit einem Samba DC. Die Pakete, die der DC an den Client sendet, müssen vom DC signiert werden. Samba stellt dafür extra einen Socket bereit. Jetzt hat Debian 12 aber von ntp zu ntpsec gewechselt, um Verbindungen zum Zeitserver gesichert durchführen zu können. Nur ist bei ntpsec die Funktion, die der Samba DC benötigt, um die Pakete signieren zu können, fehlerhaft. Wenn Sie also einen Domaincontroller unter Debian 12 einrichten wollen (die Samba-Version spielt dabei keine Rolle), sollten Sie auf jeden Fall auf chrony umsteigen.  Hier sehen Sie eine crony.conf in einer Grundkonfiguration die auf jeden Fall zusammen mit einem Domaincontroller funktioniert:

keyfile /etc/chrony/chrony.keys
driftfile /var/lib/chrony/chrony.drift
logdir /var/log/chrony
maxupdates

/etc/adjtime
rtcsync
makestep 1 3

#IP-Address of this DC
bindcmdaddress 192.168.56.201
server 0.pool.ntp.org     iburst
server 1.pool.ntp.org     iburst
server 2.pool.ntp.org     iburst

#DNS netmask
allow 192.168.56.0/24  
ntpsigndsocket  /var/lib/ntp_signd

Nach der Einrichtung müssen Sie auf jeden Fall das Verzeichnis /var/lib/samba/ntp_signd der Gruppe _chrony zuordnen (Ja, der Gruppenname beginnt mit einem Unterstrich) , damit der chrony auch auf den Socket zugreifen kann.

So können Sie dann auch wieder die Zeit an die Windows-Clients vergeben. 

Posted in Samba | Tagged , , | Leave a comment

Samba 4.19 und Function Level 2016

Mit der Samba-Version 4.19 wurde das Functional Level (FL) auf die Version 2016 aktualisiert. Bis jetzt war hier lediglich die Version 2008_R2 möglich. Jetzt werden die FL 2012, 2012R2 und 2016 unterstützt. Wenn eine komplett neue Domäne mit Samba 4.19 eingerichtet wird, das wird automatisch das neue FL 2016 genutzt. Eine bestehende Domäne wird nicht automatisch auf das neu FL angehoben. Das muss von Hand eingerichtet werden.

Was bringt das neue FL?

Das FL 2016 unterstützt jetzt Authentication-Policies und Authentication-Silos sowie den Einsatz von Claims. Bei allen drei Funktionen handelt es sich um zusätzliche Sicherheitsfunktionen. Das neue FL wird im Moment noch nicht von Samba direkt unterstützt. Das heißt, auf Samba-Servern oder Samba-Clients können diese zusätzlichen Funktionen noch nicht genutzt werden. Nur die Domaincontroller unterstützen das neu FL. Windows-Clients und Windows-Server in der Domäne können diese Funktionen schon nutzen.
Leider sind die die Funktionen noch nicht vollständig umgesetzt. Aus diesem Grund würde ich mit ein Update auf 4.19 zusammen mit dem wechsel das FL noch nicht durchführen. Erst in einer der nächsten Version sollte der Wechsel des FL durchgeführt werden. Wird das neue FL aber benötigt, kann eine bestehende Domäne mit den folgenden Schritten auf das FL 2016 aktualisiert werden.

1. Installation der Version 4.19 auf allen Domaincontroller

2. Sorgen Sie dafür, dass der Dienst neue gestartet wird.

3. Kontrollieren Sie das aktuelle FL:
samba-tool domain level show
Domain and forest function level for domain ‚DC=example,DC=net‘

Forest function level: (Windows) 2008 R2
Domain function level: (Windows) 2008 R2
Lowest function level of a DC: (Windows) 2008 R2

4. Fügen Sie die folgende Zeil in der [global] Section in der smb.conf ein:

ad dc functional level = 2016

5. Starten Sie den Dienst neu und prüfen Sie erneut das FL. Wichtig ist, dass Sie diesen Eintrag auf allen Domaincontrollern in die smb.conf schreiben und bei allen Domaincontrollern anschließend den Dienst neustarten. Nur dann kann der nächste Schritt erfolgreich durchgeführt werden.

samba-tool domain level show
Domain and forest function level for domain ‚DC=example,DC=net‘

Forest function level: (Windows) 2008 R2
Domain function level: (Windows) 2008 R2
Lowest function level of a DC: (Windows) 2016

Das FL steht jetzt schon auf 2016. Fehlen noch das Forest- und das Domain FL. Um diese beiden Level anzupassen führen Sie die folgenden Kommandos aus.

samba-tool domain schemaupgrade –schema=2019

Ja 2019 ist hier korrekt. Das Schema 2019 wird schon unterstützt. Verwechseln Sie das Schema nicht mit dem FL

samba-tool domain functionalprep –function-level=2016

samba-tool domain level raise –domain-level=2016 –forest-level=2016

Ein Neustart des Dienstes ist jetzt nicht mehr notwendig. Prüfen Sie jetzt erneut das aktuelle FL

samba-tool domain level show
Domain and forest function level for domain ‚DC=example,DC=net‘

Forest function level: (Windows) 2016
Domain function level: (Windows) 2016
Lowest function level of a DC: (Windows) 2016

Die Umstellung ist damit abgeschlossen.

Noch mal, das Upgrade auf 4.19 bringt nicht zwingend auch das Upgrade auf das neu FL mit, kann also auch auf Domaincontrollern durchgeführt werden und das bestehende FL bleibt erhalten. Mittlerweile ist 4.19 so ausgereift, dass ein Update durchgeführt werden kann.

Mehr zu allen Änderungen finden Sie hier:
https://www.samba.org/samba/history/samba-4.19.0.html

Die neuen Authentication-Policies und Authentication-Silos können Sie mit den samba-tool Kommando testen:

samba-tool domain auth

Aber die Funktionen sind dort noch nicht vollständig implementiert.

Alle anderen Samba-System, wie Samba-Clients, Samba-Fileserver und CTDB-Cluster sind von dem neuen FL nicht betroffen und können ohne weiteres aktualisiert werden.

 

Posted in Samba | 1 Comment

Fehlerteufel in den Listings zum Buch OpenLDAP 2. Auflage beseitigt

Bei den Listings im Buch OpenLDAP in der Praxis hatte sich bei den Listing ein Fehlerteufel eingeschlichen. Es gibt im Buch teilweise Listing in denn steht ou=users,dc=example,dc=net in anderen Listings steht aber ou=users,ou=firma,dc=example,dc=net. Beim Lesen und Abtippen ist das kein Problem, aber wer dann die Listing aus dem Download nutzt, der kommt irgendwann an den Punkt wo sich der Fehler bemerkbar macht. Daher haben wir alle Listings auf github jetzt doppelt abgelegt. Einmal mit der ou=firma und einmal ohne die ou=firma, so kann jetzt jeder wählen welche Einrichtung genutzt werden soll. Um die Komplexität der ACLs noch besser verstehen zu können, ist die Einrichtung mit der Zwischenebene ou=firma besser. Wer aber erst einmal die Grundlagen verstehen will, sollte ohne dieses Zwischenebene arbeiten.  

Posted in LDAP | Leave a comment

Einrichtung einer eigen Konfiguration für die ldap-Kommandos

Heute geht es mal um die Konfiguration der ldap-Kommandos wie ldapsearch. Um die Kommandos ohne die Angabe des Server oder der BASE ausführen zu können, kann eine systemweit gültige ldap.conf eingerichtet werden. Je nach verwendeter Distribution, oder bei der Verwendung der Symas-Pakete, liegt die Datei an unterschiedlichen Stellen im Dateisystem. Was aber die wenigsten wissen, jeder Benutzer kann sich auch eine eigene Konfiguration für die ldap-Kommandos erstellen und damit die systemweite Konfiguration übersteuern. Um die Einrichtung einer solchen Konfiguration soll es hier gehen.

Um eine eigene Konfiguration zu nutzen, wird eine Datei mit dem Namen .ldaprc direkt im Home-Verzeichnis benötigt. Es ist auch möglich eine Datei ldaprc (also ohne führenden Punkt) im aktuellen Verzeichnis abzulegen, dann wird die Konfiguration nur genutzt, wenn Sie direkt in das Verzeichnis wechseln.

Ich werde hier nur eine .ldaprc direkt im Home-Verzeichnis einrichten.

Im ersten Schritt soll dafür gesorgt werden, dass die systemweite Konfiguration komplett ignoriert wird. Sorgen Sie dafür, dass die Variable LDAPNOINIT gesetzt ist. Welcher Wert dort vergeben ist, spielt keine Rolle, wichtig ist nur, dass die Variable gesetzt ist.

In der systemweiten Konfiguration wird meist nur die Variable „BASE“ und „URI“ gesetzt um den Suffix und die LDAP-Server bekannt zu machen. In der eigenen .ldaprc können noch ein paar weitere Variablen genutzt werden:
Sie können hier zum Beispiel den BINDDN für die ldap-Kommandos setzen. Diese Variable steht nur in der user-Konfiguration zur Verfügung und kann nicht in der systemweiten Konfiguration gesetzt werden. Durch die Nutzung kann der eigene DN übergeben werden und der Parameter „-D“ kann entfallen. Das erspart das Tippen des DNs. Beim Aufruf von ldapsearch ist es aber notwendig, dass Sie immer noch die Option „-W“ (für die Abfrage des Passworts) angeben, ohne diese Option wird immer eine anonyme Suche gestartet.

Wenn mehrere Server in der Variablen URI angegeben werden sollen, dann dürfen die Servereinträge nicht quotiert werden, sondern die Servernamen werden einfach durch Leerzeichen voneinander getrennt.
Falsch wäre: URI „ldaps://provider01.example.net ldaps://provider02.example.net“
Richtig ist: URI ldaps://provider01.example.net ldaps://provider02.example.net

Leider ist es im Moment noch nicht möglich, so wie bei vielen anderen Werkzeugen, auf die SRV-Records des DNS zurückzugreifen. Es gibt aber eine „feature request“ für diese Möglichkeit: https://bugs.openldap.org/show_bug.cgi?id=9080.

Um die .ldaprc möglichst automatisch zu erzeugen, habe ich ein kleines Skript geschrieben, das alle benötigten Einträge erstellt, darunter auch die SRV-Records auflöst und in die eigenen .ldaprc einträgt. Das Skript ist selbstverständlich NICHT der Weisheit letzter Schluss, aber es funktioniert. Das Skript habe ich auch geschrieben, um (ACHTUNG WERBUNG) als Beispiel für das Seminar „Shell-Programmierung für Einsteiger“ in der Heinlein-Akademie zu dienen. Hier der Link zum Seminar: https://www.heinlein-support.de/schulung/shell-progammierung-einsteiger
So kann jeder Benutzer der ldap-Kommandos seine eigenen Datei erzeugen um auf die Server zugreifen zu können.

Posted in LDAP | Leave a comment

Dienste am LDAP mit Kerberos anbinden

Anbinden eines Radius-Servers an LDAP und Kerberos

Bis jetzt habe ich immer Artikel zum Thema OpenLDAP geschrieben, dabei ist die Anbindung von Diensten an den OpenLDAP immer recht kurz gekommen. In einer losen Reihenfolge möchte ich diese Lücke jetzt schließen, und nach und nach verschiedene Dienste an den LDAP-Server anbinden. Dabei soll es nicht nur um die Anbindung an OpenLDAP gehen, sondern auch gleich um die Nutzung von Kerberos zur Authentifizierung. In einer OpenLDAP-Umgebung OHNE Kerberos ist immer nur ein „simple bind“ möglich, das erfordert immer einen Benutzer und ein Passwort in Klartext in der Konfiguration des Dienstes. Der einzige „Schutz“ der Anmeldedaten ist die Einschränkung der Rechte an den Konfigurationsdatei. Ein echter Schutz ist das aber nicht. Zusammen mit Kerberos ist aber eine wirksamer Schutz der Anmeldeinformationen möglich. Alle Dienste die kerberisiert werden können, sollten auch so konfiguriert werden.

Anfangen möchte ich mit der Konfiguration des Radius-Servers mit „freeradius“.

Damit Sie die einzelnen Schritte einfacher nachvollziehen können und Kommandos und Listings direkt per copy&past übernehmen können, finden Sie das gesamte Vorgehen in dieser Textdatei.

Posted in LDAP | Leave a comment

Overlay autoca in der Praxis

Das Overlays autoca
Mit dem Overlay autoca wurde bei der neuen Version von OpenLDAP die Möglichkeit geschaffen, Zertifkate für Benutzer und Computer automatisch
erstellen zu lassen. Im LDAP-Baum kann entweder die automatisch erstellte CA mit self signed certificates genutzt werden, Sie können aber auch die
eigene CA einbinden.
Als Erweiterung zum Buch möchte ich hier das Overlay etwas genauer betrachten. Hier soll die OpenLDAP eigene CA durch eine eigene ersetzt werden.
Zusätzlich möchte ich Ihnen zeigen, wie Sie die im Binärformat abgelegten Zertifikate der Benutzer und Computer in .PEM-Dateien umwandeln können,
um die Zertifikate anschließend für andere Aufgaben nutzen zu können. Denkbar wäre so ein Nutzung für eine 802.1x Authentifizierung oder für den Einsatz mit einem Radius-Server.

Um das Overlay nutzen zu können, benötigen Sie als erstes ein Modul. Das Modul können Sie mit der folgenden LDIF-Datei laden:

dn: cn=module{0},cn=config
changetype: modify
add: olcModuleload
olcModuleload: autoca.la

 

Jetzt muss noch das Overlay in die entsprechenden Datenbank eingebunden werden. Dazu können Sie die folgende LDIF-Datei nutzen:

dn: olcOverlay={2}autoca,olcDatabase={2}mdb,cn=config
objectClass: olcAutoCAConfig
objectClass: olcOverlayConfig
olcOverlay: {2}autoca
olcAutoCADays: 3652
olcAutoCAserverDays: 1826
olcAutoCAuserDays: 365

Nachdem Sie die Konfiguration eingespielt haben, können Sie mit dem folgenden Kommando das Zertifikat und den Key anzeigen lassen:
—————-
ldapsearch -x -D cn=admin,dc=example,dc=net -W -LLL dc=example ‚cACertificate;binary‘ ‚cAPrivateKey;binary‘
—————-
Wichtig ist, den Zugriff auf den Key hat nur der rootdn der Datenbank. Alle anderen Benutzer können sich lediglich das Zertifikat anzeigen lassen.

Um eigene Zertifikate nutzen zu können, ändern Sie die Attribute in der obersten Ebenen des LDAP (hier dc=example,dc=net). Die beiden Attribute die Sie
anpassen müssen sind:
cACertificate;binary
und
cAPrivateKey;binary

Wenn das Zertifikat nicht getauscht wird, dann würde immer das vom OpenLDAP erstellte self signed Certificate genutzt. Wie das Attribut schon zeigt, wir das Zertifikat im binary-Format gespeichert. Was aber wenn nur .PEM-Zertifikate vorhanden sind? Dann können Sie das Zertifikat und den Key mit den folgenden Kommandos umwandeln:
—————
openssl rsa -inform pem -in cakey.pem -outform der -out cakey-binary.der

openssl x509 -outform der -in cacert.pem -out cacert-binary.der
————–

Anschließend tauschen Sie das Zertifikate und der Key mit der folgenden LDIF-Datei aus:

dn: dc=example,dc=net
changetype: modify
replace: cACertificate;binary
cACertificate;binary:< file:///root/mycert/cacert-binary.der

replace: cAPrivateKey;binary
cAPrivateKey;binary:< file:///root/mycert/cakey-binary.der

 

Jetzt fehlt nur noch eine ACL damit ein Benutzer sein Zertifikat und den Privatkey erstellen kann. Die ACL sollte weit oben angelegt werden, da es sich um eine ACL auf ein einzelnes Attribut handelt:

dn: olcDatabase={2}mdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {1}to attrs=pKCS8PrivateKey
by self ssf=128 write

 

Die ACL auf das Attribut pKCS8PrivateKey vererbt die Rechte an die beiden Attribute „userCertificate;binary“ und „userPrivateKey;binary“.

Jetzt können der Benutzer selber und der rootdn das Zertifikat und den Schlüssel mit dem Kommando:
—————
ldapsearch -x -D „cn=u1 verw,ou=users,ou=verwaltung,dc=example,dc=net“ -W „cn=u1 verw“ -LLL „userCertificate;binary“ „userPrivateKey;binary“
—————

erstellen. Alle anderen Benutzer können das Zertifikate lesen, nicht aber den Key.

Sollen die Zertifikate später für andere Aufgaben genutzt werden, wie zum Beispiel für einen Radius-Server, werden die Zertifikate im PEM-Format benötigt. Das folgende kleine Skript extrahiert das Zertifikat und den Key, eines als Positionsparameter
übergebenen Benutzers, aus den binären Attributen. Es entstehen zwei PEM-Dateien.

#!/bin/bash
#
LDAPSEARCH=’/opt/symas/bin/ldapsearch‘
MANAGERDN=’cn=admin,dc=example,dc=net‘
URIP1=’ldaps://ldap-r01.example.net‘
PASSWD=’geheim‘
DC=’net‘
TESTDIR=$(mktemp -dp ./)
SEARCHOUT=output.binary
USERDN=$1
EXISTS=$($LDAPSEARCH -D $MANAGERDN -H $URIP1 -w $PASSWD -LLL „$USERDN“ dn)
EXISTS=${#EXISTS}
echo $EXISTS
if [ $EXISTS -eq 0 ]
then
echo „Benutzer/Host $USERDN ist nicht vorhanden“
exit 1
fi
RDN=$(echo $USERDN | egrep ‚^uid=|^cn=‘)
if [ -z $RDN ]
then
echo “ Kein RDN angegeben Benutzer im Format „
echo “ uid=object oder cn=object angeben“
exit 2
fi

NOCERT=$($LDAPSEARCH -D $MANAGERDN -H $URIP1 -w $PASSWD -LLL „$USERDN“ | grep ‚userCertificate;binary‘ )
echo „wert: $NOCERT“
NOCERT=${#NOCERT}
echo „zahl: $NOCERT“
if [ $NOCERT -eq 0 ]
then
echo „Benutzer/Host hat noch kein Zertifikat“
while [ „$CREATECERT“ != „J“ -a „$CREATECERT“ != „N“ ]
do
echo -n „Soll ein Zertifikat erstellt werden (j/n)? „
read CREATECERT
CREATECERT=$(echo $CREATECERT | tr a-z A-Z)
done
if [ $CREATECERT == „J“ ]
then
$LDAPSEARCH -D $MANAGERDN -H $URIP1 -w $PASSWD -LLL „$USERDN“ ‚userCertificate;binary‘ ‚userPrivateKey;binary‘ >/dev/null
else
echo „Kein Zertifikat vorhanden und es wurde auch keins erstellt“
exit 1
fi
fi
echo „Suche das Zertifikat für $USERDN mit ldapsearch“
$LDAPSEARCH -D $MANAGERDN -H $URIP1 -w $PASSWD -LLL „$USERDN“ ‚userCertificate;binary‘ > $SEARCHOUT 2>&1
echo „Erstelle das Zertifikat“
echo „—–BEGIN CERTIFICATE—–“ > $TESTDIR/“${USERDN}“-usercert.pem
sed -e „/^dn:/d“ -e „/^ dc=${DC}/d“ -e „s/userCertificate;binary:://“ -e „/^$/d“ $SEARCHOUT >> $TESTDIR/“${USERDN}“-usercert.pem
echo „—–END CERTIFICATE—–“ >> $TESTDIR/“${USERDN}“-usercert.pem

echo „Suche den Key für $USERDN mit ldapsearch“
$LDAPSEARCH -D $MANAGERDN -H $URIP1 -w $PASSWD -LLL „$USERDN“ ‚userPrivateKey;binary‘ > $SEARCHOUT 2>&1
echo „Erstelle den Key“
echo „—–BEGIN PRIVATE KEY—–“ > $TESTDIR/“${USERDN}“-userkey.pem
sed -e „/^dn:/d“ -e „/^ dc=${DC}/d“ -e „s/userPrivateKey;binary:://“ -e „/^$/d“ $SEARCHOUT >> $TESTDIR/“${USERDN}“-userkey.pem
echo „—–END PRIVATE KEY—–“ >> $TESTDIR/“${USERDN}“-userkey.pem

echo „Inhalt des Zertifikats“
openssl x509 -noout -text -in $TESTDIR/“${USERDN}“-usercert.pem
echo „Weiter mit RETURN“ ; read

echo „Vergleich der Prüfsumme des Zertifikate mit der des keys“
echo „“
echo „Prüfsumme des Keys: $(openssl pkey -in $TESTDIR/“$USERDN“-userkey.pem -pubout -outform pem | sha256sum)“
echo „“
echo „Prüfsumme des Zertifikat: $(openssl x509 -in $TESTDIR/“$USERDN“-usercert.pem -pubkey -noout -outform pem | sha256sum)“

Was macht das Skript?:
– Als erstes wird geprüft, ob der als Positionsparameter übergeben Benutzer existiert.
– Im Anschluss wird geprüft, ob der Name als RDN also entweder als uid= oder cn= übergeben wurde
– Dann wird geprüft, ob der Benutzer bereits ein Zertifikat besitzt. Wenn nicht, wir gefragt, ob eins erstellt werden soll. Ein „N“ verlässt das Skript. Ein „J“ erstellt Zertifikat und Key
– Jetzt wird das binäre Zertifikat in eine .PEM-Datei umgewandelt und in einem temporären Verzeichnis abgelegt. Der Dateiname enthält den Benutzername.
– Dann wird der binäre Key in eine .PEM-Datei umgewandelt und in einem temporären Verzeichnis abgelegt. Der Dateiname enthält den Benutzername.
– Im Anschluss wir der Inhalt des Zertifikats ausgelesen und angezeigt
– Zum Abschluss werden die Prüfsummen des Zertifikats und des Keys verglichen. Nur wenn beide identisch sind, passt der Key zum Zertifikat.

In dem temporären Verzeichnis liegen jetzt zwei Dateien: Zum Einen das Zertifikat im PEM-Format und zum Anderen der Key im PEM-Format.

Wichtig!
Für den Key wurde kein Passwort gesetzt.

Alle Dateien un den Text finden Sie hier oder im git-Repository zum Buch

Posted in LDAP | Leave a comment

Listings zum Buch OpenLDAP jetzt auch über github verfügbar

Alle Listings zur 2. Auflage unseres OpenLDAP-Buchs sind jetzt auch im github abgelegt. So können wir schneller Änderungen vornehmen, eventuelle Fehler beheben, oder auch mal neu kleine Inhalte bereitstellen die noch nicht im Buch vorhanden sind.

 

Posted in LDAP | Leave a comment

Debian 12 ohne syslogd

Mit Debian 12 (bookworm) wird jetzt nur noch der journald für das
Logging installiert und nicht noch wie bei den vorherigen Versionen zusätzlich der syslog-ng. Endlich, warum auch zwei log-Systeme? Auch hat der journald eine Menge an Vorteilen gegenüber den anderen Log-Systemen.  Klar, das Log-file wird binär abgelegt und nicht mehr im ASCII-Format, aber das hat mehr Vor- als Nachteile. Man muss sich jetzt vielleicht mal etwas genauer mit dem journald auseinandersetzen um auch die Vorteile zu sehen.

Durch das binäre Format ist eine Fälschung des logs durch entfernen von einzelnen Zeilen kaum bis gar nicht mehr möglich. Für jeden Eintrag im Log wird eine Hashwert gebildet und der Hashwert beinhaltet immer auch den Hashwert des vorherigen Eintrags. Würde also eine Zeile aus dem Log entfernt, stimmen alle folgenden Hashwerte nicht mehr und die Manipulation würde sofort auffallen.

Auch ist die Suche im Log erheblich einfacher. Hier mal ein paar Beispiele:

journalctl – -until „2023-01-01 12:00:00“
Hier werden alle Einträge bis zum angegeben Datum und Uhrzeit aufgelistet

Das ganze geht natürlich auch so:
journalctl – -since „2023-01-06 12:00:00“
Starte die Suche zum angegebenen Datum und Uhrzeit bis jetzt.

Eine Kombination aus beiden ist auch möglich:
journalctl – -since „2023-01-01 12:00:00“  –until „2022-01-06 12:00:00“

Bei den Zeitangaben gibt es jede Menge an Möglichkeiten. hier ein paar Beispiele:
journalctl – -since yesterday
journalctl – -since 09:00 –until „1 hour ago“
journalctl – -since „2023-01-07 17:15:00“ –until now
journalctl – -since „2023-01-07 17:15:00“ –until „+1 hour“
journalctl – -since „2023-01-07 17:15:00“ –until „-1 minute“

Auch lässt sich gut nach Einträgen eines  bestimmten Dienstes suchen:
journalctl -u slapd.service

Ein zusätzlichen -f öffnet das Journal und Sie können alle aktuell auflaufende Meldungen des Dienstes sehen.

Sie suchen nach allen Einträgen die zu einer bestimmten Prozess-ID gehören? Kein Problem:
journalctl _PID=560

Oder Einträge die eine bestimmte UID haben:
journalctl _UID=106 –since today

Sie wollen sehen, welche Meldungen zu einem bestimmten Log-Level seit dem letzten boot im Log stehen?
journalctl -p err -b

Das sind nur ein paar Möglichkeiten die Sie mit dem journald haben. Also, nicht gleich den syslog-ng installieren so nach dem Motto: „Das haben wir immer schon so gemacht“.  

Posted in Allgemein | Leave a comment

Dateien zum neuen OpenLDAP-Buch

Wenn alles klappt, kommt das neu OpenLDAP-Buch bereits im August in den Handel. Geplant war September. Aber alle Beteiligten haben schnell gearbeitet, sodass das Buch wahrscheinlich einen Monat früher erscheinen wird. Damit Sie als Leser nicht alles Skripte und LDIF-Dateien aus dem Buch abtippen müssen, liegen hier alle Dateien zu allen Kapiteln zum Download bereit.

Posted in Allgemein, LDAP | Leave a comment

Das neue OpenLDAP-Buch ist fertig

Nach über 14 Jahren gibt es von OpenLDAP endlich eine neue Version, die Versionen 2.5/2.6. Die Version 2.5 ist vor ca. 1.5 Jahren erschienen kurz darauf dann die Version 2.6. Die Version 2.5 ist eine LTS-Version in der nur Sicherheitsupdates und Bug-fixes eingepflegt werden. Anders sieht es bei der Version 2.6 aus, da werden auch immer wieder neue Funktionen mit eingebunden. Beide Version sind stabil, aber die Version 2.6 soll dann im laufe des Jahres durch eine 2.7 ersetzt werden. 2.5 wird es erheblich länger geben.

Da im Moment noch keine Distribution die neuen Pakete enthält, verwenden wir die Pakte aus dem Repository der Firma Symas. Fast die gesamte Entwicklung von OpenLDAP wird von dort durchgeführt, somit sind die Pakte auch stabil und immer aktuell. Die Pakte gibt es dort für verschiedene Distributionen kostenfrei. Für uns ein Vorteil, so konnten wir die Installation recht kurz halten und mussten nicht mehr auf unterschiedliche Distributionen eingehen. Den Platz haben wir lieber für neue Inhalte genutzt. Alle Pfade sind auf allen Distributionen identisch.

Im neuen Buch haben Andreas und ich uns auf die Version 2.6 geeinigt. Zum Zeitpunkt der Erstellung des Buchs waren die Unterschiede nur marginal. An den Stellen, an denen es Unterschiede gibt, haben  wir das auch erwähnt.

Das alte Buch hatte ca. 370 Seiten, das neue über 450. Jetzt könnte man denken: „80 Seiten mehr ist ja kein großer Aufwand und nicht viel neues.“ Aber! Wir haben uns darauf geeinigt, die statischen Konfiguration über die slapd.conf komplett aus dem Buch zu entfernen und nur noch die dynamische Konfiguration über cn=config zu besprechen. Da sind dann so einige Seiten aus dem alten Buch raus gefallen und es gab Platz für neue Inhalte. An dieser Stelle möchte ich nur eine kurze Aufzählung der neuen Inhalte nennen:

  • Das Kapitel zum sssd wurde um die Möglichkeit der Auswertung der SRV-Records im DNS ergänzt.
  •  Bei den grafischen Tools beschränken wir uns auf den LAM und das Apache Directory Studio. Beim LAM sind wir etwas mehr in die Tiefe gegangen als in der letzten Auflage.
  • Das Kapitel der ACLs haben wir überarbeitet und um die Möglichkeit der „sets“ erweitert und ACLs mit Filtern und der Verwendung des ssf werden auch erklärt.
  • Beim Kapitle Overlays gibt es sehr viel neues. Das alles hier aufzuzählen wäre zu viel. Nur eins: Das Overlay „memberOf“ wird komplett durch das Overlay „dynlist“ ersetzt.
  • Die Funktion der Replikation wurde im neuen OpenLDAP komplett überarbeitet. Alle neuen Möglichkeiten werden im Buch besprochen. Die Funktion des „standby provider“ haben wir komplett rausgeworfen und durch die neuen Möglichkeiten der „multi provider replikation“ ersetzt.
  • Natürlich hat der neue Loadbalancer, der im neuen OpenLDAP enthalten ist, ein eigenes Kapitel erhalten. 
  • Auch die Einrichtung der verschiedenen LDAP-Proxy Möglichkeiten finden Sie im Buch, inklusive der Einrichtung de cachings.
  • Referrals fehlten in der ersten Auflage, sind aber jetzt enthalten.
  • OpenLDAP im Container wurde durch die Nutzung von Kubernetes ergänzt.
  • Die Einrichtung von OpenLDAP mittels Ansible hat auch ein eigenes Kapitel bekommen.

Sie sehen, es hat sich viel getan. 

Das Buch wurde von uns so geschrieben, dass sowohl ein Einsteiger in das Thema, als auch jemand der von 2.4 updaten will (was unbedingt zu empfehlen ist!) genutzt werden kann.

Wie bei allen Büchern an denen ich beteiligt war, ist es mir auch hier wichtig gewesen den Praxisteil möglichst groß zu gestalten. In allen Kapiteln gibt es Beispiele. Keine Angst, Sie müssen nicht alles abtippen was Sie in den Listings sehen. Ich werde alle Skripte, LDIF-Dateien und Konfigurationen hier noch bereitstellen. Auch beim Verlag wird es die Daten auch als Download geben.

Wie immer freue ich mich über konstruktive feedbacks.

Jetzt heißt es nur noch warten. Das Buch wird wohl Anfang September erscheinen.

Posted in LDAP | Leave a comment