Azure NetApp Files ile LDAP kullanımını anlama

Makale
06/13/2024

Basit dizin erişim protokolü (LDAP), İnternet Mühendisliği Görev Gücü (IETF) adlı uluslararası bir komite tarafından geliştirilen standart bir dizin erişim protokolüdür. LDAP, ağ nesnelerini bulmak için heterojen platformlarda kullanabileceğiniz genel amaçlı, ağ tabanlı bir dizin hizmeti sağlamaya yöneliktir.

LDAP modelleri LDAP dizin deposuyla nasıl iletişim kurılacağını, dizinde bir nesnenin nasıl bulunduğunu, depodaki nesnelerin nasıl tanımlandığını ve dizine erişmek için kullanılan güvenliği tanımlar. LDAP, depoda açıklanan nesnelerin özelleştirilmesine ve genişletilmesini sağlar. Bu nedenle, çok çeşitli bilgi türlerini depolamak için LDAP deposu kullanabilirsiniz. İlk LDAP dağıtımlarının çoğu, e-posta ve web uygulamaları gibi uygulamalar için dizin deposu olarak LDAP kullanımına ve çalışan bilgilerini depolamaya odaklanmıştır. Birçok şirket Ağ Bilgi Hizmeti'ni (NIS) bir ağ dizin deposu olarak LDAP ile değiştirmektedir veya değiştirmektedir.

LDAP sunucusu, NAS birimleriyle kullanılmak üzere UNIX kullanıcı ve grup kimlikleri sağlar. Azure NetApp Files'da Active Directory, şu anda desteklenen ve kullanılabilecek tek LDAP sunucusudur. Bu destek hem Active Directory Etki Alanı Hizmetleri (AD DS) hem de Microsoft Entra Domain Services'ı içerir.

LDAP istekleri iki ana operasyona ayrılabilir.

LDAP bağlamaları , LDAP istemcisinden LDAP sunucusunda oturum açma işlemleridir. Bağlama, LDAP aramalarını gerçekleştirmek için salt okunur erişimle LDAP sunucusunda kimlik doğrulaması yapmak için kullanılır. Azure NetApp Files bir LDAP istemcisi olarak görev yapar.
LDAP aramaları adlar, sayısal kimlikler , giriş dizini yolları, oturum açma kabuğu yolları, grup üyelikleri ve daha fazlası gibi kullanıcı ve grup bilgilerinin dizinini sorgulamak için kullanılır.

LDAP, çift protokollü NAS erişiminde kullanılan aşağıdaki bilgileri depolayabilir:

Kullanıcı adları
Grup adları
Sayısal kullanıcı kimlikleri (UID) ve grup kimlikleri (GID)
Giriş dizinleri
Oturum açma kabuğu
Netgroups, DNS adları ve IP adresleri
Grup üyeliği

Şu anda Azure NetApp Files, netgroup veya konak bilgisi olmadan yalnızca kullanıcı ve grup bilgileri için LDAP kullanmaktadır.

LDAP, kimlik kaynağı olarak UNIX kullanıcılarınız ve gruplarınız için çeşitli avantajlar sunar.

