6

他の場所で説明されているように、「net.pipe：// localhostでリッスンしているエンドポイントがありませんでした」というエラーが発生しますが、本当の答えが見つからないようです。

これは問題の優れた識別子です：http： //kennyw.com/indigo/102

WCFを使用する場合、Windows認証はSSPI-Negotiateを介して実行されます。これにより、ほとんどの場合、実際の認証メカニズムとしてKerberosが選択されます。ただし、SSPIに渡されるターゲットSPNがローカルコンピューターアカウント用の整形式SPN（例：host / [dns machine name]）の場合、NegotiateはNTLM（ループバック最適化）を使用し、アクセストークンにはネットワークSIDがありません（およびしたがって、NetNamedPipesで使用できます）。

しかし、それは問題を解決する方法を教えてくれません。プログラムでエンドポイントを作成しています。

var binding = new NetNamedPipeBinding();
binding.Security.Mode = NetNamedPipeSecurityMode.Transport;
binding.Security.Transport.ProtectionLevel = ProtectionLevel.EncryptAndSign;

var id = EndpointIdentity.CreateSpnIdentity("host/" + Environment.MachineName);
var endpointAddress = new EndpointAddress(new Uri(serviceClientUrl), id);

var client = new ServiceClient(binding, endpointAddress);

私の問題はCreateSpnIdentityにあると思いますが、どの値を使用すればよいかわかりません。

追加情報： より多くのコンテキストのためにこれについて詳しく説明します。Wcfサービスは、NetworkServiceアカウントで実行されているWindowsサービスとしてホストされています（ローカルシステムを試しました）。サービスは、デフォルトのNetNamedPipeBindingコンストラクターを使用して作成されます。

host.AddServiceEndpoint(typeof(IService), new NetNamedPipeBinding(), "ServiceName");

このサービスを使用するSharePointWebパーツを作成しました。キッカーは、SharePointサイトがフォームベースの認証に設定されている場合、またはWindows認証のURLでマシン名のみが使用されている場合、問題はないということです。Windows認証でURLに完全修飾マシン名が使用されている場合にのみ、上記のエラーが発生します。

これは、記事で説明されているNTLM Kerberosの問題に関係していると確信していますが、回避方法がわかりません。

4

2 に答える 2

3

問題はエンドポイントの構成ではなく、クライアント コードが実行されているセキュリティ コンテキストであるため、クライアント側でエンドポイント ID を設定しても役に立ちません。KennyW が説明しているように、マシンの完全なドメイン名を使用して SharePoint アプリケーションにアクセスすると、Web サーバー プロセスの偽装トークン (Windows 認証で SharePoint ユーザー ID を提供する) が Kerberos 経由で取得され、NETWORK USERS のメンバーシップが付与されます。グループ。マシン名だけを使用する場合、Kenny が参照する最適化により、NETWORK USERS グループにない NTLM 経由でログオン トークンが取得されるため、WCF がパイプと共有メモリ オブジェクトの両方に配置する ACL によってアクセスが拒否されることはありません。サーバーが実際のパイプ名を公開する場所。

このエラーThere was no endpoint listening at net.pipe://localhost...は、そのような名前付きパイプ エンドポイントでリッスンしている WCF サービスがないことを必ずしも意味するわけではありません。また、存在するものの、それを知るための十分なアクセス権がないことを意味する場合もあります (この場合はそうです)。リモートログオンしているからです。

于 2011-01-11T13:58:57.410 に答える
2

NamedPipe は、ハードニング後に裏側が痛くなりました: http://msdn.microsoft.com/en-us/library/bb757001.aspx同じマシンで通信する必要があるときに、実際に NamedPipe から TCP に変更しました。

これは、これがあなたの問題であることを意味するものではありません。あるアカウントで実行していて、別のアカウントで接続しようとすると、名前付きパイプがグローバルとして作成されなくなるため (LocalSys でない限り)、通常は失敗します。

私の提案は次のとおりです。

1) サービスからすべてのセキュリティを排除します。結局のところ、NamedPipe は同じマシン上で実行されるため、通常はセキュリティは必要ないと思います。2) 接続してみます。失敗した場合は、SysInternals ProcExplorer を使用して、どのオブジェクト プロセスが開始されたかを確認します。名前付きパイプがある場合、それは硬化です。

より多くの情報を提供していただければ、より多くのことをお手伝いできるはずです。

于 2010-09-16T18:07:51.970 に答える