Mendebug kesalahan autentikasi Windows

Saat menggunakan autentikasi Windows sebagai mekanisme keamanan, Antarmuka Penyedia Dukungan Keamanan (SSPI) menangani proses keamanan. Ketika kesalahan keamanan terjadi pada lapisan SSPI, kesalahan tersebut muncul oleh Windows Communication Foundation (WCF). Topik ini menyediakan kerangka kerja dan serangkaian pertanyaan untuk membantu mendiagnosis kesalahan.

Untuk gambaran umum protokol Kerberos, lihat Penjelasan Kerberos; untuk gambaran umum SSPI, lihat SSPI.

Untuk autentikasi Windows, WCF biasanya menggunakan Negosiasi Penyedia Dukungan Keamanan (SSP), yang melakukan autentikasi timbal balik Kerberos antara klien dan layanan. Jika protokol Kerberos tidak tersedia, secara default WCF kembali ke NT LAN Manager (NTLM). Namun, Anda dapat mengonfigurasi WCF untuk hanya menggunakan protokol Kerberos (dan untuk melemparkan pengecualian jika Kerberos tidak tersedia). Anda juga dapat mengonfigurasi WCF untuk menggunakan formulir terbatas dari protokol Kerberos.

Metodologi Pemecahan Kesalahan

Metode dasarnya adalah sebagai berikut:

Tentukan apakah Anda menggunakan autentikasi Windows. Jika Anda menggunakan skema lain, topik ini tidak berlaku.
Jika Anda yakin menggunakan autentikasi Windows, tentukan apakah konfigurasi WCF Anda menggunakan Kerberos secara langsung atau Negotiate.
Setelah menentukan apakah konfigurasi Anda menggunakan protokol Kerberos atau NTLM, Anda dapat memahami pesan kesalahan dalam konteks yang benar.

Ketersediaan Protokol Kerberos dan NTLM

Kerberos SSP memerlukan pengendali domain untuk bertindak sebagai Pusat Distribusi Kunci Kerberos (KDC). Protokol Kerberos hanya tersedia ketika klien dan layanan menggunakan identitas domain. Dalam kombinasi akun lain, NTLM digunakan, seperti yang dirangkum dalam tabel berikut.

Header tabel memperlihatkan kemungkinan jenis akun yang digunakan oleh server. Kolom kiri memperlihatkan kemungkinan jenis akun yang digunakan oleh klien.

	Pengguna Lokal	Sistem Lokal	Pengguna Domain	Mesin Domain
Pengguna Lokal	NTLM	NTLM	NTLM	NTLM
Sistem Lokal	NTLM Anonim	NTLM Anonim	NTLM Anonim	NTLM Anonim
Pengguna Domain	NTLM	NTLM	Kerberos	Kerberos
Komputer Domain	NTLM	NTLM	Kerberos	Kerberos

Secara khusus, keempat jenis akun tersebut meliputi:

Pengguna Lokal: Profil pengguna khusus mesin. Sebagai contoh: MachineName\Administrator atau MachineName\ProfileName.
Sistem Lokal: SISTEM akun bawaan pada komputer yang tidak bergabung ke domain.
Pengguna Domain: Akun pengguna di domain Windows. Misalnya: DomainName\ProfileName.
Mesin Domain: Sebuah proses dengan identitas mesin yang berjalan pada perangkat yang terhubung ke domain Windows. Misalnya: MachineName\Network Service.

Nota

Kredensial layanan diambil ketika metode Open dari kelas ServiceHost dipanggil. Kredensial klien dibaca setiap kali klien mengirim pesan.

Masalah Umum Autentikasi Windows

Bagian ini membahas beberapa masalah autentikasi Windows umum dan kemungkinan perbaikan.

Protokol Kerberos

Masalah SPN/UPN dengan Protokol Kerberos

Saat menggunakan autentikasi Windows, dan protokol Kerberos digunakan atau dinegosiasikan oleh SSPI, URL yang digunakan titik akhir klien harus menyertakan nama domain host layanan yang sepenuhnya memenuhi syarat di dalam URL layanan. Ini mengasumsikan bahwa akun yang dijalankan oleh layanan tersebut memiliki akses ke kunci nama prinsipal layanan (SPN) mesin (default) yang dibuat ketika komputer ditambahkan ke domain Active Directory, yang paling umum dilakukan dengan menjalankan layanan di bawah akun Network Service. Jika layanan tidak memiliki akses ke kunci SPN mesin, Anda harus menyediakan SPN atau nama prinsipal pengguna (UPN) yang benar dari akun tempat layanan berjalan dalam identitas titik akhir klien. Untuk informasi selengkapnya tentang cara kerja WCF dengan SPN dan UPN, lihat Identitas dan Autentikasi Layanan.

