AD'ye karşı bir Linux sunucusunun kimliğini doğrulamak ne kadar pratiktir?


18

Yazılım geliştirme şirketimizde hem Windows hem de Linux sunucusunu kullanıyoruz.

Bu kurulumdaki sürtünme noktalarından biri, tek bir oturum açma çözümümüzün olmamasıdır. AD'ye karşı kimlik doğrulaması yapmak istediğimiz bir Linux mağazasından daha çok Microsoft mağazası olmak.

Çevrimiçi olarak birkaç makale okudum ve bunun mümkün olduğunu anlıyorum.

Şu anda Linux'ta kimlik doğrulaması gerektiren aşağıdaki hizmetleri kullanıyoruz:
- git server (SSH aracılığıyla)
- Sendmail
- Şu anda .htaccess dosyalarını kullanan Apache web sunucusu.
- SAMBA dosya paylaşımları

Bilmek istediğim bu tür bir kurulum ne kadar pratik? Gerçekten işe yarıyor mu veya hataya açık mı?


Herkese harika yanıtlar için teşekkürler, bu bana bu düzenin gerçek dünyada yaşadığı deneyimin ne olduğu hakkında daha iyi bir his veriyor. Bu gerçekten yardımcı oluyor. Hepsi doğru soruyu cevapladığı için burada doğru cevabı seçmek zordur.
Philip Fourie

FreeIPA'yı kontrol edin :) freeipa.org
GioMac

Yanıtlar:


11

Zor değil ve son derece pratik.

AD istemcisini kullanan birkaç yüz çift önyükleme masaüstü makinemiz ve Windows istemcilerinin kullanıcılar tarafından açıkça yetkilendirilmeden samba paylaşımlarını kullanmalarını sağlamak için AD yetkilendirmesini kullanan bir dizi sunucumuz var.

SF'de yapmanız gerekenler hakkında başka bir makale daha vardı.

Temel olarak kerberos, winbind, nss ve pam yapılandırmanız gerekir.

Sonra bir kinitve bir net ads joinve yukarı.

İsterseniz pam'ı kimlik doğrulaması için birden çok yöntem kullanacak şekilde yapılandırabilirsiniz, böylece bir işe yaramazsa bir sonrakine geri döner.

Windows sunucularına dosya paylaşımı yapan sunucular için genellikle dosya, winbindd ve ldap kullanırız.

Mümkünse hesap bilgileri için LDAP ve kesinlikle kimlik doğrulaması için rüzgar bağlama kullanırdım, ancak gerekirse /etc/ldap.conf'daki özellikleri eşleştirebileceğinizi düşünüyorum. Hesap bilgileri için winbindd kullanmanız durumunda, uids / gids oluşturmak için RID (karma yöntemi) kullanmak mümkündür, ancak diğer yöntemleri de kullanmak mümkündür. RID'leri büyük bir dosya sunucusunda kullandık ve gerçek bir acı oldu, bu yüzden mümkünse diğer seçeneklerden birini keşfetmeye çalıştım. Bizim durumumuzda, tüm AD kullanıcıları ve grupları bir yukarı akış IDM sistemi tarafından LDAP'ye yansıtılır, bu nedenle yeni sunuculardaki hesap bilgileri için LDAP'yi kullanır ve yalnızca kimlik doğrulama için winbind'i kullanırız.


6

Benzer şekilde Open'ı kullanarak kimlik doğrulaması kesinlikle basittir. http://www.likewise.com/products/likewise_open/index.php

Neredeyse tüm Linux altyapım, Benzer Açık sayesinde kimlik doğrulama ve kullanıcı yönetimini merkezileştirdi. Kurulumu ve uygulaması şaşırtıcı derecede basittir. Bu konuda yeterince iyi diyemeyeceğim.

Not olarak, UID'ler ve GID'ler bir karma işlevine göre atanır, bu nedenle tüm altyapı genelinde aynıdır, bu nedenle NFS bağlantıları mükemmel çalışır.


1
Aynı şekilde birkaç sunucuda açık olarak kullanıyorum ve iyi çalıştığını gördüm. Apache / Sendmail dışarıdan bakan bir makine ise, ek gecikme / yük olup olmadığını kontrol etmek isteyebilirsiniz.
Kyle Brandt

3
Bağlantı şimdi kesildi
gogaz

Görünüşe göre (web sitesi içeriğine göre) şirket artık bu ürünü yapmıyor.
Alexei Martianov

4