LDAP geleceğe dayanıklıdır.
NFSv4.x için daha fazla NFS istemcisi destek ekledikçe, erişim tanımlandığında en iyi güvenliği ve garantili erişimi sağlamak için istemcilerden ve depolamadan erişilebilen kullanıcı ve grupların güncel bir listesini içeren NFSv4.x KIMLIK etki alanları gereklidir. SMB ve NFS kullanıcıları için bire bir ad eşlemeleri sağlayan bir kimlik yönetimi sunucusuna sahip olmak, depolama yöneticilerinin yalnızca şu anda değil, gelecek yıllarda da kullanım ömrünü büyük ölçüde kolaylaştırır.
LDAP ölçeklenebilir.
LDAP sunucuları milyonlarca kullanıcı ve grup nesnesi içerebilme olanağı sunar ve Microsoft Active Directory ile hem performans hem de dayanıklılık ölçeği için birden çok site arasında çoğaltmak için birden çok sunucu kullanılabilir.
LDAP güvenlidir.
LDAP, bir depolama sisteminin kullanıcı bilgilerine yönelik isteklerde bulunmak için LDAP sunucusuna nasıl bağlanabileceği biçiminde güvenlik sunar. LDAP sunucuları aşağıdaki bağlama düzeylerini sunar:
- Anonim (Microsoft Active Directory'de varsayılan olarak devre dışıdır; Azure NetApp Files'da desteklenmez)
- Basit parola (düz metin parolaları; Azure NetApp Files'da desteklenmez)
- Basit Kimlik Doğrulama ve Güvenlik Katmanı (SASL) – TLS, SSL, Kerberos vb. gibi şifrelenmiş bağlama yöntemleri. Azure NetApp Files TLS üzerinden LDAP, LDAP imzalama (Kerberos kullanarak), SSL üzerinden LDAP'yi destekler.
LDAP sağlamdır.
NIS, NIS+ ve yerel dosyalar UID, GID, parola, giriş dizinleri gibi temel bilgiler sunar. Ancak LDAP bu öznitelikleri ve daha fazlasını sunar. LDAP'nin kullandığı ek öznitelikler, çift protokol yönetimini LDAP ve NIS ile çok daha tümleşik hale getirir. Azure NetApp Files ile kimlik yönetimi için dış ad hizmeti olarak yalnızca LDAP desteklenir.
Microsoft Active Directory LDAP üzerine kurulmuştur.
Varsayılan olarak, Microsoft Active Directory kullanıcı ve grup girdileri için ldap arka ucu kullanır. Ancak, bu LDAP veritabanı UNIX stili öznitelikler içermez. LDAP şeması UNIX için Kimlik Yönetimi (Windows 2003R2 ve üzeri), UNIX için Hizmet (Windows 2003 ve öncesi) veya Centrify gibi üçüncü taraf LDAP araçları aracılığıyla genişletildiğinde bu öznitelikler eklenir. Microsoft, LDAP'yi arka uç olarak kullandığından, LDAP'yi Azure NetApp Files'da çift protokollü birimlerden yararlanmayı seçen ortamlar için mükemmel bir çözüm haline getirir.

Not

Azure NetApp Files şu anda yalnızca LDAP hizmetleri için yerel Microsoft Active Directory'sini destekler.

Azure NetApp Files'daki LDAP temel bilgileri

Aşağıdaki bölümde, Azure NetApp Files ile ilgili olarak LDAP'nin temelleri ele alınmaktadır.

LDAP bilgileri, LDAP sunucusundaki düz dosyalarda depolanır ve LDAP şeması yoluyla düzenlenir. LDAP istemcilerini, isteklerini ve aramalarını LDAP sunucusundaki şemayla koordine eden bir şekilde yapılandırmanız gerekir.
LDAP istemcileri, LDAP şemasına okuma erişimi olan bir hesap kullanarak LDAP sunucusunda oturum açma işlemi olan LDAP bağlaması yoluyla sorgular başlatır. İstemcilerde LDAP bağlama yapılandırması, LDAP sunucusu tarafından tanımlanan güvenlik mekanizmasını kullanacak şekilde yapılandırılır. Bazen, bunlar düz metin (basit) olarak kullanıcı adı ve parola değişimleridir. Diğer durumlarda, bağlamaların güvenliği TLS üzerinden Kerberos veya LDAP gibi Basit Kimlik Doğrulama ve Güvenlik Katmanı yöntemleri (sasl) aracılığıyla sağlanır. Azure NetApp Files, mümkün olan en iyi güvenlik için SASL kimlik doğrulamasını kullanarak bağlanmak için SMB makine hesabını kullanır.
LDAP'de depolanan kullanıcı ve grup bilgileri, RFC 2307'de tanımlandığı gibi standart LDAP arama istekleri kullanılarak istemciler tarafından sorgulanır. Buna ek olarak, RFC 2307bis gibi daha yeni mekanizmalar daha kolay kullanıcı ve grup aramalarına izin verir. Azure NetApp Files, Windows Active Directory'de şema aramaları için rfc 2307bis biçimini kullanır.
LDAP sunucuları kullanıcı ve grup bilgilerini ve netgroup'ı depolayabilir. Ancak Azure NetApp Files şu anda Windows Active Directory üzerinde LDAP'de netgroup işlevselliğini kullanamıyor.
Azure NetApp Files'daki LDAP, 389 numaralı bağlantı noktasında çalışır. Bu bağlantı noktası şu anda 636 numaralı bağlantı noktası (SSL üzerinden LDAP) veya 3268 numaralı bağlantı noktası (Active Directory Genel Katalog aramaları) gibi özel bir bağlantı noktası kullanacak şekilde değiştirilemiyor.
Şifrelenmiş LDAP iletişimleri, TLS üzerinden LDAP (bağlantı noktası 389 üzerinden çalışır) veya LDAP imzalama kullanılarak elde edilebilir ve her ikisi de Active Directory bağlantısında yapılandırılabilir.
Azure NetApp Files, tamamlanması 3 saniyeden uzun sürmeden LDAP sorgularını destekler. LDAP sunucusunda çok sayıda nesne varsa, bu zaman aşımı aşılabilir ve kimlik doğrulama istekleri başarısız olabilir. Böyle durumlarda, sorguları daha iyi performans için filtrelemek için bir LDAP arama kapsamı belirtmeyi göz önünde bulundurun.
Azure NetApp Files, istekleri hızlandırmaya yardımcı olmak için tercih edilen LDAP sunucularını belirtmeyi de destekler. Azure NetApp Files bölgenize en yakın LDAP sunucusunun kullanıldığından emin olmak istiyorsanız bu ayarı kullanın.

Tercih edilen LDAP sunucusu ayarlanmamışsa, Active Directory etki alanı adı DNS'de LDAP hizmet kayıtları için sorgulanır ve bu SRV kaydında bulunan bölgeniz için kullanılabilir LDAP sunucuları listesini doldurur. veya dig komutlarını kullanarak nslookup bir istemciden DNS'deki LDAP hizmet kayıtlarını el ile sorgulayabilirsiniz.

Örneğin:

C:\>nslookup
Default Server:  localhost
Address:  ::1

> set type=SRV
> _ldap._tcp.contoso.com.

Server:  localhost
Address:  ::1

_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 0
          port           = 389
          svr hostname   = oneway.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = ONEWAY.Contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = oneway.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = parisi-2019dc.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = contoso.com
oneway.contoso.com       internet address = x.x.x.x
ONEWAY.Contoso.com       internet address = x.x.x.x
oneway.contoso.com       internet address = x.x.x.x
parisi-2019dc.contoso.com        internet address = y.y.y.y
contoso.com      internet address = x.x.x.x
contoso.com      internet address = y.y.y.y

LDAP sunucuları, kullanıcılar için özel ad eşlemesi gerçekleştirmek için de kullanılabilir. Daha fazla bilgi için bkz . LDAP kullanarak özel ad eşleme.
LDAP sorgusu zaman aşımları

Varsayılan olarak, LDAP sorguları zamanında tamamlanamıyorsa zaman aşımına girer. Ldap sorgusu zaman aşımı nedeniyle başarısız olursa, kullanıcı ve/veya grup araması başarısız olur ve birimin izin ayarlarına bağlı olarak Azure NetApp Files birimine erişim reddedilebilir. Azure NetApp Files LDAP sorgu zaman aşımı ayarlarını anlamak için Active Directory bağlantıları oluşturma ve yönetme bölümüne bakın.

Ad eşleme türleri

Ad eşleme kuralları iki ana türe ayrılabilir: simetrik ve asimetrik.

Simetrik ad eşlemesi, unix ile aynı kullanıcı adını kullanan Windows kullanıcıları arasındaki örtük ad eşlemesidir. Örneğin, Windows kullanıcısı UNIX kullanıcı CONTOSO\user1user1ile eşler.
Asimetrik ad eşlemesi, farklı kullanıcı adları kullanan UNIX ve Windows kullanıcıları arasındaki ad eşlemesidir. Örneğin, Windows kullanıcısı UNIX kullanıcı CONTOSO\user1user2ile eşler.

Varsayılan olarak, Azure NetApp Files simetrik ad eşleme kurallarını kullanır. Asimetrik ad eşleme kuralları gerekiyorsa LDAP kullanıcı nesnelerini bunları kullanacak şekilde yapılandırmayı göz önünde bulundurun.

LDAP kullanarak özel ad eşlemesi

LDAP sunucusundaki LDAP şema öznitelikleri doldurulmuşsa LDAP bir ad eşleme kaynağı olabilir. Örneğin, UNIX kullanıcılarını birebir (asimetrik) eşleşmeyen ilgili Windows kullanıcı adlarına eşlemek içinuid, kullanıcı nesnesinde Windows kullanıcı adı için yapılandırılandan farklı bir değer belirtebilirsiniz.

Aşağıdaki örnekte, bir kullanıcının Windows adı asymmetric vardır ve bir UNIX kimliğiyle eşlenmesi UNIXusergerekir. Bunu Azure NetApp Files'da başarmak için mmc Active Directory Kullanıcıları ve Bilgisayarları bir örneğini açın. Ardından, istediğiniz kullanıcıyı bulun ve özellikler kutusunu açın. (Bunu yapmak için Öznitelik Düzenleyicisi'nin etkinleştirilmesi gerekir). Öznitelik Düzenleyicisi sekmesine gidin ve UID alanını bulun, ardından UID alanını istenen UNIX kullanıcı adıyla UNIXuser doldurun ve onaylamak için Ekle ve Tamam'a tıklayın.

