Memahami penggunaan LDAP dengan Azure NetApp Files

Protokol akses direktori ringan (LDAP) adalah protokol akses direktori standar yang dikembangkan oleh komite internasional yang disebut Internet Engineering Task Force (IETF). LDAP dimaksudkan untuk menyediakan layanan direktori berbasis jaringan tujuan umum yang dapat Anda gunakan di seluruh platform heterogen untuk menemukan objek jaringan.

Model LDAP menentukan cara berkomunikasi dengan penyimpanan direktori LDAP, cara menemukan objek di direktori, cara menggambarkan objek di toko, dan keamanan yang digunakan untuk mengakses direktori. LDAP memungkinkan penyesuaian dan ekstensi objek yang dijelaskan di penyimpanan. Oleh karena itu, Anda dapat menggunakan penyimpanan LDAP untuk menyimpan banyak jenis informasi yang beragam. Banyak penyebaran LDAP awal yang berfokus pada penggunaan LDAP sebagai penyimpanan direktori untuk aplikasi seperti email dan aplikasi web dan untuk menyimpan informasi karyawan. Banyak perusahaan mengganti atau telah mengganti Network Information Service (NIS) dengan LDAP sebagai penyimpanan direktori jaringan.

Server LDAP menyediakan identitas pengguna dan grup UNIX untuk digunakan dengan volume NAS. Di Azure NetApp Files, Active Directory adalah satu-satunya server LDAP yang saat ini didukung yang dapat digunakan. Dukungan ini mencakup Active Directory Domain Services (AD DS) dan Microsoft Entra Domain Services.

Permintaan LDAP dapat dipecah menjadi dua operasi utama.

  • Pengikatan LDAP adalah login ke server LDAP dari klien LDAP. Ikatan digunakan untuk mengautentikasi ke server LDAP dengan akses baca-saja untuk melakukan pencarian LDAP. Azure NetApp Files bertindak sebagai klien LDAP.
  • Pencarian LDAP digunakan untuk mengkueri direktori untuk informasi pengguna dan grup, seperti nama, ID numerik, jalur direktori beranda, jalur shell masuk, keanggotaan grup, dan banyak lagi.

LDAP dapat menyimpan informasi berikut yang digunakan dalam akses NAS protokol ganda:

  • Nama pengguna
  • Nama grup
  • ID pengguna numerik (UID) dan ID grup (GID)
  • Direktori rumah
  • Shell masuk
  • Netgroup, nama DNS, dan alamat IP
  • Keanggotaan grup

Saat ini, Azure NetApp Files hanya menggunakan LDAP untuk informasi pengguna dan grup – tidak ada netgroup atau informasi host.

LDAP menawarkan berbagai manfaat bagi pengguna dan grup UNIX Anda sebagai sumber identitas.

  • LDAP adalah bukti masa depan.
    Karena lebih banyak klien NFS menambahkan dukungan untuk NFSv4.x, domain NFSv4.x ID yang berisi daftar pengguna dan grup terbaru yang dapat diakses dari klien dan penyimpanan diperlukan untuk memastikan keamanan optimal dan akses terjamin saat akses ditentukan. Memiliki server manajemen identitas yang menyediakan pemetaan nama satu-ke-satu untuk pengguna SMB dan NFS sangat menyederhanakan kehidupan bagi administrator penyimpanan, bukan hanya saat ini, tetapi untuk tahun-tahun mendatang.
  • LDAP dapat diskalakan.
    Server LDAP menawarkan kemampuan untuk berisi jutaan objek pengguna dan grup, dan dengan Microsoft Active Directory, beberapa server dapat digunakan untuk mereplikasi di beberapa situs untuk skala performa dan ketahanan.
  • LDAP aman.
    LDAP menawarkan keamanan dalam bentuk bagaimana sistem penyimpanan dapat terhubung ke server LDAP untuk membuat permintaan informasi pengguna. Server LDAP menawarkan tingkat ikatan berikut:
    • Anonim (dinonaktifkan secara default di Microsoft Active Directory; tidak didukung di Azure NetApp Files)
    • Kata sandi sederhana (kata sandi teks biasa; tidak didukung di Azure NetApp Files)
    • Simple Authentication and Security Layer (SASL) – Metode pengikatan terenkripsi termasuk TLS, SSL, Kerberos, dan sebagainya. Azure NetApp Files mendukung LDAP melalui penandatanganan TLS, LDAP (menggunakan Kerberos), LDAP melalui SSL.
  • LDAP kuat.
    NIS, NIS+, dan file lokal menawarkan informasi dasar seperti UID, GID, kata sandi, direktori beranda, dan sebagainya. Namun, LDAP menawarkan atribut tersebut dan banyak lagi. Atribut tambahan yang digunakan LDAP membuat manajemen protokol ganda jauh lebih terintegrasi dengan LDAP versus NIS. Hanya LDAP yang didukung sebagai layanan nama eksternal untuk manajemen identitas dengan Azure NetApp Files.
  • Microsoft Active Directory dibangun di LDAP.
    Secara default, Microsoft Active Directory menggunakan back-end LDAP untuk entri pengguna dan grupnya. Namun, database LDAP ini tidak berisi atribut gaya UNIX. Atribut ini ditambahkan ketika skema LDAP diperluas melalui Manajemen Identitas untuk UNIX (Windows 2003R2 dan yang lebih baru), Layanan untuk UNIX (Windows 2003 dan yang lebih lama), atau alat LDAP pihak ketiga seperti Centrify. Karena Microsoft menggunakan LDAP sebagai back-end, Ini menjadikan LDAP solusi yang sempurna untuk lingkungan yang memilih untuk memanfaatkan volume protokol ganda di Azure NetApp Files.

    Catatan

    Azure NetApp Files saat ini hanya mendukung Microsoft Active Directory asli untuk layanan LDAP.