Unix için Windows Services'i yükledim ve AD'ye "Unix Authenticator" adlı bir kullanıcı ekledim, sonra linux makinelerinde aşağıdaki yapılandırma dosyası değişikliklerini yaptım:

/etc/ldap.conf:
host ldap.<foo>.com
base cn=Users,dc=<foo>,dc=com
binddn cn=Unix Authenticator,cn=Users,dc=<foo>,dc=com
bindpw <password>
nss_base_passwd cn=Users,dc=<foo>,dc=com?sub
nss_base_shadow cn=Users,dc=<foo>,dc=com?sub
nss_base_group cn=Users,dc=<foo>,dc=com?sub
nss_map_objectclass posixAccount User
nss_map_objectclass shadowAccount User
nss_map_objectclass posixGroup Group
nss_map_attribute cn msSFUName
nss_map_attribute uid msSFUName
nss_map_attribute gid gidNumber
nss_map_attribute gecos sAMAccountName
nss_map_attribute homeDirectory msSFUHomeDirectory
nss_map_attribute uniqueMember Member
pam_login_attribute msSFUName
pam_filter objectclass=user
pam_password ad
/etc/ldap.secret:
<password>
/etc/nsswitch.conf:
passwd: compat ldap
shadow: compat ldap
group: compat ldap
/etc/nsswitch.ldap:
host files dns
/etc/pam.d/system-auth:
auth required /lib/security/pam_env.so
auth sufficient /lib/security/pam_unix.so likeauth nullok
auth sufficient /lib/security/pam_ldap.so use_first_pass
auth required /lib/security/pam_deny.so

account sufficient /lib/security/pam_ldap.so
account required /lib/security/pam_unix.so

password required /lib/security/pam_cracklib.so retry=3
password sufficient /lib/security/pam_unix.so nullok md5 shadow use_authtok
password sufficient /lib/security/pam_ldap.so use_first_pass use_authtok
password required /lib/security/pam_deny.so

session required /lib/security/pam_limits.so
session required /lib/security/pam_unix.so

Bu yardımcı olur umarım.


Bu ilginç bir yaklaşım, teşekkürler bu caddeyi de keşfedeceğim.
Philip Fourie

1
Lütfen yetkilendirme için pam_ldap (/etc/pam.d/system-auth içinde) kullanmayın. Parolanızı açık metin olarak gönderir. LDAP ile kimlik doğrulaması yapmak istiyorsanız LDAPS veya GSSAPI kullanıyor olmalısınız. Güvenli bir şekilde yapmak istiyorsanız, kimlik doğrulama için NSS için LDAP ve Kerberos kullanabilirsiniz (aşağıya bakın)
TheFiddlerWins

2

AD'ye karşı Windows kullanıcıları yetkilendirdi, ancak sunucularımızın çoğu (genel sürücü vb.) Linux ve alan adının bir parçası. Bir Windows PoV kimse bildirimleri. Benim açımdan, windows kullanıcı adımla biraz meyveli hissediyor ama bunun boyutu hakkında.

Sadece düz eski samba kullanıyorum.


2

Samba kullanmanıza gerek yoktur, AD doğrudan Kerberos ve LDAP'yi destekler. Çoğu dağıtımda herhangi bir harici yazılım kullanmanız için hiçbir neden yoktur.

Debian / Ubuntu için bunu libnss-ldap ve libpam-krb5 ile yapabilirsiniz. % 100 almak için birkaç püf noktası var. Bu, Linux kullanıcıları için "unixHomeDirectory" kullandığınızı, Linux kutularınızın Windows sistemlerinizde ortak olan NTP kullandığını (Kerberos için gereklidir) ve düz metin NSS aramalarıyla (şifre değil, grup üyeliği bilgileri vb.) Tamam olduğunuzu varsayar - ayrıca TLS kullanın ancak kurulumu daha karmaşıktır). TLS kullanacak şekilde ayarlanmadıysanız pam_ldap'ı PAM'de şifre veya kimlik doğrulama kaynağı olarak KULLANMAMALISINIZ.

/etc/ldap.conf

