Linux sunucuları için Active Directory kimlik doğrulaması hakkında ortak bilgelik?

2014 yılında, Linux sunucuları ve modern Windows Server işletim sistemleri (CentOS / RHEL-odaklı) için Active Directory kimlik doğrulaması / entegrasyonu hakkındaki ortak bilgelik nedir ?

2004’te ilk entegrasyon girişiminde bulunduğumdan bu yana geçen yıllar boyunca, bunun etrafındaki en iyi uygulamalar değişti. Hangi yöntemin şu anda en fazla ivmeye sahip olduğundan emin değilim.

Alanda gördüm:

Winbind / Samba
Düz-up LDAP
Bazen LDAP + Kerberos
Microsoft Windows Hizmetleri Unix (SFU) için
Unix için Microsoft Kimlik Yönetimi
NSLCD
SSSD
FreeIPA
Centrify
powerbroker ( née Keza )

Winbind her zaman korkunç ve güvenilmez görünüyordu. Centrify ve Likewise gibi ticari çözümler her zaman işe yaradı, ancak bu özellik işletim sistemine dahil edildiğinden gereksiz görünüyordu.

Yaptığım son birkaç kurulumda , Linux tarafında bir Windows 2008 R2 sunucusuna ve NSLCD'ye eklenmiş Unix rolü için Microsoft Kimlik Yönetimi özelliği vardı (RHEL5 için). Bu, NSLCD ve bellek kaynak yönetimi konularında bakım eksikliğinin SSSD'de bir değişiklik yapması gerektiği RHEL6'ya kadar çalıştı. Red Hat ayrıca SSSD yaklaşımını destekliyor gibiydi, bu yüzden benim kullanımıma uygun oldu.

Etki alanı denetleyicilerinin Windows 2008 R2 Çekirdek sistemleri olduğu ve Unix için Kimlik Yönetimi rolü özelliğini ekleyemediğim yeni bir kurulumla çalışıyorum . Ve bu özelliğin kullanımdan kaldırıldığını ve Windows Server 2012 R2’de artık mevcut olmadığını söyledim .

Bu role sahip olmanın faydası, bu GUI'nin varlığıdır, kullanıcı özelliklerinin bir adımda kolayca yönetilmesine izin verir.

Fakat...

Uzak Sunucu Yönetim Araçları'nın (RSAT) Ağ Bilgi Hizmeti Sunucusu (NIS) Araçları seçeneği kullanımdan kaldırılmıştır. Yerel LDAP, Samba İstemcisi, Kerberos veya Microsoft dışı seçenekleri kullanın.

Bu, ileriye dönük uyumlulukları kırabilirse güvenmeyi gerçekten zorlaştırır. Müşteri Winbind'i kullanmak istiyor ancak Red Hat tarafından gördüğüm her şey SSSD'nin kullanımına işaret ediyor.

Doğru yaklaşım nedir?
Nasıl bu hallediyorsunuz sizin çevreye?

Mart 2014'te Red Hat, Red Hat Enterprise Server'ı Active Directory ile entegre etmek için bir referans mimarisi yayınladı . (Bu materyal kesinlikle güncel ve alakalı olmalıdır.) Bunu cevap olarak göndermekten nefret ediyorum, ancak cevap alanına aktarılması gerçekten çok fazla materyal.

Bu belge (düzeltilmiş) basının sıcak olduğu Red Hat Enterprise Linux'un (RHEL) 7'nin yeni özelliklerine odaklandığı görülüyor. Geçen hafta Zirve için yayınlandı.

Bu bağlantı bayatlanırsa, lütfen bana bildirin; yanıtı buna göre güncelleyeceğim.

Kişisel olarak WinBind'i kimlik doğrulama için oldukça güvenilir bir şekilde kullandım. Kök veya başka bir yerel hesaba sahip birinin içeri girip winbindd'i zıplatmasını gerektiren çok az sayıda hizmet hatası var. Çaba göstermeye özen gösterirseniz, bu muhtemelen uygun izleme yoluyla ele alınabilir.

Ayrı konfigürasyon yönetimi tarafından sağlanabilmesine rağmen, Centrify'nin ek bir işlevselliğe sahip olduğuna dikkat etmek önemlidir. (Kukla, vb.)

16/16/14 Düzenle:

Red Hat Enterprise Linux 7 Windows Entegrasyon Kılavuzu

re: "Centrify and Likewise gibi ticari çözümler her zaman işe yaradı, ancak bu özellik işletim sistemine dahil edildiğinden gereksiz görünüyordu."

