Lösung 1:
Im März 2014 veröffentlichte Red Hat eine Referenzarchitektur für die Integration von Red Hat Enterprise Server mit Active Directory. (Dieses Material sollte sicherlich aktuell und relevant sein.) Ich hasse es, dies als Antwort zu posten, aber es ist wirklich einfach zu viel Material, um es in das Antwortfeld zu übertragen.
Dieses Dokument (korrigiert) ist frisch aus der Druckerei und scheint sich auf die neuen Funktionen von Red Hat Enterprise Linux (RHEL) 7 zu konzentrieren. Es wurde letzte Woche für den Summit veröffentlicht.
Sollte dieser Link veraltet sein, lassen Sie es mich bitte wissen und ich werde die Antwort entsprechend aktualisieren.
Ich persönlich habe WinBind ziemlich zuverlässig zur Authentifizierung verwendet. Es gibt sehr seltene Dienstausfälle, bei denen jemand mit root oder einem anderen lokalen Konto hineingehen und winbindd zurückschicken muss. Dies könnte wahrscheinlich durch eine angemessene Überwachung behoben werden, wenn Sie sich die Mühe machen.
Es ist erwähnenswert, dass Centrify über zusätzliche Funktionen verfügt, die jedoch durch ein separates Konfigurationsmanagement bereitgestellt werden können. (Marionette usw.)
Bearbeiten 16.06.14:
Red Hat Enterprise Linux 7 Windows-Integrationsleitfaden
Lösung 2:
Betreff:"Die kommerziellen Lösungen wie Centrify und Equal funktionierten immer, schienen aber unnötig, da diese Funktion in das Betriebssystem integriert ist."
Nun, ich denke, die meisten von uns hören seit Jahren, dass das XYZ-Betriebssystem endlich das Rätsel der AD-Integration knackt. Meiner Meinung nach besteht das Problem darin, dass die AD-Integration für den Betriebssystemanbieter eine Kontrollkästchenfunktion ist, d. h. sie müssen etwas liefern, das irgendwie funktioniert, um dieses Kontrollkästchen zu erhalten, und dieses Kontrollkästchen funktioniert normalerweise nur auf ...
- ihre Betriebssystemplattform und
- die aktuelle Version dieser Plattform und
- gegen eine neuere Version von Active Directory.
Die Realität ist, dass die meisten Umgebungen in Bezug auf Betriebssystemanbieter und Betriebssystemversion nicht monolithisch sind und ältere Versionen von AD haben. Aus diesem Grund muss ein Anbieter wie Centrify mehr als 450 Varianten von UNIX/Linux/Mac/usw. unterstützen. gegen Windows 2000 bis Windows 2012 R2, nicht nur RHEL 7 wieder Windows 2012 R2.
Darüber hinaus müssen Sie berücksichtigen, wie Ihr AD bereitgestellt wird, ebenso unterstützt die AD-Integration des Betriebssystemanbieters Read Only Domain Controllers (RODCs), One-Way-Trusts, bietet Multi-Forest-Unterstützung usw. Und was ist, wenn Sie Vor- vorhandener UID-Raum (was Sie wollen), gibt es Migrationstools, um die UIDs in AD zu migrieren. Und befasst sich die AD-Unterstützung des Betriebssystemanbieters mit der Möglichkeit, mehrere UIDs einem einzelnen AD in Situationen zuzuordnen, in denen Ihr UID-Bereich nicht flach ist? Und was ist mit ... nun, Sie wissen schon.
Dann ist da noch die Frage des Supports ...
Point is AD-Integration mag konzeptionell einfach erscheinen und kann mit dem neuesten Betriebssystem eines Anbieters „kostenlos“ sein und kann wahrscheinlich funktionieren, wenn Sie nur eine Version eines Betriebssystems von einem Anbieter und ein Vanilla-AD haben, das die neueste Version ist, und Sie haben einen Premium-Supportvertrag mit dem Betriebssystemanbieter, der sein Bestes geben wird, um auftretende Probleme zu beheben. Andernfalls sollten Sie möglicherweise eine spezialisierte Lösung eines Drittanbieters in Betracht ziehen.
Lösung 3:
Die Option Server for Network Information Service (NIS) Tools der Remote Server Administration Tools (RSAT) ist veraltet.
Das kommt für mich nicht überraschend – NIS ist ein Beweis dafür, dass Sun uns hasste und wollte, dass wir unglücklich sind.
Verwenden Sie native LDAP-, Samba-Client-, Kerberos- oder Nicht-Microsoft-Optionen.
Das ist ein guter Rat. Angesichts der Auswahlmöglichkeiten würde ich sagen "Natives LDAP verwenden (bitte über SSL)" - dafür stehen viele Optionen zur Verfügung, die beiden, mit denen ich am besten vertraut bin, sind pam_ldap + nss_ldap (von PADL) oder das kombinierte nss-pam- ldapd (das als Fork entstand und laufend weiterentwickelt und verbessert wurde).
Da Sie speziell nach RedHat fragen, ist es erwähnenswert, dass RedHat Ihnen andere Alternativen mit SSSD bietet.
Wenn Ihre Umgebung ausschließlich aus RedHat besteht (oder nur über eine große Anzahl von RedHat-Systemen verfügt), wäre es sicherlich Ihre Zeit wert, sich mit dem offiziell unterstützten „RedHat Way of Doing Things“ zu befassen.
Da ich selbst keine Erfahrung mit RedHat/SSSD habe, gehe ich nur von der Dokumentation aus, aber es scheint ziemlich robust und gut gestaltet zu sein.
Lösung 4:
Von den vorgeschlagenen Methoden möchte ich Ihnen eine Pro/Contra-Liste geben:
Einfaches Kerberos/LDAP
Vorteile:Funktioniert hervorragend, wenn es richtig konfiguriert ist. Seltene Unterbrechungen, widerstandsfähig, überstehen Netzwerkstörungen. Keine Änderungen in AD erforderlich, keine Schemaänderung, kein Administratorzugriff auf das AD erforderlich. Kostenlos.
Nachteile:Relativ schwierig zu konfigurieren. Mehrere Dateien müssen geändert werden. Funktioniert nicht, wenn der Authentifizierungsserver (Kerberos/LDAP) nicht verfügbar ist.
Winbind
Vorteile:Einfach zu konfigurieren. Grundlegende Sudo-Funktionalität. Kostenlos.
Nachteile:Support intensiv. Nicht netzwerkfähig. Wenn es ein Netzwerkproblem gibt, könnten Linux-Rechner aus dem AD fallen gelassen werden, was eine Neuregistrierung des Servers erforderlich macht, eine Support-Aufgabe. Zugriff auf das Administratorkonto von AD erforderlich. Möglicherweise müssen Schemaänderungen in AD vorgenommen werden.
Zentrieren/Ebenfalls etc.
Vorteile:Relativ einfach zu konfigurieren.
Nachteile:Ändert die sudo-Funktionalität zu proprietär, schwieriger zu unterstützen. Lizenzkosten pro Server. Für die Verwaltung sind zusätzliche Fähigkeiten erforderlich.
SSSD
Vorteile:Eine Konfigurationsdatei, einfach zu konfigurieren. Funktioniert mit allen gegenwärtigen und zukünftigen Authentifizierungsmethoden. Skalierbar, wächst mit dem System. Funktioniert im getrennten Modus. Netzwerk belastbar. Es müssen keine Änderungen am AD-Schema vorgenommen werden. Keine Anmeldeinformationen für den AD-Administrator erforderlich. Kostenlos, unterstützt.
Nachteile:Hat keine Win-Services wie automatische DNS-Updates. CIFS-Freigaben müssen konfiguriert werden.
Zusammenfassung
Betrachtet man die Vor- und Nachteile, ist SSSD der klare Sieger. Wenn es sich um ein neues System handelt, gibt es keinen Grund, etwas anderes als SSSD zu verwenden. Es ist ein Integrator, der mit allen vorhandenen Authentifizierungsmethoden funktioniert und mit dem System wachsen kann, da neue Methoden hinzugefügt werden können, wenn sie verfügbar sind. Es verwendet native Linux-Methoden und ist viel zuverlässiger und schneller. Wenn Caching aktiviert ist, funktionieren die Systeme auch in vollständig getrennten Systemen mit vollständigem Netzwerkausfall.
Winbind kann für bestehende Systeme verwendet werden, wenn eine Änderung zu aufwendig ist.
Centrify hatte Probleme mit der Integration, die kostspielig werden könnten. Die meisten Fehler wurden in der neuen Version behoben, aber es gibt immer noch einige, die Kopfschmerzen bereiten.
Ich habe mit all diesen Methoden gearbeitet und SSSD ist der klare Gewinner. Auch bei älteren Systemen ist der ROI für die Umstellung von Winbind auf SSSD sehr hoch. Verwenden Sie immer SSSD, es sei denn, es gibt einen bestimmten Grund, SSSD nicht zu verwenden.
Lösung 5:
Muss dazu kommentieren:
Es ist erwähnenswert, dass Centrify über zusätzliche Funktionen verfügt, die jedoch durch ein separates Konfigurationsmanagement bereitgestellt werden können. (Marionette usw.)
Als jemand, der mit Centrify arbeitet, bin ich mir nicht sicher, woher dieser Kommentar stammt. Schauen Sie sich das an und Sie können sehen, dass es eine Bootsladung von Funktionen gibt, die Sie mit einem Konfigurations-Management-Tool ala Puppet nicht erhalten. Zum Beispiel Unterstützung für die Zuordnung mehrerer UIDs zu einem einzelnen AD-Konto (Zonen), Unterstützung für vollständige Active Directory-Domänenvertrauensstellungen (die die Red Hat-Lösung auf Seite 3 dokumentiert, dass sie nicht unterstützt wird) usw.
Aber zurück zu diesem Red Hat-Leitfaden. Es ist großartig, dass Red Hat dies veröffentlicht, die Optionen sind gut. Beachten Sie, dass der Kunde 10 Optionen für die grundlegende AD-Integration erhält. Die meisten Optionen sind Variationen von Winbind, und Seite 15 listet die Vor- und Nachteile von jeder auf, und für jede sind eine Reihe manueller Schritte erforderlich (mit entsprechenden Nachteilen / fehlender Funktionalität wie oben). Der Vorteil von Centrify Express ist, dass laut den anderen Kommentatoren oben:
- Es ist einfach zu installieren ohne alle manuellen Schritte und...
- ist kostenlos und...
- ist nicht auf Red Hat V7 beschränkt, was wichtig ist, da die Frage mit Linux zu tun hat, nicht nur eine Variante -- Centrify unterstützt über 300 Varianten von *nix und...
- unterstützt alle Varianten von Windows AD, nicht nur Windows 2008. Sie haben hier einen Vergleich von Centrify vs. Winbind veröffentlicht, aber es ist nicht Open Source.
Am Ende läuft es darauf hinaus, ob Sie es selbst rollen oder sich für eine kommerzielle Lösung entscheiden möchten. Wirklich eine Frage, wo Sie und wie Sie Ihre Zeit verbringen.