Lokalni pomocnicy proxy NTLM: dostęp klienta a logowanie do serwera nadrzędnego

Twoja aplikacja łączy się z proxy na własnym komputerze. Ten pomocnik uwierzytelnia się następnie w proxy firmy. Aplikacja niekoniecznie sama wykonuje wymianę uwierzytelnienia firmy.

application → local helper → company proxy → destination

Pomocnik taki jak CNTLM ma konfigurację konta i proxy nadrzędnego. Jego lokalny nasłuch ma odrębną granicę osiągalności i dostępu. Hasło wpisane w przeglądarce wobec innego punktu końcowego nie konfiguruje automatycznie żadnego z nich.

Ustal, który etap zawiódł

Najpierw potwierdź, że aplikacja wybrała rzeczywisty nasłuch i protokół pomocnika. Błąd przed dotarciem do tego nasłuchu nie jest awarią NTLM. Następnie sprawdź, czy pomocnik dotarł do skonfigurowanego rodzica i czy rodzic zaakceptował jego tożsamość.

Kod 407 zwracany na tej trasie wymaga przypisania. Powiąż transakcję lokalną z zredagowaną diagnostyką pomocnika, zamiast zakładać, że widoczny status wskazuje konto, które aplikacja ma wysłać.

Stare przykłady czasem dodają nagłówek keep-alive i zgłaszają sukces. Trwałość połączenia może mieć znaczenie w uwierzytelnianiu zorientowanym na połączenie, ale ta obserwacja nie dowodzi, że każda nieudana konfiguracja pomocnika wymaga tego samego nagłówka. Wybór punktu końcowego, obsługiwana metoda, konto i czas życia połączenia pozostają odrębnymi danymi wejściowymi.

Nasłuch to prawdziwa usługa

Loopback trzyma nasłuch poza otaczającą siecią; nie rozróżnia wszystkich procesów ani użytkowników na tym komputerze. Brama lub szersze powiązanie zmienia zbiór wywołujących, którzy potencjalnie mogą użyć tożsamości nadrzędnej pomocnika. Wprowadzaj tę zmianę świadomie.

Używaj zatwierdzonego układu z pomocnikiem, gdy aplikacja nie potrafi wykonać wymaganego schematu. Użytecznym wynikiem jest znana ścieżka ze znanym właścicielem konta, a nie niewyjaśniona dodatkowa usługa, która przypadkiem pozwala na jedno pobranie.