Otentikasi Active Directory load balancing dan failover

8

Untuk aplikasi yang mengautentikasi terhadap Active Directory DC, jelas lebih baik mengarahkannya ke catatan DNS domain utama daripada DC spesifik untuk failover, load balancing, dll.

Apa praktik terbaik untuk aplikasi-aplikasi yang memaksa Anda melakukan hardcode IP DC? Kami dapat mengode kode alamat IP penyeimbang beban, jadi jika satu DC turun, aplikasi itu masih dapat mengautentikasi. Apakah ada alternatif yang lebih baik?

— Kerekan
sumber

2

Siapa pun yang menulis aplikasi yang memaksa Anda untuk meng-hardcode alamat IP pengontrol domain ke dalamnya tidak tahu apa yang dia lakukan.

— Ryan Ries

1

Temukan pengembang aplikasi dan minta mereka memperbaikinya.

— Michael Hampton

Ini sebagian besar untuk beberapa aplikasi lawas dan kotak NAS lama yang belum siap kami ganti.

— Derrick

8

Active Directory sudah memiliki teknik load balancing. Klien Windows Anda tahu cara menemukan pengontrol domain redundan di situsnya sendiri, dan cara menggunakan yang lain jika yang pertama tidak tersedia. Tidak perlu melakukan penyeimbangan beban tambahan, seperti DC "berkerumun", dll. Selama Anda memiliki DC berlebihan.

Di satu sisi, Anda dapat menganggap Situs Direktori Aktif sebagai "penyeimbang beban," karena klien di situs itu akan secara acak memilih salah satu DC di situs yang sama. Jika semua DC di situs gagal atau jika situs tidak memiliki DC, maka klien akan memilih situs lain (baik situs terdekat berikutnya atau secara acak.)

Anda dapat memuat keseimbangan Layanan DNS yang disediakan Active Directory untuk klien yang bergabung dengan domain dengan menempatkan VIP pada penyeimbang beban perangkat keras, dan memiliki keseimbangan beban VIP di antara beberapa pengontrol domain. Kemudian pada klien Anda, tempatkan VIP itu sebagai server DNS pilihan dalam konfigurasi TCP / IP.

Saya melakukan itu sekarang untuk infrastruktur global dan ini bekerja dengan baik.

Tetapi itu hanya berlaku untuk layanan DNS.

Jangan mencoba memuat keseimbangan pengontrol domain Anda untuk otentikasi. Ia meminta masalah. Setidaknya Anda harus melakukan banyak pekerjaan kustom SPN yang kompleks dan Anda akan membuang diri Anda keluar dari batas-batas dukungan Microsoft. Dari blog ini, yang harus Anda baca , saya akan mengutipnya:

Kembali ke vendor dan beri tahu mereka bahwa Anda tidak menganggapnya sebagai AD Integrated dan Anda akan menemukan solusi yang berbeda.

Sekarang untuk aplikasi yang meminta Anda untuk mengetik alamat IP pengendali domain? Baiklah, saya hanya akan mengulangi komentar saya:

Siapa pun yang menulis aplikasi yang memaksa Anda untuk meng-hardcode alamat IP pengontrol domain ke dalamnya tidak tahu apa yang dia lakukan.

— Ryan Ries
sumber

Pertanyaan aslinya adalah "Apa praktik terbaik untuk aplikasi yang memaksa Anda melakukan hardcode pada IP DC?". Anggap tidak ada aplikasi yang sah di luar sana yang tidak mendukung penemuan dinamis adalah asumsi yang buruk. Ada banyak aplikasi non-Windows yang ingin melakukan autentikasi terhadap Active Directory. Jadi apa cara terbaik untuk membuat aplikasi ini bekerja di mana penemuan DC dinamis bukanlah suatu pilihan?

— Dscoduc

@Dscoduc Dapatkan aplikasi yang lebih baik.

— Ryan Ries

3

tidak pernah ada alasan yang baik untuk melakukan hardcode IP atau menggunakan IP untuk menyelesaikan pertanyaan AD. Tidak ada praktik terbaik untuk praktik buruk.

— Jim B
sumber

1

"Tidak ada praktik terbaik untuk praktik buruk." Kutipan hari ini, tuan.

— mfinni

1

Beberapa jawaban lain untuk pertanyaan ini tampaknya menganggap tidak ada dunia lain selain aplikasi yang disadari Microsoft. Sayangnya ini bukan masalahnya, seperti bukti dari pertanyaan asli:

Apa praktik terbaik untuk aplikasi-aplikasi yang memaksa Anda melakukan hardcode IP DC?

Sementara Microsoft tidak mendukung atau merekomendasikan menggunakan solusi NLB di depan Active Directory, memang ada beberapa opsi untuk mengotentikasi aplikasi yang tidak menyadari Microsoft AD.

— Dscoduc
sumber

Untuk menindaklanjuti qyestion ini dan jawaban saya yang diposting - perusahaan saya telah menerapkan solusi F5 LDAP Local Traffic Manager yang kuat yang berhasil mengungguli Active Directory untuk sistem non-Windows yang tidak mampu memanfaatkan layanan DCLocator. Kami memiliki enam lalu lintas penanganan LTM di seluruh dunia tanpa masalah.

— Dscoduc

0

Kebutuhan aktual untuk eksternal "Load balancing" AD jarang terjadi, dan sulit dilakukan dengan benar. Kebutuhan akan permintaan tipikal dapat berfungsi dengan baik, namun klien Windows dan aplikasi tipikal perlu melakukan pembaruan. Klien Windows mencoba untuk membangun afinitas dengan dc tertentu, sehingga jika memperbarui sesuatu dan segera mencoba operasi berikutnya, ia menyentuh dc yang sama. Pengembang aplikasi melakukan hal yang sama. Jika Anda menulis kode yang membuat akun pengguna, kemudian mencoba mengubah kata sandi pada akun itu 1 ms nanti, Anda harus menekan dc yang sama.

Jika Anda ke front-end AD dengan beberapa solusi penyeimbang beban, Anda mengambil kepemilikan memastikan pendekatan dan afinitas tidak putus.

Jika kebutuhan adalah ketersediaan, tidak seperti menyeimbangkan beban, pengelompokan mungkin lebih tepat (mengesampingkan kaleng cacing).

Dalam implementasi AD besar, pendekatan yang lebih tradisional adalah mengidentifikasi mayoritas konsumen, dan menempatkan mereka di situs dengan dc mereka sendiri. Misalnya, jika Anda memiliki lima server Exchange, buat situs untuk subnet untuk server tersebut, dan letakkan GC khusus di situs itu. Hal yang sama berlaku untuk server lain seperti SharePoint.

— Greg Askew
sumber