web-dev-qa-db-ja.com

DCOM認証がKerberosの使用に失敗し、NTLMにフォールバックします

ClassicASPで記述されたWebサービスがあります。このWebサービスでは、DCOMを介して別のサーバーにVirtualServer.Applicationオブジェクトを作成しようとします。これは、許可が拒否された場合に失敗します。ただし、同じリモートサーバー上の同じWebサービスでインスタンス化された別のコンポーネントがあり、問題なく作成されています。このコンポーネントは、カスタムインハウスコンポーネントです。

Webサービスは、WinHTTPを介して呼び出すスタンドアロンのEXEプログラムから呼び出されます。 WinHTTPがKerberosを使用してWebサービスに対して正常に認証していることが確認されています。 Webサービスに対して認証されたユーザーは、管理者ユーザーです。 EXEからWebサービスへの認証ステップは成功し、Kerberosを使用します。

リモートコンピューターのDCOMアクセス許可をDCOMCNFGで確認しました。デフォルトの制限により、管理者はローカルとリモートの両方のアクティベーション、ローカルとリモートの両方のアクセス、およびローカルとリモートの両方の起動が可能になります。デフォルトのコンポーネント権限でも同じことが許可されています。これは確認済みです。作業コンポーネントの個々のコンポーネントの権限はデフォルトに設定されています。 VirtualServer.Applicationコンポーネントの個々のコンポーネントのアクセス許可もデフォルトに設定されています。これらの設定に基づいて、Webサービスはリモートコンピューター上のコンポーネントをインスタンス化してアクセスできる必要があります。

両方のテストの実行中にWiresharkトレースを設定すると、1つは動作コンポーネントを使用し、もう1つはVirtualServer.Applicationコンポーネントを使用して、興味深い動作を示します。 Webサービスが動作中のカスタムコンポーネントをインスタンス化しているとき、RPCSSエンドポイントマッパーへのネットワーク上の要求が最初にTCP接続シーケンスを実行するのを見ることができます。次に、バインド要求を実行するのを見ることができます。適切なセキュリティパッケージ（この場合はkerberos）。動作中のDCOMコンポーネントのエンドポイントを取得した後、Kerberosを介して再度認証するDCOMエンドポイントに接続し、インスタンス化と通信に成功します。

失敗したVirtualServer.Applicationコンポーネントで、Kerberosを使用したバインド要求がRPCCエンドポーリングマッパーに正常に送信されることを再度確認します。ただし、仮想サーバープロセスでエンドポイントに接続しようとすると、NTLMでの認証のみを試みるため接続に失敗し、最終的にはWebサービスがNTLMハッシュを実行するための資格情報にアクセスできないために失敗します。

NTLM経由で認証を試みているのはなぜですか？

追加情報：

  • 両方のコンポーネントは、DCOMを介して同じサーバー上で実行されます
  • 両方のコンポーネントは、サーバー上でローカルシステムとして実行されます
  • どちらのコンポーネントもWin32サービスコンポーネントです
  • 両方のコンポーネントには、まったく同じ起動/アクセス/アクティブ化DCOMアクセス許可があります
  • 両方のWin32サービスはローカルシステムとして実行するように設定されています
  • 拒否されたアクセス許可は、私が知る限り、アクセス許可の問題ではなく、認証の問題です。 NTLM認証がKerberos委任の代わりにNULLユーザー名で使用されているため、アクセス許可が拒否されました
  • 制約付き委任は、Webサービスをホストしているサーバーにセットアップされます。
  • Webサービスをホストしているサーバーは、rpcss/dcom-server-nameに委任できます。
  • Webサービスをホストしているサーバーは、vssvc/dcom-server-nameに委任できます。
  • Dcomサーバーはrpcss/webservice-serverに委任できます
  • Dcomサーバーに登録されているSPNには、rpcss/dcom-server-nameとvssvc/dcom-server-name、およびHost/dcom-server-nameに関連するSPNが含まれます。
  • Webservice-serverに登録されているSPNには、rpcss/webservice-serverおよびHost/webservice-server関連のSPNが含まれます。

リモートサーバー上にVirtualServer.Applicationオブジェクトを作成しようとすると、NTLM認証にフォールバックして失敗し、アクセス許可が拒否される理由を誰かが知っていますか？

追加情報：次のコードがWebサービスのコンテキストで、テスト専用の開発されたばかりのCOMコンポーネントを介して直接実行されると、アクセスが拒否された指定の行で失敗します。

COSERVERINFO csi;
csi.dwReserved1=0;
csi.pwszName=L"terahnee.rivin.net";
csi.pAuthInfo=NULL;
csi.dwReserved2=NULL;
hr=CoGetClassObject(CLSID_VirtualServer, CLSCTX_ALL, &csi, IID_IClassFactory, (void **) &pClsFact);
if(FAILED( hr )) goto error1;

// Fails here with HRESULT_FROM_WIN32(ERROR_ACCESS_DENIED)
hr=pClsFact->CreateInstance(NULL, IID_IUnknown, (void **) &pUnk);
if(FAILED( hr )) goto error2;

また、Wiresharkトレースで、サービスプロセスコンポーネントに接続しようとしていることにも気づきましたリクエストのみ NTLMSSP認証であり、Kerberosを使用することすら試みていません。これは、何らかの理由でWebサービスがKerberosを使用できないと考えていることを示しています...

authenticationkerberosntlmdcomvirtualization
1
Asa Yeamans

NTLM認証のフォールバックは症状です。本当の問題は、Kerberosが失敗する理由です。

これは、取得された偽装レベルの典型的なケースでは、要求されたアクティビティを実行するには不十分であるように思われます。 Kerberosで委任を使用すると、偽装しているマシンまたはプロセスに「偽装」トークンがなく、代わりに「ID」などの下位トークンがあり、別のIDを使用してリソースにアクセスするためにKerberos認証を要求すると失敗します。

偽装トークンには次の4つのタイプがあります。

匿名
身元
なりすまし
委任

「偽装」により、偽装は、偽装を実行するプロセスが配置されているのと同じマシン上のリソースにアクセスできます。偽装を実行するプロセスが、偽装が実行されている場所とは異なるコンピューター上のリソースにアクセスしている場合は、「委任」トークンが必要です。これには通常、TCB特権が必要です（オペレーティングシステムの一部として機能します）。

TokenImpersonationLevel列挙
http://msdn.Microsoft.com/en-us/library/system.security.principal.tokenimpersonationlevel%28v=vs.80%29.aspx

Windows XP/Server 2003のDCOMのデフォルトの偽装レベルは、「ID」であることに注意してください。これは、プロセスが別のIDになりすましている間はリソースにアクセスできない可能性があることを意味します。マシン全体またはプロセスレベルのセキュリティ構成を試して、何が機能するかを確認することをお勧めします。一部のリソースに接続するには、暗号化を有効にする必要がある場合があります。一方のサービスをもう一方のサービスと同じように構成することは、アップルトゥアップルの比較ではない場合があります。

異なるオペレーティングシステム間の接続
http://msdn.Microsoft.com/en-us/library/aa389284%28v=vs.85%29.aspx

DCOMCNFGを使用したシステム全体のセキュリティの設定
http://msdn.Microsoft.com/en-us/library/ms680051%28v=vs.85%29.aspx

C++を使用したデフォルトのプロセスセキュリティレベルの設定
http://msdn.Microsoft.com/en-us/library/aa393617%28v=vs.85%29.aspx

1
Greg Askew