Pengesahan proksi NTLM melibatkan jabat tangan, bukan sekadar melampirkan nama pengguna sekali. Sebelum menukar kata laluan akaun, pastikan proksi benar-benar menawarkan NTLM dan binari curl menyokongnya.

curl --version

Periksa senarai ciri binari yang melaksanakan permintaan anda. Pemasangan curl lain, imej bekas atau binaan sistem pengendalian boleh mempunyai sokongan pengesahan berbeza.

Pilih kaedah khusus untuk proksi

curl --proxy http://proxy.example:3128 --proxy-ntlm --proxy-user 'EXAMPLE\alice' --noproxy '' --connect-timeout 5 --max-time 20 https://example.com/

Titik akhir, domain dan nama pengguna ialah contoh. Gunakan format yang diberikan pentadbir. Tanpa kata laluan dalam argumen, curl boleh memintanya dan bukannya meninggalkan rahsia dalam perintah yang dipaparkan.

Cabaran pengesahan awal boleh menjadi sebahagian daripada rundingan. Bezakan itu daripada penolakan selepas jabat tangan selesai. Jangan gunakan pilihan NTLM untuk pelayan asal bagi menjawab cabaran proksi.

Sertakan tingkah laku sambungan dalam diagnosis

NTLM mempunyai keadaan yang terikat pada sambungan. Jabat tangan mesti melalui laluan sambungan yang dijangka; menggantikan sambungan berulang kali antara peringkatnya boleh menghalang penyelesaian.

Bagi aplikasi yang menggunakan libcurl, biarkan pustaka mengurus pengesahan dan penggunaan semula sambungan. Jangan bina kumpulan umum yang menganggap sambungan yang disahkan untuk identiti berbeza boleh saling ditukar. Bagi perkhidmatan berbilang hop atau perantara, semak sama ada susunan sambungan yang diperlukan dikekalkan.

Jika sokongan dan pemilihan kaedah betul, siasat format akaun, dasar domain serta log pengesahan pelayan yang telah dibuang data sensitif. Tamat masa sebelum sebarang cabaran masih masalah kebolehcapaian, bukan bukti kata laluan NTLM salah.

Jejak terperinci boleh mengandungi token pengesahan dan nama dalaman. Gunakannya secara setempat dan buang data sensitif sebelum berkongsi; laporan ralat awam tidak memerlukan pertukaran token mentah.

Artikel berkaitan