서버에서 사용자 계정을 사용하는 WCF Kerberos 클라이언트의 패턴

Question

우리는 WCF (Windows Communication Foundation) 클라이언트 및 서비스 응용 프로그램을 보유하고 있습니다. Kerberos와 함께 Windows 인증을 사용하고 있습니다.

문제는 서비스가 여러 계정 중 하나 (네트워크 서비스, 아마도 특정 사용자 계정 - IT 그룹에 따라 다름) 중 하나에서 실행될 수 있다는 것입니다. 이 계정은 매일 바뀔 가능성이 없지만 경우에 따라 (아마도 몇 개월마다) 변경 될 수 있습니다. 또한이 클라이언트/서비스 패키지를 여러 그룹에 제공하며 각 그룹에는 서비스를 실행하는 데 사용하는 자체 계정이있을 수 있습니다 (이는 단일 팀에 대해 사용자 지정 솔루션을 사용할 수 없음을 알려주는 것입니다.)).

위의 단락이 문제 인 이유는 서비스가 SYSTEM 또는 NETWORK SERVICE 계정 (예 : 사용자 계정)에서 실행되고 있지 않은 경우 클라이언트가 ID의 사용자 계정 이름을 지정해야한다는 것입니다. 끝점. 이 제한에 대한 자세한 내용은

은 다음을 참조하십시오 http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/feb6bc31-9a4b-4f8d-a887-ef6d2c7abe41 및 http://www.vistax64.com/indigo/146204-using-localhost-v-s-environment-machinename.html

지금이 겉보기 서비스가 실행되는 IT 부서가 계정을 변경하는 상황에 대처하기가 힘들 수 있습니다. 이 패턴을 처리하는 패턴은 무엇입니까? 다른 사람들이 이것을 어떻게 처리 했습니까? 내가 생각한 한 가지 해결책은 서비스의 사용자 계정이 변경되었을 때 관리자가 이메일을 보내고 클라이언트 또는 구성 파일을 업데이트하는 응용 프로그램에 웹 링크가있어서 클라이언트가 새 사용자 계정을 참조하도록합니다 . 그러나 그것은 hackish 것처럼 보인다.

틀림없이 이것은 이동하는 끝점의 URI와 비슷합니다. 나는 URI를 변경하는 것은 클라이언트가 알아야 할 것이지만, 서비스가 실행중인 계정을 변경하는 것은 클라이언트에게 상대적으로 투명해야한다는 것을 사람들이 대신하여 훨씬 더 기대하고 있다고 생각합니다.

현재로서는 IIS 7.0에서 호스팅해야합니다.

Answer 1

NegotiateServiceCredential 속성을 true로 설정하면 바인딩이 Kerberos이 아닌 SPNego이되도록 설정할 수 있다고 생각합니다. when을 true로 설정하면 클라이언트는 SPN을 지정할 필요가 없으며 컴퓨터가 아닌 계정을 실행하는 서버에 연결할 수 있습니다.

클라이언트는 더 이상 특정 SPN을 요청하지 않으므로 서비스의 도용당한 가장 가해기에 연결되어 있는지 더 이상 감지 할 수 없지만 실제로 보안에 대한 편집증이없는 경우에는 대개 사소한 문제입니다.

또한 WCF가 SPN으로 계정 이름을 요청한다는 사실은 기본적으로 두뇌 방귀입니다. 클라이언트는 DsMakeSpn API를 사용하여 서비스 이름, 호스트 및 포트에서 SPN을 작성해야합니다. 서버는 시작할 때 해당 SPN을 등록하거나 관리자가 setspn.exe을 사용하여 SPN을 등록하도록합니다. 이것은 Kerberos/ActiveDirecotry/Windows 환경의 전통적인 (잘 작동하는) 모든 서비스에 의해 수행되는 방식입니다.

업데이트 초에

하지만 나는 클라이언트 가 SPN로 계정 이름을 사용해야합니다 지정 아무것도 표시되지 않습니다. 기본적으로 나쁜 습관을 권장하는 적절한 방법을 문서화하는 것이 아니라 문서 감시와 비슷하게 보입니다. 아니면 MSDN 바인딩 사양이 SPN에 대해 실제로 말하는 것을 보려고하지 않았기 때문에 포럼의 조언이 좋지 않을 수도 있습니다.

테스트 할 수있는 WCF 환경이 없지만 YourService/server:port과 같은 올바른 SPN을 요청하도록 클라이언트를 구성 할 수 있으며 서버 측에서도 동일한 SPN을 등록 할 수 있습니다. 관리자에게 남겨진 운동으로 수동으로 시작하거나 시작시 서비스에서 자동으로 종료하고 종료시 등록을 취소합니다. 올바른 방법은 관리자가 수행하도록하는 것이지만 실제로는 대부분의 서비스가 SPN을 스스로 등록하는 것과 같은 고통이므로이 방법을 따를 수도 있습니다. SPN을 등록하려면 DsWriteAccountSpn으로 전화하십시오. 쓰기가 AD에 전파되어 AD 서버간에 복제되어야합니다. SPN을 자동 등록/자동 등록 취소해야하는 이유 중 하나가 의심스러운 사례입니다.

SPN의 wonderfool 세계와 그들이 하루를 어떻게 망가 뜨릴 수 있는지에 대한 자세한 내용을 보려면 How Service Publication and Service Principal Names Work을 읽어보십시오.

업데이트

난 당신이 원하는 SPN을 사용할 수 있습니다 확신 해요. 대부분의 exmaples은 SPN 대신 'UPN'(User Principal Name)으로 계정 이름을 사용하지만 이는 실제 SPN을 사용하면 사용자 계정으로 SPN을 설정하는 관리 문제가 발생하므로 샘플의 편의를 위해 사용됩니다 왜 관리자가해야 하는가 ...). Overriding the Identity of a Service for Authentication에서 관련 강조 :

기본적으로

, 서비스가 Windows 자격 증명을 사용하도록 구성 이다, 요소가 는 <userPrincipalName> 또는 <servicePrincipalName> 요소가 WSDL에서 생성 입니다 포함되어 있음. 서비스 가 로컬 시스템, LocalService를 또는 NetworkService와 계정에서 실행중인 경우 서비스 사용자 이름 (SPN)이 host/<hostname> 그 때문에 계정의 형태로 기본적으로 생성되는 컴퓨터의 SPN 데이터에 액세스 할 수 있습니다. 서비스가 다른 계정에서 을 실행하는 경우 Windows WCF (Communication Foundation) 은 <username>@<domainName>의 형식으로 UPN을 생성합니다. Kerberos 인증 에 서비스를 인증하기 위해 클라이언트에 UPN 또는 SPN을 제공하면 클라이언트에 이 제공되어야하므로이 경우 이 발생합니다.

Setspn.exe 도구 을 사용하여 도메인에 서비스 계정이있는 추가 SPN을 등록 할 수도 있습니다. 다음 의 ID로 SPN을 사용할 수 있습니다. 도구를 다운로드하려면 Windows 2000 Resource Kit Tool : Setspn.exe를 참조하십시오. 도구 에 대한 자세한 내용은 Setspn Overview를 참조하십시오.

Answer 2

설정 NegotiateServiceCredential 및 False에 EstablishSecurityContext 속성.