GNU/Linux >> Belajar Linux >  >> Linux

Kebijaksanaan umum tentang autentikasi Direktori Aktif untuk Server Linux?

Solusi 1:

Pada Maret 2014, Red Hat menerbitkan arsitektur referensi untuk mengintegrasikan Red Hat Enterprise Server dengan Active Directory. (Materi ini harus terkini dan relevan.) Saya benci memposting ini sebagai jawaban, tetapi terlalu banyak materi untuk ditransfer ke bidang jawaban.

Dokumen ini (diperbaiki) yang sedang hangat diterbitkan tampaknya berfokus pada fitur-fitur baru Red Hat Enterprise Linux (RHEL) 7. Diterbitkan untuk KTT minggu lalu.

Jika tautan ini basi, beri tahu saya dan saya akan memperbarui jawabannya.

Saya pribadi menggunakan WinBind dengan cukup andal untuk otentikasi. Sangat jarang terjadi kegagalan layanan yang mengharuskan seseorang dengan root atau akun lokal lainnya untuk masuk dan memantulkan winbindd. Ini mungkin dapat ditangani melalui pemantauan yang tepat jika Anda mau berusaha.

Perlu dicatat bahwa Centrify memang memiliki fungsionalitas tambahan, meskipun ini dapat disediakan oleh manajemen konfigurasi terpisah. (Boneka, dll.)

Edit 16/6/14:

Panduan Integrasi Windows Red Hat Enterprise Linux 7

Solusi 2:

re:"Solusi komersial seperti Centrify dan Demikian juga selalu berfungsi, tetapi tampaknya tidak perlu, karena kemampuan ini dimasukkan ke dalam OS."

Yah saya pikir sebagian besar dari kita telah mendengar selama bertahun-tahun bahwa sistem operasi XYZ akhirnya memecahkan teka-teki integrasi AD. IMHO masalahnya adalah untuk vendor OS, integrasi AD adalah fitur kotak centang, yaitu mereka perlu mengirimkan sesuatu yang agak berfungsi untuk mendapatkan kotak centang itu, dan kotak centang itu biasanya hanya berfungsi pada...

  1. platform OS mereka dan
  2. versi saat ini dari platform tersebut dan
  3. terhadap versi Active Directory yang lebih baru.

Kenyataannya adalah sebagian besar lingkungan tidak monolitik dalam hal vendor OS dan versi OS, dan akan memiliki versi AD yang lebih lama. Itu sebabnya vendor seperti Centrify harus mendukung 450+ varian UNIX/Linux/Mac/dll. terhadap Windows 2000 ke Windows 2012 R2, bukan hanya RHEL 7 lagi Windows 2012 R2.

Selain itu, Anda perlu mempertimbangkan bagaimana AD Anda diterapkan, begitu juga integrasi AD vendor OS mendukung Pengontrol Domain Hanya Baca (RODC), kepercayaan satu arah, memberikan dukungan multi-hutan, dll. ruang UID yang ada (yang Anda inginkan), apakah ada alat migrasi untuk memigrasikan UID ke dalam AD. Dan apakah dukungan AD vendor OS mengatasi kemampuan untuk memetakan beberapa UID ke satu AD dalam situasi di mana ruang UID Anda tidak rata. Dan bagaimana dengan ... yah, Anda mengerti.

Lalu ada pertanyaan tentang dukungan ...

Intinya adalah integrasi AD mungkin tampak mudah secara konseptual dan mungkin "gratis" dengan OS terbaru vendor, dan mungkin dapat berfungsi jika Anda hanya memiliki satu versi OS dari satu vendor dan memiliki vanilla AD yang merupakan versi terbaru, dan Anda memiliki kontrak dukungan premium dengan vendor OS yang akan berusaha sebaik mungkin untuk memperbaiki masalah apa pun yang akan muncul. Kalau tidak, Anda mungkin ingin mempertimbangkan solusi pihak ketiga khusus.

Solusi 3:

Opsi Alat Server untuk Layanan Informasi Jaringan (NIS) dari Alat Administrasi Server Jarak Jauh (RSAT) tidak digunakan lagi.

Ini tidak mengejutkan saya -- NIS adalah bukti bahwa Sun membenci kami dan ingin kami sengsara.

Gunakan LDAP asli, Klien Samba, Kerberos, atau opsi non-Microsoft.

Ini saran yang bagus. Diberi pilihan, saya akan mengatakan "Gunakan LDAP asli (tolong melalui SSL)" - ada banyak opsi yang tersedia untuk ini, dua yang paling saya kenal adalah pam_ldap + nss_ldap (dari PADL), atau gabungan nss-pam- ldapd (yang berasal dari fork dan telah mengalami pengembangan dan peningkatan berkelanjutan).

Karena Anda bertanya tentang RedHat secara khusus, perlu dicatat bahwa RedHat memberi Anda alternatif lain menggunakan SSSD.
Jika lingkungan Anda semuanya RedHat (atau hanya memiliki sejumlah besar sistem RedHat), melihat ke dalam "Cara Melakukan Hal-Hal RedHat" yang didukung secara resmi pasti akan sepadan dengan waktu Anda.

Karena saya sendiri tidak memiliki pengalaman dengan RedHat/SSSD, saya hanya membaca dokumen, tetapi tampaknya cukup tangguh dan dirancang dengan baik.

Solusi 4:

Dari metode yang disarankan, izinkan saya memberi Anda daftar pro/kontra:

Luruskan Kerberos/LDAP

