X

Speichern von publicKeys im Samba AD

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.

Categories: Allgemein
Stefan:
Related Post

This website uses cookies.