Nachdem ich mich jetzt um eine Dokumentation zum Thema Himmelblau, dem Linux-Client für Entra Id“ gekümmert habe, wollte ich auch auch mal sehen, wie so ein Windows-Client in der Umgebung aussieht und verwaltet werden kann. Geht ja schnell. Kurz eine Windows 11 VM in VirtualBox eingerichtet dann mit Entra Id verbunden und? Die Ernüchterung schlägt schnell zu. Die Maschine wird immer als „non compliant“ angezeigt. Aber warum? Ein bisschen lesen hier und googlen dort und die Antwort ist gar nicht mal so einfach. Tipp vorab: Es liegt an der fehlenden Verschlüsselung mit bitLocker und dem nicht vorhandenem TPM.

Deshalb hier eine Schritt-für-Schritt-Anleitung, wie man eine Windows-VM in Intune auf „Compliant“ bringt, ohne das BitLocker und/oder TPM vorhanden sind.

1. Compliance-Policy erstellen

Problem ist, dass wenn ein Windows-Client in Entra-Id aufgenommen wird immer eine Compliance-Policy vorhanden sein muss. Ist keine eigen Policy vorhanden, wird eine default Policy genutzt und zwar die „Default Device Compliance Policy“. Diese Policy kann nicht geändert werden. Sie können diese Policy nur durch eine eigene Policy ersetzen. In der default Policy ist aber festgelegt, dass ein Client nur dann die Compliance-Regeln einhällt, wenn TPM, verschlüsselte Datenträger und secure Boot eingerichtet sind. Aber, dass trifft auf meine Vms nicht zu. Also muss eine eigen Policy her. Die folgenden Schritte sorgen dafür, dass auch meine VMs jetzt als „compliant“ angezeigt werden.

1. Das Intune Admin Center öffnen: https://endpoint.microsoft.com
2. Unter Geräte → Windows → Konformitätsrichtlinien → Richtlinie erstellen (Create Policy) Die Plattform: „Windows 10 und später“ auswählen und der Policy einen Namen geben z. B. „VM Compliance Policy“
3. In der Policy alle Einstellungen auf Nicht konfiguriert setzen:
   • BitLocker: Nicht konfiguriert
   • TPM: Nicht konfiguriert
   • Secure Boot: Nicht konfiguriert
   • Passwort/PIN: Optional
   • Defender / OS-Version: Optional
4. Dann die richtlinie speichern.

2. Erstellen einer Sicherheitsgruppe für die VM

Im portal von Entra Id muss jetzt eine Gruppe eingerichtet werden, in dann alle Windows-VMs Mitglied werden.

1. Unter Gruppen → + Neue Gruppe eine neu Gruppe ezeugen vom Typ „Sicherheitsgruppe“ und der Gruppe einen Name: z. B. „Win-VMs“ vergeben. An diesen Punkt wird die Mitgliedschaft jetzt manuell Zugewiesen. Es besteht auch die Möglichkeit Gruppen dynamisch zuzuweisen. Auf diese Möglichkeit werde ich hier nicht eingehen, da dieses Thema nicht mein eigentliches Problem betrifft.

3. Richtlinie der Gruppe zuweisen

Zurück zu Intune und die Gruppe der zuvor erstellten Policy zuweisen. Sie können natürlich die Gruppe auch erst einrichten und dann bei der Erstellung der Policy gleich zuweisen.

1. Unter Geräte → Windows → Kompatibilität finden Sie Ihre vorher erstellte Policy. Über die Eigenschaften können Sie jetzt die vorher erstellte Gruppe der Policy zuweisen
2. Speichenr Sie die neue Einstellung

4. Erzwingen der Policy auf der VM

Dazu öffnen Sie, auf der VM, die PowerShell als Administrator und führen den folgenden Befehl aus:

Start-Process „C:\Windows\System32\DeviceEnroller.exe“ -ArgumentList „/c“ -W

Sie können den Vorgang aber auch über die GUI durchführen und zwar unter Einstellungen →Konten → Auf Arbeits- oder Schulkonto zugreifen → Info → Synchronisieren klicken. Warten bis die Synchronisierung abgeschlossen ist. Eventuell die Windows-VM neu starten.

5. Prüfen des Compliance-Status

Im Intune Admin Center unter Geräte →Windows die VM auswählen und auf „Gerätekompatibilität“ klicken, dort sollte jetzt die neue Policy sichtbar sein und die VM sollte den Status „comliant“ haben

Das hat aber leider bei mir so nicht geklappt, es war immer noch nur die default Policy aktiv. Für den Fall jetzt hier der Weg zur Fehlersuche und Behebung.

6. Fehlersuche (falls Status immer noch Not Compliant)

Prüfen Sie, ob die VM Mitgliedschaft der Sicherheitsgruppe für die Windows-VMs istEin Blick in den Event Viewer zeigt auch Fehler an. Hier der Weg zum entsprechenden Ereignis.

Event Viewer → Applications and Services Logs → Microsoft → Windows → DeviceManagement-Enterprise-Diagnostics-Provider → Admin

