Bagikan melalui

Melakukan debug pada kesalahan NTLM

  • Artikel

Saat menggunakan NTLM sebagai mekanisme keamanan, Antarmuka Penyedia Dukungan Keamanan akan menangani proses keamanan. Saat kesalahan keamanan terjadi di lapisan Antarmuka Penyedia Dukungan Keamanan, kesalahan itu akan ditampilkan oleh WCF. Topik ini menyediakan kerangka kerja dan serangkaian pertanyaan untuk membantu mendiagnosis kesalahan tersebut.

Untuk ringkasan protokol Kerberos, lihat Penjelasan Kerberos; untuk ringkasan Antarmuka Penyedia Dukungan Keamanan, lihat Antarmuka Penyedia Dukungan Keamanan.

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

Metodologi Penelusuran Kesalahan

Metode dasarnya adalah sebagai berikut:

  1. Tentukan apakah Anda menggunakan NTLM. Jika menggunakan skema lain, topik ini tidak berlaku.

  2. Jika yakin menggunakan NTLM, tentukan apakah konfigurasi WCF Anda menggunakan Kerberos direct atau Negotiate.

  3. Setelah menentukan apakah konfigurasi Anda menggunakan protokol Kerberos atau NTLM, Anda dapat memahami pesan kesalahan dalam konteks yang benar.

Ketersediaan Protokol Kerberos dan NTLM

SSP Kerberos memerlukan pengontrol domain untuk bertindak sebagai Pusat Distribusi Kunci Kerberos (KDC). Protokol Kerberos hanya tersedia saat klien dan layanan menggunakan identitas domain. Di kombinasi akun lainnya, NTLM akan digunakan, sebagaimana dirangkum dalam tabel berikut.

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

Pengguna Lokal Sistem Lokal Pengguna Domain Komputer Domain
Pengguna Lokal NTLM NTLM NTLM NTLM
Sistem Lokal Anonymous NTLM Anonymous NTLM Anonymous NTLM Anonymous NTLM
Pengguna Domain NTLM NTLM Kerberos Kerberos
Komputer Domain NTLM NTLM Kerberos Kerberos

Secara khusus, empat jenis akun meliputi:

  • Pengguna Lokal: Profil pengguna khusus komputer. Sebagai contoh: MachineName\Administrator atau MachineName\ProfileName.

  • Sistem Lokal: SISTEM akun bawaan pada komputer yang tidak tergabung ke domain.

  • Pengguna Domain: Akun pengguna di domain Windows. Sebagai contoh: DomainName\ProfileName.

  • Komputer Domain: Proses dengan identitas komputer yang berjalan pada komputer yang digabungkan ke domain Windows. Sebagai contoh: MachineName\Network Service.

Catatan

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

Masalah NTLM Umum

Bagian ini membahas beberapa masalah NTLM umum dan kemungkinan solusinya.

Protokol Kerberos

Masalah SPN/UPN terkait Protokol Kerberos

Saat menggunakan NTLM, dan protokol Kerberos digunakan atau dinegosiasikan oleh Antarmuka Penyedia Dukungan Keamanan, URL yang digunakan titik akhir klien harus menyertakan nama domain yang sepenuhnya memenuhi syarat dari host layanan di dalam URL layanan. Hal ini mengasumsikan bahwa akun tempat layanan berjalan memiliki akses ke kunci nama prinsipal layanan (SPN) komputer (default) yang dibuat saat komputer ditambahkan ke domain Active Directory, yang paling sering dilakukan dengan menjalankan layanan menggunakan akun Layanan Jaringan. Jika layanan tidak memiliki akses ke kunci SPN komputer, 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 garden Web, praktik umum adalah menentukan akun unik untuk setiap aplikasi, menetapkan SPN ke akun itu, dan memastikan bahwa semua layanan aplikasi berjalan di akun itu.

Untuk mendapatkan SPN bagi akun layanan, Anda harus menjadi administrator domain Active Directory. Untuk informasi selengkapnya, lihat Tambahan Teknis Kerberos untuk Windows.

Kerberos Protocol Direct Mewajibkan Layanan Berjalan Di Akun Komputer Domain

Hal ini terjadi ketika properti ClientCredentialType diatur ke Windows dan properti NegotiateServiceCredential 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 mengatasinya, jalankan layanan menggunakan akun Komputer Domain, seperti Layanan Jaringan, pada komputer yang bergabung dengan domain.

Delegasi Memerlukan Negosiasi Kredensial

Untuk menggunakan protokol autentikasi Kerberos dengan delegasi, Anda harus mengimplementasikan protokol Kerberos dengan negosiasi kredensial (terkadang disebut Kerberos "multi-sesi" atau "multi-langkah"). Jika Anda menerapkan autentikasi Kerberos tanpa negosiasi kredensial (terkadang disebut Kerberos "satu kali" atau "sesi tunggal"), pengecualian akan dilemparkan.

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

  1. Implementasikan delegasi dengan mengatur AllowedImpersonationLevel ke Delegation.

  2. Memerlukan negosiasi Antarmuka Penyedia Dukungan Keamanan:

    1. Jika Anda menggunakan pengikatan standar, atur properti NegotiateServiceCredential ke true.

    2. Jika Anda menggunakan pengikatan kustom, atur atribut AuthenticationMode elemen Security ke SspiNegotiated.

  3. Memerlukan negosiasi Antarmuka Penyedia Dukungan Keamanan untuk menggunakan Kerberos dengan melarang penggunaan NTLM:

    1. Lakukan hal ini dalam kode, dengan pernyataan berikut: ChannelFactory.Credentials.Windows.AllowNtlm = false

    2. Atau Anda dapat melakukannya dalam file konfigurasi dengan mengatur atribut allowNtlm ke false. Atribut ini tersimpan dalam <windows>.

Protokol NTLM

Menegosiasikan SSP 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 kabel.

Berikut adalah cara menonaktifkan penggantian 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

Proses Masuk NTLM Gagal

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

Proses Masuk NTLM Anonim Terjadi, tetapi Proses Masuk Anonim Dinonaktifkan secara Default

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

Kode klien berikut mencoba mengaktifkan proses masuk anonim (perhatikan bahwa properti defaultnya 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 pengaturan default untuk mengaktifkan proses 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 klien, lihat Delegasi dan Peniruan.

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

Masalah Lain

Kredensial Klien Tidak Diatur dengan Benar

NTLM menggunakan instans WindowsClientCredential yang ditampilkan oleh properti ClientCredentials kelas ClientBase<TChannel>, bukan UserNamePasswordClientCredential. Berikut adalah 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 adalah 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()

Antarmuka Penyedia Dukungan Keamanan tidak tersedia

Sistem operasi berikut tidak mendukung NTLM saat digunakan sebagai server: Windows XP Home Edition, Windows XP Media Center Edition, dan edisi Windows Vista Home.

Menyebarkan dan Menyebarkan dengan Identitas Yang Berbeda

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

Lihat juga