DCOM認証とRPCベースの認証/認証との違いは何ですか？
2003 PKIのMSFTベストプラクティスの次の段落では、RPCと2003を介してWindows 2000authenticatedがauthenticates[〜＃〜] dcom [〜＃〜]を使用
Windows Server 2003、Enterprise Editionを実行しているCAは、要求者の認証にDCOMおよびKerberosの偽装を使用します。証明書が要求されると、クライアントトークンを、証明書テンプレートに設定されているアクセス制御リスト（ACL）と、CA自体のDCOM登録インターフェイスと比較します。 Windows 2000 Server CAは、DCOMの代わりにリモートプロシージャコール（RPC）を使用して、要求者を認証します。ユーザーが認証され、要求されたテンプレートへのアクセスを許可された後、ユーザーがテンプレートに対する適切な登録アクセス許可を持ち、CA構成が自動登録に設定されている場合、CAは直ちに要求を処理できます。
Q：認証と承認に関して、DCOMがRPCとどのように異なるかを誰かが説明できますか？
DCOM構成のいくつかの関連するスクリーンショット（RPCには同様のものはありません）：
ソフトウェア実装でRPCよりもDCOMを選択するのはなぜですか？ DCOMはRPCのスーパーセットですか、それとも別個のエンティティですか？
DCOM/RPC認証についても同様の質問がありました。数日間勉強して、結論を得ました：
- DCOM/RPCは複数の認証メカニズムをサポートしていると主張していますが、皮肉なことに、DCOM/RPC自体はインラインログインダイアログを提供していません（サーバーの共有フォルダーにアクセスしたときに表示されるような）。 DCOM/RPCクライアントインフラストラクチャは、認証設定を外部に保存する一般的な方法（Windows資格情報ストアなど）を提供していません。これは非常に不便です。
- クライアントユーザーがドメインユーザーとしてログインし、サーバーもドメイン内にある場合、またはクライアントユーザー/パスワードがサーバーのローカルアカウントデータベースでも有効な場合、デフォルトでIDが使用されます。
- DCOM/RPCがトランスポートとして名前付きパイプを使用する場合、これはSMB protocol（port 445）の上に構築されます）、クライアントは最初にコマンド "Net Use \\ SERVER/user：USER 「次にパスワードを入力」またはエクスプローラに\\ SERVERと入力してサーバーにログインします。それ以外の場合は、単に「アクセス拒否」します。
- DCOM/RCPがTCP transport（port 135））を使用する場合、クライアントはDCOMのCoGetClassObjectのCOAUTHINFOまたはRPCのRpcBindingSetAuthInfoのRPC_AUTH_IDENTITY_HANDLEにユーザー/パスワードを設定する必要があります。サーバー側では、ほとんどの場合、DCOMCNFGのデフォルトのACL設定により、最終的に「アクセス拒否」が発生します。
- DCOMコンポーネントの認証方法とACL設定は、DCOMCNFG外部ユーティリティによって、マシンレベルまたはコンポーネントレベルでいつでも制御できます。しかし、RPCコンポーネントはできません。代わりに、RPCコンポーネントの作成時にのみ定義できます。
- DCOMコンポーネントのACL設定は、DCOMCNFGユーティリティの[Set Limits]を使用してさらに強化できます。[Set Limits]を使用すると、各DCOMコンポーネントの最大許可を強制的に制御できます。
DCOMとRPCの比較は、HTTPとTCPの比較によく似ています。
実際、DCOMはネットワーク経由でDCOM要求を送信する必要がある場合、実際にはRPCをトランスポートメカニズムとして使用します。
RPCはトランスポートプロトコルとして、認証メカニズムが組み込まれていません。 DCOMは、プロトコルの一部として認証を備えています。
そのため、Windows 2000の場合、DCOMの完全なスイートがまだ利用できない場合、CAは既存のトランスポートプロトコルであるRPCを使用しましたが、その上にカスタムアプリケーションプロトコルを開発して、認証や承認などを実装する必要がありました。
Windows 2003の場合、事前に開発され、事前に構築され、事前にテストされ、事前に配備されたDCOMを利用できるので、すでにそこにある認証と承認のメカニズムを使用するだけで済みます。
これが、RPC（これはプロトコルの一部として存在しない）ではなく、DCOMアクセス許可（OSに組み込まれている）の構成のスクリーンショットを取得できる理由です。
さらに、DCOMはKerberosを認証メカニズムとして使用できるため、（CA）アプリケーションをカスタム化する代わりに、_impersonation for authenticating requesters_およびcompares the client token against an access control list (ACL)を許可する限定的な偽装のようなものを使用できます。自分で転がします。
ソフトウェア実装でRPCよりもDCOMを選択するのはなぜですか？
それが利用可能だからです。
したがって、最初の質問は、認証と承認の点で、DCOMがRPCとどのように異なるかということです。
そうではない。 DCOMはRPCの上に構築され、基盤となる認証メカニズムを使用します。 DCOMは、RPCの単なるオブジェクト指向の拡張機能です。類推は、CからC++に行くでしょう。
（着信DCOM呼び出しを中断すると、デバッガーでこれを確認できます。コードは、スタブから呼び出されますDLL通常、RPCコードから呼び出されるDCOMコードから呼び出されるOLEAUT32.dll ）。
あなたが引用した記事に関する限り、私は彼らが2つのことを言って混乱させていると思います。
- 新しい証明書サービスAPIは、フラットなRPC APIとしてではなく、DCOMによって公開されます。
- DCOMを使用するため、DCOMオブジェクトのアクセス許可を構成して、セキュリティチェックを追加できます。
これは意図的な設計の選択ではないと思います。これは、DCOM APIへの移行による副作用であり、APIの使用と管理をより簡単にすることによって動機付けされたと確信しています。
ユーザーがテンプレートに対する適切な登録権限を持ち、CA構成が自動登録に設定されている場合、CAはすぐに要求を処理できます。
したがって、誰かが登録できないようにするための正しい方法はテンプレートへの登録権限を付与しないです。それ以外の場合は、RPC api まだ存在し、機能しますを使用して登録できます。