Erzwingen sie eine erneute manuelle Synchronisation. Warte 10–15 Minuten nach Synchronisation und starten Sie die VM neu. Klappt immer noch nicht? Dann prüfen Sie, ob die
VM auch als Mitglied der Gruppe in Intune angezeigt wird. Gehen Sie dazu wieder auf die Eigenschaften der VM und klicken Sie auf „Gruppenmitgliedschaft“, dort sollte die Gruppe für Ihre
VMs eingetragen sein. Ist das nicht der Fall, dann gehen Sie in Intune wieder auf Geräte → Windows und klicken Sie auf Ihre VM dort klicken Sie dann oben in der Menüleiste auf „Löschen“,
damit wird die VM aus Entra Id ausgetragen. Wenn Sie jetzt die VM über Einstellungen → Konto wieder verbinden, sollten alle Informationen, auch die Gruppenmitgliedschaft, sauber synchronisiert werden.
Bei mir hatten anschließend alle VMs den Status „compliant“.

Noch eine Anmerkung: Ich bin es von OpenLDAP und auch Samba so gewöhnt, dass eine Änderung, nachdem ich sie bestätigt habe, auch sofort ausgeführt wird und das Ergebnis sichtbar ist. Mit den ersten Schritten bei Entra Id habe ich mich davon verabschiedet. Hier dauert es manchmal Stunden, bis eine Änderung auch sichtbar ist. Also besser einmal eine Tasse Kaffee mehr als hektisch versuche den „Fehler“ zu beheben.

Ich habe mich dazu entschlossen, meine GIT-Repositories von github auf codeberg.org umzuziehen. Codeberg wird in Deutschland betrieben und auch die Server stehen in Deutschland. Die Listings für das Samba-Buch können jetzt mit dem folgenden Kommando geladen werden:

I have decided to move my GIT repositories from GitHub to codeberg.org. Codeberg is operated in Germany and the servers are also located in Germany. The listings for the Samba book can now be loaded with the following command:

git clone https://www.codeberg.org/stka/samba4-buch-2024

Die Listings des OpenLDAP-Buches bekommen Sie mit dem folgenden Kommando:

You can get the listings from the OpenLDAP book with the following command:

git clone https://www.codeberg.org/stka/openldap-in-der-praxis

Damit habe ich alle meine,, im Internet bereitgestellten Daten, auf Server in Deutschland umgestellt. Alle Webseiten werden auf jpberlin.de gehosted. Auch alle Mailadressen werde dort verwaltet. Der letzte Schritt waren jetzt die Repositories.

This means that I have now transferred all my data stored on the internet to servers in Germany. All websites are hosted on jpberlin.de. All email addresses are also managed there. The final step was the repositories.

Bis vor einiger Zeit war es leider nicht möglich, dynamische Posix-Gruppen in eine Multiproviderumgebung im OpenLDAP einzurichten, die entsprechenden Attribute wurden einfach nicht repliziert. Jetzt aber klappt es.

Sollen die dynamischen Posix-Gruppe genutzt werden, ist es wichtig, dass die dynmischen LDAP-Gruppen bereits korrekt eingerichtet sind. Das Einrichten der dynamischen LDAP-Gruppen ist nicht Bestandteil dieser Anleitung.

Um die dynamischen Posix-Gruppen nutzen zu können, wird eine Schemaerweiterung benötigt. Es werden je eine neue ObjectClass für Posix-Benutzer und für Posix-Gruppen benötigt. Das folgenden Listing zeig die LDIF-Datei um die Schemaerweiterung einzuspielen. Achten Sie darauf, meinen ODI durch den eigene OID zu ersetzen, das Gleiche gilt auch für den Suffix der Namen.

dn: cn=stkaPosixExtension,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: stkaPosixExtension
olcObjectClasses: ( 1.3.6.1.4.1.56860.1.2.1
NAME ’stkaPosixGroup‘
DESC ‚advanced PosixGroup for dynamic use‘
SUP top
AUXILIARY
MUST ( cn $ gidNumber )
MAY ( userPassword $ memberUid $ description ) )
olcObjectClasses: ( 1.3.6.1.4.1.56860.1.2.2
NAME ’stkaPosixAccount‘
DESC ‚advanced PosixAccount for dynamic use‘
SUP posixAccount
AUXILIARY
MAY ( memberUID ) )

Denken Sie daran, das Schema nicht nur auf den Providern, sondern auch auf allen Consumern einzuspielen.

Um später die Gruppen dynamisch erstellen zu können, wird hier nicht das Overlay „dynlist“ verwendet, sondern das Overlay „autogroup“. Für diese Overlay muss ein eigens Modul geladen werden. Das folgenden Listing zeigt das einbinden des Moduls und das Hinzufügen des Overlays zur Objekt-Datenbank.

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

dn: olcOverlay=autogroup,olcDatabase={2}mdb,cn=config
changetype: add
objectClass: olcAutoGroupConfig
objectClass: olcOverlayConfig
olcOverlay: autogroup
olcAutoGroupAttrSet: groupOfURLs memberURL memberUID

Auch hier müssen Sie darauf achten, dass die Änderungen sowohl auf den Providern als auch auf den Consumern durchgeführt werden.