Dalam skenario penyeimbangan beban, seperti farm Web atau kebun Web, praktik umumnya adalah menentukan akun unik untuk setiap aplikasi, menetapkan SPN ke akun tersebut, dan memastikan bahwa semua layanan aplikasi berjalan di akun tersebut.

Untuk mendapatkan SPN untuk akun layanan Anda, Anda harus menjadi administrator domain Direktori Aktif. Untuk informasi selengkapnya, lihat Suplemen Teknis Kerberos untuk Windows.

Protokol Kerberos Direct Mengharuskan Layanan Dijalankan Di Bawah Akun Komputer Domain

Ini terjadi ketika ClientCredentialType properti diatur ke Windows dan NegotiateServiceCredential properti diatur ke false, seperti yang ditunjukkan dalam kode berikut.

WSHttpBinding b = new WSHttpBinding();
// By default, the WSHttpBinding uses Windows authentication
// and Message mode.
b.Security.Message.NegotiateServiceCredential = false;

Dim b As New WSHttpBinding()
' By default, the WSHttpBinding uses Windows authentication 
' and Message mode.
b.Security.Message.NegotiateServiceCredential = False

Untuk memperbaiki masalah, jalankan service menggunakan akun mesin domain, seperti Network Service, pada mesin yang terhubung dalam domain.

Delegasi Memerlukan Negosiasi Kredensial

Untuk menggunakan protokol autentikasi Kerberos dengan delegasi, Anda harus menerapkan protokol Kerberos dengan negosiasi kredensial (terkadang disebut "multi-leg" atau "multi-langkah" Kerberos). Jika Anda menerapkan autentikasi Kerberos tanpa negosiasi kredensial (terkadang disebut "one-shot" atau "single-leg" Kerberos), akan terjadi pengecualian.

Untuk menerapkan Kerberos dengan negosiasi kredensial, lakukan langkah-langkah berikut:

Terapkan delegasi dengan mengatur AllowedImpersonationLevel ke Delegation.
Memerlukan negosiasi SSPI:
1. Jika Anda menggunakan pengikatan standar, atur properti ke NegotiateServiceCredentialtrue.
2. Jika Anda menggunakan pengikatan kustom, atur AuthenticationMode atribut Security elemen ke SspiNegotiated.
Wajibkan negosiasi SSPI untuk menggunakan Kerberos dengan melarang penggunaan NTLM:
1. Lakukan ini dalam kode, dengan pernyataan berikut: ChannelFactory.Credentials.Windows.AllowNtlm = false
2. Atau Anda dapat melakukan ini dalam file konfigurasi dengan mengatur allowNtlm atribut ke false. Atribut ini terkandung dalam <jendela>.

Protokol NTLM

Negosiasi SSP beralih kembali ke NTLM, tetapi NTLM dinonaktifkan

Properti AllowNtlm diatur ke false, yang menyebabkan Windows Communication Foundation (WCF) melakukan upaya terbaik untuk melemparkan pengecualian jika NTLM digunakan. Mengatur properti ini ke false mungkin tidak mencegah kredensial NTLM dikirim melalui kawat.

Berikut ini menunjukkan cara menonaktifkan fallback ke NTLM.

CalculatorClient cc = new
    CalculatorClient("WSHttpBinding_ICalculator");
cc.ClientCredentials.Windows.AllowNtlm = false;

Dim cc As New CalculatorClient("WSHttpBinding_ICalculator")
cc.ClientCredentials.Windows.AllowNtlm = False

Gagal Masuk NTLM

Kredensial klien tidak valid pada layanan. Periksa apakah nama pengguna dan kata sandi diatur dengan benar dan sesuai dengan akun yang diketahui oleh komputer tempat layanan berjalan. NTLM menggunakan kredensial yang ditentukan untuk masuk ke komputer layanan. Meskipun kredensial mungkin valid pada komputer tempat klien berjalan, log masuk ini akan gagal jika kredensial tidak valid pada komputer layanan.