Bence çoğumuz yıllardır XYZ işletim sisteminin nihayetinde AD entegrasyon bulmacasını çözdüğünü duyuyoruz. IMHO sorun şu ki, işletim sistemi satıcısı için AD entegrasyonu bir onay kutusu özelliğidir, yani sorta'nın bu onay kutusunu almak için işe yarayacak bir şey sunması gerekir ve bu onay kutusu genellikle yalnızca ...

1. onların işletim sistemi platformu ve
2. bu platformun güncel sürümü ve
3. Active Directory'nin daha yeni bir sürümüne karşı.

Gerçek şu ki, çoğu ortam işletim sistemi satıcısı ve işletim sistemi sürümü açısından yekpare değildir ve daha eski AD sürümlerine sahip olacaktır. Bu yüzden Centrify gibi bir satıcının UNIX / Linux / Mac / etc gibi 450'den fazla lezzetini desteklemesi gerekiyor. Windows 2000'den Windows 2012 R2'ye, sadece RHEL 7'ye değil, yine Windows 2012 R2'ye.

Ayrıca, AD’nizin nasıl kullanıldığını da hesaba katmanız gerekir; işletim sistemi sağlayıcısının AD entegrasyonu, Salt Okunur Etki Alanı Denetleyicilerini (RODC’ler), tek yönlü güvenleri destekler, çok orman desteği sağlar. mevcut UID alanı (olacak), UID'leri AD'ye geçirmek için geçiş araçları var. Ayrıca, OS satıcısının AD desteği, UID alanınızın düz olmadığı durumlarda birden fazla UID'yi tek bir AD ile eşleştirme özelliğini ele alıyor mu? Ve ne hakkında ... peki anladın.

O zaman destek meselesi var ...

Mesele şu ki, AD entegrasyonu kavramsal olarak kolay görünebilir ve bir satıcının en son işletim sistemiyle "ücretsiz" olabilir ve muhtemelen bir üreticiden bir işletim sisteminin yalnızca bir sürümüne sahipseniz ve en son sürüm olan bir vanilya AD'sine sahipseniz çalışabilir. OS satıcısıyla ortaya çıkacak herhangi bir sorunu çözmek için elinden gelenin en iyisini yapacak bir prim destek sözleşmesi. Aksi takdirde, uzmanlaşmış bir üçüncü taraf çözümünü düşünebilirsiniz.

Uzak Sunucu Yönetim Araçları'nın (RSAT) Ağ Bilgi Hizmeti Sunucusu (NIS) Araçları seçeneği kullanımdan kaldırılmıştır.

Bu benim için sürpriz değil - NIS Sun'ın bizden nefret ettiğini ve bizi sefil olmamızı istediğinin kanıtı.

Yerel LDAP, Samba İstemcisi, Kerberos veya Microsoft dışı seçenekleri kullanın.

