Geekly articles weekly

Auf der Bühne wieder Gewinner der internationalen Wettbewerbe SSH und sudo. Unter der Anleitung von Honoured Conductor Active Directory

In der Vergangenheit wurden die Sudo- Rechte durch den Inhalt der Dateien aus /etc/sudoers.d und visudo geregelt , und die Schlüsselautorisierung wurde mit ~ / .ssh / authorized_keys durchgeführt . Mit dem Wachstum der Infrastruktur besteht jedoch der Wunsch, diese Rechte zentral zu verwalten. Bisher kann es mehrere Lösungen geben:

  • Konfigurationsmanagementsystem - Chef , Marionette , Ansible , Salz
  • Active Directory + sssd
  • Verschiedene Verzerrungen in Form von Skripten und manueller Bearbeitung von Dateien

Meiner subjektiven Meinung nach ist die beste Option für die zentrale Verwaltung immer noch eine Reihe von Active Directory + sssd . Die Vorteile dieses Ansatzes sind:

  • Wirklich ein einziges zentrales Benutzerverzeichnis.
  • Beim Verteilen von Sudo- Rechten wird ein Benutzer zu einer bestimmten Sicherheitsgruppe hinzugefügt.
  • Bei verschiedenen Linux-Systemen müssen zusätzliche Überprüfungen zur Ermittlung des Betriebssystems bei Verwendung von Konfigurationssystemen eingeführt werden.

Die heutige Suite ist dem Active Directory + sssd-Bundle zum Verwalten von Sudo- Rechten und Speichern von SSH- Schlüsseln in einem einzigen Repository gewidmet.
Also erstarrte das Publikum in angespannter Stille, der Dirigent hob seinen Zauberstab, das Orchester bereitete sich vor.
Lass uns gehen.

Gegeben:

  • Active Directory- Domäne testopf.local unter Windows Server 2012 R2.
  • Linux-Host mit Centos 7
  • Konfigurierte Autorisierung mit sssd

Beide Lösungen nehmen Änderungen am Active Directory-Schema vor . Daher überprüfen wir alles in einer Testumgebung und nehmen erst dann Änderungen an der funktionierenden Infrastruktur vor. Ich möchte darauf hinweisen, dass alle Änderungen punktbasiert sind und tatsächlich nur die erforderlichen Attribute und Klassen hinzufügen.

Schritt 1: Verwalten von Sudorollen über Active Directory .


Um das Active Directory-Schema zu erweitern, müssen Sie noch heute die neueste Sudo- Version 1.8.27 herunterladen. Entpacken Sie die Datei schema.ActiveDirectory aus dem Verzeichnis ./doc auf den Domänencontroller. Führen Sie in der Befehlszeile mit Administratorrechten aus dem Verzeichnis, in das Sie die Datei kopiert haben, Folgendes aus:

ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Vergessen Sie nicht, Ihre Werte zu ersetzen)

Öffnen Sie adsiedit.msc und stellen Sie eine Verbindung zum Standardkontext her:

Erstellen Sie im Stammverzeichnis der Domäne eine Sudoers- Einheit. (Die Bourgeois argumentieren hartnäckig, dass der sssd- Daemon in dieser Einheit nach sudoRole- Objekten sucht. Nach dem Aktivieren des detaillierten Debugs und dem Überprüfen der Protokolle wurde jedoch festgestellt, dass die Suche im gesamten Katalogbaum durchgeführt wird.)

Erstellen Sie das erste Objekt in der Einheit, das zur sudoRole- Klasse gehört. Der Name kann absolut willkürlich gewählt werden, da er nur zur bequemen Identifizierung dient.

Unter den möglichen verfügbaren Attributen aus der Schemaerweiterung sind die wichtigsten:

  • sudoCommand - Legt fest, welche Befehle auf dem Host ausgeführt werden dürfen.
  • sudoHost - bestimmt, für welche Hosts diese Rolle gilt. Es kann als ALL oder für einen einzelnen Host nach Namen festgelegt werden. Es ist auch möglich, eine Maske zu verwenden.
  • sudoUser - Geben Sie an, welche Benutzer sudo ausführen dürfen.
    Wenn eine Sicherheitsgruppe angegeben ist, fügen Sie am Anfang des Namens das Zeichen "%" hinzu. Wenn der Gruppenname Leerzeichen enthält, besteht kein Grund zur Sorge. Nach den Protokollen zu urteilen , übernimmt der sssd- Mechanismus die Aufgabe, Leerzeichen zu verlassen.


Abbildung 1. sudoRole-Objekte in der sudoers-Einheit im Stammverzeichnis des Verzeichnisses


Abbildung 2. Mitgliedschaft in den in sudoRole-Objekten angegebenen Sicherheitsgruppen.

Die folgende Konfiguration erfolgt auf Linux-Seite.

Fügen Sie in der Datei /etc/nsswitch.conf die Zeile am Ende der Datei hinzu:

 sudoers: files sss

Fügen Sie in der Datei /etc/sssd/sssd.conf im Abschnitt [sssd] den Diensten sudo hinzu

 cat /etc/sssd/sssd.conf | grep services services = nss, pam, sudo

Nach allen Vorgängen müssen Sie den sssd-Daemon-Cache leeren. Automatische Updates werden alle 6 Stunden durchgeführt, aber warum müssen wir so lange warten, wenn wir jetzt wollen?

 sss_cache -E