Bu eylem tamamlandıktan sonra, Windows kullanıcısının asymmetric Windows SMB paylaşımlarından yazılan dosyalar NFS tarafında sahip UNIXuser olur.

Aşağıdaki örnekte Windows SMB sahibi gösterilmektedir asymmetric:

Aşağıdaki örnekte NFS sahibi UNIXuser (LDAP kullanılarak Windows kullanıcısından asymmetric eşlenir) gösterilmektedir:

root@ubuntu:~# su UNIXuser
UNIXuser@ubuntu:/root$ cd /mnt
UNIXuser@ubuntu:/mnt$ ls -la
total 8
drwxrwxrwx  2 root     root   4096 Jul  3 20:09 .
drwxr-xr-x 21 root     root   4096 Jul  3 20:12 ..
-rwxrwxrwx  1 UNIXuser group1   19 Jul  3 20:10 asymmetric-user-file.txt

LDAP ile yerel NFS kullanıcılarına izin ver

Kullanıcı NFS aracılığıyla bir Azure NetApp Files birimine erişmeye çalıştığında, istek sayısal bir kimlikle gelir. Varsayılan olarak, Azure NetApp Files NFS kullanıcıları için genişletilmiş grup üyeliklerini destekler (standart 16 grup sınırının ötesine geçmek için). Sonuç olarak, Azure NetApp dosyaları bu sayısal kimliği almayı dener ve kullanıcı için grup üyeliklerini bir RPC paketine geçirmek yerine grup üyeliklerini çözümlemeye yönelik bir girişimde LDAP'de arar. Bu davranış nedeniyle, bu sayısal kimlik LDAP'deki bir kullanıcıya çözümlenemiyorsa arama başarısız olur ve istekte bulunan kullanıcının birime veya veri yapısına erişim izni olsa bile erişim reddedilir. Active Directory bağlantılarında LDAP ile yerel NFS kullanıcılarına izin ver seçeneği, genişletilmiş grup işlevselliğini devre dışı bırakarak NFS istekleri için bu LDAP aramalarını devre dışı bırakmaya yöneliktir. Azure NetApp Files içinde "yerel kullanıcı oluşturma/yönetim" sağlamaz.

