Historisch gesehen wurden Sudo-Berechtigungen durch den Inhalt von Dateien aus gesteuert /etc/sudoers.d и visudo, und die Schlüsselautorisierung wurde mit durchgeführt ~ / .ssh / autorisierte_Tasten. Mit zunehmender Infrastruktur besteht jedoch der Wunsch, diese Rechte zentral zu verwalten. Heute kann es mehrere Lösungsmöglichkeiten geben:
- Konfigurationsmanagementsystem - KüchenchefIn, Marionette, Ansible, Salz
- Active Directory + SSD
- Diverse Perversionen in Form von Skripten und manueller Dateibearbeitung
Meiner subjektiven Meinung nach ist die beste Option für eine zentrale Verwaltung immer noch eine Kombination Active Directory + SSD. Die Vorteile dieses Ansatzes sind:
- Wirklich ein einziges zentrales Benutzerverzeichnis.
- Verteilung der Rechte sudo kommt es darauf an, einen Benutzer zu einer bestimmten Sicherheitsgruppe hinzuzufügen.
- Bei verschiedenen Linux-Systemen ist es erforderlich, bei Verwendung von Konfigurationssystemen zusätzliche Prüfungen zur Ermittlung des Betriebssystems einzuführen.
Die heutige Suite ist speziell der Verbindung gewidmet Active Directory + SSD für die Rechteverwaltung sudo und Lagerung ssh Schlüssel in einem einzigen Repository.
So erstarrte der Saal in angespannter Stille, der Dirigent hob seinen Taktstock und das Orchester machte sich bereit.
Kommen Sie.
Mai:
– Active Directory-Domäne testtopf.local auf Windows Server 2012 R2.
– Linux-Host mit Centos 7
— Konfigurierte Autorisierung mit SSD
Beide Lösungen nehmen Änderungen am Schema vor Active DirectoryDeshalb prüfen wir alles in einer Testumgebung und nehmen erst dann Änderungen an der funktionierenden Infrastruktur vor. Ich möchte darauf hinweisen, dass alle Änderungen gezielt sind und tatsächlich nur die erforderlichen Attribute und Klassen hinzufügen.
Aktion 1: Kontrolle sudo Rollen durch Active Directory.
Um die Schaltung zu erweitern Active Directory Sie müssen die neueste Version herunterladen — 1.8.27, Stand heute. Entpacken und kopieren Sie die Datei schema.ActiveDirectory vom ./doc-Verzeichnis zum Domänencontroller. Führen Sie in der Befehlszeile mit Administratorrechten aus dem Verzeichnis, in das die Datei kopiert wurde, Folgendes aus:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Vergessen Sie nicht, Ihre Werte zu ersetzen)
Öffnen adsiedit.msc und stellen Sie eine Verbindung zum Standardkontext her:
Erstellen Sie eine Abteilung im Stammverzeichnis der Domäne sudoers. (Die Bourgeoisie behauptet hartnäckig, dass in dieser Einheit der Dämon steckt SSD sucht nach einem Artikel sudoRole Objekte. Nach dem Einschalten des detaillierten Debuggens und dem Studium der Protokolle stellte sich jedoch heraus, dass die Suche im gesamten Verzeichnisbaum durchgeführt wurde.)
Wir erstellen das erste Objekt, das zur Klasse in der Division gehört sudoRole. Der Name kann absolut beliebig gewählt werden, da er ausschließlich der bequemen Identifizierung dient.
Unter den möglichen verfügbaren Attributen der Schemaerweiterung sind die wichtigsten die folgenden:
- sudoCommand – legt fest, welche Befehle auf dem Host ausgeführt werden dürfen.
- sudoHost – bestimmt, für welche Hosts diese Rolle gilt. Kann angegeben werden als ALLER, und für einen einzelnen Gastgeber mit Namen. Es ist auch möglich, eine Maske zu verwenden.
- sudoUser – Geben Sie an, welche Benutzer ausführen dürfen sudo.
Wenn Sie eine Sicherheitsgruppe angeben, fügen Sie am Anfang des Namens ein „%“-Zeichen hinzu. Wenn der Gruppenname Leerzeichen enthält, besteht kein Grund zur Sorge. Den Protokollen nach zu urteilen, wird die Aufgabe, Leerzeichen zu entkommen, vom Mechanismus übernommen SSD.
Abb. 1. sudoRole-Objekte in der sudoers-Unterteilung im Stammverzeichnis des Verzeichnisses
Abbildung 2. Mitgliedschaft in Sicherheitsgruppen, die in sudoRole-Objekten angegeben sind.
Das folgende Setup wird auf der Linux-Seite durchgeführt.
Im Ordner /etc/nsswitch.conf Fügen Sie die Zeile am Ende der Datei hinzu:
sudoers: files sssIm Ordner /etc/ssd/ssd.conf im Abschnitt [sssd] zu Dienstleistungen hinzufügen sudo
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
Nach allen Vorgängen müssen Sie den SSD-Daemon-Cache leeren. Automatische Updates finden alle 6 Stunden statt, aber warum sollten wir so lange warten, wenn wir es jetzt wollen?
sss_cache -EEs kommt oft vor, dass das Leeren des Caches nicht hilft. Dann stoppen wir den Dienst, bereinigen die Datenbank und starten den Dienst.
service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start
Wir verbinden uns als erster Benutzer und prüfen, was ihm unter sudo zur Verfügung steht:
su user1
[user1@testsshad log]$ id
uid=1109801141(user1) gid=1109800513(domain users) groups=1109800513(domain users),1109801132(admins_)
[user1@testsshad log]$ sudo -l
[sudo] password for user1:
Matching Defaults entries for user1 on testsshad:
!visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
secure_path=/sbin:/bin:/usr/sbin:/usr/bin
User user1 may run the following commands on testsshad:
(root) /usr/bin/ls, /usr/bin/catDasselbe machen wir auch mit unserem zweiten Benutzer:
su user2
[user2@testsshad log]$ id
uid=1109801142(user2) gid=1109800513(domain users) groups=1109800513(domain users),1109801138(sudo_root)
[user2@testsshad log]$ sudo -l
Matching Defaults entries for user2 on testsshad:
!visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
secure_path=/sbin:/bin:/usr/sbin:/usr/bin
User user2 may run the following commands on testsshad:
(root) ALL
Mit diesem Ansatz können Sie Sudo-Rollen für verschiedene Benutzergruppen zentral definieren.
Speichern und Verwenden von SSH-Schlüsseln in Active Directory
Mit einer leichten Erweiterung des Schemas ist es möglich, SSH-Schlüssel in Active Directory-Benutzerattributen zu speichern und diese bei der Autorisierung auf Linux-Hosts zu verwenden.
Die Autorisierung über SSD muss konfiguriert sein.
Fügen Sie das erforderliche Attribut mithilfe eines PowerShell-Skripts hinzu.
AddsshPublicKeyAttribute.ps1Funktion New-AttributeID {
$Prefix="1.2.840.113556.1.8000.2554"
$GUID=[System.Guid]::NewGuid().ToString()
$Parts=@()
$Parts+=[UInt64]::Parse($guid.SubString(0,4),“AllowHexSpecifier“)
$Parts+=[UInt64]::Parse($guid.SubString(4,4),“AllowHexSpecifier“)
$Parts+=[UInt64]::Parse($guid.SubString(9,4),“AllowHexSpecifier“)
$Parts+=[UInt64]::Parse($guid.SubString(14,4),“AllowHexSpecifier“)
$Parts+=[UInt64]::Parse($guid.SubString(19,4),“AllowHexSpecifier“)
$Parts+=[UInt64]::Parse($guid.SubString(24,6),“AllowHexSpecifier“)
$Parts+=[UInt64]::Parse($guid.SubString(30,6),“AllowHexSpecifier“)
$oid=[String]::Format(«{0}.{1}.{2}.{3}.{4}.{5}.{6}.{7}»,$prefix,$Parts[0],
$Parts[1],$Parts[2],$Parts[3],$Parts[4],$Parts[5],$Parts[6])
$oid
}
$schemaPath = (Get-ADRootDSE).schemaNamingContext
$oid = New-AttributeID
$attributes = @{
lDAPDisplayName = 'sshPublicKey';
attributeId = $oid;
oMSyntax = 22;
attributeSyntax = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'Öffentlicher Benutzerschlüssel für SSH-Anmeldung';
}
New-ADObject -Name sshPublicKey -Type attributeSchema -Path $schemapath -OtherAttributes $attributes
$userSchema = get-adobject -SearchBase $schemapath -Filter 'name -eq "user"'
$userSchema | Set-ADObject -Add @{mayContain = 'sshPublicKey'}
Nachdem Sie das Attribut hinzugefügt haben, müssen Sie die Active Directory-Domänendienste neu starten.
Kommen wir nun zu den Active Directory-Benutzern. Wir generieren ein Schlüsselpaar für die SSH-Verbindung mit jeder für Sie geeigneten Methode.
Wir starten PuttyGen, drücken die Schaltfläche „Generieren“ und bewegen die Maus hektisch über den leeren Bereich.
Nach Abschluss des Vorgangs können wir den öffentlichen und privaten Schlüssel speichern, den öffentlichen Schlüssel in das Active Directory-Benutzerattribut hochladen und den Vorgang genießen. Allerdings muss der öffentliche Schlüssel aus dem „“ verwendet werden.Öffentlicher Schlüssel zum Einfügen in die OpenSSH-authorized_keys-Datei:«.
Fügen Sie den Schlüssel zum Benutzerattribut hinzu.
Option 1 – GUI:
Option 2 – PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Wir haben also derzeit: einen Benutzer mit ausgefülltem sshPublicKey-Attribut, einen konfigurierten Putty-Client für die Autorisierung mithilfe von Schlüsseln. Es bleibt noch ein kleiner Punkt: Wie kann man den SSHD-Daemon zwingen, den benötigten öffentlichen Schlüssel aus den Benutzerattributen zu extrahieren? Ein kleines Skript aus dem bürgerlichen Internet kann damit erfolgreich umgehen.
cat /usr/local/bin/fetchSSHKeysFromLDAP
#!/bin/sh
ldapsearch -h testmdt.testopf.local -xb "dc=testopf,dc=local" '(sAMAccountName='"${1%@*}"')' -D [email protected] -w superSecretPassword 'sshPublicKey' | sed -n '/^ /{H;d};/sshPublicKey:/x;$g;s/n *//g;s/sshPublicKey: //gp'Wir setzen die Berechtigungen dafür auf 0500 für Root.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
In diesem Beispiel wird ein Administratorkonto zur Bindung an das Verzeichnis verwendet. Unter Kampfbedingungen muss ein separates Konto mit einem Mindestsatz an Rechten vorhanden sein.
Mich persönlich hat der Moment des Passworts in seiner reinen Form im Skript trotz der eingestellten Rechte sehr verwirrt.
Lösungsmöglichkeit:
- Ich speichere das Passwort in einer separaten Datei:
echo -n Supersecretpassword > /usr/local/etc/secretpass - Ich habe die Dateiberechtigungen für Root auf 0500 gesetzt
chmod 0500 /usr/local/etc/secretpass - Ändern der Startparameter von ldapsearch: Parameter -w superSecretPassword Ich ändere es in -y /usr/local/etc/secretpass
Der Schlussakkord in der heutigen Suite ist die Bearbeitung von sshd_config
cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root
Als Ergebnis erhalten wir die folgende Sequenz mit im SSH-Client konfigurierter Schlüsselautorisierung:
- Der Benutzer verbindet sich mit dem Server, indem er sein Login angibt.
- Der sshd-Daemon extrahiert über ein Skript den Wert des öffentlichen Schlüssels aus einem Benutzerattribut in Active Directory und führt die Autorisierung mithilfe der Schlüssel durch.
- Der SSSD-Daemon authentifiziert den Benutzer außerdem basierend auf der Gruppenmitgliedschaft. Aufmerksamkeit! Wenn dies nicht konfiguriert ist, hat jeder Domänenbenutzer Zugriff auf den Host.
- Wenn Sie sudo versuchen, durchsucht der SSSD-Daemon das Active Directory nach Rollen. Wenn Rollen vorhanden sind, werden die Attribute und die Gruppenmitgliedschaft des Benutzers überprüft (wenn sudoRoles für die Verwendung von Benutzergruppen konfiguriert ist).
Zusammenfassung.
Somit werden die Schlüssel in Active Directory-Benutzerattributen und Sudo-Berechtigungen gespeichert. Ebenso erfolgt der Zugriff auf Linux-Hosts durch Domänenkonten durch Überprüfung der Mitgliedschaft in der Active Directory-Gruppe.
Der letzte Wink des Dirigentenstabs – und der Saal erstarrt in andächtiger Stille.
Beim Schreiben verwendete Ressourcen:
Source: habr.com