☰

Streben nach echter Active Directory-Integration

tag-icon • tag-icon linux active-directory sssd likewise-open
Streben nach echter Active Directory-Integration

Bevor Sie mich auslachen und sagen: „Wenn Sie Active Directory möchten, verwenden Sie Windows“ oder mir sagen, ich solle Google verwenden, hören Sie mich an.

Mein Unternehmen verlässt sich sehr stark auf AD. Wir sind mittlerweile fest damit verbunden und als Fortune-10-Unternehmen wird sich das auch nicht ändern. Allerdings haben wir in unserer Umgebung viele *nix-Systeme (hauptsächlich RHEL und SLES) und ich habe noch keinen guten Mechanismus für die Integration mit Active Directory als Identitätsquelle gefunden. Zumindest brauche ich etwas, das Folgendes bietet:

  1. Authentifizierung über AD-Anmeldeinformationen (Benutzer hereinlassen)
  2. Autorisierung nach Authentifizierung (Gewährung des Zugriffs eines Benutzers auf Bereiche des Systems)
  3. Audit (Benutzeraktionen mit ihren AD-Anmeldeinformationen verknüpfen können)
  4. Unterstützung für AD-Gruppen (nicht nur Standard-LDAP und die Notwendigkeit, einzelne Benutzer auf Systemen hinzuzufügen/zu entfernen)
  5. Keine doppelte/gespiegelte Identitätsquelle basierend auf einem Vertrauen von AD (ich brauche keine zwei riesigen Systeme)

Die besten Lösungen, die ich gefunden habe, sind die folgenden:

  1. Zentrifizieren
  2. PowerBroker Open (PBIS Open, früher Likewise-Open)
  3. SSSD+SELinux

Centrify ... ist einfach hässlich. Ich war noch nie ein richtiger Fan. Außerdem können wir für die Anforderungen meines Unternehmens Centrify-Express nicht verwenden, es ist also nicht kostenlos und es gibt keine unbegrenzte Lizenz. Es ist jedoch die beste Lösung, die wir gefunden haben, und ich bin verzweifelt auf der Suche nach etwas anderem.

Ich tendiere zu PBIS Open. Das ist das, was VMware im Backend von vShield verwendet, und es funktioniert ziemlich gut. Es erfordert nur wenige Befehle zur Einrichtung, es unterstützt AD-Gruppen und es gibt kein sekundäres Identitätsverwaltungssystem – es kommuniziert direkt mit AD. Der einzige Grund, warum ich diesen Weg nicht gehe, ist, dass ich native Lösungen mag, und wenn es eine bessere Möglichkeit gibt, die bereits in modernen Distributionen enthalten ist, bin ich voll dafür.

SSSD+SELinux klang großartig. Es ist zwar mühsam einzurichten, aber es ist flexibel, nativ und wird von den meisten modernen Distributionen unterstützt. Das einzige, was fehlt (soweit ich weiß), ist die Unterstützung für AD-Gruppen. Viele Artikel schlagen vor, FreeIPA oder etwas Ähnliches zu nutzen, um diese Funktionalität hinzuzufügen, aber bei genauerem Lesen verstößt dies gegen Anforderung 5 und erstellt im Grunde einen Identitätsdienst als Mittelsmann. Ich bin nicht daran interessiert, AD grundsätzlich zu duplizieren oder Vertrauen zu einem sekundären Identitätsdienst aufzubauen.

Andere Behelfsoptionen, die ich in Erwägung gezogen habe, umfassen die Verwendung von Puppet (das wir verwenden), um /etc/password,shadow,group-Dateien an Endpunkte zu übertragen, aber das erfordert Entwicklung, ist unglaublich indirekt und ich könnte mir vorstellen, dass etwas schiefgeht. Eine bessere Option wäre, SSSD+SELinux zur Puppet-Idee hinzuzufügen. Das würde das Desaster zwar vereinfachen, ist aber immer noch ein Desaster.

Was übersehe ich, was verwenden Sie und was ist der „heiße neue Knüller“, den ich zur Lösung des Problems mit der Linux AD-Integration nicht berücksichtigt habe?