Im Anschluss daran kann die erste dynamische Posix-Gruppe auf einem der Provider angelegt werden. Ein Beispiel für eine Posix-Gruppe zeigt das folgende Listing:

dn: cn=dynposix,ou=groups,dc=example,dc=net
cn: dynposix
objectClass: top
objectClass: groupOfURLs
objectClass: stkaPosixGroup
gidNumber: 4242
memberURL: ldap:///dc=example,dc=net?memberUID?sub?(title=Linuxuser)

Jeder Benutzer der im Attribute „title“ jetzt „Linuxuser“ als Eintrag hat, wird zum Mitglied der Gruppe. Selbstverständlich können Sie hier auch andere Attribute oder komplexe Filter nutzen.

Jetzt folgt ein Listing für einen neuen Benutzer, der Mitglied der Gruppe werden soll.

dn: uid=dynuser,ou=users,dc=example,dc=net
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: stkaPosixAccount
cn: John Doe
sn: Dynamo
title: Linuxuser
uid: dynuser
gidNumber: 1000
homeDirectory: /home/dynuser
uidNumber: 12345
userPassword: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$ZHN…
memberUid: dynuser

Der neue Benutzer zeigt die neue ObjecClass und das Attribut „memberUid: dynuser“. Selbstverständlich lassen sich bereits vorhandene Benutzer um die ObjectClass und das Attribut erweitern.

Bleibt noch der Test, ob der Benutzer auch auf allen Providern und allen Consumern Mitglied der Gruppe ist. Den Test sehen Sie im folgenden Listing:

root@ldap01:~# ldapsearch -Y external -LLL -H ldapi:/// cn=dynposix
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: cn=dynposix,ou=groups,dc=example,dc=net
cn: dynposix
objectClass: top
objectClass: groupOfURLs
objectClass: stkaPosixGroup
gidNumber: 4242
memberURL: ldap:///dc=example,dc=net?memberUID?sub?(title=Linuxuser)
memberUid: dynuser

Es hat geklappt, der Benutzer ist Mitglied der Gruppe und zwar auf allen Providern und allen Consumern. Dieser Punkt war zum Zeitpunkt als wir das Buch geschrieben noch nicht der Fall. Sollte die Mitgliedschaft bei Ihnen nur auf dem Provider angezeigt werden, auf dem Sie die Gruppe und den Benutzer angelegt haben, ist Ihre OpenLDAP-Version nicht auf dem aktuelle Stand. Ich habe es mit der Version 2.6.10 der Symas-Pakete auf einem Debian 13 getestet.

Serverseitig ist damit alles eingerichtet. Fehlt noch der Client. Auf einem Linux-Client, auf dem der „sssd“ (und nur damit klappt es) eingerichtet ist, muss die Datei sssd.conf um die folgenden zwei Zeilen ergänzt werden:

ldap_group_object_class = stkaPosixGroup
ldap_group_object_class_alt = PosixGroup

Vergessen Sie nicht, nach der Änderung den sssd neu zu starten.

Werfen wir jetzt eine Blick auf den Client. Als erstes wird die Identität des vorher eingerichteten Benutzer abgefragt:

root@client:~# id dynuser
uid=12345(dynuser) gid=1000(stka) Gruppen=1000(stka),4242(dynposix)

Dort sehen Sie jetzt auch die Gruppe „dynposix“ aufgelistet.

Jetzt lege ich zu Testen ein Verzeichnis an und gebe nur der Gruppe „dynposix“ das Recht auf das Verzeichnis zuzugreifen und dort Daten speichern zu können.
root@client:~# mkdir /daten

root@client:~# chgrp dynposix /daten

root@client:~# ls -ld /daten
drwxr-xr-x 2 root dynposix 4096 5. Dez 19:37 /daten

root@client:~# chmod 770 /daten

Anschließend wechsel ich die Identität zum Benutzer „dynuser“ um zu testen, ob der Zugriff möglich ist.

root@client:~# su – dynuser

$ cd /daten

$ touch dat1

$ ls -l
insgesamt 0
-rw-r–r– 1 dynuser stka 0 5. Dez 19:38 dat1

Der Zugriff ist möglich, auch das Erstellen einer neuen Datei klappt. Somit sind Sie jetzt in der Lage, die Dateisystemberechtigungen über dynamische Gruppen im OpenLDAP zu steuern.

Ein Wermutstropfen gibt es aber noch: Da hier das Overlay „autoGroup“ genutzt wird, kann das Attribute „memberOf“ nicht dynamisch gefüllt werden. Hier müsste dann noch das Overlay „memberOf“ mit eingebunden werden. Das Overlay war lange Zeit als „deprecated“ gekennzeichnet, wird aber jetzt wieder weiter gepflegt. Der Aufwand ist aber etwas größer, aus diesem Grund (und weil die Funktion der dynamischen Gruppe darunter nicht leidet) bin ich hier auf das Thema nicht weiter eingegangen. Die beiden Manpages zu „slapo-autogroup“ und „slapo-memberof“ sind aber so hilfreich, dass die Einrichtung auch ohne weitere Hilfe durchgeführt werden kann. Hier ging es mir HAUPTSÄCHLICH um die Einrichtung der dynamischen Posix-Gruppen.

