これが可能になるとは思いません。
問題は、名前付きパイプの作成時に提供されるセキュリティ記述子で整合性ラベルを指定する必要があることです。標準の NetNamedPipeBinding では、内部 WCF クラスのCreateNamedPipeプライベートメソッド内で呼び出しが行われます。パイプの初期セキュリティ記述子を指定する方法を変更する方法がわかりません。CreatePipe()System.ServiceModel.Channels.PipeConnectionListener
達成する必要があることの概要については、この質問と回答を参照してください。
カスタムの名前付きパイプ トランスポート バインド要素をゼロから作成することが、現時点でこれを回避する唯一の方法のように思われます。失敗した場合は、Microsoft が将来のバージョンの WCF でいくつかの有効化機能を追加するのを待つ必要があります。Microsoft Connect にアクセスできる場合は、この機能を要求している他のユーザーにあなたの声を追加できます。
編集：私は悲観的すぎました。私は今、これを行う方法を見つけました。
重要なのは、パイプの作成時にセキュリティ記述子で整合性ラベルを必ずしも指定する必要がないことが判明したことですが、リスナーが開かれたときに CreateNamedPipe から返されたハンドルを使用して SACL を変更する必要があります。パイプへの最初のサーバー側ハンドル。他のハンドルを使用すると、整合性ラベルを追加しようとすると常に失敗します。これは、dwOpenModeフラグ パラメータ toCreateNamedPipeがビットの 1 つの使用を と の両方を意味するようにオーバーロードするためFILE_FLAG_FIRST_PIPE_INSTANCEですWRITE_OWNER。整合性ラベルを追加するには後者のアクセス許可が必要ですが、前者が存在すると、最初のパイプ インスタンス以外で呼び出しが失敗します。
最初のパイプ ハンドルを取得するのは簡単なことではありません。WCF はSystem.ServiceModel.Channels.PipeConnectionListener.PendingAccept、パイプ接続リスナーによって維持されるリストに格納された type のインスタンスでそれを取り除きます。接続リスナーは、チャネル リスナーと同じではありません (これは、BuildChannelListener<>バインディング要素のメソッド)、そして到達するのははるかに困難です。これには、リフレクションを使用して、エンドポイントの接続リスナーへの参照を保持するエンドポイントの TransportManager を特定し、パイプ接続リスナーが見つかるまで接続リスナーのチェーン (トレースなどの構成によって異なります) をたどる英雄的な作業が含まれます。 . 運が良ければ、リスナーの保留中の受け入れリストで最初のパイプ ハンドルを見つけることができます (ただし、ここには競合状態があります。ハンドルを取得する前にクライアントが接続した場合、ハンドルは永久に失われます)。
ハンドルが使用可能になると、整合性を下げて、整合性の低いクライアントがサービスと通信できるようにするSetSecurityInfoには、ハンドルを呼び出して整合性ラベルを追加するだけです。
これについては、近日中にブログで詳細を説明する予定です。