로컬 NTLM 프록시 도우미: 클라이언트 접근과 업스트림 로그인

애플리케이션은 자기 컴퓨터의 프록시에 연결합니다. 그러면 그 도우미가 회사 프록시에 인증합니다. 애플리케이션이 회사의 인증 교환을 반드시 직접 수행하는 것은 아닙니다.

application → local helper → company proxy → destination

CNTLM 같은 도우미에는 업스트림 계정과 프록시 설정이 있습니다. 도우미의 로컬 리스너에는 별도의 도달성 및 접근 경계가 있습니다. 다른 엔드포인트에 입력한 브라우저 비밀번호가 둘 중 어느 것도 자동으로 설정하지 않습니다.

실패한 구간 파악하기

먼저 애플리케이션이 도우미의 실제 리스너와 프로토콜을 선택했는지 확인하세요. 그 리스너에 도달하기 전의 오류는 NTLM 실패가 아닙니다. 그다음 도우미가 설정된 상위에 도달했는지, 상위가 그 ID를 받아들였는지 살펴보세요.

이 경로에서 돌아온 407은 원인 배분이 필요합니다. 보이는 상태가 애플리케이션이 보내야 할 계정을 가리킨다고 가정하지 말고, 로컬 트랜잭션을 도우미의 편집된 진단 정보와 대조하세요.

오래된 예제는 때때로 keep-alive 헤더를 추가하고 성공을 보고합니다. 연결 지향 인증에서 지속성은 중요할 수 있지만, 그 관찰이 실패한 모든 도우미 설정에 같은 헤더가 필요하다는 것을 증명하지는 않습니다. 엔드포인트 선택, 지원되는 방식, 계정, 연결 수명은 여전히 별개의 입력입니다.

리스너는 실제 서비스입니다

루프백은 리스너를 주변 네트워크에서 떼어 놓지만, 그 컴퓨터의 모든 프로세스나 사용자를 구분하지는 않습니다. 게이트웨이나 더 넓은 바인딩은 도우미의 업스트림 ID를 사용할 수 있는 호출자 집합을 바꿉니다. 그 변경은 의도적으로 하세요.

애플리케이션이 요구되는 방식을 수행할 수 없을 때는 승인된 도우미 구성을 사용하세요. 유용한 결과는 계정 소유가 알려진 알려진 경로이지, 다운로드 하나가 우연히 동작하게 만드는 설명되지 않는 추가 서비스가 아닙니다.