Auch für das Jahr 2026 habe ich wieder Termine für online Seminare geplant. Geplant ist ein Linux-Grundlagen Seminar im Januar und ein Samba-Seminar im Februar. Die Ausschreibungen habe ich hinter dem jeweiligen Titel hinterlegt.

I have also planned dates for online seminars for 2026. A Linux basics seminar is planned for January and a Samba seminar for February. I have posted the announcements behind the respective titles.

Für OpenLDAP gibt es bereits eine Objektklass, die den LDAP um ein Attribut für die Verwaltung von publickeys erweitert. Warum soll das nicht auch im Samba-AD funktionieren. Es muss lediglich das Attribut angepasst werden und als Schemaerweiterung im AD eingetragen sein. Darum soll es hier gehen.

Hier vorab aber noch einmal der Hinweis:
Schemaerweiterungen können nicht wieder aus dem Active Directory-Schema entfernt werden. Planen Sie daher genau.

Als erstes erstellen Sie eine LDIF-Datei, über die Sie das Attribut einspielen, erst dann können Sie die Objektklasse der Benutzer anpassen. Für das Erstellen eigener Attribute und Objektklassen benötigen Sie einen eigene ODI, den Sie sich kostenlos bei der IANA registrieren lassen können. Dadurch wird das Attribut auf jeden Fall eindeutig. Auch verwende ich hier wieder meinen Präfix „stka“ um auch den Namen des Attributs eindeutig zu halten. Nachfolgend sehen Sie die LDIF-Datei für das Attribut:

——————————————–

dn: CN=stka-sshPublicKey,CN=Schema,CN=Configuration,DC=example,DC=net
changetype: add
objectClass: attributeSchema
attributeID: 1.3.1.5.1.4.1.123456.3.1
attributeSyntax: 2.5.5.12
oMSyntax: 64
lDAPDisplayName: stka-sshPublicKey
adminDisplayName: stka-sshPublicKey

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1

——————————————–

An Stelle der „123456“ tragen Sie Ihren eigenen ODI ein. Als Syntax wird hier ein Unicode String verwendet. Es wäre auch möglich, einen Octet String zu nutzen, aber der Unicode String ermöglicht es, dass Attribut später mit dem Windows tool ADSI-Editor zu verwalten.

Spielen Sie das neue Attribut mit dem Kommando „ldbmodify -H /var/lib/samba/private/sam.ldb ssh-attribut.ldif“ ein.

Erst wenn Sie das Attribut eingespielt haben, können Sie mit der nun folgenden LDIF-Datei die Objektklasse der Benutzer erweitern:

——————————————–

dn: CN=User,CN=Schema,CN=Configuration,DC=example,DC=net
changetype: modify
add: mayContain
mayContain: stka-sshPublicKey

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1

——————————————–

Auf gar keine Fall dürfen Sie hier ein „mustContain“ verwenden, denn dann können Sie keine Benutzer mehr mit dem ADUC anlegen. Denn dann müssten Sie die Maske zur Erstellung eines neuen Benutzers ändern.

Für die Anpassung des Objekts verwenden Sie wieder das Kommando: „ldbmodify -H /var/lib/samba/private/sam.ldb ch-user.ldif„.

Jetzt sind Sie in der Lage, Ihre Benutzerobjekte um den ssh publickey zu erweitern. Das können Sie entweder grafisch, mit dem ADSI-Editor, oder über eine entsprechende LDIF-Datei realisieren. Ein Beispiel für eine LDIF-Datei sehen Sie hier:

——————————————–

dn: CN=username,CN=Users,DC=example,DC=net
changeType: modify
add: stka-sshPublicKey
stka-sshPublicKey: ssh-ed25519 thepublickeyoftheuser usernam@myclient01.example.net

——————————————–

Aber wie kommt denn ein ssh-Server jetzt an den publickey?

Dafür ist ein kleiner Trick notwendig. Anders als beim OpenLDAP ist zum Zugriff auf den Samba Active Directory immer eine Kerberos-Authentifizierung notwendig. Da aber der ssh-Server nach dem publickey eines Benutzer suchen muss, sind hier ein paar kleiner Zwischenschritte notwendig.

Als erstes erstellen Sie eine Benutzer mit einem zufälligen Passwort, das nie abläuft.

root@addc01:~# samba-tool user create –random-password sshsearch
User ’sshsearch‘ added successfully

root@addc01:~# samba-tool user setexpiry sshsearch –noexpiry
Expiry for user ’sshsearch‘ disabled

Im Anschluss daran erzeugen Sie die keytab-Datei für den Benutzer, die anschließend auf alle Server kopiert wird, bei denn der sshd nach den publickeys im Active Directory suchen soll.

root@addc01:~# samba-tool domain exportkeytab –principal=sshsearch@EXAMPLE.NET /root/sshsearch.keytab
Export one principal to /root/sshsearch.keytab

