Memahami autentikasi Direktori Aktif untuk SQL Server di Linux dan kontainer

  • Artikel

Berlaku untuk:SQL Server - Linux

Artikel ini memberi Anda detail tentang cara kerja autentikasi Direktori Aktif untuk SQL Server yang disebarkan di Linux atau kontainer.

Konsep

Protokol Akses Direktori Ringan (LDAP)

LDAP adalah protokol aplikasi untuk bekerja dengan berbagai layanan direktori, termasuk Direktori Aktif. Layanan direktori menyimpan informasi pengguna dan akun, dan informasi keamanan seperti kata sandi. Informasi tersebut dienkripsi lalu dibagikan dengan perangkat lain di jaringan.

Untuk mengetahui selengkapnya tentang mengamankan LDAP, lihat Cara mengaktifkan masuk LDAP di Windows Server.

Kerberos

Kerberos adalah protokol autentikasi yang digunakan untuk memverifikasi identitas pengguna atau komputer host. Anda dapat menganggapnya sebagai cara untuk memverifikasi klien dan server.

Ketika Anda bekerja di lingkungan heterogen (campuran) di mana Anda memiliki server dan klien Windows dan non-Windows, ada dua jenis file yang Anda butuhkan untuk bekerja dengan layanan direktori berbasis Direktori Aktif:

  • File keytab (singkatan dari "tabel kunci")
  • File konfigurasi Kerberos (krb5.conf atau krb5.ini)

Apa itu file keytab?

Proses server pada sistem Linux atau Unix tidak dapat dikonfigurasi untuk menjalankan proses dengan akun layanan Windows. Ketika Anda ingin sistem Linux atau Unix secara otomatis masuk ke Direktori Aktif saat startup, Anda harus menggunakan file keytab .

Keytab adalah file kriptografi yang berisi representasi layanan yang dilindungi Kerberos dan kunci jangka panjang dari nama perwakilan layanan terkait di Pusat Distribusi Kunci (KDC). Kunci bukan kata sandi itu sendiri.

Keytabs digunakan untuk:

  • mengautentikasi layanan itu sendiri ke layanan lain di jaringan, atau
  • dekripsi tiket layanan Kerberos dari pengguna direktori masuk ke layanan.

Apa itu krb5.conf file?

File /etc/krb5.conf (juga disebut krb5.ini) menyediakan input konfigurasi untuk pustaka Kerberos v5 (KRB5) dan GNU Simple Authentication and Security Layer API (GSSAPI).

Informasi ini mencakup domain default, properti setiap domain (seperti Pusat Distribusi Kunci), dan masa pakai tiket Kerberos default.

File ini diperlukan agar autentikasi Direktori Aktif berfungsi. krb5.conf adalah file INI, tetapi setiap nilai dalam pasangan kunci-nilai dapat menjadi subgrup yang diapit oleh { dan }.

Untuk informasi selengkapnya tentang krb5.conf file, lihat dokumentasi Konsorsium MIT Kerberos.

Mengonfigurasi Kerberos untuk SQL Server di Linux

Ini adalah nilai yang Anda butuhkan di server host yang menjalankan SQL Server di Linux. Jika Anda memiliki layanan (non-SQL Server) lain yang berjalan pada host yang sama, file Anda krb5.conf mungkin memerlukan beberapa entri lagi.

Berikut adalah krb5.conf contoh file untuk referensi:

[libdefaults]
default_realm = CONTOSO.COM

[realms]
CONTOSO.COM = {
  kdc = adVM.contoso.com
  admin_server = adVM.contoso.com
  default_domain = contoso.com
}

[domain_realm]
.contoso.com = CONTOSO.COM
contoso.com = CONTOSO.COM

  • libdefaultsdefault_realm- nilai harus ada. Nilai ini menentukan domain tempat komputer host berada.

  • realms (opsional) - Untuk setiap realm, kdc nilai mungkin diatur untuk menentukan Pusat Distribusi Kunci mana yang harus dihubungi mesin saat mencari akun Direktori Aktif. Jika Anda telah mengatur lebih dari satu KDC, KDC untuk setiap koneksi akan dipilih oleh round-robin.

  • domain_realm (opsional) - Pemetaan untuk setiap realm mungkin disediakan. Jika tidak, SQL Server di Linux mengasumsikan bahwa domain contoso.com memetakan ke ranah CONTOSO.COM.

Proses autentikasi Kerberos

Seperti halnya autentikasi Kerberos di Windows, dua langkah pertama untuk mendapatkan tiket pemberian tiket (TGT) sama:

  • Klien memulai proses masuk dengan mengirim nama pengguna dan kata sandi mereka (dienkripsi) ke pengendali domain (DC).

  • Setelah memeriksa nama pengguna dan kata sandi terhadap penyimpanan internalnya, DC mengembalikan TGT untuk pengguna ke klien.

