Jaka jest powszechna opinia na temat uwierzytelniania / integracji Active Directory dla serwerów Linux i nowoczesnych systemów operacyjnych Windows Server (zorientowanych na CentOS / RHEL)?
Przez lata od moich pierwszych prób integracji w 2004 roku wydaje się, że zmieniły się najlepsze praktyki w tym zakresie. Nie jestem pewien, która metoda ma obecnie największy impet.
W terenie widziałem:
Winbind / Samba
Prosto w górę LDAP
Czasami LDAP + Kerberos
Usługi Microsoft Windows dla Unix (SFU)
Zarządzanie tożsamością Microsoft dla Unix
NSLCD
SSSD
FreeIPA
Centrify
Powerbroker (z domu podobnie )
Winbind zawsze wydawał się okropny i zawodny. Rozwiązania komercyjne, takie jak Centrify i Likeewise, zawsze działały, ale wydawały się niepotrzebne, ponieważ ta funkcja jest wbudowana w system operacyjny.
Ostatnie kilka instalacji, które wykonałem, zawierały funkcję roli Microsoft Identity Management for Unix na serwerze Windows 2008 R2 i NSLCD po stronie Linux (dla RHEL5). Działało to do RHEL6, gdzie brak konserwacji NSLCD i problemy z zarządzaniem zasobami pamięci wymusiły zmianę na SSSD. Wydawało się, że Red Hat popiera podejście SSSD, więc nie mam nic przeciwko temu.
Pracuję z nową instalacją, w której kontrolerami domeny są systemy Windows 2008 R2 Core i nie mam możliwości dodania funkcji roli Zarządzanie tożsamością dla systemu Unix. I powiedziano mi, że ta funkcja jest przestarzała, nie jest już dostępna w systemie Windows Server 2012 R2 .
Zaletą zainstalowania tej roli jest obecność tego GUI, a jednocześnie umożliwia łatwe zarządzanie atrybutami użytkownika w jednym kroku.
Ale...
Opcja Server for Network Information Service (NIS) narzędzi Remote Server Administration Tools (RSAT) jest przestarzała. Użyj rodzimych opcji LDAP, Samba Client, Kerberos lub innych firm niż Microsoft.
To sprawia, że naprawdę trudno polegać, jeśli może to złamać kompatybilność. Klient chce korzystać z Winbind, ale wszystko, co widzę od strony Red Hata, wskazuje na użycie SSSD.
Jakie jest właściwe podejście?
Jak sobie z tym poradzić w swoim środowisku?
źródło
Odpowiedzi:
W marcu 2014 r. Red Hat opublikował architekturę referencyjną dotyczącą integracji Red Hat Enterprise Server z Active Directory . (Ten materiał z pewnością powinien być aktualny i odpowiedni.) Nie chcę publikować tego jako odpowiedzi, ale tak naprawdę to po prostu zbyt dużo materiału, aby przenieść go na pole odpowiedzi.
Ten dokument (poprawiony) jest na topie, wydaje się, że prasa koncentruje się na nowych funkcjach Red Hat Enterprise Linux (RHEL) 7. Został opublikowany na szczycie w zeszłym tygodniu.
Jeśli ten link przestanie być aktualny, daj mi znać, a ja odpowiednio zaktualizuję odpowiedź.
Osobiście korzystałem z WinBind dość niezawodnie do uwierzytelniania. Bardzo rzadko zdarza się awaria usługi, która wymaga, aby ktoś z kontem root lub innym kontem lokalnym wszedł i odrzucił winbindd. Prawdopodobnie można to rozwiązać za pomocą odpowiedniego monitorowania, jeśli zechcesz włożyć w to wysiłek.
Warto zauważyć, że Centrify ma dodatkową funkcjonalność, choć może to być zapewnione przez osobne zarządzanie konfiguracją. (Marionetka itp.)
Edytuj 16.06.14:
Red Hat Enterprise Linux 7 Windows Integration Guide
źródło
Myślę, że większość z nas słyszała od lat, że system operacyjny XYZ w końcu łamie łamigłówkę integracji AD. IMHO problem polega na tym, że dla dostawcy systemu operacyjnego integracja AD jest funkcją pola wyboru, tj. Muszą dostarczyć coś, co w pewnym sensie działa, aby uzyskać to pole wyboru, a to pole wyboru zwykle działa tylko na ...
W rzeczywistości większość środowisk nie jest monolityczna pod względem dostawcy i wersji systemu operacyjnego i będzie miała starsze wersje AD. Dlatego dostawca, taki jak Centrify, musi obsługiwać ponad 450 odmian UNIX / Linux / Mac / itp. przeciwko Windows 2000 do Windows 2012 R2, nie tylko RHEL 7 ponownie Windows 2012 R2.
Ponadto należy uwzględnić sposób wdrożenia usługi AD, podobnie jak integracja AD dostawcy systemu operacyjnego z kontrolerami domeny tylko do odczytu (RODC), zaufanie w jedną stronę, obsługa wielu lasów itp. A co, jeśli masz wcześniej istniejąca przestrzeń UID (którą będziesz), czy istnieją narzędzia do migracji do migracji UID do AD. Czy obsługa AD dostawcy systemu operacyjnego rozwiązuje problem odwzorowywania wielu identyfikatorów UID na pojedynczy AD w sytuacjach, w których przestrzeń UID nie jest płaska. A co z ... no cóż, masz pomysł.
Następnie pojawia się pytanie o wsparcie ...
Chodzi o to, że integracja AD może wydawać się łatwa koncepcyjnie i może być „darmowa” z najnowszym systemem operacyjnym dostawcy, i prawdopodobnie może działać, jeśli masz tylko jedną wersję systemu operacyjnego od jednego dostawcy i masz waniliową AD, która jest najnowszą wersją, i masz umowa wsparcia premium z dostawcą systemu operacyjnego, który dołoży wszelkich starań, aby naprawić wszelkie pojawiające się problemy. W przeciwnym razie możesz rozważyć skorzystanie ze specjalistycznego rozwiązania innej firmy.
źródło
Nie jest to dla mnie żadną niespodzianką - NIS jest dowodem, że Sun nas nienawidziła i chciała, abyśmy byli nieszczęśliwi.
To dobra rada. Biorąc pod uwagę opcje, które powiedziałbym „Użyj natywnego LDAP (przez SSL, proszę)” - dostępnych jest wiele opcji, dwie najbardziej znane mi z bycia pam_ldap + nss_ldap (z PADL) lub połączonego nss-pam- ldapd (który powstał jako widelec i był stale rozwijany i ulepszany).
Ponieważ pytasz o RedHat, warto zauważyć, że RedHat zapewnia inne alternatywy przy użyciu SSSD.
Jeśli twoje środowisko jest w całości oparte na RedHat (lub po prostu ma dużą liczbę systemów RedHat), warto zajrzeć do oficjalnie obsługiwanego „RedHat Way of Doing Things”.
Ponieważ sam nie mam doświadczenia z RedHat / SSSD, po prostu przechodzę przez dokumentację, ale wygląda na dość solidną i dobrze zaprojektowaną.
źródło
Spośród sugerowanych metod, pozwól, że dam ci listę zalet / wad:
Prosto w Kerberos / LDAP
Plusy: Działa świetnie, jeśli poprawnie skonfigurowany. Rzadko się psuje, jest odporny, przetrwa usterki sieciowe. Żadnych zmian w AD, żadnych zmian schematu, żadnego dostępu administratora do AD. Wolny.
Minusy: stosunkowo trudny do skonfigurowania. Wiele plików wymaga zmiany. Nie będzie działać, jeśli serwer uwierzytelniania (Kerberos / LDAP) nie jest dostępny.
Winbind
Plusy: łatwy w konfiguracji. Podstawowa funkcjonalność sudo. Wolny.
Minusy: intensywne wsparcie. Nie jest odporny na sieć. Jeśli występuje problem z siecią, maszyny linux mogą zostać usunięte z AD, wymagając ponownej rejestracji serwera, co jest zadaniem wsparcia. Wymagany dostęp do konta administratora AD. Może to spowodować zmiany schematu w AD.
Wirowanie / podobnie itp.
Plusy: stosunkowo łatwa w konfiguracji.
Minusy: Zmienia funkcjonalność sudo na zastrzeżone, trudniejsze do obsługi. Koszt licencji na serwer. Potrzebujesz dodatkowych umiejętności do zarządzania.
SSSD
Plusy: jeden plik konfiguracyjny, łatwy do skonfigurowania. Działa ze wszystkimi obecnymi i przyszłymi metodami uwierzytelniania. Skalowalny, rośnie wraz z systemem. Działa w trybie odłączonym. Odporny na sieci. Nie trzeba wprowadzać żadnych zmian w schemacie AD. Nie potrzeba poświadczeń administratora AD. Bezpłatne, obsługiwane.
Minusy: nie ma usług wygrywających, takich jak automatyczne aktualizacje DNS. Musisz skonfigurować udziały CIFS.
Podsumowanie
Patrząc na zalety i wady, SSSD jest wyraźnym zwycięzcą. Jeśli jest to nowy system, nie ma powodu, aby używać niczego innego niż SSSD. Jest to integrator, który współpracuje ze wszystkimi obecnymi metodami uwierzytelniania i może się rozwijać wraz z systemem, ponieważ nowe metody można dodawać, jeśli są dostępne. Wykorzystuje natywne metody linux i jest znacznie bardziej niezawodny i szybki. Jeśli buforowanie jest włączone, systemy będą działać nawet w całkowicie odłączonych systemach z całkowitą awarią sieci.
Winbind może być użyty do istniejących systemów, jeśli do zmiany wymaga zbyt wiele pracy.
Centrify ma problemy z integracją, które mogą być kosztowne. Większość błędów została naprawiona w nowej wersji, ale wciąż są pewne, które powodują bóle głowy.
Pracowałem z tymi wszystkimi metodami, a SSSD jest wyraźnym zwycięzcą. Nawet w przypadku starszych systemów zwrot z inwestycji w konwersję z Winbind na SSSD jest bardzo wysoki. O ile nie ma konkretnego powodu, aby nie używać SSSD, zawsze używaj SSSD.
źródło
Muszę to skomentować:
Jako osoba współpracująca z Centrify nie jest pewna, skąd pochodzi ten komentarz. Spójrz na to i zobaczysz, że istnieje mnóstwo funkcji, których nie dostaniesz za pomocą narzędzia konfiguracyjnego mgmt ala Puppet. Na przykład obsługa mapowania wielu identyfikatorów UID na pojedyncze konto AD (strefy), obsługa pełnych zaufania domen Active Directory (których dokumentacja rozwiązania Red Hat na stronie 3 nie obsługuje) itd.
Wróćmy jednak do przewodnika Red Hat. To wspaniałe, że Red Hat to publikuje, opcje są dobre. Uwaga: daje klientowi 10 opcji podstawowej integracji AD. Większość opcji to odmiany Winbind, a strona 15 zawiera listę zalet i wad każdego z nich, a dla każdego z nich jest kilka ręcznych kroków (z odpowiednimi wadami / brakiem funkcjonalności powyżej). Zaletą Centrify Express jest to, że według pozostałych komentatorów powyżej:
Na koniec sprowadza się do tego, czy chcesz sam go zwinąć, czy przejść do komercyjnego rozwiązania. Naprawdę to kwestia, w której miejscu spędzasz swój czas.
źródło