Wenn Sie den Benutzer angelegt, die keytab Datei erstellt und kopiert haben, benötigen Sie jetzt noch ein Skript für die Suche. Das Skript sehen Sie im folgenden Listing:
Um das Skript später verwenden zu können, installieren Sie das heimdal-clients oder mit-user Paket auf dem Server.

——————————————–

#!/bin/sh
kinit -k -t /etc/sshsearch.keytab sshsearch

for i in $(host -t srv _ldap._tcp.example.net | cut -d “ “ -f 8 | cut -d „.“ -f 1)
do
ss -tlpn | grep 389
if true
then
DC=$i
break
fi
done
echo „domaincontroller = $DC“
ldbsearch -H ldap://“$DC“ ‚(&(objectClass=user)(sAMAccountName='“$1″‚))‘ ’stka-sshPublicKey‘ –use-kerberos=required | sed -n ‚/^ /{H;d};/stka-sshPublicKey:/x;$g;s/\n *//g;s/stka-sshPublicKey: //gp‘
kdestroy

——————————————–

Speichern Sie das Skript unter /usr/local/bin/fetchSSHKeysFromAD.bash. Vergessen Sie nicht, das Skript ausführbar zu machen.

In dem Skript wird als erstes ein Kerberos-Ticket mit dem vorher erstellten Benutzer und dessen keytab-Datei angefordert. In der Schleife wir nach aktiven Domaincontrollern gesucht. Wird ein aktiver Domaincontroller gefunden, wird die Schleife verlassen. Anschließend wird nach dem Benutzer, der die ssh-Sitzung aufbauen will gesucht und ein eventuelle publickey geladen. Zum Schluss wird das Ticket wieder gelöscht.

So vorbereitet, kann jetzt der sshd konfiguriert werden. Stellen Sie sicher, das in der Konfigurationsdatei /etc/ssh/sshd_config die folgenden Zeilen eingetragen sind.

——————————————–

PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromAD.bash
AuthorizedKeysCommandUser root
AllowGroups ssh-user

——————————————–

Das Skript muss als root ausgeführt werden. Dafür sorgt die Option „AuthorizedKeysCommandUser“.
Nur Mitglieder der Gruppe „ssh-user“ können sich auf dem Server via ssh anmelden. Das sollten Sie auf jeden Fall so regeln, denn sonst könnte sich jeder beliebige Benutzer, der einen publickey im Active Directory besitzt, am Server anmelden.

Eine kleine Klippe gibt es noch zu umschiffen. Damit das Ermitteln der Gruppenmitgliedschaft funktioniert, erweitern Sie die globale Konfiguration der smb.conf um die Zeile „winbind expand groups = 1„. Wenn Sie mit verschachtelten Gruppen arbeiten, erhöhen Sie den Wert um Ihre Verschachtelungstiefe.

Wenn Sie jetzt den sshd neu starten, steht der Anmeldung mit zentralen Publickeys nichts mehr im wege. Hier finden Sie alle benötigten Dateien.

Heute soll es darum gehen, ein Samba Active Directory um eine neue eigene auxiliary ObjectClass zu erstellen, mit eigenen Attributen.
Doch hier erst ein wichtiger Hinweis:

Das Ändern des Schemas in ein schwer Eingriff in die Struktur des Active Directories und sollte gut überlegt und geplant sein. Eine einmal in Active Directory eingespielte Änderung kann nicht wieder Rückgängig gemacht werden! Vor dem Einspielen sollten Sie auf jeden Fall Ihre Active Directory sichern. Testen Sie die Schemaänderung immer erst in einer Testumgebung!

Das Vorgehen beim Einspielen einer neuen ObjectClass und neuer Attribute ist hier anders, als Sie es vielleicht vom OpenLDAP her kennen. Im ersten Schritt müssen Sie immer erst die Attribute im Schema eintragen, erst dann kann die ObjectClass eingespielt werden. Hier im Beispiele sollen zwei neue Attribute angelegt werden, die dann später einzelnen Benutzern zugewiesen werden können. Sie sollten sich, sofern noch nicht passiert, auf jeden Fall einen eigene ODI bei der IANA registrieren um Ihre ObjectClass und Ihre Attribute weltweit eindeutig zu halten. Der Eigene ODI beginnt immer mit 1.3.6.1.4.1. Von der IANA erhalten Sie dann eine sechsstellige Nummer. Hier habe ich zur Demonstration die „123456“ genutzt. Die Zahlen nach dem OID sind frei wählbar. die erste ‚1‘ verweist hier immer auf meine erste eigenen Objectclass. Jede weitere neue ObjectClass wird immer um ‚1‘ hochgezählt. Die folgenden Zahl gib hier die Position des Attributs an. Alle neuen Attribute werden immer wieder um ‚1‘ hochgezählt. Verwenden Sie auch immer einen Suffix für Ihre ObjectClass und Ihre Attribute so ist auch beim Namen die Eindeutigkeit besser gegeben. Ich nutze hier „stka“ Jetzt folgt der LDIF für die Attribute