Pro:Berfungsi dengan baik jika dikonfigurasi dengan benar. Jarang rusak, ulet, akan selamat dari gangguan jaringan. Tidak perlu perubahan di AD, tidak ada perubahan skema, tidak perlu akses Administrator ke AD. Gratis.

Cons:Relatif sulit untuk dikonfigurasi. Beberapa file perlu diubah. Tidak akan berfungsi jika server autentikasi (Kerberos/LDAP) tidak tersedia.

Mengikat

Pro:Mudah dikonfigurasi. Fungsi sudo dasar. Gratis.

Cons:Dukungan intensif. Tidak tangguh jaringan. Jika ada masalah jaringan, mesin linux dapat dikeluarkan dari AD yang memerlukan pendaftaran ulang server, tugas dukungan. Akses ke akun administrator AD diperlukan. Mungkin perlu membuat perubahan skema di AD.

Pusatkan/Demikian juga dll.

Kelebihan:Relatif mudah dikonfigurasi.

Cons:Mengubah fungsionalitas sudo menjadi hak milik, lebih sulit untuk didukung. Biaya lisensi per server. Perlu keterampilan tambahan untuk mengelola.

SSSD

Pro:Satu file konfigurasi, mudah dikonfigurasi. Bekerja dengan semua metode otentikasi sekarang dan masa depan. Dapat diskalakan, tumbuh bersama sistem. Akan bekerja dalam mode terputus. Jaringan tangguh. Tidak perlu melakukan perubahan apa pun pada skema AD. Tidak perlu kredensial administrator AD. Gratis, didukung.

Cons:Tidak memiliki layanan win seperti update otomatis DNS. Perlu mengonfigurasi pembagian CIFS.

Ringkasan

Melihat kelebihan dan kekurangannya, SSSD adalah pemenangnya. Jika ini adalah sistem baru, tidak ada alasan untuk menggunakan selain SSSD. Ini adalah integrator yang bekerja dengan semua metode otentikasi yang ada dan dapat berkembang dengan sistem karena metode baru dapat ditambahkan bila tersedia. Ini menggunakan metode linux asli dan jauh lebih andal dan cepat. Jika caching diaktifkan, sistem akan bekerja bahkan dalam sistem yang benar-benar terputus dengan kegagalan jaringan penuh.

Winbind dapat digunakan untuk sistem yang sudah ada jika terlalu banyak pekerjaan yang harus diubah.

Centrify memiliki masalah dengan integrasi yang bisa menjadi mahal. Sebagian besar bug diperbaiki dalam rilis baru, tetapi masih ada beberapa yang menyebabkan sakit kepala.

Saya telah bekerja dengan semua metode ini dan SSSD adalah pemenangnya. Bahkan untuk sistem lama, ROI untuk mengonversi dari Winbind ke SSSD sangat tinggi. Kecuali ada alasan khusus untuk tidak menggunakan SSSD, selalu gunakan SSSD.

Solusi 5:

Harus mengomentari ini:

Perlu dicatat bahwa Centrify memang memiliki fungsionalitas tambahan, meskipun ini dapat disediakan oleh manajemen konfigurasi terpisah. (Boneka, dll.)

Sebagai seseorang yang bekerja dengan Centrify tidak yakin dari mana komentar itu berasal. Lihat ini dan Anda dapat melihat bahwa ada banyak sekali fitur yang tidak Anda dapatkan dengan alat config mgmt ala Puppet. Misalnya, dukungan untuk pemetaan beberapa UID ke satu akun AD (Zona), dukungan untuk kepercayaan domain Direktori Aktif penuh (yang tidak didukung oleh solusi Red Hat pada halaman 3), dll.

Tapi kembali ke panduan Red Hat ini. Sangat bagus Red Hat menerbitkan ini, pilihannya bagus. Perhatikan bahwa ini memberi pelanggan 10 opsi untuk melakukan integrasi AD dasar. Sebagian besar opsi adalah variasi Winbind, dan halaman 15 mencantumkan kelebihan dan kekurangan masing-masing, dan ada banyak langkah manual yang diperlukan untuk masing-masing (dengan kekurangan / kekurangan fungsi yang sesuai di atas). Keuntungan dari Centrify Express adalah menurut komentator lain di atas adalah:

  1. mudah untuk menginstal tanpa semua langkah manual dan...
  2. gratis dan...
  3. tidak terbatas pada Red Hat V7 yang penting karena pertanyaannya berkaitan dengan Linux, bukan hanya satu varian -- Centrify mendukung lebih dari 300 jenis *nix dan...
  4. mendukung semua varian Windows AD, bukan hanya Windows 2008. Mereka menerbitkan perbandingan Centrify vs. Winbind di sini, tetapi ini bukan open source.

Pada akhirnya intinya adalah apakah Anda ingin menggulungnya sendiri atau menggunakan solusi komersial. Benar-benar masalah di mana Anda dan bagaimana Anda menghabiskan waktu Anda.


Linux
  1. Lembar contekan untuk perintah umum Linux

  2. Tutorial perintah cd Linux untuk pemula (8 Contoh)

  3. 17 Contoh Perintah hpacucli untuk Linux di Server HP

  1. Cara Membuat Direktori Bersama untuk Semua Pengguna di Linux

  2. Linux – Variabel Lingkungan Permanen Untuk Semua Pengguna?

  3. Linux – Masalah Izin Untuk Direktori Bersama Di Server?

  1. Menggunakan ssh-keygen dan berbagi untuk otentikasi berbasis kunci di Linux

  2. Perintah Dasar Linux Teratas untuk Pemula

  3. Apakah server Linux yang menggunakan AD/Kerberos untuk autentikasi/otorisasi memerlukan akun komputer?