Řešení 1:
V březnu 2014 Red Hat zveřejnil referenční architekturu pro integraci Red Hat Enterprise Server s Active Directory. (Tento materiál by měl být určitě aktuální a relevantní.) Nerad to zveřejňuji jako odpověď, ale je to opravdu příliš mnoho materiálu na převedení do pole odpovědí.
Zdá se, že se tento dokument (opravený) v tisku zaměřuje na nové funkce Red Hat Enterprise Linux (RHEL) 7. Byl zveřejněn pro Summit minulý týden.
Pokud by tento odkaz zanikl, dejte mi prosím vědět a já odpovídajícím způsobem aktualizuji odpověď.
Osobně jsem WinBind používal pro autentizaci poměrně spolehlivě. Velmi zřídka dochází k selhání služby, které vyžaduje, aby někdo s rootem nebo jiným místním účtem vstoupil a vrátil winbindd. To by se pravděpodobně dalo vyřešit řádným monitorováním, pokud do toho vložíte úsilí.
Stojí za zmínku, že Centrify má další funkce, i když je lze zajistit samostatnou správou konfigurace. (loutka atd.)
Upravit 16. 6. 2014:
Red Hat Enterprise Linux 7 Průvodce integrací Windows
Řešení 2:
re:"Komerční řešení jako Centrify a Likewise vždy fungovala, ale zdála se zbytečná, protože tato schopnost je zapečena v operačním systému."
Myslím, že většina z nás už léta slýchá, že operační systém XYZ konečně rozlouskl puzzle integrace AD. IMHO je problém v tom, že pro dodavatele OS je integrace AD funkcí zaškrtávacího políčka, tj. musí dodat něco, co tak trochu funguje, aby toto zaškrtávací políčko získalo, a toto zaškrtávací políčko obvykle funguje pouze na...
- jejich platformu OS a
- aktuální verzi této platformy a
- proti novější verzi služby Active Directory.
Realita je taková, že většina prostředí není monolitická z hlediska dodavatele OS a verze OS a bude mít starší verze AD. To je důvod, proč dodavatel, jako je Centrify, musí podporovat 450+ variant UNIX/Linux/Mac/atd. proti Windows 2000 až Windows 2012 R2, nejen RHEL 7 znovu Windows 2012 R2.
Kromě toho musíte vzít v úvahu, jak je vaše AD nasazeno, takže integrace AD dodavatele OS podporuje řadiče domény pouze pro čtení (RODC), jednosměrné důvěryhodnosti, poskytuje podporu pro více doménových struktur atd. A co když máte předběžnou existující prostor UID (což budete chtít), existují nástroje pro migraci pro migraci UID do AD. A řeší podpora AD dodavatele OS možnost mapovat více UID na jeden AD v situacích, kdy váš prostor UID není plochý. A co třeba ... no, máte představu.
Pak je tu otázka podpory ...
Pointou je, že integrace AD se může zdát koncepčně snadná a může být „zdarma“ s nejnovějším OS dodavatele a pravděpodobně může fungovat, pokud máte pouze jednu verzi OS od jednoho dodavatele a máte vanilla AD, která je nejnovější verzí, a máte smlouvu o prémiové podpoře s dodavatelem operačního systému, který se bude snažit vyřešit všechny problémy, které se objeví. Jinak možná budete chtít zvážit specializované řešení třetí strany.
Řešení 3:
Možnost Server for Network Information Service (NIS) Tools nástroje Remote Server Administration Tools (RSAT) je zastaralá.
To mě nepřekvapuje – NIS je důkazem toho, že nás Sun nenáviděl a chtěl, abychom byli nešťastní.
Použijte nativní LDAP, Samba Client, Kerberos nebo možnosti jiných výrobců.
To je dobrá rada. Vzhledem k volbám bych řekl "Použít nativní LDAP (přes SSL, prosím)" - k tomu je k dispozici mnoho možností, dvě, které znám nejvíce, jsou pam_ldap + nss_ldap (z PADL) nebo kombinované nss-pam- ldapd (který vznikl jako fork a zaznamenal neustálý vývoj a vylepšení).
Protože se ptáte konkrétně na RedHat, stojí za zmínku, že RedHat vám poskytuje další alternativy pomocí SSSD.
Pokud je vaše prostředí výhradně RedHat (nebo má jen velký počet systémů RedHat), určitě by stálo za to podívat se na oficiálně podporovaný „RedHat způsob, jak dělat věci“.
Protože sám nemám s RedHat/SSSD žádné zkušenosti, jdu jen podle dokumentů, ale vypadá to, že je docela robustní a dobře navržený.
Řešení 4:
Z navrhovaných metod mi dovolte uvést seznam výhod a nevýhod:
Přímo Kerberos/LDAP
Pro:Při správné konfiguraci funguje skvěle. Zřídka se zlomí, odolný, přežije síťové závady. Žádné změny v AD, žádná změna schématu, žádný administrátorský přístup není potřeba k AD. Zdarma.
Nevýhody:Poměrně obtížné konfigurovat. Je třeba změnit více souborů. Nebude fungovat, pokud ověřovací server (Kerberos/LDAP) není dostupný.
Winbind
Pro:Snadná konfigurace. Základní funkce sudo. Zdarma.
Nevýhody:Intenzivní podpora. Není odolný vůči síti. Pokud dojde k problému se sítí, linuxové stroje mohou vypadnout z AD vyžadující novou registraci serveru, což je úkol podpory. Vyžaduje se přístup k účtu správce AD. Možná bude potřeba provést změny schématu v AD.
Vycentrovat/Podobně atd.
Výhody:Relativně snadná konfigurace.
Nevýhody:Mění funkci sudo na proprietární, obtížnější podporu. Cena licence na server. Ke správě potřebujete další dovednosti.
SSSD
Výhody:Jeden konfigurační soubor, snadno konfigurovatelný. Pracuje se všemi současnými a budoucími metodami ověřování. Škálovatelný, roste se systémem. Bude fungovat v odpojeném režimu. Síťově odolná. Není třeba provádět žádné změny ve schématu AD. Nejsou potřeba přihlašovací údaje správce AD. Zdarma, podporované.
Nevýhody:Nemá win služby, jako jsou automatické aktualizace DNS. Je třeba nakonfigurovat sdílení CIFS.
Shrnutí
Při pohledu na výhody a nevýhody je jasným vítězem SSSD. Pokud se jedná o nový systém, není důvod používat něco jiného než SSSD. Je to integrátor, který pracuje se všemi současnými metodami autentizace a může růst se systémem, protože nové metody mohou být přidány, jakmile budou k dispozici. Využívá nativní linuxové metody a je mnohem spolehlivější a rychlejší. Pokud je zapnuto ukládání do mezipaměti, systémy budou fungovat i ve zcela odpojených systémech s úplným selháním sítě.
Winbind lze použít pro stávající systémy, pokud je s tím spojeno příliš mnoho práce na změnu.
Centrify má problémy s integrací, která by se mohla prodražit. Většina chyb je v nové verzi opravena, ale stále existují některé, které způsobují bolesti hlavy.
Pracoval jsem se všemi těmito metodami a SSSD je jasným vítězem. I u starších systémů je ROI pro převod z Winbind na SSSD velmi vysoká. Pokud neexistuje konkrétní důvod nepoužívat SSSD, vždy používejte SSSD.
Řešení 5:
Musím se k tomu vyjádřit:
Stojí za zmínku, že Centrify má další funkce, i když je lze zajistit samostatnou správou konfigurace. (loutka atd.)
Jako někdo, kdo pracuje s Centrify, si není jistý, odkud tento komentář pochází. Podívejte se na to a můžete vidět, že existuje spousta funkcí, které nezískáte s konfiguračním nástrojem mgmt ala Puppet. Například podpora mapování více UID na jeden AD účet (zóny), podpora úplných důvěryhodných domén Active Directory (což řešení Red Hat na straně 3 dokumentuje, že nepodporuje) atd.
Ale zpět k této příručce Red Hat. Je skvělé, že to Red Hat vydává, možnosti jsou dobré. Všimněte si, že poskytuje zákazníkovi 10 možností, jak provést základní integraci AD. Většina možností jsou varianty Winbindu a na straně 15 jsou uvedeny výhody a nevýhody každé z nich a pro každou je vyžadována spousta ručních kroků (s odpovídajícími nevýhodami / nedostatkem funkcí podle výše uvedeného). Výhodou Centrify Express je, že podle ostatních výše uvedených komentátorů je:
- je jednoduchá instalace bez všech manuálních kroků a...
- je zdarma a...
- není omezeno na Red Hat V7, což je důležité, protože otázka se týkala Linuxu, nikoli pouze jedné varianty – Centrify podporuje více než 300 variant *nix a...
- podporuje všechny varianty Windows AD, nejen Windows 2008. Zveřejnili zde srovnání Centrify vs. Winbind, ale není to open source.
Na konci se to scvrkává na to, zda si to chcete převálcovat sami, nebo jít s komerčním řešením. Opravdu záleží na tom, kde a jak trávíte čas.