Antwort1

Ihre Lösungen sind hier entweder FreeIPA oder Centrify/PowerBroker. FreeIPA ist Teil Ihres Standard-RHEL-Abonnements, sodass bereits einige Einsparungen erzielt werden.

FreeIPA kann in einem Modus ausgeführt werden, in dem alle Benutzer und Gruppen aus Active Directory stammen können. Sie würden nur die Zuordnung dieser Benutzer und Gruppen zu POSIX-spezifischen Umgebungen in FreeIPA beibehalten, wie etwa SUDO-Regeln, öffentliche SSH-Schlüssel, hostbasierte Zugriffskontrolldefinitionen, SE Linux-Kontextzuweisungen und so weiter. Dazu müssten Sie einige Ihrer AD-Benutzer/-Gruppen einigen Gruppen in FreeIPA zuordnen, aber das ist keine Duplizierung der Informationen, sondern eine Ergänzung um die Teile, die nicht AD-spezifisch sind.

FreeIPA implementiert die Kompatibilität mit Active Directory, indem es sich als eine Art Active Directory-kompatible Gesamtstruktur präsentiert. Dies reicht aus, um AD-Benutzern die Nutzung von FreeIPA-Ressourcen über Cross-Forest-Vertrauen zu ermöglichen, reicht jedoch nicht aus, um FreeIPA-Benutzern den Zugriff auf Windows-Systeme auf der anderen Seite der Vertrauensstellung zu ermöglichen. Sie scheinen sich für den ersten Teil zu interessieren, daher sollte dies kein Problem sein.

Mit FreeIPA 4.1, das bereits Teil der Betaversion von RHEL 7.1 ist (RHEL 7.1 erscheint hoffentlich „bald“), verfügen wir über einen leistungsstarken Mechanismus, um die Overrides für AD-Benutzer und -Gruppen in FreeIPA beizubehalten, und SSSD ist in der Lage, sie alle auf Serverebene zu erkennen.

Antwort2

Ich würde wirklich gerne hören, was Sie mit „echten AD-Gruppen“ meinen, wenn Sie über SSSD sprechen. Die neueren Versionen von SSSD erfordern keine POSIX-Attribute für die Gruppen und lesen die Gruppenmitgliedschaften meist aus TokenGroups, wenn der AD-Anbieter verwendet wird.

Darüber hinaus erhielt der SSSD in RHEL-7.1 (Upstream 1.12+) die Möglichkeit, Zugriffskontrollprüfungen mithilfe von GPO-Richtlinien durchzuführen.

Wenn Sie eine spezielle Frage haben, können Sie gerne in die SSDSD-Benutzerliste schreiben.

Antwort3

Das Redhat-Angebot wird hier gut abgedeckt:
Allgemeines zur Active Directory-Authentifizierung für Linux-Server?

In meinen letzten Installationen wurde dies über SSSD (integriert) und LDAP- oder sssd.conf-Gruppenfilter erledigt.

Was genau müssen Ihre Linux-BenutzerTunauf den Systemen?

Antwort4

was ist mit Winbind + Samba + Kerberos?

  • Authentifizierung über AD-Anmeldeinformationen (Benutzer hereinlassen)

geprüft

  • Autorisierung nach Authentifizierung (Gewährung des Zugriffs eines Benutzers auf Bereiche des Systems)

geprüft

  • Audit (Benutzeraktionen mit ihren AD-Anmeldeinformationen verknüpfen können)

/var/log/secure? aktiviert

  • Unterstützung für AD-Gruppen (nicht nur Standard-LDAP und die Notwendigkeit, einzelne Benutzer auf Systemen hinzuzufügen/zu entfernen)

es erlaubt sowohl Anzeigengruppen als auch Anzeigenbenutzer in lokalen Gruppen, aktiviert

  • Keine doppelte/gespiegelte Identitätsquelle basierend auf einem Vertrauen von AD (ich brauche keine zwei riesigen Systeme)

Freeipa ist nicht erforderlich, geprüft

verwandte Informationen