2

WCF (Windows Communication Foundation) クライアントとサービス アプリケーションがあります。Kerberos で Windows 認証を使用しています。

問題は、サービスが多数のアカウント (ネットワーク サービス、特定のユーザー アカウントなど、IT グループによって異なります) のいずれかで実行される可能性があることです。このアカウントは毎日変更される可能性は低いですが、場合によっては (数か月ごとに) 変更される可能性があります。さらに、このクライアント/サービス パッケージを複数のグループに提供します。各グループは、サービスを実行するために使用する独自のアカウントを持っている場合があります (これは、1 つのチームに対してカスタム ソリューションを実行できないことをお知らせするためのものです)。 )。

上記の段落が問題である理由は、サービスが 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-vs-environment-machinename.html

これにより、IT 部門がサービスを実行するアカウントを変更する状況に対処することが難しくなっているようです。ある場合、これを処理するためのパターンは何ですか? 他の人々はこれをどのように処理しましたか? 私が考えた 1 つの解決策は、サービスのユーザー アカウントが変更されたときに管理者がメールを送信することです。これには、クライアントまたは構成ファイルを更新するアプリケーションへの Web リンクが含まれているため、クライアントは新しいユーザー アカウントを参照します。 . しかし、それはハックのようです。

確かに、これは移動するエンドポイントの URI によく似ています。例外として、URI の変更はクライアントが知っておくべきことであるが、サービスが実行されているアカウントの変更は、クライアントに対して比較的透過的であるべきものであるという人々に代わって、より多くの期待があると思います。

ところで、これが重要な場合は、IIS 7.0 でホストする必要があります。

4

2 に答える 2

8

NegotiateServiceCredentialプロパティを True に設定して、バインディングでハードコールドKerberosの代わりにSPNegoを使用できると思います。が true に設定されている場合、クライアントは SPN を指定する必要がなく、マシン以外のアカウントを実行しているサーバーに接続できます。

クライアントは特定の SPN を要求しなくなったため、ハイジャックされたサービスの偽装者に接続されているかどうかを検出できなくなりましたが、セキュリティについて本当に偏執的でない限り、これは通常小さな懸念事項です。

また、余談ですが、WCF がアカウント名を SPN として要求するという事実は、基本的に脳のおならです。クライアントは、DsMakeSpn API を使用して、サービス名、ホスト、およびポートから SPN を構成する必要があります。サーバーは、起動時にその SPN を登録するか、管理者にsetspn.exeを使用して登録させる必要があります。これは、Kerberos/ActiveDirecotry/Windows 環境のすべての従来の (適切に動作する) サービスで行われている方法です。

アップデート

2 番目に、クライアントがアカウント名を SPN として使用する必要があることを指定するものは何も表示されません。基本的に悪い習慣を推奨する適切な方法を文書化するのではなく、文書化の見落としのように見えます。または、MSDNバインディング仕様が使用するSPNについて実際に何を述べているのかを掘り下げなかったので、フォーラムのアドバイスだけが悪いかもしれません...

テストに便利な WCF 環境はありませんが、適切な SPN を要求するようにクライアントを構成YourService/server:portし、サーバー側で同じ SPN を登録することもできます。管理者に任せて手動で行うか、起動時にサービスから自動的に行い、シャットダウン時に登録を解除します。これを行う適切な方法は、管理者に任せることですが、実際にはほとんどのサービスが SPN 自体を登録することは非常に面倒であり、おそらくこの方法に従うこともできます。SPN を登録するために、サービスはDsWriteAccountSpnを呼び出します。書き込みは AD に伝達され、AD サーバー間でレプリケートされる必要があります。これが、サービスに SPN の自動登録/自動登録解除をさせることが疑わしい慣行である理由の少なくとも 1 つです。

SPN の不思議な世界と、SPN が日常生活をどのように台無しにするかについて詳しく知りたい場合は、How Service Publication and Service Principal Names Work を参照してください。

アップデート

好きな SPN を使用できると確信しています。そこにあるほとんどの例では、アカウント名を SPN の代わりに「UPN」(ユーザー プリンシパル名) として使用していますが、これはサンプルの便宜のためです。真の SPN を使用すると、ユーザー アカウントで SPN を設定する管理上の問題が発生するためです (再び、なぜ管理者がそれを行うべきなのか...)。Overriding the Identity of a Service for Authenticationから、関連する強調:

既定では、サービスが Windows 資格情報を使用するように構成されている場合、<userPrincipalName>または <servicePrincipalName>要素を含む要素が WSDL に生成されます。サービスが LocalSystem、LocalService、または NetworkService アカウントで実行されている場合、サービス プリンシパル名 (SPN) は既定で の形式で生成されます。これはhost/<hostname>、これらのアカウントがコンピューターの SPN データにアクセスできるためです。サービスが別のアカウントで実行されている場合、Windows Communication Foundation (WCF) は の形式で UPN を生成し <username>@<domainName>ます。これは、Kerberos 認証では、サービスを認証するために UPN または SPN をクライアントに提供する必要があるために発生します。

Setspn.exe ツールを使用して、追加の SPN をドメイン内のサービスのアカウントに登録することもできます。その後、SPN をサービスの ID として使用できます。ツールをダウンロードするには、Windows 2000 リソース キット ツール : Setspn.exe を参照してください。このツールの詳細については、「Setspn の概要」を参照してください。

于 2009-07-19T02:12:24.760 に答える
2

プロパティを に設定NegotiateServiceCredentialします。EstablishSecurityContextFalse

于 2010-02-03T20:11:51.820 に答える