————-
dn: CN=stka-geburtstag,CN=Schema,CN=Configuration,DC=example,DC=net
objectClass: top
objectClass: attributeSchema
cn: stka-geburtstag
attributeID: 1.3.6.1.4.1.123456.1.1
lDAPDisplayName: stka-geburtstag
attributeSyntax: 2.5.5.12
omSyntax: 64
isSingleValued: TRUE
searchFlags: 0
description: Geburtstag des Benutzers (Datum als String)

dn: CN=stka-kfz,CN=Schema,CN=Configuration,DC=example,DC=net
objectClass: top
objectClass: attributeSchema
cn: stka-kfz
attributeID: 1.3.6.1.4.1.123456.1.2
lDAPDisplayName: stka-kfz
attributeSyntax: 2.5.5.12
omSyntax: 64
isSingleValued: TRUE
searchFlags: 0
description: Fahrzeugkennung des Benutzers (String)
————-

Aber woher kommen die Werte für die attributeSyntax und omSyntax? Laden Sie sich dafür die Quellen zu ihrer Samba-Version von der Webseite www.samba.org herunter. Nachdem Sie die Datei entpackt haben, suchen Sie nach der Datei source4/dsdb/schema/schema_syntax.c, in der Datei suchen Sie nach dem Muster ’static const struct‘, darunter finden Sie die Werte für die verschiedene Syntaxattribute. Dort finden Sie auch, welches Format für das Attribut gültig ist.

Nachdem Sie die Datei erstellt haben, können Sie die Attribute, mit dem folgenden Kommando, einspielen:

ldbmodify -H /var/lib/samba/private/sam.ldb /root/new-attrib.ldif –option=“dsdb:schema update allowed“=true

Die Option ist zwingend erforderlich, da das Verändern des Schemas normaler Weise gesperrt ist.

Im Anschluss kann dann die neu ObjectClass erstellt werden. Das folgenden Listing zeigt ein Beispiel:

————
dn: CN=stka-user,CN=Schema,CN=Configuration,DC=example,DC=net
objectClass: top
objectClass: classSchema
cn: stka-user
governsID: 1.3.6.1.4.1.123456.1.3
lDAPDisplayName: stka-user
subClassOf: top
objectClassCategory: 3
mayContain: stka-geburtstag
mayContain: stka-kfz
description: Auxiliary ObjectClass zur Erweiterung von Benutzerobjekten
————

Dann können Sie die ObjectClass einspielen:
ldbmodify -H /var/lib/samba/private/sam.ldb /root/new-objectclass.ldif –option=“dsdb:schema update allowed“=true

Für alle folgenden Änderungen an den Objekten, verwenden Sie immer das Kommando:
ldbmodify -H /var/lib/samba/private/sam.ldb <datei.ldif>
Jetzt einen LDIF erstellen um die neue ObjectClass zu einem Benutzer hinzuzufügen:

———–
dn: CN=Karl_Klammer,CN=Users,DC=example,DC=net
changetype: modify
add: objectClass
objectClass: stka-user
———–

Erst jetzt können die neuen Attribute dem Benutzer hinzugefügt werden. Dafür wird der folgende LDIF benötigt:
———–
dn: CN=Karl_Klammer,CN=Users,DC=example,DC=net
changetype: modify
add: stka-geburtstag
stka-geburtstag: 1990-05-14
–
add: stka-kfz
stka-kfz: AB-XY-1234

———–

Jetzt ist der Benutzer geändert und die Änderung kann angezeigt werden:
————
root@dc01:~# ldbsearch -H /var/lib/samba/private/sam.ldb cn=Karl_Klammer
# record 1
dn: CN=Karl_klammer,CN=Users,DC=example,DC=net
cn: Karl_klammer
instanceType: 4
whenCreated: 20251030190730.0Z
uSNCreated: 4080
name: Karl_klammer
objectGUID: 8c932e96-9ae7-4d77-b0f8-62553617cfe8
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
primaryGroupID: 513
objectSid: S-1-5-21-1270304378-1688964665-1878507777-1106
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: Karl_klammer
sAMAccountType: 805306368
userPrincipalName: Karl_klammer@example.net
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=example,DC=net
pwdLastSet: 134063248508330770
userAccountControl: 512
objectClass: top
objectClass: stka-user
objectClass: person
objectClass: organizationalPerson
objectClass: user
stka-geburtstag: 1990-05-14
stka-kfz: AB-XY-1234
whenChanged: 20251030191518.0Z
uSNChanged: 4084
distinguishedName: CN=Karl_klammer,CN=Users,DC=example,DC=net

# Referral
ref: ldap://example.net/CN=Configuration,DC=example,DC=net

# Referral
ref: ldap://example.net/DC=DomainDnsZones,DC=example,DC=net

# Referral
ref: ldap://example.net/DC=ForestDnsZones,DC=example,DC=net

# returned 4 records
# 1 entries
# 3 referrals
————

Natürlich können die Werte in den Benutzerobjekten auch geändert oder gelöscht werden. Dazu wird wieder ein entsprechender LDIF benötigt. Als erstes sehen Sie den LDIF für die Änderung eines der beiden Attribute:
————
dn: CN=Karl_Klammer,CN=Users,DC=example,DC=net
changetype: modify
replace: stka-geburtstag
stka-geburtstag: 1999-05-14
————