"LDAP ile yerel NFS kullanıcılarına izin ver" seçeneği etkinleştirildiğinde, sayısal kimlikler Azure NetApp Files'a geçirilir ve LDAP araması yapılmaz. Bu, aşağıda açıklandığı gibi farklı senaryolar için farklı davranışlar oluşturur.

UNIX güvenlik stili birimleri ile NFSv3

Sayısal kimliklerin kullanıcı adlarına çevrilmesi gerekmez. "LDAP ile yerel NFS kullanıcılarına izin ver" seçeneği birime erişimi etkilemez, ancak NFS istemcisinde kullanıcı/grup sahipliğinin (ad çevirisi) görüntülenme şeklini etkileyebilir. Örneğin, 1001 sayısal kimliği LDAP'de user1 ise ancak NFS istemcisinin yerel passwd dosyasında user2 ise, sayısal kimlik 1001 olduğunda istemci dosyanın sahibi olarak "user2" görüntüler.

UNIX güvenlik stili birimleriyle NFSv4.1

Sayısal kimliklerin kullanıcı adlarına çevrilmesi gerekmez. Varsayılan olarak, NFSv4.1 kimlik doğrulaması için ad dizelerini (user@CONTOSO.COM) kullanır. Ancak Azure NetApp Files, NFSV4.1 ile sayısal kimlik kullanımını destekler; bu da NFSv4.1 isteklerinin NFS sunucusuna sayısal kimlikle ulaşacağı anlamına gelir. Azure NetApp Files birimi için LDAP gibi yerel dosyalarda veya ad hizmetlerinde kullanıcı adı çevirisi için sayısal kimlik yoksa, sayısal istemciye sunulur. Sayısal kimlik bir kullanıcı adına çevrilirse, ad dizesi kullanılır. Ad dizesi eşleşmiyorsa, istemci adı istemcinin idmapd.conf dosyasında belirtilen anonim kullanıcıya sıkıştıracaktır. "LDAP ile yerel NFS kullanıcılarına izin ver" seçeneğinin etkinleştirilmesi NFSv4.1 erişimini etkilemez. Azure NetApp Files, yerel NFS kullanıcı veritabanındaki bir kullanıcı adına yönelik sayısal kimliği çözümleyemedikçe standart NFSv3 davranışına geri döner. Azure NetApp Files,bazı istemciler için sorunlu olabilecek bir dizi varsayılan UNIX kullanıcısına sahiptir ve etki alanı kimliği dizeleri eşleşmiyorsa "hiç kimse" kullanıcısına sıkıştırabilir.

