次の方法で共有


プリンシパル名

クライアントがサーバー プログラムと相互に認証されたセッションを作成するには、サーバーの予想されるプリンシパル名を指定する必要があります。 Kerberos などの一部のプロトコルでは、認証されたセッションに正しいサーバー プリンシパル名が必要です。 プリンシパルは、セキュリティ システムが認識するエンティティです。 これには、人間のユーザーとシステム サービスが含まれます。 すべてのプリンシパル名は、特定のセキュリティ サポート プロバイダー (SSP) に対して同様の形式になります。 SSP は、セキュリティ検証を実行するソフトウェア モジュールです。 詳細については、「 SSPI アーキテクチャの概要」を参照してください。 統一性を維持するために、セキュリティ プロバイダーは通常、システム サービスにユーザーと同様の名前を付けます。 一部のセキュリティ プロバイダーでは、システム サービスにプリンシパル名がない場合があります。

サーバーは 、RpcServerRegisterAuthInfo 関数を使用して、セキュリティ プロバイダーのプリンシパル名を登録します。 セキュリティ プロバイダーごとに使用できるサーバー プリンシパル名は 1 つだけです。 複数の名前が登録されている場合、1 つの名前がランダムに選択され、使用されます。 SSP はプリンシパル名の形式を指示します。 たとえば、システム サービスの Kerberos/Negotiate SP は、machine_name$@childdomain.parentdomain1.parentdomain2.COM とほぼ同じです。

プリンシパル名を生成するための推奨手順は、ドキュメント化された API ( DsMakeSpn 関数など) を使用して、文字列からプリンシパル名を連結するのではなく使用することです。 文書化された API を使用すると、さまざまなデプロイ環境間の移植性が向上し、エラーが発生する可能性がなくなります。

正しくないプリンシパル名を指定すると、クライアントとサーバーが認証されたセッションを確立できなくなる可能性があります。 SCHANNEL SSP は、次の 2 つの形式のいずれかでプリンシパル名を受け取ります。

  • 最初の SCHANNEL プリンシパル名フォームは msstd フォームです。 msstd 形式の名前は、通常、msstd:servername@serverdomain.com というパターンに従います。 これは、電子メール名プロパティと呼ばれます。 証明書に電子メール名プロパティが含まれており、それにアット マーク (@) が含まれている場合、プリンシパル名は msstd:email name です。 それ以外の場合は、共通名プロパティを含む必要があります。 文字列バインディングと同様に、内部円記号は 2 倍になります。
  • 2 番目の SCHANNEL プリンシパル名フォームは 完全形式です 。 これは、山かっこで囲まれた円記号で区切られた一連の RFC1779 準拠の名前です。 通常は、fullsic:\\<Authority\SubAuthority\....\Person> または fullsic:\\Authority\<SubAuthority\....\ServerProgram> のパターンに従います。

名前が証明書と一致しない場合は、ERROR_ACCESS_DENIEDが返されます。 名前の形式が無効な場合、SCHANNEL SSP はコード ERROR_INVALID_PARAMETERを返します。

サーバーのプリンシパル名を照会するために、アプリケーションは RpcMgmtInqServerPrincName を呼び出すことができます。 これにより、プリンシパル名を保持するために null で終わる文字列が割り当てられます。 終了する前に、アプリケーションで RpcStringFree を呼び出して、この文字列が占有するメモリを解放する必要があります。

この方法でサーバー名を照会することは安全ではなく、避ける必要があります。 サーバー認証の場合、クライアント プログラムは接続先のサーバーを認識し、サーバー プリンシパル名を最初から作成する必要があります。