Dasar-dasar LDAP di Azure NetApp Files

Bagian berikut membahas dasar-dasar LDAP yang berkaitan dengan Azure NetApp Files.

  • Informasi LDAP disimpan dalam file datar di server LDAP dan diatur berdasarkan skema LDAP. Anda harus mengonfigurasi klien LDAP dengan cara yang mengoordinasikan permintaan dan pencarian mereka dengan skema di server LDAP.

  • Klien LDAP memulai kueri dengan cara pengikatan LDAP, yang pada dasarnya merupakan login ke server LDAP menggunakan akun yang memiliki akses baca ke skema LDAP. Konfigurasi pengikatan LDAP pada klien dikonfigurasi untuk menggunakan mekanisme keamanan yang ditentukan oleh server LDAP. Terkadang, mereka adalah pertukaran nama pengguna dan kata sandi dalam teks biasa (sederhana). Dalam kasus lain, pengikatan diamankan melalui metode Autentikasi Sederhana dan Lapisan Keamanan (sasl) seperti Kerberos atau LDAP melalui TLS. Azure NetApp Files menggunakan akun komputer SMB untuk mengikat menggunakan autentikasi SASL untuk keamanan terbaik.

  • Informasi pengguna dan grup yang disimpan di LDAP dikueri oleh klien dengan menggunakan permintaan pencarian LDAP standar seperti yang didefinisikan dalam RFC 2307. Selain itu, mekanisme yang lebih baru, seperti RFC 2307bis, memungkinkan pencarian pengguna dan grup yang lebih efisien. Azure NetApp Files menggunakan bentuk RFC 2307bis untuk pencarian skemanya di Windows Active Directory.

  • Server LDAP dapat menyimpan informasi pengguna dan grup dan netgroup. Namun, Azure NetApp Files saat ini tidak dapat menggunakan fungsionalitas netgroup di LDAP di Windows Active Directory.

  • LDAP di Azure NetApp Files beroperasi pada port 389. Port ini saat ini tidak dapat dimodifikasi untuk menggunakan port kustom, seperti port 636 (LDAP melalui SSL) atau port 3268 (pencarian Active Directory Global Catalog).

  • Komunikasi LDAP terenkripsi dapat dicapai menggunakan LDAP melalui TLS (yang beroperasi melalui port 389) atau penandatanganan LDAP, yang keduanya dapat dikonfigurasi pada koneksi Direktori Aktif.

  • Azure NetApp Files mendukung kueri LDAP yang membutuhkan waktu tidak lebih dari 3 detik untuk diselesaikan. Jika server LDAP memiliki banyak objek, batas waktu tersebut mungkin terlampaui, dan permintaan autentikasi dapat gagal. Dalam kasus tersebut, pertimbangkan untuk menentukan cakupan pencarian LDAP untuk memfilter kueri untuk performa yang lebih baik.

  • Azure NetApp Files juga mendukung penentuan server LDAP pilihan untuk membantu mempercepat permintaan. Gunakan pengaturan ini jika Anda ingin memastikan server LDAP yang paling dekat dengan wilayah Azure NetApp Files Anda sedang digunakan.

  • Jika tidak ada server LDAP pilihan yang diatur, nama domain Direktori Aktif dikueri di DNS untuk catatan layanan LDAP untuk mengisi daftar server LDAP yang tersedia untuk wilayah Anda yang terletak di dalam catatan SRV tersebut. Anda dapat mengkueri rekaman layanan LDAP secara manual di DNS dari klien menggunakan nslookup atau dig perintah.

    Misalnya:

    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
    
  • Server LDAP juga dapat digunakan untuk melakukan pemetaan nama kustom untuk pengguna. Untuk informasi selengkapnya, lihat Pemetaan nama kustom menggunakan LDAP.

  • Batas waktu kueri LDAP

    Secara default, kueri LDAP kehabisan waktu jika tidak dapat diselesaikan secara tepat waktu. Jika kueri LDAP gagal karena waktu habis, pencarian pengguna dan/atau grup akan gagal dan akses ke volume Azure NetApp Files dapat ditolak, tergantung pada pengaturan izin volume. Lihat Membuat dan mengelola koneksi Direktori Aktif untuk memahami pengaturan batas waktu kueri LDAP Azure NetApp Files.

