다른 요청에서는 Kerberos가 되는데 한 프록시 요청만 비밀번호를 묻는 이유

여러 요청이 회사 프록시를 통해 Kerberos를 성공적으로 사용합니다. 그런데 한 요청만 비밀번호 입력을 요구합니다. keytab을 교체하기 전에 그 특정 요청이 어떤 인증 정책을 선택했는지 확인하십시오.

게이트웨이는 정책을 통해 영역과 지원 스킴을 선택할 수 있습니다. 같은 브라우저에서 같은 프록시에 도달하는 두 트랜잭션이 동일한 인증 요구 사항을 받아야 하는 것은 아닙니다.

다음 가상 추적을 생각해 보십시오.

첫 번째 성공한 교환은 선택된 한 경로가 작동함을 보여 줍니다. 두 번째 트랜잭션이 그 경로에 도달했음을 보여 주지는 않습니다. 자격 증명은 유효하지만 그 인증 메커니즘을 선택하는 규칙이 틀릴 수 있습니다.

선택된 규칙과 그 순서를 살펴보십시오

챌린지를 받은 요청의 대상과 시간을 게이트웨이의 정책 추적과 연관 지으십시오. 첫 번째 적용 가능한 규칙이 만든 영역, 스킴 선택, 인증 모드를 파악하십시오. 그 값을 같은 클라이언트의 성공한 요청과 비교하십시오.

IP와 연결된 ID에 기반한 정책도 연결에서 인증을 요구하는 정책과 다르게 동작할 수 있습니다. 새 핸드셰이크가 없다고 해서 같은 영역이 선택되었다고 가정하지 마십시오.

리소스가 의도하지 않은 예외에 빠졌다면 그 규칙이나 범위를 바로잡고 결과 추적을 검토하십시오. 허용되는 인증 방법을 모든 곳에서 넓히면 불일치를 숨길 수 있지만, 무관한 트래픽의 접근 동작을 바꿉니다.

의도한 영역이 선택되었는데 예상한 교환이 실패하면 계정과 Kerberos 증거로 넘어가십시오. 그때 티켓, 서비스 이름 또는 백엔드 진단이 관련됩니다.