SQL Server di Linux menggunakan file keytab untuk membaca kata sandi untuk Nama Prinsipal Layanan (SPN) dan kemudian mendekripsi blob terenkripsi, yang digunakan untuk mengotorisasi koneksi. Langkah berikutnya menguraikan proses ini.

  • Setelah pengguna memiliki TGT, klien memulai koneksi ke SQL Server dengan menentukan nama host dan port instans SQL Server.

  • Klien SQL secara internal membuat Nama Perwakilan Layanan dalam format MSSQLSvc/<host>:<port>. Ini adalah format hardcoded di sebagian besar klien SQL Server.

  • Klien memulai jabat tangan Kerberos dengan meminta kunci sesi dari DC untuk SPN tersebut. Baik TGT maupun SPN dikirim ke DC.

Diagram showing Active Directory authentication for SQL Server on Linux - Ticket-Granting Ticket and Service Principal Name sent to Domain Controller.

  • Setelah DC memvalidasi TGT dan SPN, DC mengirimkan kunci sesi ke klien, untuk menyambungkan ke SQL Server SPN.

Diagram showing Active Directory authentication for SQL Server on Linux - session key returned to client by DC.

  • Blob terenkripsi dari kunci sesi dikirim ke server.

Diagram showing Active Directory authentication for SQL Server on Linux - session key sent to server.

  • SQL Server membaca kata sandi untuk SPN dari keytab-nya (mssql.keytab), yang merupakan file pada disk yang berisi tuple terenkripsi (SPN, kata sandi).

  • SQL Server mendekripsi blob terenkripsi dari klien dengan kata sandi yang baru saja dicarinya, untuk mendapatkan nama pengguna klien.

  • SQL Server mencari klien dalam sys.syslogins tabel untuk memeriksa apakah klien berwenang untuk tersambung.

  • Koneksi diterima atau ditolak.

Diagram showing Active Directory authentication for SQL Server on Linux - connection accepted or denied.

Mengonfigurasi Kerberos untuk kontainer SQL Server

Autentikasi Direktori Aktif untuk SQL Server dalam kontainer pada dasarnya sama dengan SQL Server di Linux. Satu-satunya perbedaan adalah SPN host SQL Server. Dalam skenario sebelumnya, SPN karena MSSQLSvc/<host>:<port> kami terhubung melalui nama host SQL Server. Namun, sekarang kita perlu terhubung ke kontainer.

Untuk kontainer SQL Server, Anda dapat membuat file di krb5.conf dalam kontainer. Simpul host yang menjalankan kontainer tidak perlu menjadi bagian dari domain, tetapi harus dapat menjangkau pengontrol domain tempat kontainer akan mencoba terhubung.

Karena kami menyambungkan ke kontainer, nama server dalam koneksi klien mungkin berbeda dari sekadar nama host. Ini bisa berupa nama host, nama kontainer, atau alias lain. Selain itu, ada kemungkinan baik bahwa port yang diekspos untuk SQL Server tidak akan menjadi default 1433.

Anda harus menggunakan SPN yang disimpan untuk mssql.keytab menyambungkan ke kontainer SQL Server. Misalnya, jika SPN di mssql.keytab adalah MSSQLSvc/sqlcontainer.domain.com:8000, Anda akan menggunakan sqlcontainer.domain.com,8000 sebagai string koneksi Anda di klien (termasuk sqlcmd, SQL Server Management Studio, dan Azure Data Studio).

Diagram showing Active Directory authentication for SQL Server Containers.

Refresh grup SQL Server

Anda mungkin bertanya-tanya mengapa ada akun pengguna di keytab jika Anda hanya memerlukan Nama Perwakilan Layanan untuk mengautentikasi.

Bayangkan Anda memiliki pengguna adUser, yang merupakan anggota grup adGroup. Jika adGroup ditambahkan sebagai login ke SQL Server, itu berarti adUser memiliki izin untuk masuk ke instans SQL Server juga. Saat adUser masih tersambung ke SQL Server, admin domain mungkin menghapus adUser dari adGroup. Sekarang adUser seharusnya tidak lagi memiliki izin untuk masuk ke SQL Server, tetapi mereka telah melewati proses autentikasi Kerberos dan terhubung.

Kami secara berkala menjalankan proses yang disebut refresh grup untuk melindungi dari skenario di mana pengguna yang terhubung tidak lagi diizinkan untuk melakukan tindakan istimewa (seperti membuat login atau mengubah database).

SQL Server memiliki akun Active Directory istimewa yang digunakannya untuk refresh grup. Akun ini dikonfigurasi menggunakan mssql-conf dengan pengaturan network.privilegedadaccount , atau default ke akun komputer komputer host (<hostname>$).

Kredensial untuk akun istimewa di mssql.keytab digunakan untuk meniru klien (adUser dalam contoh ini). SQL Server melakukan jabat tangan Kerberos dengan dirinya sendiri untuk mengidentifikasi informasi keanggotaan grup, dan membandingkannya dengan sys.syslogins untuk memeriksa apakah adUser masih memiliki izin yang diperlukan untuk menyambungkan dan menjalankan perintah Transact-SQL yang diminta. Jika adUser telah dihapus dari adGroup, koneksi dihentikan oleh SQL Server.

Refresh grup memerlukan dua kondisi berikut:

  • Konektivitas jaringan antara instans SQL Server dan domain Active Directory lokal.
  • Kepercayaan dua arah antara domain yang tersambung dengan SQL Server, dan domain Active Directory lokal. Untuk informasi selengkapnya, lihat Memahami Direktori Aktif.

Konten terkait