Uwierzytelnianie proxy NTLM wymaga uzgodnienia, a nie tylko jednorazowego dołączenia nazwy użytkownika. Zanim zmienisz hasło konta, potwierdź, że proxy rzeczywiście oferuje NTLM i że plik wykonywalny curl go obsługuje.

curl --version

Sprawdź listę funkcji pliku, który wykonuje żądanie. Inna instalacja curl, obraz kontenera lub kompilacja systemu operacyjnego może obsługiwać inne uwierzytelnianie.

Wybierz metodę przeznaczoną dla proxy

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

Punkt końcowy, domena i nazwa użytkownika są przykładami. Użyj formatu podanego przez administratora. Bez hasła w argumencie curl może o nie zapytać, zamiast pozostawiać sekret w wyświetlanym poleceniu.

Początkowe wyzwanie uwierzytelniania może być częścią negocjacji. Odróżnij je od odrzucenia po zakończonym uzgodnieniu. Nie odpowiadaj na wyzwanie proxy opcją NTLM przeznaczoną dla serwera źródłowego.

Uwzględnij zachowanie połączeń w diagnozie

NTLM utrzymuje stan związany z połączeniem. Uzgodnienie musi przebiegać oczekiwaną ścieżką połączenia; wielokrotna wymiana połączeń między jego etapami może uniemożliwić zakończenie.

W aplikacji korzystającej z libcurl pozostaw bibliotece zarządzanie uwierzytelnianiem i ponownym użyciem połączeń. Nie twórz ogólnej puli, która traktuje jako zamienne połączenia uwierzytelnione dla różnych tożsamości. W usłudze z wieloma przeskokami lub pośrednikami sprawdź, czy zachowuje wymagany układ połączeń.

Jeśli obsługa i wybór metody są poprawne, zbadaj format konta, zasady domeny i dzienniki uwierzytelniania serwera pozbawione danych wrażliwych. Przekroczenie czasu przed jakimkolwiek wyzwaniem pozostaje problemem osiągalności, a nie dowodem błędnego hasła NTLM.

Szczegółowe ślady mogą zawierać tokeny uwierzytelniania i nazwy wewnętrzne. Używaj ich lokalnie i usuń dane wrażliwe przed udostępnieniem; publiczne zgłoszenie błędu nie wymaga surowej wymiany tokenów.

Powiązane artykuły