1

IIS で netMsmqBinding を使用して WCF サービスを実行しています。メッセージの暗号化と署名に kerberos を使用する「Windows」クライアント資格情報タイプで「メッセージ」セキュリティを使用するように構成されています。サービス コントラクトは ProtectionLevel.EncryptAndSign を適用します。クライアントからサービスへのトランザクションが使用されていることに注意することが重要な場合があります。

サービスが稼働しているとき、通信は問題なく機能します。ただし、遅延メッセージの耐久性をテストするため、またはサービスに到達できない場合に、IIS でサービスのアプリケーション プールを一時的に無効にしました。次に、クライアントからメッセージを送信します。クライアント マシンの発信キューを離れ、サーバーのプライベート キューに転送されます。.NET MSMQ リスナーはメッセージを取得し、WCF サービス メソッドを呼び出そうとしますが、期待どおりに失敗します。約 10 分後、アプリケーション プールを再度有効にします。サービス トレース ログに、次の例外が記録されます。

System.ServiceModel.Security.MessageSecurityException:
"Message security verification failed."
  System.IdentityModel.Tokens.SecurityTokenException:
  "The AcceptSecurityContext failed."
    System.ComponentModel.Win32Exception:
    "The clocks on the client and server machines are skewed"

また、サーバー上でメッセージ キュー サービスをオフラインにして、同じシナリオを試しました。結果は同じです。

私の推測では、クライアントはメッセージを暗号化するために kerberos チケットを取得しますが、メッセージは (少なくとも) 10 分後に WCF サービスによって復号化されるため、クロック スキューが検出されます。もちろん、クライアントとサーバーの両方で時計を手動で確認しましたが、それらは同じです。

クライアント構成:

<bindings>
  ...
  <netMsmqBinding>
    <binding>
      <security mode="Message">
        <message clientCredentialType="Windows" />
      </security>
    </binding>
  </netMsmqBinding>
</bindings>

<client>
  ...
  <endpoint address="net.msmq://host/private/service/service.svc"
            binding="netMsmqBinding"
            contract="Namespace.Contract" />
</client>

サーバー構成:

<bindings>
  ...
  <netMsmqBinding>
    <binding receiveErrorHandling="Reject">
      <security mode="Message">
        <message clientCredentialType="Windows" />
      </security>
    </binding>
  </netMsmqBinding>
</bindings>

<serviceActivations>
  ...
  <add relativeAddress="service.svc"
       service="Namespace.Contract"
       factory="Ninject.Extensions.Wcf.NinjectServiceHostFactory"/>
</serviceActivations>

<services>
  ...
  <service name="Namespace.Contract">
    <endpoint address="net.msmq://localhost/private/service/service.svc"
              binding="netMsmqBinding"
              contract="Namespace.IContract" />
  </service>
</services>

これはどのように機能するはずですか？私は何が欠けていますか？

編集：

このページには、「キューに入れられた通信に Kerberos プロトコルを使用する際の問題は、キー配布センター (KDC) が配布するクライアント ID を含むチケットの寿命が比較的短いことです。」それは役に立ちます。

kerberos メッセージ セキュリティの優れた点は、ほとんどそのままで機能することです。

編集2：

両方のサーバーで時間を確認したところ、両方のクライアントでスキューが約 0.1 秒でした (DC01 はドメイン コントローラー)。

C:\>w32tm /stripchart /computer:DC01 /samples:5
Tracking DC01 [10.1.1.2:123].
Collecting 5 samples.
The current time is 04-11-2015 16:49:17.
16:49:17 d:+00.0000000s o:-00.1020864s  [                           *                           ]
16:49:19 d:+00.0000000s o:-00.1020897s  [                           *                           ]
16:49:21 d:+00.0000000s o:-00.1020896s  [                           *                           ]
16:49:23 d:+00.0000000s o:-00.1020952s  [                           *                           ]
16:49:25 d:+00.0000000s o:-00.1021011s  [                           *                           ]

そしてサーバー：

C:\>w32tm /stripchart /computer:DC01 /samples:5
Tracking DC01 [10.1.1.2:123].
Collecting 5 samples.
The current time is 04-11-2015 16:49:17.
16:49:17 d:+00.0000000s o:-00.1171919s  [                           *                           ]
16:49:19 d:+00.0000000s o:-00.1360460s  [                           *                           ]
16:49:21 d:+00.0000000s o:-00.1237094s  [                           *                           ]
16:49:23 d:+00.0000000s o:-00.1269640s  [                           *                           ]
16:49:25 d:+00.0000000s o:-00.1302236s  [                           *                           ]
4

1 に答える 1