Bu iyi bir tavsiye. "Yerel LDAP kullan (SSL üzerinden, lütfen)" diyeceğim seçenekler dikkate alındığında - bunun için birçok seçenek var, ikisi en çok pam_ldap + nss_ldap (PADL'den) ya da birleşik nss-pam- ldapd (çatal olarak ortaya çıktı ve devam eden gelişme ve gelişmeleri gördü).

RedHat hakkında soru sorduğunuzdan dolayı , RedHat'ın SSSD kullanarak size başka alternatifler sunduğuna dikkat etmek önemlidir .
Çevreniz tamamen RedHat ise (veya sadece çok sayıda RedHat sistemine sahipse), resmi olarak desteklenen "RedHat İşleri Yapma Yolu" na bakarak kesinlikle zaman ayırmaya değer.

RedHat / SSSD ile kendim hakkında deneyimim olmadığından, sadece dokümanlar tarafından gidiyorum, ancak oldukça sağlam ve iyi tasarlanmış görünüyor.

Önerilen yöntemlerden, size bir artı / eksiler listesi vereyim:

Doğruca Kerberos / LDAP

Artıları: Doğru yapılandırıldığında harika çalışır. Nadiren kırılan, esnek, ağ arızası hayatta kalacaktır. AD'de değişiklik yapılmasına gerek yoktur, şema değişikliği yapılmaz, AD'ye Yönetici erişimi gerekmez. Ücretsiz.

Eksileri: Yapılandırması nispeten zor. Birden fazla dosyanın değiştirilmesi gerekiyor. Kimlik doğrulama sunucusu (Kerberos / LDAP) mevcut değilse çalışmaz.

winbind

Artıları: Yapılandırması kolaydır. Temel sudo işlevselliği. Ücretsiz.

Eksileri: Yoğun destekleyin. Esnek değil ağ Bir ağ sorunu varsa, linux makineler, sunucunun yeniden kaydedilmesini gerektiren bir destek görevi gerektiren AD'den çıkarılabilir. AD'nin yönetici hesabına erişim gerekli. AD'de şema değişiklikleri yapmak için toplanmış olabilir.

Centrify / Benzer şekilde vb

Artıları: Yapılandırması nispeten kolaydır.

Eksileri: Sudo işlevselliğini tescilli, daha zor desteklemesi için değiştirir. Sunucu başına lisans maliyeti. Yönetmek için ek becerilere ihtiyacınız var.

SSSD

Artıları: Bir yapılandırma dosyası, yapılandırması kolay. Tüm mevcut ve gelecekteki kimlik doğrulama yöntemleri ile çalışır. Ölçeklenebilir, sistemle birlikte büyür. Bağlantısız modda çalışacak. Ağ esnek. AD şemasında herhangi bir değişiklik yapmanıza gerek yok. AD yönetici kimlik bilgilerine gerek yok. Ücretsiz

Eksileri: DNS'nin otomatik güncellemeleri gibi kazanma hizmetleri yok. CIFS paylaşımlarını yapılandırmanız gerekir.

özet

Avantaj ve dezavantajlara bakıldığında, SSSD en açık kazanandır. Eğer yeni bir sistemse, SSSD'den başka bir şey kullanmak için hiçbir sebep yoktur. Mevcut tüm kimlik doğrulama yöntemleriyle çalışan ve sistemle birlikte büyüyebilen bir entegratördür, çünkü kullanılabilir olduğunda yeni yöntemler eklenebilir. Yerel linux yöntemlerini kullanır ve çok daha güvenilir ve hızlıdır. Önbellekleme açıksa, sistemler tamamen ağ bağlantısı kesilmiş tamamen bağlantısı kesilmiş bir sistemde bile çalışacaktır.

Değişmek için çok fazla iş varsa, Winbind mevcut sistemler için kullanılabilir.

Centrify, entegrasyon ile ilgili masraflı olabilecek problemler yaşadı. Hataların çoğu yeni sürümde düzeltildi, ancak hala baş ağrısına neden olan bazı şeyler var.

Tüm bu yöntemlerle çalıştım ve SSSD en açık kazanan. Eski sistemler için bile, Winbind'den SSSD'ye dönüştürme ROI'si çok yüksektir. SSSD kullanmamak için belirli bir neden yoksa, her zaman SSSD kullanın.

Bu konuda yorum yapmak zorundasınız:

Ayrı konfigürasyon yönetimi tarafından sağlanabilmesine rağmen, Centrify'nin ek bir işlevselliğe sahip olduğuna dikkat etmek önemlidir. (Kukla, vb.)

Centrify ile çalışan biri olarak bu yorumun nereden geldiğinden emin değilim. Bak bu ve size Kukla ala bir yapılandırma mgmt aracıyla alamadım özelliklerin bir gemi dolusu olduğunu görebiliriz. Örneğin, birden fazla UID'nin tek bir AD hesabına eşlenmesi için destek (Bölgeler), tam Active Directory etki alanı güvenlerinin (Red Hat çözümünün 3. sayfada desteklemediğini belgelemesi) desteklenmesi vb.

Ama bu Red Hat rehberine geri dönelim. Red Hat'in bunu yayınlaması harika, seçenekler iyi. Müşteriye, temel AD entegrasyonu için 10 seçenek sunar. Seçeneklerin çoğu Winbind'in varyasyonlarıdır ve sayfa 15'te her birinin avantaj ve dezavantajları listelenmiştir ve her biri için gereken bir dizi manuel adım vardır (ilgili dezavantajları / işlevsellik eksikliği ile). Centrify Express'in avantajı, yukarıdaki diğer yorumculara göre:

1. tüm manuel adımları w / dışarı yüklemek kolaydır ve ...
2. ücretsiz ve ...
3. sadece bir değişken değil Linux ile ilgili olduğu için önemli olan Red Hat V7 ile sınırlı değildir - Centrify 300'den fazla * * nix çeşidini ve ...
4. yalnızca Windows 2008'i değil, tüm Windows AD değişkenlerini de destekler. Burada Centrify ile Winbind arasındaki karşılaştırmayı yayınladılar , ancak açık kaynak değil.

Sonunda, kendin yuvarlamak ya da ticari bir çözüm bulmak istiyorsan, kaynar. Gerçekten senin ve zamanını nasıl harcadığın meselesi.