WCF의 위임이 작동하지 않습니다. - 첫 번째 홉은 NTLM입니까?

Question

저는 더블 홉 시나리오에서 위임을 요구하는 프로젝트 작업을하고 있습니다. NetBcp 바인딩을 사용하는 WCF 서비스에 연결하여 다른 서버의 SQL 데이터베이스에 연결하는 데스크톱 클라이언트가 있습니다. 우리의 목표는 사용자의 자격 증명을 사용하여 SQL 데이터베이스에 액세스하는 것입니다.

WCF 서비스 및 SQL 데이터베이스 모두

위임은 SQL 데이터베이스를 사용할 수있는 동일한 도메인 사용자에서 실행된다. 지침 here을 준수했지만 아무런 성과가 없습니다.

로그에 기록 된 세부 정보 : SQL 데이터베이스에서 사용되는 로그인은 WCF 서비스가 실행중인 사용자로 표시되며 Kerberos를 사용합니다. WCF 서버에서 사용되는 로그인은 클라이언트의 사용자로 나타나지만 NTLM을 사용합니다. [OperationBehavior(Impersonation = ImpersonationOption.Allowed)] 또는 using (ServiceSecurityContext.Current.WindowsIdentity.Impersonate())을 사용하면 명령이 클라이언트로 WCF 서버에서 실행됩니다. 이것은 내가 가장이 잘 작동하고 있다고 믿게합니다.

따라서 첫 번째 홉이 NTLM으로 되돌아 갈 수있는 원인은 무엇입니까? 우리는 그것이 SPN 문제라고 생각하지만 WCF 서비스와 SQL 서비스의 SPN을 공유 도메인 사용자에게 등록했습니다. 또한 위에 나열된 지침에 따라 도메인 사용자 위임에 대해 SQL 서비스를 신뢰할 수있는 것으로 설정했습니다.

우리는 SPN을 설정 WCF 서비스에 EndpointIdentity.CreateSpnIdentity를 사용했습니다, 이것은 우리가 도메인 사용자에 등록 한 SPN입니다.

제안 사항? 미리 감사드립니다!

편집 : 우리는 클라이언트에서 EndpointIdentity.CreateSpnIdentity을 사용하지 않았습니다. 이 값을 설정 한 후 "target principle name is incorrect"내부 예외가있는 "SSPI 호출 실패"오류가 나타납니다. 그러나 클라이언트와 서버에서 설정 한 SPN이 일치하며 둘 다 서비스의 호스트 이름과 일치합니다. 클라이언트와 서버 SPN을 완전히 다른 것으로 설정하거나 클라이언트의 지정된 SPN이 서버의 SPN과 일치하지 않으면 이전과 마찬가지로 인증이 NTLM으로 되돌아갑니다. Google은 오류에 대한 조사를 수행했지만 그 원인을 찾을 수 없습니다. 어떤 제안? NTLM 다시 떨어지고 우리가받을 때 오류를 "SSPI를 호출하지 못했습니다"-

우리는 또한 두 경우의 패킷 캡처를 수행했습니다. 두 경우 모두 NTLM이 언급 될 때까지 유사한 패킷이 송수신됩니다. 다른 한편으로, "TURN CHANNEL"패킷이 클라이언트에서 서버로 전송됩니다. 이 패킷에는 NTLM이 언급되고 사용자 이름과 컴퓨터 이름이 전송되거나 "튠 (TURN CHANNEL)"패킷이 전송 될 때까지 서버의 IP 주소를 제외하고는 사람이 읽을 수있는 것이 없습니다. 호스트 이름. 사람이 읽을 수있는 오류 코드 또는 오류 메시지는 나타나지 않습니다. 패킷에서 무엇을 찾아야하는지에 대한 제안이 있습니까?

Answer 1

클라이언트가 서버의 IP 주소를 사용하여 연결을 생성하는 중 오류가 발견되었습니다. IP를 완전한 도메인 이름으로 전환 한 후 첫 번째 홉은 Kerberos를 사용하여 일관성있게 인증합니다.

IP 주소는 두 SPN에서 사용한 것과 같은 문자열로 처리되지만 클라이언트가 연결 문자열이 다른 검사를 수행하기 전에 슬래시 뒤에 오는 SPN 부분과 일치하는지 확인한다고 가정합니다.

우리는 아무 문제가 없었다만큼 SPN 각각 컴퓨터 또는 사용자에게 등록으로 네트워크 서비스 및 우리의 도메인 사용자, 모두를 사용하여 우리의 결과를 테스트했다.

이 답변을 사용하면 다른 사람들에게 시간과 번거 로움을 덜어주기를 바랍니다.

추가 참고 :이 모든 연결에 대해 Kerberos 인증을 사용할 수 있지만, 우리는 나중에 우리의 상황에서 불필요한 것을 발견했다. 데이터베이스에 연결하는 부분이 블록을 사용하는 가장 (impersonation using 블록)에 있지 않아 테이블 읽기가 실패했습니다. 이후 모든 위임 및 SPN 관련 코드가 제거되었으며 데이터베이스 연결이 계속 올바르게 작동했습니다. 첫 번째 홉은 NTLM을 사용하고 있습니다. 우리의 연결은 Kerberos와 위임을 필요로하는 이중 홉 시나리오로 묘사 된 것과 똑같기 때문에 SQL 서버에서 자격 증명이 어떻게 사용되는지 정확히 알 수는 없지만 작동하는 것과 논쟁하기는 어렵습니다. 나는 this document에 위임 아래에있는 메모와 함께 할 수있는 뭔가가 의심 :

클라이언트가 백 엔드에 Windows 계정에 해당하는 사용자 이름과 암호를 사용하여 프런트 엔드 서비스에 인증 서비스에서 프런트 엔드 서비스는 클라이언트의 사용자 이름과 암호를 다시 사용하여 백 엔드 서비스에 대해 인증 할 수 있습니다. 백엔드 서비스에 사용자 이름과 암호를 전달하면 백엔드 서비스가 가장을 수행 할 수 있지만 Kerberos는 사용되지 않으므로 위임을 구성하지 않기 때문에 특히 강력한 ID 흐름 유형입니다. 위임시 Active Directory 제어는 사용자 이름 및 암호 인증에 적용되지 않습니다.

다른 사람이 그 이유에 대해 제안 할만한 의견이 있으면 저도 들었습니다. 그러나 나는 다른 질문을할만한 가치가 있다고 생각하지 않는다.