Neue Versionierung bei OpenLDAP

Bei OpenLDAP werden sich zum Anfang des Jahres 2025 die Versionen wie folgt ändern:

  • Die Version 2.5 wird auslaufen, bekommt aber noch bis 15.01.2027 Sicherheitsupdates. Nach diesem Datum bekommt die Version den Status „historical“ und erhält dann keine Updates oder Sicherheitspatches mehr.
  • Die Version 2.6 wird zur neuen LTS-Version werden.
  • Im Herbst 2024 wird die Version 2.7 erscheinen, bei dieser Version handelt es sich um die neue „feature Release“ Version. Also mit allen Neuerungen.

Die Umstellung vom 2.5 auf 2.6 kann mit der laufenden Konfiguration stattfinden. Nur beim Einsatz des Loadbalancers muss die Konfiguration angepasst werden.

Die Replikation zwischen Version 2.5 und 2.6 läuft ohne Probleme, so kann ein Server nach dem anderen Umgestellt werden.

Posted in Allgemein | Leave a comment

OpenLDAP Erweiterung für Postfix-Abfragen

Für die Verwaltung von Postfix-Abfragen werden die beiden Attribute mailacceptinggeneralid und maildrop benötigt. Leider gibt es kein Standardschema in dem diese beiden Attribute vorhanden sind. Eine Lösung dafür wird hier angeboten. Aber dort gibt es nur das Schema für die Einbindung über die slapd.conf, die LDIF-Datei für die dynamische Konfiguration fehlt hier leider. Ich habe die Datei umgewandelt und stelle sie hier zum Download bereit. Die LDIF-Datei für das Schema können Sie einfach mit dem Kommando ldapadd -Y external -H ldapi:/// -f postfix.ldif in die Konfiguration eingefügt. Anschließend können Sie die Objektklasse allen Benutzer zuweisen. Da beide Attribute nur MAY-Attribute sind, kann die Objektklasse auch ohne Werte den Benutzern zugewiesen werden.

Was ist aber mit dem LAM? Kann der LAM erweitert werden, sodass beim Anlegen eines Benutzer die Objektklasse und die Attribute gleich vergeben werden können? Ja, das geht, aber nur in der LAM-Pro Version. Dazu wird das Profil des LDAP-Servers im LAM angepasst. Die folgenden Schritte sind dafür notwendig:

Nach dem Öffnen des Profiles wird im Karteireiter Module, das Modul customFields zum Benutzer hinzugefügt.

Dann auf den Karteireiter Moduleinstellung wechseln, das neue Modul suchen, einen Alias-Name eintragen:

und anschließen auf Neue Gruppe anlegen klicken. Daraufhin wird das Fenster um die Möglichkeit der Eingabe einer Objektklasse erweitert. Hier tragen Sie die Objektklasse PostfixUser ein. Jetzt fehlen dann nur noch die beiden Felder für die beiden Attribute der Objektklasse. Um die Felder zur Gruppe hinzuzufügen klicken Sie auf „Feld hinzufügen“.

Im nächsten Bild sehen Sie, am Beispiel des Attributs maildrop, wie Sie die Felder hinzufügen. Bei beiden Feldern handelt es sich um Textfelder.

Wenn Sie beide Felder hinzugefügt haben, können Sie bei der Beschriftung der Gruppe noch einen Namen vergeben. Dieser Name wird dann als zusätzliches Feld beim Anlegen eines Benutzer angezeigt.
Speichern Sie die Änderungen und melden Sie sich anschließend am LDAP-Server an. Wenn Sie jetzt einen neuen Benutzer anlegen, sehen Sie die neue Gruppe und können dann dort die Werte ergänzen.

Posted in Allgemein | Leave a comment

Warum „su“ ohne „-“ eine schlechte Idee ist

Mal was einfaches zum Thema Sicherheit in Linux-Systemen. Es müssen nicht immer die großen Klatschen sein, kleine Dinge helfen da auch.

Immer wieder (oder sagen wir leider immer noch) sehe ich, dass beim Wechsel zum root-Konto auf einem System nur „su“ und nicht „su -„ eingegeben wird. Auch in Bereichen an denen sonst alles soooooo super abgesichert ist. Aber was ist das Problem dabei?

Bei einem einfachen „su“ behält der Benutzer „root“ die Umgebung, mit allen gesetzten Variablen, auch „$PATH“. Wenn jetzt der Benutzer das aktuelle Verzeichnis, also „.“ an den Anfang von „$PATH“ setzt, werden alle eingegebenen Kommandos immer erst im aktuellen Verzeichnis gesucht. Ganz schön dumm. Denn so kann ein Benutzer dem Admin mal schnell ein kleines Skript unterjubeln und damit das Passwort abfangen. Schön ist da sowas:

#!/bin/bash
PWALT=““
PWNEU1=““
PWNEU2=““
echo „Passworts für $USER wird geändert.“
echo -n „Geben Sie das aktuelle Passwort ein: “
stty -echo
read PWALT
echo „“
stty echo
echo -n „Geben Sie ein neues Passwort ein: “
stty -echo
read PWNEU1
echo „“
stty echo
echo -n  „Geben Sie das neue Passwort erneut ein: “
stty -echo
read PWNEU2
echo „“
stty echo
sleep 2
echo „Die Passwörter stimmen nicht überein.“
echo „passwd: Bearbeitungssfehler des Legitimierungszeichens“
echo „passwd: Passwort nicht geändert“
echo $PWALT > ${HOME}/passklau
echo $PWNEU1 >> ${HOME}/passklau  
echo $PWNEU2 >> ${HOME}/passklau  
mv passwd.bash passwd1.bash

Das Skript wird mit dem name passwd abgespeichert. Wenn jetzt der Admin, nach der Eingabe von „su“ sein Passwort ändern will, ruft er das Skript auf. Na vertippen kann sich jeder mal. Beim zweiten Aufruf klappt es dann ja, also alles Ok.

Wird stattdessen „su -“ genutzt, ist das identisch mit einem Login, der „root“ erhält seine eigene Umgebung und würde nicht in Falle laufen.

Sie sehen, es macht Sinn „su -“ zu nutzen und es ist absolut Sinnvoll, dass das aktuelle Verzeichnis NICHT in $PATH eingetragen ist. 

Posted in Allgemein | Leave a comment

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 | Leave a 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