Yerel kullanıcılar şunlardır: kök (0), pcuser (65534), kimse (65535).
Yerel gruplar şunlardır: kök (0), daemon (1), pcuser (65534), kimse (65535).

En yaygın olarak, NFSv4.1 etki alanı kimliği yanlış yapılandırıldığında NFSv4.1 istemci bağlamalarında kök yanlış görünebilir. NFSv4.1 Kimliği etki alanı hakkında daha fazla bilgi için bkz . Azure NetApp Files için NFSv4.1 Kimlik etki alanını yapılandırma.

NFSv4.1 ACL'leri bir ad dizesi veya sayısal kimlik kullanılarak yapılandırılabilir. Sayısal kimlikler kullanılıyorsa, ad çevirisi gerekmez. Bir ad dizesi kullanılırsa, doğru ACL çözümlemesi için ad çevirisi gerekir. NFSv4.1 ACL'lerini kullanırken, "LDAP ile yerel NFS kullanıcılarına izin ver" seçeneğinin etkinleştirilmesi, ACL yapılandırmasına bağlı olarak yanlış NFSv4.1 ACL davranışına neden olabilir.

İkili protokol yapılandırmalarında NTFS güvenlik stili birimlerine sahip NFS (v3 ve v4.1)

UNIX güvenlik stili birimleri UNIX stili izinlerinden (mod bitleri ve NFSv4.1 ACL'ler) yararlanır. Bu tür birimler için NFS, yukarıda listelenen senaryolara bağlı olarak yalnızca sayısal kimlik veya ad dizesini kullanan UNIX stili kimlik doğrulamasından yararlanıyor. Ancak NTFS güvenlik stili birimleri NTFS stil izinlerini kullanır. Bu izinler Windows kullanıcıları ve grupları kullanılarak atanır. NFS kullanıcısı NTFS stil iznine sahip bir birime erişmeye çalıştığında, uygun erişim denetimlerini sağlamak için UNIX-Windows ad eşlemesi gerçekleştirilmelidir. Bu senaryoda, NFS sayısal kimliği Azure NetApp Files NFS birimine geçirilir, ancak ilk kimlik doğrulaması için bir Windows kullanıcı adına eşlenebilmesi için sayısal kimliğin bir UNIX kullanıcı adına çevrilmesi gerekir. Örneğin, sayısal kimlik 1001, Windows kullanıcısı "user1" erişimine izin veren NTFS güvenlik stili izinlerine sahip bir NFS bağlamasına erişmeye çalışırsa, beklenen erişimi elde etmek için LDAP'de "user1" kullanıcı adına 1001'in çözümlenmesi gerekir. LDAP'de sayısal kimliği "1001" olan bir kullanıcı yoksa veya LDAP yanlış yapılandırılmışsa, denenen UNIX-Windows ad eşlemesi olacaktır 1001@contoso.com. Çoğu durumda, bu ada sahip kullanıcılar mevcut değildir, bu nedenle kimlik doğrulaması başarısız olur ve erişim reddedilir. Benzer şekilde, 1001 sayısal kimliği yanlış kullanıcı adına (user2 gibi) çözümlenirse NFS isteği beklenmeyen bir Windows kullanıcısıyla eşlenir ve kullanıcının izinleri "user2" erişim denetimlerini kullanır.

"LDAP ile yerel NFS kullanıcılarına izin ver" etkinleştirildiğinde, sayısal kimliklerin kullanıcı adlarına yönelik tüm LDAP çevirileri devre dışı bırakılır ve bu da NTFS güvenlik stili birimlerine erişimi etkili bir şekilde bozar. Bu nedenle, NTFS güvenlik stili birimlerinde bu seçeneğin kullanılması önerilmez.

LDAP şemaları

LDAP şemaları, LDAP sunucularının bilgileri düzenleme ve toplama şeklidir. LDAP sunucu şemaları genellikle aynı standartlara uyar, ancak farklı LDAP sunucu sağlayıcılarının şemaların nasıl sunulduğuna ilişkin varyasyonları olabilir.

Azure NetApp Files LDAP'yi sorguladığında, kullanıcı hakkında UID gibi bilgileri bulmak için belirli özniteliklerin kullanılmasını etkinleştirdikleri için ad aramalarını hızlandırmaya yardımcı olmak için şemalar kullanılır. Girdiyi bulabilmek için Azure NetApp Files için LDAP sunucusunda şema özniteliklerinin bulunması gerekir. Aksi takdirde LDAP sorguları veri döndürmeyebilir ve kimlik doğrulama istekleri başarısız olabilir.

Örneğin, Azure NetApp Files tarafından bir UID numarasının (root=0 gibi) sorgulanması gerekiyorsa RFC 2307 uidNumber Attribute şema özniteliği kullanılır. Alanda LDAP'de uidNumber UID numarası 0 yoksa arama isteği başarısız olur.

Şu anda Azure NetApp Files tarafından kullanılan şema türü RFC 2307bis tabanlı bir şema biçimidir ve değiştirilemez.

RFC 2307bis, RFC 2307'nin bir uzantısıdır ve LDAP şemasında özniteliğini kullanmak memberUid yerine özniteliğini kullanarak uniqueMember yardımcı gruplar için dinamik aramalar sağlayan desteği eklerposixGroup. Bu öznitelik yalnızca kullanıcının adını kullanmak yerine LDAP veritabanındaki başka bir nesnenin tam ayırt edici adını (DN) içerir. Bu nedenle, grupların üye olarak başka grupları da olabilir ve bu da grupların iç içe yerleştirilmesine olanak tanır. RFC 2307bis desteği, nesne sınıfı groupOfUniqueNamesiçin de destek ekler.

Bu RFC uzantısı, Microsoft Active Directory'nin her zamanki yönetim araçları aracılığıyla kullanıcıları ve grupları yönetme şekline çok uygundur. Bunun nedeni, standart Windows yönetim yöntemlerini kullanarak bir gruba Windows kullanıcısı eklediğinizde (ve bu grubun geçerli bir sayısal GID'i varsa), LDAP aramalarının normal Windows özniteliğinden gerekli ek grup bilgilerini çekmesi ve sayısal GID'leri otomatik olarak bulmasıdır.

Aracılığıyla paylaş