Das folgende Listing zeigt das löschen eines Attributs

————
dn: CN=Karl_Klammer,CN=Users,DC=example,DC=net
changetype: modify
delete: stka-geburtstag
————

Um die ObjectClass bei einem Objekt zu entfernen, müssen erst alle Attribute der ObjectClass vom Objekt entfernt werden. Dazu wird der LDIF aus dem folgenden Listing benötigt:

————
dn: CN=Karl_Klammer,CN=Users,DC=example,DC=net
changetype: modify
delete: objectClass
objectClass: stka-user
————

Hier noch einmal der Hinweis: Die eingespielten Attribute und Objektklassen können NICHT wieder entfernt werden.

So können Sie in Zukunft Ihren Samba-AD um eigen ObjectClasses und Attribute erweitern.

Wenn ich bei so manchem Betreiber frage: „Wann habt ihr denn das letzt Mal den Masterkey eures Kerberos-Servers getauscht?“ Ist oft die Antwort „noch nie“ oder noch schlimmer „was für einen Masterkey?“

Der Masterkey auf einem Kerberos-Server sollte aber immer regelmäßig getauscht werden, spätestens dann, wenn der Admin, der den aktuellen Key vergeben hat, fas Unternehmen verlässt. Um das Verfahren mal darzustellen, stelle ich hier mal eine Schritt für Schritt Anleitung bereit:

Alles wird auf dem primary KDC ausgeführt.
Anzeigen des aktuellen Schlüssels

root@kerberos01:~# kdb5_util list_mkeys
Master keys for Principal: K/M@EXAMPLE.NET
KVNO: 1, Verschlüsselungstyp: aes256-cts-hmac-sha384-192, aktiviert auf: Do Jan 01 01:00:00 CET 1970 *

Das Datum „Do Jan 01 01:00:00 CET 1970“ zeigt, dass der Masterkey, seit erstellen der Datenbank noch nie gewechselt wurde. Jetzt wird erst noch einmal sichergestellt, dass der Schlüssel verwendet wird.

root@kerberos01:~# kdb5_util use_mkey 1

Jetzt kann der neuen Schlüssels erstellt werden  und in den stash-file geschrieben werden.

root@kerberos01:~# kdb5_util add_mkey -s
Es wird ein neuer Hauptschlüssel für den Hauptschlüssel-Principal »K/M@EXAMPLE.NET« erstellt. Sie werden nach einem neuen Datenbank-Master-Passwort gefragt.
Es ist wichtig, dass Sie dieses Passwort NICHT VERGESSEN.
Enter KDC database master key:
Re-enter KDC database master key to verify:

Der Schlüssel wird erzeugt und in die Datei geschrieben, aber noch nicht aktiviert

Erneutes Auflisten der Schlüssel

root@kerberos01:~# kdb5_util list_mkeys
Master keys for Principal: K/M@EXAMPLE.NET
KVNO: 2, Verschlüsselungstyp: aes256-cts-hmac-sha384-192, keine Aktivierungszeit gesetzt
KVNO: 1, Verschlüsselungstyp: aes256-cts-hmac-sha384-192, aktiviert auf: Fr Feb 07 16:54:01 CET 2025 *

Noch ist der Schlüssel mit KVNO 1 aktiv (erkennbar an dem Stern am Ende der Zeile)

Wenn mehrere Kerberos-Server vorhanden sind, dann ist jetzt der Zeitpunk gekommen, den stash-file zu verteilen und die Datenbank neu replizieren.

Es macht Sinn auf allen KDCs mit kdb5_util list_mkeys zu prüfen, ob der neue Schlüssel vorhanden ist

Auf dem primary KDC den neuen Schlüssel aktivieren:

root@kerberos01:~#  kdb5_util use_mkey 2

Dann sollten Sie sich  noch einmal die Schlüssel auflisten lassen

root@kerberos01:~# kdb5_util list_mkeys
Master keys for Principal: K/M@EXAMPLE.NET
KVNO: 2, Verschlüsselungstyp: aes256-cts-hmac-sha384-192, aktiviert auf: Fr Feb 07 17:12:11 CET 2025 *
KVNO: 1, Verschlüsselungstyp: aes256-cts-hmac-sha384-192, aktiviert auf: Fr Feb 07 16:54:01 CET 2025

Jetzt ist der neu Schlüssel aktiv. die (2) ist die KVNO des neuen Schlüssels

Anschließend muss der kdc-Dienst, auf allen KDCs, neu gestartet werden.

Jetzt müssen noch alle Schlüssel der Principals in der Datenbank mit dem neuen Master-key verschlüsselt werden. Das passiert wieder auf dem primary KDC. Dafür gibt es zwei Möglichkeiten:
1. Die schneller Methode, aber dann ist der KDC währen der neuen Verschlüsselung nicht erreichbar. Clients können aber die anderen KDC zur Authentifizierung nutzen.