# LDAP Configuration for libnss-ldap and libpam-ldap.
# Permit host to continue boot process with out contacting LDAP server
bind_policy soft
# Define LDAP servers to use for queries, these must be Global Catalog servers
uri ldap://ldap.site.company.local
# Define root search location for queries
base dc=company,dc=local
#debug 1
# LDAP version, almost always going to be v3, it is quite mature
ldap_version 3
# Username used to proxy authentication. You can have this in a separate file owned by root for security OR use TLS/SSL (see man page)
# Do NOT use LDAP for authentication if you are using plain text binds, use Kerberos instead (and LDAP for authorization only). See libpam-krb5.
binddn cn=ldap-auth-svc,ou=ldap,ou=services,dc=site,dc=company,dc=local
# Password for proxy acct
bindpw SooperSekeretPazzwerd
#  TCP port to perform queries on, 3268 is a Global Catalog port which will reply for all users in *.company.local
port 3268
# Search range scope (sub = all)
scope sub
# Tell the client to close TCP connctions after 30 seconds, Windows will do this on the server side anyways, this will prevent errors from showing up in the logs.
 idle_timelimit 30
# Expect queries for group membership to return DN for group members instead of usernames (lets you use MSAD group membership seamlessly)
nss_schema rfc2307bis
# Filters - User accounts must have a UID >= 2000 to be recognized in this configuration and must have a unixHomeDirectory defined.
nss_base_group dc=company,dc=local?sub?&(objectClass=group)(gidNumber=*)
nss_base_user dc=company,dc=local?sub?&(objectClass=user)(!(objectClass=localputer))(uidNumber>=2000)(unixHomeDirectory=*)
nss_base_shadow dc=company,dc=local?sub?&(objectClass=user)(!(objectClass=localputer))(uidNumber>=2000)(unixHomeDirectory=*)
# Object Class mappings.  You may want to have the posixAccount to map to "mail" and have users login with their email addresses, i.e.  "nss_map_objectclass posixAccount mail".
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_objectclass posixGroup group
# Attribute mappings.
nss_map_attribute uniqueMember member
nss_map_attribute uid sAMAccountName
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute shadowLastChange pwdLastSet
# Attribute in LDAP to query to match the username used by PAM for authentication
pam_login_attribute sAMAccountName
# Filter for objects which are allowed to login via PAM
pam_filter objectclass=User

Linux kutularınızın AD hakkında bilgi sahibi DNS sunucuları kullandığını varsayarak /etc/krb5.conf dosyasını düzenlemenize gerek yoktur (uygun SRV kayıtlarına sahip _msdcs bölgeleri çözümlenebilir)

/etc/nsswitch.conf, kullanıcılar, gruplar, gölge için "dosyalar ldap" olmalıdır.

SSSD kullanan Red Hat için:

/etc/sssd/sssd.conf

[domain/AD]
id_provider = ldap
auth_provider = krb5
chpass_provider = krb5
access_provider = ldap

ldap_uri = ldap://ldap.company.local:3268/
ldap_search_base = dc=company,dc=com
ldap_default_bind_dn = cn=ldap-auth-svc,ou=ldap,ou=services,dc=site,dc=company,dc=local
ldap_default_authtok = SooperSekeretPazzwerd
ldap_schema = rfc2307bis
ldap_user_object_class = user
ldap_group_object_class = group
ldap_user_name = sAMAccountName
ldap_user_home_directory = unixHomeDirectory
enumerate = true
ldap_tls_reqcert = never
ldap_tls_cacertdir = /etc/openldap/cacerts

ldap_id_use_start_tls = False
cache_credentials = True
krb5_realm = SITE.COMPANY.COM
case_sensitive = false
[sssd]
services = nss, pam
config_file_version = 2

domains = AD
[nss]
filter_users = root,named,avahi,nscd

Bu senaryoda AD tarafında bir şey değiştirmeniz gerekiyor mu? SAMBA kullanırken bazı "Windows için Unix araçlarının" yüklenmesi gerektiğini hatırlıyor musunuz?
Martin Nielsen

Bu çözüm SAMBA'ya bağlı değildir, yerel LDAP / Kerberos kullanıyor. Unix araçlarını kullanmanın tek nedeni, POSIX kullanıcı / grup özniteliklerini düzenlemek için bir GUI elde etmektir. SSSD kullanıyorsanız bile bu gerekli değildir. SAMBA (Winbind'de), sistemin bir Windows istemcisini taklit etmesini sağlayan bir yazılım yüklemenizi sağlar. Yukarıdaki kurulum sadece standart LDAP / Kerberos kullanıyor.
TheFiddlerWins

Lanet olsun, "ldap / kerberos" yazmak istedim, ne olduğunu bilmiyorum. Benim hatam. Ancak AD için Unix araçları LDAP / Kerberos için gerekli değildir?
Martin Nielsen
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.