Masuk NTLM Anonim Terjadi, tetapi Masuk Anonim Dinonaktifkan secara Default

Saat membuat klien, AllowedImpersonationLevel properti diatur ke Anonymous, seperti yang ditunjukkan dalam contoh berikut, tetapi secara default server melarang masuk anonim. Ini terjadi karena nilai AllowAnonymousLogons default properti kelas WindowsServiceCredential adalah false.

Kode klien berikut mencoba mengaktifkan masuk anonim (perhatikan bahwa properti default adalah Identification).

CalculatorClient cc =
    new CalculatorClient("WSHttpBinding_ICalculator");
cc.ClientCredentials.Windows.AllowedImpersonationLevel =
System.Security.Principal.TokenImpersonationLevel.Anonymous;

Dim cc As New CalculatorClient("WSHttpBinding_ICalculator")
cc.ClientCredentials.Windows.AllowedImpersonationLevel = _
System.Security.Principal.TokenImpersonationLevel.Anonymous

Kode layanan berikut mengubah default untuk mengaktifkan masuk anonim oleh server.

Uri httpUri = new Uri("http://localhost:8000/");
ServiceHost sh = new ServiceHost(typeof(Calculator), httpUri);
sh.Credentials.WindowsAuthentication.AllowAnonymousLogons = true;

Dim httpUri As New Uri("http://localhost:8000/")
Dim sh As New ServiceHost(GetType(Calculator), httpUri)
sh.Credentials.WindowsAuthentication.AllowAnonymousLogons = True

Untuk informasi selengkapnya tentang peniruan identitas, lihat Delegasi dan Peniruan Identitas.

Atau, klien berjalan sebagai layanan Windows, menggunakan SISTEM akun bawaan.

Masalah Lain

Kredensial Klien Tidak Diatur dengan Benar

Autentikasi Windows menggunakan instans dari WindowsClientCredential yang dikembalikan oleh properti ClientCredentials dari kelas ClientBase<TChannel>, bukan UserNamePasswordClientCredential. Berikut ini memperlihatkan contoh yang salah.

CalculatorClient cc = new
    CalculatorClient("WSHttpBinding_ICalculator");
cc.ClientCredentials.UserName.UserName = GetUserName(); // wrong!
cc.ClientCredentials.UserName.Password = GetPassword(); // wrong!

Dim cc As New CalculatorClient("WSHttpBinding_ICalculator")
cc.ClientCredentials.UserName.UserName = GetUserName() ' wrong!
cc.ClientCredentials.UserName.Password = GetPassword() ' wrong!

Berikut ini menunjukkan contoh yang benar.

CalculatorClient cc = new
    CalculatorClient("WSHttpBinding_ICalculator");
// This code returns the WindowsClientCredential type.
cc.ClientCredentials.Windows.ClientCredential.UserName = GetUserName();
cc.ClientCredentials.Windows.ClientCredential.Password = GetPassword();

Dim cc As New CalculatorClient("WSHttpBinding_ICalculator")
' This code returns the WindowsClientCredential type.            
cc.ClientCredentials.Windows.ClientCredential.UserName = GetUserName()
cc.ClientCredentials.Windows.ClientCredential.Password = GetPassword()

SSPI tidak tersedia

Sistem operasi berikut ini tidak mendukung autentikasi Windows ketika digunakan sebagai server: Windows XP Home Edition, Windows XP Media Center Edition, dan Windows Vista Home editions.

Mengembangkan dan Menyebarkan dengan Identitas Yang Berbeda

Jika Anda mengembangkan aplikasi di satu komputer, dan menyebarkan di komputer lain, dan menggunakan jenis akun yang berbeda untuk mengautentikasi di setiap komputer, Anda mungkin mengalami perilaku yang berbeda. Misalnya, Anda mengembangkan aplikasi di komputer Windows XP Pro menggunakan SSPI Negotiated mode autentikasi. Jika Anda menggunakan akun pengguna lokal untuk mengautentikasi, maka protokol NTLM akan digunakan. Setelah aplikasi dikembangkan, Anda menyebarkan layanan ke komputer Windows Server 2003 tempat aplikasi berjalan di bawah akun domain. Pada titik ini, klien tidak akan dapat mengautentikasi layanan karena akan menggunakan Kerberos dan pengendali domain.

Lihat juga

Last updated on 2025-06-17

Bagikan melalui