Jenis pemetaan nama

Aturan pemetaan nama dapat dipecah menjadi dua jenis utama: simetris dan asimetris.

  • Pemetaan nama konten adalah pemetaan nama implisit antara pengguna UNIX dan Windows yang menggunakan nama pengguna yang sama. Misalnya, pengguna CONTOSO\user1 Windows memetakan ke pengguna user1UNIX .
  • Pemetaan nama asimetris adalah pemetaan nama antara pengguna UNIX dan Windows yang menggunakan nama pengguna yang berbeda . Misalnya, pengguna CONTOSO\user1 Windows memetakan ke pengguna user2UNIX .

Secara default, Azure NetApp Files menggunakan aturan pemetaan nama konten. Jika aturan pemetaan nama asimetris diperlukan, pertimbangkan untuk mengonfigurasi objek pengguna LDAP untuk menggunakannya.

Pemetaan nama kustom menggunakan LDAP

LDAP dapat menjadi sumber daya pemetaan nama, jika atribut skema LDAP di server LDAP telah diisi. Misalnya, untuk memetakan pengguna UNIX ke nama pengguna Windows terkait yang tidak cocok dengan satu-ke-satu (yaitu, asimetris), Anda dapat menentukan nilai yang berbeda untuk uid dalam objek pengguna daripada apa yang dikonfigurasi untuk nama pengguna Windows.

Dalam contoh berikut, pengguna memiliki nama asymmetric Windows dan perlu memetakan ke identitas UNIX .UNIXuser Untuk mencapainya di Azure NetApp Files, buka instans Pengguna Direktori Aktif dan KOMPUTER MMC. Kemudian, temukan pengguna yang diinginkan dan buka kotak properti. (Melakukannya memerlukan pengaktifan Editor Atribut). Navigasi ke tab Editor Atribut dan temukan bidang UID, lalu isi bidang UID dengan nama UNIXuser pengguna UNIX yang diinginkan dan klik Tambahkan dan OK untuk mengonfirmasi.

Screenshot that shows the Asymmetric Properties window and Multi-valued String Editor window.

Setelah tindakan ini selesai, file yang ditulis dari berbagi Windows SMB oleh pengguna asymmetric Windows akan dimiliki oleh UNIXuser dari sisi NFS.

Contoh berikut menunjukkan pemilik asymmetricWindows SMB :

Screenshot that shows Windows SMB owner named Asymmetric.

Contoh berikut menunjukkan pemilik UNIXuser NFS (dipetakan dari pengguna asymmetric Windows menggunakan LDAP):

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

Skema LDAP

Skema LDAP adalah cara server LDAP mengatur dan mengumpulkan informasi. Skema server LDAP umumnya mengikuti standar yang sama, tetapi penyedia server LDAP yang berbeda mungkin memiliki variasi tentang bagaimana skema disajikan.

Saat Azure NetApp Files mengkueri LDAP, skema digunakan untuk membantu mempercepat pencarian nama karena memungkinkan penggunaan atribut tertentu untuk menemukan informasi tentang pengguna, seperti UID. Atribut skema harus ada di server LDAP untuk Azure NetApp Files agar dapat menemukan entri. Jika tidak, kueri LDAP mungkin tidak mengembalikan data dan permintaan autentikasi yang mungkin gagal.

Misalnya, jika nomor UID (seperti root=0) harus dikueri oleh Azure NetApp Files, maka atribut skema RFC 2307 uidNumber Attribute digunakan. Jika tidak ada nomor 0 UID di LDAP di uidNumber bidang , permintaan pencarian gagal.

Jenis skema yang saat ini digunakan oleh Azure NetApp Files adalah bentuk skema berdasarkan RFC 2307bis dan tidak dapat dimodifikasi.

RFC 2307bis adalah ekstensi RFC 2307 dan menambahkan dukungan untuk posixGroup, yang memungkinkan pencarian dinamis untuk grup tambahan dengan menggunakan uniqueMember atribut , bukan dengan menggunakan memberUid atribut dalam skema LDAP. Alih-alih hanya menggunakan nama pengguna, atribut ini berisi nama khusus lengkap (DN) objek lain dalam database LDAP. Oleh karena itu, grup dapat memiliki grup lain sebagai anggota, yang memungkinkan bersarangnya grup. Dukungan untuk RFC 2307bis juga menambahkan dukungan untuk kelas groupOfUniqueNamesobjek .

Ekstensi RFC ini cocok dengan cara Microsoft Active Directory mengelola pengguna dan grup melalui alat manajemen biasa. Ini karena ketika Anda menambahkan pengguna Windows ke grup (dan jika grup tersebut memiliki GID numerik yang valid) menggunakan metode manajemen Windows standar, pencarian LDAP akan menarik informasi grup tambahan yang diperlukan dari atribut Windows biasa dan menemukan GID numerik secara otomatis.

Langkah berikutnya