Xác thực proxy NTLM có quá trình bắt tay, không chỉ đính kèm tên người dùng một lần. Trước khi đổi mật khẩu tài khoản, hãy xác nhận proxy thực sự cung cấp NTLM và tệp thực thi curl hỗ trợ nó.

curl --version

Xem danh sách tính năng của đúng tệp thực thi gửi yêu cầu. Một bản cài curl khác, ảnh container hay bản dựng hệ điều hành có thể hỗ trợ xác thực khác.

Chọn phương thức dành riêng cho proxy

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

Điểm cuối, miền và tên người dùng là ví dụ. Dùng định dạng do quản trị viên cung cấp. Khi đối số không chứa mật khẩu, curl có thể hỏi thay vì để bí mật trong lệnh được hiển thị.

Thách thức xác thực ban đầu có thể là một phần của thương lượng. Phân biệt điều đó với việc bị từ chối sau khi bắt tay đã hoàn tất. Đừng dùng tùy chọn NTLM dành cho máy chủ gốc để trả lời thách thức của proxy.

Đưa hành vi kết nối vào chẩn đoán

Trạng thái của NTLM gắn với kết nối. Quá trình bắt tay phải đi theo đường kết nối dự kiến; thay kết nối liên tục giữa các giai đoạn có thể ngăn nó hoàn tất.

Với ứng dụng dùng libcurl, để thư viện quản lý xác thực và tái sử dụng kết nối. Đừng tạo nhóm chung coi các kết nối đã xác thực cho danh tính khác nhau là có thể hoán đổi. Với dịch vụ nhiều chặng hoặc trung gian, kiểm tra xem nó có giữ cách tổ chức kết nối cần thiết không.

Nếu hỗ trợ và lựa chọn phương thức đều đúng, hãy xem định dạng tài khoản, chính sách miền và nhật ký xác thực của máy chủ đã loại bỏ dữ liệu nhạy cảm. Hết thời gian chờ trước bất kỳ thách thức nào vẫn là vấn đề khả năng truy cập, không phải bằng chứng mật khẩu NTLM sai.

Dấu vết chi tiết có thể chứa token xác thực và tên nội bộ. Dùng chúng cục bộ và loại bỏ dữ liệu nhạy cảm trước khi chia sẻ; báo cáo lỗi công khai không cần nội dung trao đổi token thô.

Bài viết liên quan