Jak skłonić ntlm_auth do mówienia protokołem pomocnika Squida
Udana jednorazowa weryfikacja hasła nie dowodzi, że ntlm_auth uruchamia trwały protokół oczekiwany przez Squida.
W przypadku uwierzytelniania NTLM w Squidzie sprawdź, czy efektywne polecenie pomocnika wybiera --helper-protocol=squid-2.5-ntlmssp. Historyczny numer nazywa rozmowę pomocnika; nie oznacza polecenia instalacji Squida 2.5.
Jednorazowa weryfikacja nazwy użytkownika i hasła przez ntlm_auth testuje inny tryb. Jej sukces nie dowodzi, że Squid uruchomił pomocnika zdolnego utrzymać wymaganą wymianę.
Przeczytaj pełne polecenie w załadowanej konfiguracji auth_param i zachowaj jego argumenty, badając komunikat startowy lub wyjściowy procesu potomnego. Następnie sprawdź rozmowę: Squid wysyła komunikaty protokołu na standardowe wejście i oczekuje odpowiedzi protokołu na standardowym wyjściu. Baner powitalny lub wydruk debugowania opakowania w tym miejscu może zepsuć integrację, zanim dane logowania zostaną ocenione. Diagnostykę wysyłaj na standardowe wyjście błędów.
Sprawdź konto uruchamiające pomocnika oddzielnie od użytkownika, który jest uwierzytelniany. Dostęp do uprzywilejowanych mechanizmów uwierzytelniania Samby to kwestia lokalnych uprawnień usługi. Zmiana hasła użytkownika nie może go przyznać.
Gdy pomocnik pozostanie dostępny i mówi wybranym protokołem, przejdź do przynależności do domeny, akceptacji konta i negocjacji przeglądarki. Wcześniejsze zwiększenie liczby pomocników jedynie uruchamia więcej kopii tej samej niesprawnej integracji.