Es kommt oft vor, dass das Löschen des Caches nicht hilft. Dann beenden wir den Dienst, reinigen die Basis und starten den Dienst.

 service sssd stop rm -rf /var/lib/sss/db/* service sssd start

Wir verbinden uns unter dem ersten Benutzer und prüfen, ob unter sudo darauf zugegriffen werden kann:

 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/cat

Wir machen dasselbe 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 kleinen Erweiterung des Schemas ist es möglich, SSH-Schlüssel in Active Directory-Benutzerattributen zu speichern und für die Autorisierung auf Linux-Hosts zu verwenden.

Die Autorisierung über sssd muss konfiguriert werden.

Fügen Sie das gewünschte Attribut mithilfe des PowerShell-Skripts hinzu.

AddsshPublicKeyAttribute.ps1
Funktion 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}", $ Präfix, $ Teile [ 0],
$ Teile [1], $ Teile [2], $ Teile [3], $ Teile [4], $ Teile [5], $ Teile [6])
$ oid
}}
$ schemaPath = (Get-ADRootDSE) .schemaNamingContext
$ oid = New-AttributeID
$ attribute = @ {
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 $ attribute
$ userSchema = get-adobject -SearchBase $ schemapath -Filter 'name -eq "user"'
$ userSchema | Set-ADObject -Add @ {mayContain = 'sshPublicKey'}

Starten Sie nach dem Hinzufügen des Attributs die Active Directory-Domänendienste neu.
Wir geben an Benutzer von Active Directory weiter. Auf jede für Sie bequeme Weise generieren wir ein Schlüsselpaar für die SSH-Verbindung.

Starten Sie PuttyGen, klicken Sie auf die Schaltfläche "Generieren" und klicken Sie verzweifelt mit der Maus in einem leeren Bereich.

Nach Abschluss des Vorgangs können wir den öffentlichen und den privaten Schlüssel speichern, den öffentlichen Schlüssel im Active Directory-Benutzerattribut eingeben und den Vorgang genießen. Der öffentliche Schlüssel muss jedoch aus dem Fenster " Öffentlicher Schlüssel zum Einfügen in die OpenSSH-Datei " authorized_keys " : " verwendet werden.



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 im Moment: einen Benutzer mit dem ausgefüllten Attribut sshPublicKey, einen Putty-Client, der für die Schlüsselautorisierung konfiguriert ist. Es bleibt noch ein kleiner Punkt, wie der sshd-Dämon den öffentlichen Schlüssel, den wir benötigen, aus den Benutzerattributen ziehen kann. Ein kleines Skript auf den Freiflächen des bürgerlichen Internets schafft dies erfolgreich.

 cat /usr/local/bin/fetchSSHKeysFromLDAP #!/bin/sh ldapsearch -h testmdt.testopf.local -xb "dc=testopf,dc=local" '(sAMAccountName='"${1%@*}"')' -D Administrator@testopf.local -w superSecretPassword 'sshPublicKey' | sed -n '/^ /{H;d};/sshPublicKey:/x;$g;s/\n *//g;s/sshPublicKey: //gp'

Wir haben 0500 Berechtigungen für root festgelegt.

 chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP

In diesem Beispiel wird das Administratorkonto für die Bindung an das Verzeichnis verwendet. Unter Kampfbedingungen sollte es ein separates Konto mit einem Mindestmaß an Rechten geben.

Ich persönlich war sehr verwirrt über den Moment des Passworts in seiner reinen Form im Skript, trotz der festgelegten Rechte.

Lösungsoption:

  • Ich speichere das Passwort in einer separaten Datei:

     echo -n Supersecretpassword > /usr/local/etc/secretpass
  • Ich habe die Berechtigungen für die 0500-Datei für root festgelegt

     chmod 0500 /usr/local/etc/secretpass
  • Ich ändere die Startparameter von ldapsearch: Der Parameter -w superSecretPassword wird in -y / usr / local / etc / secretpass geändert

Der letzte Akkord in der heutigen Suite ist das Bearbeiten 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 der im SSH-Client konfigurierten Schlüsselauthentifizierung:

  1. Der Benutzer stellt eine Verbindung zum Server her und gibt seinen Benutzernamen an.
  2. Der sshd-Daemon ruft über ein Skript den Wert des öffentlichen Schlüssels aus dem Benutzerattribut in Active Directory ab und autorisiert die Schlüssel.
  3. Der sssd-Daemon authentifiziert den Benutzer basierend auf der Gruppenmitgliedschaft weiter. Achtung! Wenn dies nicht konfiguriert ist, hat jeder Domänenbenutzer Zugriff auf den Host.
  4. Wenn sudo es versucht, durchsucht der sssd-Dämon das Active Directory-Verzeichnis nach Rollen. Wenn Rollen vorhanden sind, werden die Attribute und die Benutzermitgliedschaft der Gruppe überprüft (wenn sudoRoles für die Verwendung von Benutzergruppen konfiguriert ist).

Zusammenfassung


Daher werden die Schlüssel in Active Directory-Benutzerattributen und Sudo-Berechtigungen gespeichert. Ebenso wird der Zugriff auf Linux-Hosts über Domänenkonten durch Überprüfen der Mitgliedschaft in der Active Directory-Gruppe ausgeführt.

Die letzte Welle des Zauberstabs des Dirigenten - und die Halle gefriert in entsetzter Stille.

Schriftlich verwendete Ressourcen:

Source: https://habr.com/ru/post/de449702/

More articles:


All Articles