root@kerberos01:~#  kdb5_util update_princ_encryption
Sollen alle Schlüssel neu verschlüsselt werden, die nicht die Hauptschlüssel-VNO 2 verwenden?
(Geben Sie als Bestätigung »yes« ein) yes
6 Principals verarbeitet: 6 aktualisiert, 0 bereits aktuell

2. Muss der primary KDC während des Prozesse verfügbar bleiben geht das mit:

root@kerberos01:~# kdb5_util -x unlockiter update_princ_encryption
Sollen alle Schlüssel neu verschlüsselt werden, die nicht die Hauptschlüssel-VNO 2 verwenden?
(Geben Sie als Bestätigung »yes« ein) yes
6 Principals verarbeitet: 0 aktualisiert, 6 bereits aktuell

Dauert bei einer großen Anzahl an Principals aber länger.
Jetzt muss wieder dafür gesorgt werden, dass die Datenbank auf alle KDCs repliziert wird!

Nach der Replikation kann der alte Schlüssel entfernt werden mit:

root@kerberos01:~#  kdb5_util purge_mkeys
Sind Sie sicher, dass alle nicht verwendeten Hauptschlüssel, die für Principal »K/M@EXAMPLE.NET« gespeichert sind, vollständig entfernt werden sollen?
(Geben Sie als Bestätigung »yes« ein)? yes
Ok, die nicht verwendeten Hauptschlüssel von »K/M@EXAMPLE.NET« werden vollständig entfernt …
Der/Die folgende(n) Hauptschlüssel werden/wird von K/M@EXAMPLE.NET vollständig entfernt:
KVNO: 1
1 Schlüssel vollständig entfernt

Beim Auflisten wird nur noch der neue Schlüssel angezeigt:

root@kerberos01:~# kdb5_util list_mkeys
Master keys for Principal: K/M@EXAMPLE.NET
KVNO: 2, Verschlüsselungstyp: aes256-cts-hmac-sha384-192, aktiviert auf: Fr Feb 07 17:12:11 CET 2025 *

Liegt die Kerberos-Datenbank im LDAP, wird die Replikation automatisch durchgeführt. Nur wenn standalone Kerberos-Server mit einer lokalen Datenbank verwendet werden, muss die Replikation von Hand angestoßen werden.

Für mein Samba 4 Buchprojekt, für die englische Ausgabe, habe ich ja auf Amazons KDP-Programm gesetzt. Neben dem Paperback wollte ich auf jeden Fall ein ebook anbieten. Das ging natürlich nur als .kdp also im Kindle-Format. Aber wie bekomme ich aus meinem PDF, das aus meinen LaTeX-Quellen erstellt wurde, ein .epub? Denn ein PDF lässt sich zwar übernehmen, sieht aber gruselig aus. Also erst einmal ein epub erstellen. Hört sich einfach an, ist aber etwas komplizierter. Denn meine Formatierungen mit den Kästen und vor allen Dingen die ALT-Texte zu den Bildern sollten erhalten bleiben. Leider gab es im Netz dazu nirgendwo ein passende Lösung. Also dachte ich, frage mal chatGPT, und nach drei Tagen (musste immer ans Maximum meiner Anfragen gehen) stand dann die Lösung, die ich hier gerne mal präsentieren möchte. Es reicht ja, wenn es einmal erstellt wird :-). Ich brauchte ein Skript, das die Umstellung vornimmt, das hat mit chatGPT auch schnell erstellt. Aber dann fehlten alle Formatierungen. Dafür gibt es jetzt eine .css Datei, die dafür sorgt, dass alles auch hübsch ist. Fehlten immer noch meine ALT-Texte. Die können mittels pandoc und einem LUA-Filter erstellt werden. Dieser Filter sucht dann nach den ALT-Texten im LaTeX-Dokument und und erzeugt den ALT-Text im ebook. Wenn kein ALT-Text vorhanden ist, wird der „caption“ Text aus dem LaTeX-Dokument genutzt. Im Skript wird der Filter direkt eingebunden, muss also beim Erstellen des epub nicht mit angegeben werden. Alle benötigten Dateien finden Sie hier. Das Kommando für die Einrichtung lautet dann:

latex2kpf.sh buch.tex –title „Buchtitel“ –author „Name des Autors“ –cover <cover.jpg> –css kindle.css –math mathml

Im Anschluss finden Sie dann, im Ordner „build-kindle“, das Buch als epub. Das kann dann direkt im KDP hochgeladen werden. Das Kindle-Format wird dann daraus automatisch erstellt und alle Formatierungen bleiben erhalten.
Nachdem ich alles hochgeladen habe, kamen dann 72 Stunden banges warten, ob auch alle gut gegangen ist. Solange dauert die Prüfung, ob das Buch auch allen Regeln von Amazon entspricht. Passt! Das Buch ist jetzt auf Amazon (englisch) und (deutsch) verfügbar.

I have planned various new seminars for the fall. All seminars listed will take place online and in English. I offer the following seminars:
Linux Basics
OpenLDAP Administration
Samba Administration
The exact contents, prior knowledge, and prerequisites are described in the corresponding announcements.
All seminars listed here will take place online and in English.
Do you have any further questions? Just get in touch with me.