プロトコルのためのユーザ・マッピング情報拡張子
ユーザ・マッピング情報を含むヒントが、認証ハンドシェーク期間に交換されるメッセージに設けられる。例えば、認証期間に、クライアントはサーバにユーザ・マッピング情報を提供する。クライアントのドメイン／ユーザ名情報を送出するために、（例えば、ＴＬＳ拡張子メカニズムの形式の）ヒントが用いられて、サーバがユーザの証明書をアカウントへマッピングするのを助ける。拡張子メカニズムは、クライアントによって送出されたマッピング・データの完全性と信頼性とを提供する。ユーザは、正しいアカウント又は（正しいアカウントを指摘し又は維持する）ドメイン・コントローラをどこで見つけるに関するヒントを提供する。ヒントと証明書の他の情報とに基づいて、ユーザはアカウントにマッピングされる。ヒントはユーザがログインするときにユーザによって提供される。こうして、ユーザを認証するために、証明書が本人にマッピングされる。結び付けを実施するために、証明書と共にヒントが送出される。結び付けを実施するために、現存のプロトコルが、追加のマッピング情報（ヒント）を伝えるよう拡張される。ベンダ特有のケルベロスへの拡張子が、Ｘ．５０９証明書とマッピング・ユーザ名ヒントとに基づいて許可データを取得するために定義される。
【発明の詳細な説明】
【技術分野】
【０００１】
エンティティとそのエンティティの公開鍵とに関する情報を含む証明書は、デジタル署名された陳述である。ハンドシェークは、エンティティ相互間の識別及び認証のために使用される２つのエンティティ間（例えば、ユーザとコンピュータとの間、コンピュータと他のコンピュータとの間、プログラムと他のプログラムとの間）の会話である。証明書がユーザの身元又は領域を識別するに足る情報を提供しない場合、ハンドシェークにしたがって証明書をユーザ・アカウント又は機密保護責任者にマッピングすると、不成功に終わることが多い。
【背景技術】
【０００２】
証明書及びハンドシェークを用いるサービスの一例はセキュア・チャネル（Secure Channel）である。エスチャネル（Schannel）としても知られるセキュア・チャネルは、ＳＳＬ／ＴＬＳ（セキュア・ソケッツ・レイヤ／トランスポート・レイヤ・セキュリティ）プロトコルを実装するセキュリティ・サービス・プロバイダ・インターフェース（ＳＳＰＩ）の下でのセキュリティ・サポート・プロバイダ（ＳＳＰ）の名称である。エスチャネルＳＳＰはＳＳＰＩの下でプラグインする。ケルベロスＳＳＰもＳＳＰＩの下でプラグインする。エスチャネルは、ＳＳＬ又はＴＬＳを介してのようなハイパーテキスト・トランスファ・プロトコル（ＨＴＴＰ）に対する拡張された機密保護を必要とするインターネット・アプリケーションに主に用いられる。例えばＳＳＬ又はＴＬＳのようなエスチャネル・プロトコルは、サービスと（オプションとして）クライアントとを認証するために資格認定書を必要とする。サーバがその身元のプルーフをクライアントに提供する場合のサーバ認証は、エスチャネル機密保護プロトコルによって要求される。クライアント認証は常にサーバによって要求される。
【０００３】
エスチャネル資格認定書はＸ．５０９証明書であり得る。証明書からの秘密鍵及び公開鍵の情報は、サーバと（オプションとして）クライアントとを認証するのに用いられる。また、これらの鍵は、クライアントとサーバがセッション鍵を生成して交換するのに必要な情報を交換する間にメッセージの完全性を提供するために用いられる。
【０００４】
エスチャネルは、サーバ上でユーザ認証を確立するのに用いられるクライアント／サーバ・プロトコルであるＳＳＬ及びＴＬＳを実装するモジュールである。この認証により、クライアントの擬人化のためにサーバによって用いられることができるトークンがもたらされる。エスチャネルは証明書を用いてユーザを認証する（証明書をユーザ・アカウントにマッピングする）。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ユーザ（クライアント）がサーバに対して身元を明らかにすると、サーバは（ユーザのアカウントに対する）権限を定めなければならない。典型的には、これはＸ．５０９証明書におけるユーザ・プリンシパル・ネーム（ＵＰＮ）拡張子の使用によって確立される。しかし、ＵＰＮがない場合、又はＵＰＮが（クロス・フォレスト・シナリオにおいて）ユーザの領域を識別するに足る情報を提供しない場合、ユーザ・アカウント（例えば、アクティブ・ディレクトリ・ユーザ・アカウント）への証明書のマッピングは失敗する。Ｓ４Ｕを用いてケルベロスによって証明書をユーザ・アカウントへマッピングする際にも、同様の問題が存在する。
【課題を解決するための手段】
【０００６】
（例えば、「ヒント」の形式の）ユーザ・マッピング情報が認証プロトコルで提供される。例えば、認証期間に、クライアントはサーバにユーザ・マッピング情報を提供する。ヒントは、ユーザ・アカウントをどこで見つけるかを識別するのを助け、それにより、証明書をユーザ・アカウントへマッピングする能力を提供するために用いられる。
【０００７】
例えば、データ・フォーマット（例えば、オン・ザ・ワイヤ・フォーマット）は、ドメイン名情報とユーザ名情報とを送出するためにＴＬＳプロトコルに対して変更される。例えば、（ＴＬＳ拡張子メカニズムの形式等の）ヒントは、ドメイン／ユーザ名情報を送出してサーバがユーザの証明書をアカウントへマッピングするのを助けるために用いられる。ＴＬＳ拡張子メカニズムはクライアントによって送出されたマッピング・データの完全性と信頼性とを提供する。
【０００８】
サーバ側において、プロトコル層からの情報は拡張されてマッピングされ、ユーザ証明書をアカウントへマッピングするため及び機密保護（ユーザの擬人化）トークンを生成するために用いられる。同様に、ケルベロス・プロトコルへの拡張子は、マッピング・ヒントと証明書が供給され、ユーザ・トークンが返送されるのを可能にする。
【発明を実施するための最良の形態】
【０００９】
ユーザ・マッピング情報を含むヒントは、クライアント／サーバ認証及び鍵交換ステップの一部として交換されるメッセージにおいて提供される。例えば、クライアントは認証期間にサーバにユーザ・マッピング情報を提供する。（例えば、ＴＬＳ拡張子メカニズムの形の）ヒントを用いて、サーバがユーザの証明書をアカウントにマッピングするのを助けるよう、クライアントのドメイン／ユーザ名情報を送出する。拡張子メカニズムは、クライアントによって送出されたマッピング・データの完全性と信頼性とを提供する。ユーザは、正しいアカウント又は（正しいアカウントを示す又は維持する）ドメイン・コントローラをどこで見出すかに関するヒントを提供する。ヒントと証明書における他の情報とに基づいて、ユーザはアカウントへマッピングされる。ヒントは、ユーザがログインするときにユーザによって提供され得る。
【００１０】
こうして、ユーザを認証するために証明書が本人にマッピングされる。結び付けを実施するために、ヒントは証明書情報と共に送出される。拡張子プロトコルは、結び付けを実施するために追加のマッピング情報（ヒント）を伝えるよう拡張され得る。
【００１１】
図１は、例示のマッピング方法のフロー図である。ステップ１０において、クライアントは、（例えば、マッピング情報又はヒントを含む）マッピング拡張子が使用されていることを示すために、データ又は信号をサーバに送る。ステップ１５において、サーバは、拡張子を取り扱うことができる又はできないことを知らせる。ステップ２０において、マッピング拡張子が例えばハッシュとしてのユーザ・マッピング・データ（UserMappingData）としてサーバへ送出される。サーバが拡張子を取り扱える場合には、サーバは、ステップ２５において、マッピング拡張子データ（ヒント）を用いて、誰と話すべきかを決定する。ステップ３０において、両者はアプリケーション・データを導出する。
【００１２】
プロバイダ（例えばエスチャネル）は、ユーザ・アカウントへの証明書のマッピングをサーバ側が実施するのを助けるよう、ユーザのプリンシパル・ネーム（ＵＰＮ）及びドメインを含むマッピング情報を送出するよう拡張されることが望ましい。これは、ＵＰＮが証明書自体にも、複数のアクティブなディレクトリを持つ配置にもない場合に特に有用である。また、マッピング情報は、例えば俗称やアカウント名であってもよい。
【００１３】
図２のクライアント−サーバ・マッピング・システムに関して記述されるＳＳＬハンドシェークの例は、クライアントとユーザのＸ．５０９証明書に基づいて相互認証をサポートするとともに、マスタ・シークレットから導出されるセッション鍵によるクライアント／サーバ通信チャネルのその後の秘密性と完全性とを提供する。
【００１４】
ＵＰＮと（ユーザ・アカウントが配置される）ドメイン名がハンドシェーク期間に特定されて送出されることが望ましい。ハンドシェークが完了した後、中間で情報の改竄が行われなかったことを保証するよう、両者によって情報が機密であるとして検証される。
【００１５】
クライアント側の認証のために、セキュリティ・サポート又はプロトコル・プロバイダ（例えば、エスチャネル）はユーザの証明書と、「証明書」メッセージ及び「証明書検証」メッセージにおける対応の署名とを送出する。ハンドシェークの完了時に、サーバ側は、擬人化トークンを生成するために、証明書をユーザ・アカウントにマッピングすることを試みる。
【００１６】
図２は、ユーザ・マッピング情報がＴＬＳハンドシェークのようなハンドシェークにどのように統合されるかを示している。ＴＬＳハンドシェークについて記述するが、本発明はハンドシェーク、証明書及び／又は認証に関係する任意のプロトコルに関して使用され得るものとする。最初の「ハロー」メッセージ交換において、クライアント１０１とサーバ１３０はマッピング情報が（例えば、クライアントとサーバとのハローの拡張部分に追加される新たな拡張子形式を介して）サポートされるかどうかを交渉する。ユーザ・マッピング・データ（例えば、プリンシパル・ネーム及びドメイン名）は、ユーザ証明書メッセージに続く新たなメッセージ（例えば、「user_mapping_data」）において送出されることが望ましい。
【００１７】
上で述べたとおり、ＴＬＳメッセージに関しては、クライアントからサーバへのユーザ・マッピング情報の転送はＴＬＳ拡張子を使用する。新たな拡張子（例えば、user_mapping）はクライアントのハローにおいて確立されて送出される。サーバが同じ拡張子（user_mapping）をサーバのハローに置くならば、これはクライアントに対してサーバが拡張子を理解することを示すことになる。サーバが拡張子を理解しないならば、サーバは拡張されないサーバのハローで応答し、クライアントは通常のように進んで拡張子を無視する。
【００１８】
新たな拡張子が理解されると、クライアントは自己の証明書メッセージの前に新たなハンドシェーク・メッセージを入れる。このメッセージの位置付けにより、サーバは証明書を検証（してマッピング）しなければならない前にマッピング情報を受け取ることができる。次いで、サーバはこのメッセージを構文解析し、クライアントのドメインを抽出し、証明書マッピングの際の使用のためにクライアントのドメインをコンテキストに格納する。
【００１９】
「サーバ処理」はマッピング機能に完全に含まれる。この点で、そこに拡張子情報があるならば、拡張子情報が用いられ、拡張子情報がない場合には、処理は通常どおりに進行する。拡張子を持たないことによるエラーがないことが望ましい。
【００２０】
クライアントはこの拡張子のイニシエータであるから、クライアントがユーザ・マッピング情報を送出する時点が決定される。この情報は常に送出されるけれども、この情報を常に任意のサーバにブロードキャストすることは望ましくない。これは、ユーザ・マッピング情報がクライアントとサーバとで使用するネットワーク・インフラストラクチャを明らかにすることができるからである。一方、この情報が明らかにされると、該情報を取り消す試みがなされないことになる。
【００２１】
ユーザ・マッピング情報の必要以上の送出を回避するよう、その配布を抑えるために種々の技術が用いられている。その例は、（１）「ハロー」の交換の際に同意した場合にのみ、クライアントは拡張子を送出し、それによって、ユーザ・マッピング情報を理解しないサーバに対して該情報が送出されるのを防止すること、及び、（２）送出しても「安全な」ドメインのリストにサーバが載っている場合にのみ、クライアントはユーザ・マッピング情報を送出することである。このリストは例えばレジストリに設定され得る。
【００２２】
こうして、図３に示すように、方法は、ステップ２００においてユーザ（例えば、クライアント）から受信者（例えば、サーバ）へ証明書と署名を送出することを含む。次いで、ステップ２１０において、受信者にヒント又はマッピング情報が送出されなければならないか否かが決定される。送出されなければならない場合には、次いで、ステップ２２０において、ヒント又はマッピング情報が受信者へ送出され、ヒント又はマッピング情報を用いて証明書がユーザ・アカウントにマッピングされる。ヒント又はマッピング情報が受信者に送出されるべきではないならば、ステップ２３０において、証明書は、ヒントの恩恵を受けることなくユーザ・アカウントにマッピングされるよう試みられる。
【００２３】
送出されるべきユーザ・マッピング情報の収集はプログラムにしたがって又は対話的に処理される。例えば、エスチャネルにおいて用いるための資格認定書を確立するために、ユーザ（例えば、エンド・ユーザのために動作するクライアント・プログラム）はSCHANNEL_CRED構造を構築し、これをAcquireCredentialsHandle()へ伝える。SCHANNEL_CRED構造により、ユーザは、（クライアントの証明書を添付している）資格認定書を構築するためにACH()が用いる証明書（CERT_CONTEXT）を供給することができる。代わりに、ユーザは証明書を特定せず、エスチャネルにユーザのデフォルトの証明書を選択させる。
【００２４】
ヒントをどのように実現するかの例として、ＵＰＮ及びＤＮＳドメイン名を抽出するために、NameUserPrincipalのEXTENDED_NAME_FORMAT及びNameDnsDomainを用いてGetUserNameEx()が２度呼び出される。NameUserPrincipal及びNameDnsDomainはPSPCredentialGroup構造に添付される。ユーザ名のための例示のヒントは、UNICODE_STRING UserPrincipalNameとしてメッセージにおいて提供され得る。ドメイン名の例示のヒントは、UNICODE_STRING DomainNameとしてメッセージにおいて提供され得る。
【００２５】
例えば、InitializeSecurityContext()は、そのパラメータの１つとして、コンテキストのターゲット（すなわち、セキュア・コンテキストを確立しているサーバの名称）を受け取る。InitializeSecurityContextはCheckUserMappingTarget()を呼び出し、その結果に対して以下のPSPContext構造フラグ、すなわち
BOOL fSendMappingExtension
をセットする。デフォルトにより、このフラグはセットされないので、クライアントは拡張子を送出しない。デバッグ・ログはフラグをセットする又はフラグをそのままにする判定を示す。
【００２６】
別の例として、ユーザ・マッピング拡張子が成功裡に交渉されたならば、ＵＰＮ及びドメインはPSPContext構造に置かれることが望ましい。この情報はマッピング処理の開始時に用いられて、証明書を基礎とするLsaLogonUser()(S4U2Self)のバージョンへ送られる。
【００２７】
上記の例の特徴は、ＳＳＬ及びＴＬＳに関係するプロトコルに関するものであった。また、本発明の特徴はケルベロスのようなプロトコルにおいて具体化される。ケルベロス拡張子は証明書を供給し、オプションとして、証明書がマッピングされるユーザ名をも供給する。ＫＤＣ（鍵分配センタ）はアカウント・マッピング及び検証を実施し、例えば、許可のために用いられるトークンを作るためにクライアントによって使用される認証データを返送する。
【００２８】
特に、例えばLsaLogonUser()呼び出しはヒントを含み得る。ネーム・ヒントがLsaLogonUser()へ送られる。例えば、メッセージにおいて、供給されるならば、UNICODE_STRING DomainName,//OPTIONALがフォレストを見つけるために用いられる。また、供給されるならば、UNICODE_STRING UserName,//OPTIONALがアカウントを見つけるために用いられる。ドメイン名は、マッピングされたユーザ・アカウントをどのドメインが含むかをクライアント（例えば、ユーザがログインしているローカルのマシン）に知らせる。
【００２９】
呼び出し側は、証明書が複数のユーザ・アカウントにマッピングされることを可能にするように、ユーザ名を供給することが許可される。ユーザ名が供給されると、ＫＤＣは当該ユーザ名を用いてユーザ・アカウントを見つけ、証明書がこのアカウントにマッピングされることを検証する。
【００３０】
ユーザ名ヒントが供給されず、ドメイン名が供給されるならば、ドメイン名は、認証のためにＫＤＣを見つけるためにケルベロス・クライアントに用いられ、ＫＤＣは証明書をユーザ・アカウントへマッピングする。subjectAltName拡張子を含まないクライアント証明書をサポートすることが望ましい。こうした証明書はActiveDirectoryアカウントへマッピングされる。アカウント・マッピング問題に対して、包括的且つ拡張可能な解決法が証明書に用意される。
【００３１】
証明書がsubjectAltName/UPN拡張子を含むならば、ＫＤＣは当該拡張子を用いてクライアントをマッピングする。この場合、クライアント証明書はNT_AUTHポリシーを満足することが望ましい。ＵＰＮに基づいてユーザ・オブジェクトが見出されない場合、認証は不成功に終わるべきである。
【００３２】
証明書にＵＰＮがない場合、ＫＤＣは検索のための゛X509:<I><S>″AltSecID名を構築する。この場合、クライアント証明書はNT_AUTHポリシーを満足する必要はない。
【００３３】
証明書にＵＰＮがなく、上記のステップにおいてユーザ・オブジェクトが見つかったことがない場合、サブジェクトの著名な名称に基づいてクライアント・アカウントが検索され、ＫＤＣは検索のための゛X509:<S>″AltSecID名を構築する。この場合、クライアント証明書はNT_AUTHポリシーを満足することが望ましい。
【００３４】
証明書にＵＰＮがなく、上記のステップにおいてユーザ・オブジェクトが見つからない場合、ＫＤＣはサブジェクトと連番とを用いて、検索のための゛X509:<I><SR>″AltSecID名を構築する。この場合、クライアント証明書はNT_AUTHポリシーを満足する必要はない。
【００３５】
証明書にＵＰＮがなく、ユーザ・オブジェクトが見つからず、クライアント証明書がＳＫＩIを含む場合、ＫＤＣは検索のための゛X509:<SKI>″AltSecID名を構築する。この場合、クライアント証明書はNT_AUTHポリシーを満足する必要はない。
【００３６】
証明書にＵＰＮがなく、上記のステップにおいてユーザ・オブジェクトが見つからない場合、ＫＤＣは検索のための゛X509:<SHA1-PUKEY>″AltSecID名を構築する。この場合、クライアント証明書はNT_AUTHポリシーを満足する必要はない。
【００３７】
証明書にＵＰＮがなく、上記のステップにおいてユーザ・オブジェクトが見つからない場合、クライアント・アカウントがSAN/822nameに基づいて検索され、ＫＤＣは検索のための”X509:<RFC822>″AltSecIDを構築する。この場合、クライアント証明書はNT_AUTHポリシーを満足することが望ましい。
【００３８】
留意されるように、上記のステップ及び基準は、単独で又は任意の組み合わせ又は順序で用いられる。追加のステップ及び基準も用いられ得る。アカウントを成功裡に見つける第１のステップ又は基準が成功すると検索が停止することが望ましい。しかし、同一の証明書を異なるユーザ・アカウントへマッピングする２つのマッピング方法が存在する場合には、構成エラーが生じ得る。
【００３９】
留意されるように、クライアント証明書がＵＰＮを持たず、証明書におけるクライアントのＤＮがユーザ・アカウントのＤＮと一致するが、ユーザ・アカウントがマッピングされない場合、認証は不成功であるべきである。
【００４０】
例示のコンピュータ環境
図４は、本発明が実施される適宜のコンピューティング・システム環境８００の例を示している。コンピューティング・システム環境８００は適宜のコンピュータ環境の一例にすぎず、発明の用途及び機能の範囲を限定するものではない。コンピュータ環境８００を、例示の動作環境８００に示す任意の１つの構成要素又は構成要素の組み合わせに関係する依存性又は要件を持つものと解釈してはならない。
【００４１】
本発明は、他の多くの汎用の又は特定用途のコンピューティング・システム環境又は構成と共に動作可能である。本発明と共に使用するのに適したコンピューティング・システム、環境及び／又は構成は、パーソナル・コンピュータ、サーバ・コンピュータ、携帯型又はラップトップ装置、マルチプロセッサ・システム、マイクロプロセッサ型のシステム、セットトップ・ボックス、プログラム可能な家庭用電気機器、ネットワークＰＣ、ミニコンピュータ、メインフレーム・コンピュータ、任意の上記システム及び装置を含む分散型コンピュータ環境を含むが、これらに限定されない。
【００４２】
本発明は、コンピュータによって実行されるプログラム・モジュールのようなコンピュータ実行可能命令の一般的な文脈で記述される。一般に、プログラム・モジュールは、特定のタスクを実施し又は特定の抽象的なデータ形式を実施するルーチン、プログラム、オブジェクト、データ構造等を含む。また、本発明は、通信ネットワーク又は他のデータ伝送媒体を介してリンクされるリモート処理装置によってタスクが実施される分散型コンピュータ環境において実施され得る。分散型コンピュータ環境においては、プログラム・モジュール及び他のデータは、メモリ記憶装置を含むローカルの及びリモートのコンピュータ記憶媒体に配置され得る。
【００４３】
図４を参照すると、本発明を実施するための例示のシステムは、コンピュータ８１０の形の汎用コンピューティング装置を備えている。コンピュータ８１０の構成要素は、処理ユニット８２０、システム・メモリ８３０、及び、システム・メモリを含む種々のシステム構成要素を処理ユニット８２０に接続するシステム・バス８２１を含む。システム・バス８２１は、種々のバス構造を用いたメモリ・バス又はメモリ・コントローラ、ペリフェラル・バス及びローカル・バスを含む複数の型式のバス・アーキテクチャのうちの任意のものであり得る。例えば、こうしたアーキテクチャは産業標準アーキテクチャ（ＩＳＡ）、マイクロチャネル・アーキテクチャ（ＭＣＡ）、エンハンストＩＳＡ（ＥＩＳＡ）バス、ビデオ・エレクトロニクス基準協会（ＶＥＳＡ）バス、周辺コンポーネント相互接続（ＰＣＩ）バス（メザニン・バスとしても知られている）を含むが、これらに限定されない。
【００４４】
典型的には、コンピュータ８１０は種々のコンピュータ読み取り可能媒体を備える。コンピュータ読み取り可能媒体は、コンピュータ８１０によってアクセス可能な任意の利用可能な媒体であり、揮発性及び不揮発性の媒体並びに取り外し可能及び取り外し不可能な媒体を含む。例えば、コンピュータ読み取り可能媒体はコンピュータ記憶媒体及び通信媒体を含むが、これらに限定されない。
【００４５】
コンピュータ記憶媒体は、コンピュータ読み取り可能命令、データ構造、プログラム・モジュール又は他のデータのような情報を記憶するための方法又は技術において実装される揮発性及び不揮発性で取り外し可能及び取り外し不可能な媒体を含む。コンピュータ記憶媒体はＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリ又は他のメモリ技術、ＣＤ−ＲＯＭ、ディジタル・バーサタイル・ディスク（ＤＶＤ）又は他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置又は他の磁気記憶装置、或いは、所望の情報を記憶するのに用いられ且つコンピュータ８１０がアクセスできる任意の他の媒体を含むが、これらに限定されない。
【００４６】
通信媒体は、典型的には、コンピュータ読み取り可能命令、データ構造、プログラム・モジュール又は他のデータを搬送波又は他の移送機構のような変調データ信号において具現するものであり、任意の情報配信媒体を含む。用語「変調データ信号」は、その特性の組の１つ以上を備えた信号又は情報を符号化するように変更された信号を意味する。例えば、通信媒体は、有線ネットワーク又は直接有線接続のような有線媒体や、音響、ＲＦ、赤外線及びその他の無線媒体を含む無線媒体を含むが、これらに限定されない。上記の媒体の任意の組み合わせもコンピュータ読み取り可能媒体の範囲内に含まれる。
【００４７】
システム・メモリ８３０はＲＯＭ８３１及びＲＡＭ８３２のような揮発性及び／又は不揮発性のメモリの形のコンピュータ記憶媒体を含む。基本入力／出力システム８３３（ＢＩＯＳ）は、例えば起動期間にコンピュータ８１０の要素間で情報を転送するのを助ける基本ルーチンを含んでおり、典型的にはＲＯＭ８３１に記憶される。典型的には、ＲＡＭ８３２は、処理ユニット８２０に対して即座にアクセス可能であり及び／又は処理ユニットによって動作されているデータ及び／又はプログラム・モジュールを含む。例えば、図４はオペレーティング・システム８３４、アップリケーション・プログラム８３５、他のプログラム・モジュール８３６及びプログラム・データ８３７を示しているが、これらに限定されない。
【００４８】
また、コンピュータ８１０は他の取り外し可能／取り外し不可能な揮発性／不揮発性のコンピュータ記憶媒体を含む。例示のみであるが、図４は、取り外し不可能な不揮発性磁気媒体との間で読み出し、書き込みを行うハードディスク・ドライブ８４０、取り外し可能な不揮発性磁気ディスク８５２との間で読み出し、書き込みを行う磁気ディスク・ドライブ８５１、及び、ＣＤ−ＲＯＭその他の光媒体のような取り外し可能な不揮発性光ディスク８５６との間で読み取り、書き込みを行う光ディスク・ドライブ８５５を示している。例示の動作環境において使用可能な他の取り外し可能／取り外し不可能な揮発性／不揮発性コンピュータ記憶媒体は、磁気テープ・カセット、フラッシュメモリ・カード、ディジタル・バーサタイル・ディスク、ディジタル・ビデオ・テープ、固体ＲＡＭ等を含むが、これらに限定されない。典型的には、ハードディスク・ドライブ８４１はインターフェース８４０のような取り外し不可能メモリ・インターフェースを介してシステム・バス８２１と接続され、磁気ディスク・ドライブ８５１及び光ディスク・ドライブ８５５は、典型的には、インターフェース８５０のような取り外し可能メモリ・インターフェースによってシステム・バス８２１と接続される。
【００４９】
ドライブとその関連のコンピュータ記憶媒体は、コンピュータ８１０のためのコンピュータ読み取り可能命令、データ構造、プログラム・モジュール及び他のデータの記憶装置を提供する。例えば、図４においては、ハードディスク・ドライブ８４１はオペレーティング・システム８４４、アプリケーション・プログラム８４５、他のプログラム・モジュール８４６及びプログラム・データ８４７を記憶するものとして図示されている。留意されるように、これらの構成要素はオペレーティング・システム８３４、アプリケーション・プログラム８３５、他のプログラム・モジュール８３６及びプログラム・データ８３７と同じであっても、違っていてもよい。ここでオペレーティング・システム８４４、アプリケーション・プログラム８４５、他のプログラム・モジュール８４６及びプログラム・データ８４７に別の番号を付したのは、異なるものであることを示すためである。
【００５０】
ユーザは、マウス、トラックボール、タッチパッドとして通常呼ばれるポインティング・デバイス８６１やキーボード８６２などの入力装置を介して、コンピュータ８１０にコマンド及び情報を入力する。他の入力装置（図示せず）はマイクロホン、ジョイスティック、ゲームパッド、衛星アンテナ、スキャナ等を含み得る。これらの及び他の入力装置は、システムと結合されたユーザ入力インターフェース８６０を介して処理ユニット８２０と接続されることが多いが、パラレル・ポート、ゲーム・ポート又はユニバーサル・シリアル・バス（ＵＳＢ）等の他のインターフェース及びバス構造によって接続されてもよい。また、モニタ８９１及び他の形式の表示装置が、ビデオ・インターフェース８９０のようなインターフェースを介してシステム・バス８２１と接続される。モニタに加えて、コンピュータは、出力周辺インターフェース８９５を介して接続される、スピーカ８９７及びプリンタ８９６のような他の周辺出力装置を備え得る。
【００５１】
コンピュータ８１０は、リモート・コンピュータ８８０のような１つ以上のリモート・コンピュータとの論理接続を用いたネットワーク環境において動作し得る。リモート・コンピュータ８８０はパーソナル・コンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置又は他の共通ネットワーク・ノードであり得、典型的には、コンピュータ８１０に関して上で説明した多くの又は全部の要素を備えるが、図４にはメモリ記憶装置８８１のみが示されている。図示の論理接続はＬＡＮ８７１及びＷＡＮ８７３を含むが、他のネットワークをも含み得る。こうしたネットワーク環境はオフィス、企業規模の広域コンピュータ・ネットワーク、イントラネット及びインターネットにおいて一般的である。
【００５２】
ＬＡＮネットワーキング環境において用いられるとき、コンピュータ８１０はネットワーク・インターフェース又はアダプタ８７０を介してＬＡＮ８７１と接続される。ＷＡＮネットワーキング環境において用いられるとき、典型的には、コンピュータ８１０はモデム８７２や、インターネットのような，ＷＡＮ８７３を介して通信を確立する他の手段を備える。外付け又は内蔵のモデム８７２はユーザ入力インターフェース８６０又は他の適宜の機構を介してシステム・バス８２１と接続される。ネットワーク環境においては、コンピュータ８１０又はその一部に関して図示されているプログラム・モジュールはリモート・メモリ記憶装置に記憶され得る。図４は、メモリ装置８８１上に常駐するものとしてリモート・悪利けーション・プログラム８８５を図示している。理解されるように、図示のネットワーク接続は例示であり、コンピュータ間の通信リンクを確立する他の手段を用いることができる。
【００５３】
上で説明したように、本発明の例示の実施の形態を種々のコンピューティング装置と関連させて説明してきたが、その基礎となる概念は任意のコンピューティング装置又はシステムに対して適用され得る。
【００５４】
ここで記述された種々の技術はハードウェア又はソフトウェアとの関連において、及び、適切であれば、ハードウェアとソフトウェアの組み合わせとの関連において実現され得る。こうして、本発明の方法及び装置、或いは本発明の或る特徴又は一部は、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ、ハードドライブ又は他の任意の機械読み取り可能記憶媒体のような有形媒体において具現化されるプログラム・コード（すなわち命令）の形を取り得、プログラム・コードがコンピュータ等の機械にロードされて実行されるとき、機械は本発明を実施するための装置となる。プログラム可能なコンピュータ上でのプログラム・コードの実行の場合、一般に、コンピューティング装置は、プロセッサと、該プロセッサによって読み取り可能な（揮発性及び不揮発性のメモリ及び／又は記憶素子を含む）記憶媒体と、少なくとも１つの入力装置と、少なくとも１つの出力装置とを備える。所望であれば、プログラムはアセンブリ言語又は機械語で実現される。いずれにしても、言語は編集又は解釈された言語であり、ハードウェア実装と結合され得る。
【００５５】
また、本発明の方法及びシステムは、電線やケーブル、光ファイバ又は他の任意の伝送形式等の伝送媒体を介して伝送されるプログラム・コードの形に具現化される通信によって実施され得る。プログラム・コードがＥＥＰＲＯＭ、ゲートアレイ、プログラム可能論理デバイス（ＰＬＤ）、クライアント・コンピュータ等のマシンによって受信され、ロードされ、実行されるとき、このマシンは本発明を実施するための装置となる。汎用プロセッサ上で実施されるとき、プログラム・コードはプロセッサと組み合わされて、本発明の機能を行使する独自の装置を提供する。さらに、本発明と結合して用いられる記憶技術は必ずハードウェアとソフトウェアとの組み合わせであり得る。
【００５６】
種々の図面の好ましい実施の形態との関連で本発明を説明してきたが、理解されるように、他の同様の実施の形態を用いることができ、本発明から逸脱することなく本発明と同じ機能を実施するために、説明してきた実施の形態に対して修正及び追加を行うことができる。したがって、本発明は任意の単一の実施の形態に限定されるべきではなく、特許請求の範囲にしたがって幅と範囲を解釈されるべきである。
【図面の簡単な説明】
【００５７】
【図１】例示のマッピング方法のフロー図である。
【図２】ハンドシェーク付きの例示のクライアント−サーバ・マッピング・システムの図である。
【図３】他の例示のマッピング方法のフロー図である。
【図４】本発明の特徴が実現される、例示のコンピュータ環境を示すブロック図である。
【技術分野】
【０００１】
エンティティとそのエンティティの公開鍵とに関する情報を含む証明書は、デジタル署名された陳述である。ハンドシェークは、エンティティ相互間の識別及び認証のために使用される２つのエンティティ間（例えば、ユーザとコンピュータとの間、コンピュータと他のコンピュータとの間、プログラムと他のプログラムとの間）の会話である。証明書がユーザの身元又は領域を識別するに足る情報を提供しない場合、ハンドシェークにしたがって証明書をユーザ・アカウント又は機密保護責任者にマッピングすると、不成功に終わることが多い。
【背景技術】
【０００２】
証明書及びハンドシェークを用いるサービスの一例はセキュア・チャネル（Secure Channel）である。エスチャネル（Schannel）としても知られるセキュア・チャネルは、ＳＳＬ／ＴＬＳ（セキュア・ソケッツ・レイヤ／トランスポート・レイヤ・セキュリティ）プロトコルを実装するセキュリティ・サービス・プロバイダ・インターフェース（ＳＳＰＩ）の下でのセキュリティ・サポート・プロバイダ（ＳＳＰ）の名称である。エスチャネルＳＳＰはＳＳＰＩの下でプラグインする。ケルベロスＳＳＰもＳＳＰＩの下でプラグインする。エスチャネルは、ＳＳＬ又はＴＬＳを介してのようなハイパーテキスト・トランスファ・プロトコル（ＨＴＴＰ）に対する拡張された機密保護を必要とするインターネット・アプリケーションに主に用いられる。例えばＳＳＬ又はＴＬＳのようなエスチャネル・プロトコルは、サービスと（オプションとして）クライアントとを認証するために資格認定書を必要とする。サーバがその身元のプルーフをクライアントに提供する場合のサーバ認証は、エスチャネル機密保護プロトコルによって要求される。クライアント認証は常にサーバによって要求される。
【０００３】
エスチャネル資格認定書はＸ．５０９証明書であり得る。証明書からの秘密鍵及び公開鍵の情報は、サーバと（オプションとして）クライアントとを認証するのに用いられる。また、これらの鍵は、クライアントとサーバがセッション鍵を生成して交換するのに必要な情報を交換する間にメッセージの完全性を提供するために用いられる。
【０００４】
エスチャネルは、サーバ上でユーザ認証を確立するのに用いられるクライアント／サーバ・プロトコルであるＳＳＬ及びＴＬＳを実装するモジュールである。この認証により、クライアントの擬人化のためにサーバによって用いられることができるトークンがもたらされる。エスチャネルは証明書を用いてユーザを認証する（証明書をユーザ・アカウントにマッピングする）。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ユーザ（クライアント）がサーバに対して身元を明らかにすると、サーバは（ユーザのアカウントに対する）権限を定めなければならない。典型的には、これはＸ．５０９証明書におけるユーザ・プリンシパル・ネーム（ＵＰＮ）拡張子の使用によって確立される。しかし、ＵＰＮがない場合、又はＵＰＮが（クロス・フォレスト・シナリオにおいて）ユーザの領域を識別するに足る情報を提供しない場合、ユーザ・アカウント（例えば、アクティブ・ディレクトリ・ユーザ・アカウント）への証明書のマッピングは失敗する。Ｓ４Ｕを用いてケルベロスによって証明書をユーザ・アカウントへマッピングする際にも、同様の問題が存在する。
【課題を解決するための手段】
【０００６】
（例えば、「ヒント」の形式の）ユーザ・マッピング情報が認証プロトコルで提供される。例えば、認証期間に、クライアントはサーバにユーザ・マッピング情報を提供する。ヒントは、ユーザ・アカウントをどこで見つけるかを識別するのを助け、それにより、証明書をユーザ・アカウントへマッピングする能力を提供するために用いられる。
【０００７】
例えば、データ・フォーマット（例えば、オン・ザ・ワイヤ・フォーマット）は、ドメイン名情報とユーザ名情報とを送出するためにＴＬＳプロトコルに対して変更される。例えば、（ＴＬＳ拡張子メカニズムの形式等の）ヒントは、ドメイン／ユーザ名情報を送出してサーバがユーザの証明書をアカウントへマッピングするのを助けるために用いられる。ＴＬＳ拡張子メカニズムはクライアントによって送出されたマッピング・データの完全性と信頼性とを提供する。
【０００８】
サーバ側において、プロトコル層からの情報は拡張されてマッピングされ、ユーザ証明書をアカウントへマッピングするため及び機密保護（ユーザの擬人化）トークンを生成するために用いられる。同様に、ケルベロス・プロトコルへの拡張子は、マッピング・ヒントと証明書が供給され、ユーザ・トークンが返送されるのを可能にする。
【発明を実施するための最良の形態】
【０００９】
ユーザ・マッピング情報を含むヒントは、クライアント／サーバ認証及び鍵交換ステップの一部として交換されるメッセージにおいて提供される。例えば、クライアントは認証期間にサーバにユーザ・マッピング情報を提供する。（例えば、ＴＬＳ拡張子メカニズムの形の）ヒントを用いて、サーバがユーザの証明書をアカウントにマッピングするのを助けるよう、クライアントのドメイン／ユーザ名情報を送出する。拡張子メカニズムは、クライアントによって送出されたマッピング・データの完全性と信頼性とを提供する。ユーザは、正しいアカウント又は（正しいアカウントを示す又は維持する）ドメイン・コントローラをどこで見出すかに関するヒントを提供する。ヒントと証明書における他の情報とに基づいて、ユーザはアカウントへマッピングされる。ヒントは、ユーザがログインするときにユーザによって提供され得る。
【００１０】
こうして、ユーザを認証するために証明書が本人にマッピングされる。結び付けを実施するために、ヒントは証明書情報と共に送出される。拡張子プロトコルは、結び付けを実施するために追加のマッピング情報（ヒント）を伝えるよう拡張され得る。
【００１１】
図１は、例示のマッピング方法のフロー図である。ステップ１０において、クライアントは、（例えば、マッピング情報又はヒントを含む）マッピング拡張子が使用されていることを示すために、データ又は信号をサーバに送る。ステップ１５において、サーバは、拡張子を取り扱うことができる又はできないことを知らせる。ステップ２０において、マッピング拡張子が例えばハッシュとしてのユーザ・マッピング・データ（UserMappingData）としてサーバへ送出される。サーバが拡張子を取り扱える場合には、サーバは、ステップ２５において、マッピング拡張子データ（ヒント）を用いて、誰と話すべきかを決定する。ステップ３０において、両者はアプリケーション・データを導出する。
【００１２】
プロバイダ（例えばエスチャネル）は、ユーザ・アカウントへの証明書のマッピングをサーバ側が実施するのを助けるよう、ユーザのプリンシパル・ネーム（ＵＰＮ）及びドメインを含むマッピング情報を送出するよう拡張されることが望ましい。これは、ＵＰＮが証明書自体にも、複数のアクティブなディレクトリを持つ配置にもない場合に特に有用である。また、マッピング情報は、例えば俗称やアカウント名であってもよい。
【００１３】
図２のクライアント−サーバ・マッピング・システムに関して記述されるＳＳＬハンドシェークの例は、クライアントとユーザのＸ．５０９証明書に基づいて相互認証をサポートするとともに、マスタ・シークレットから導出されるセッション鍵によるクライアント／サーバ通信チャネルのその後の秘密性と完全性とを提供する。
【００１４】
ＵＰＮと（ユーザ・アカウントが配置される）ドメイン名がハンドシェーク期間に特定されて送出されることが望ましい。ハンドシェークが完了した後、中間で情報の改竄が行われなかったことを保証するよう、両者によって情報が機密であるとして検証される。
【００１５】
クライアント側の認証のために、セキュリティ・サポート又はプロトコル・プロバイダ（例えば、エスチャネル）はユーザの証明書と、「証明書」メッセージ及び「証明書検証」メッセージにおける対応の署名とを送出する。ハンドシェークの完了時に、サーバ側は、擬人化トークンを生成するために、証明書をユーザ・アカウントにマッピングすることを試みる。
【００１６】
図２は、ユーザ・マッピング情報がＴＬＳハンドシェークのようなハンドシェークにどのように統合されるかを示している。ＴＬＳハンドシェークについて記述するが、本発明はハンドシェーク、証明書及び／又は認証に関係する任意のプロトコルに関して使用され得るものとする。最初の「ハロー」メッセージ交換において、クライアント１０１とサーバ１３０はマッピング情報が（例えば、クライアントとサーバとのハローの拡張部分に追加される新たな拡張子形式を介して）サポートされるかどうかを交渉する。ユーザ・マッピング・データ（例えば、プリンシパル・ネーム及びドメイン名）は、ユーザ証明書メッセージに続く新たなメッセージ（例えば、「user_mapping_data」）において送出されることが望ましい。
【００１７】
上で述べたとおり、ＴＬＳメッセージに関しては、クライアントからサーバへのユーザ・マッピング情報の転送はＴＬＳ拡張子を使用する。新たな拡張子（例えば、user_mapping）はクライアントのハローにおいて確立されて送出される。サーバが同じ拡張子（user_mapping）をサーバのハローに置くならば、これはクライアントに対してサーバが拡張子を理解することを示すことになる。サーバが拡張子を理解しないならば、サーバは拡張されないサーバのハローで応答し、クライアントは通常のように進んで拡張子を無視する。
【００１８】
新たな拡張子が理解されると、クライアントは自己の証明書メッセージの前に新たなハンドシェーク・メッセージを入れる。このメッセージの位置付けにより、サーバは証明書を検証（してマッピング）しなければならない前にマッピング情報を受け取ることができる。次いで、サーバはこのメッセージを構文解析し、クライアントのドメインを抽出し、証明書マッピングの際の使用のためにクライアントのドメインをコンテキストに格納する。
【００１９】
「サーバ処理」はマッピング機能に完全に含まれる。この点で、そこに拡張子情報があるならば、拡張子情報が用いられ、拡張子情報がない場合には、処理は通常どおりに進行する。拡張子を持たないことによるエラーがないことが望ましい。
【００２０】
クライアントはこの拡張子のイニシエータであるから、クライアントがユーザ・マッピング情報を送出する時点が決定される。この情報は常に送出されるけれども、この情報を常に任意のサーバにブロードキャストすることは望ましくない。これは、ユーザ・マッピング情報がクライアントとサーバとで使用するネットワーク・インフラストラクチャを明らかにすることができるからである。一方、この情報が明らかにされると、該情報を取り消す試みがなされないことになる。
【００２１】
ユーザ・マッピング情報の必要以上の送出を回避するよう、その配布を抑えるために種々の技術が用いられている。その例は、（１）「ハロー」の交換の際に同意した場合にのみ、クライアントは拡張子を送出し、それによって、ユーザ・マッピング情報を理解しないサーバに対して該情報が送出されるのを防止すること、及び、（２）送出しても「安全な」ドメインのリストにサーバが載っている場合にのみ、クライアントはユーザ・マッピング情報を送出することである。このリストは例えばレジストリに設定され得る。
【００２２】
こうして、図３に示すように、方法は、ステップ２００においてユーザ（例えば、クライアント）から受信者（例えば、サーバ）へ証明書と署名を送出することを含む。次いで、ステップ２１０において、受信者にヒント又はマッピング情報が送出されなければならないか否かが決定される。送出されなければならない場合には、次いで、ステップ２２０において、ヒント又はマッピング情報が受信者へ送出され、ヒント又はマッピング情報を用いて証明書がユーザ・アカウントにマッピングされる。ヒント又はマッピング情報が受信者に送出されるべきではないならば、ステップ２３０において、証明書は、ヒントの恩恵を受けることなくユーザ・アカウントにマッピングされるよう試みられる。
【００２３】
送出されるべきユーザ・マッピング情報の収集はプログラムにしたがって又は対話的に処理される。例えば、エスチャネルにおいて用いるための資格認定書を確立するために、ユーザ（例えば、エンド・ユーザのために動作するクライアント・プログラム）はSCHANNEL_CRED構造を構築し、これをAcquireCredentialsHandle()へ伝える。SCHANNEL_CRED構造により、ユーザは、（クライアントの証明書を添付している）資格認定書を構築するためにACH()が用いる証明書（CERT_CONTEXT）を供給することができる。代わりに、ユーザは証明書を特定せず、エスチャネルにユーザのデフォルトの証明書を選択させる。
【００２４】
ヒントをどのように実現するかの例として、ＵＰＮ及びＤＮＳドメイン名を抽出するために、NameUserPrincipalのEXTENDED_NAME_FORMAT及びNameDnsDomainを用いてGetUserNameEx()が２度呼び出される。NameUserPrincipal及びNameDnsDomainはPSPCredentialGroup構造に添付される。ユーザ名のための例示のヒントは、UNICODE_STRING UserPrincipalNameとしてメッセージにおいて提供され得る。ドメイン名の例示のヒントは、UNICODE_STRING DomainNameとしてメッセージにおいて提供され得る。
【００２５】
例えば、InitializeSecurityContext()は、そのパラメータの１つとして、コンテキストのターゲット（すなわち、セキュア・コンテキストを確立しているサーバの名称）を受け取る。InitializeSecurityContextはCheckUserMappingTarget()を呼び出し、その結果に対して以下のPSPContext構造フラグ、すなわち
BOOL fSendMappingExtension
をセットする。デフォルトにより、このフラグはセットされないので、クライアントは拡張子を送出しない。デバッグ・ログはフラグをセットする又はフラグをそのままにする判定を示す。
【００２６】
別の例として、ユーザ・マッピング拡張子が成功裡に交渉されたならば、ＵＰＮ及びドメインはPSPContext構造に置かれることが望ましい。この情報はマッピング処理の開始時に用いられて、証明書を基礎とするLsaLogonUser()(S4U2Self)のバージョンへ送られる。
【００２７】
上記の例の特徴は、ＳＳＬ及びＴＬＳに関係するプロトコルに関するものであった。また、本発明の特徴はケルベロスのようなプロトコルにおいて具体化される。ケルベロス拡張子は証明書を供給し、オプションとして、証明書がマッピングされるユーザ名をも供給する。ＫＤＣ（鍵分配センタ）はアカウント・マッピング及び検証を実施し、例えば、許可のために用いられるトークンを作るためにクライアントによって使用される認証データを返送する。
【００２８】
特に、例えばLsaLogonUser()呼び出しはヒントを含み得る。ネーム・ヒントがLsaLogonUser()へ送られる。例えば、メッセージにおいて、供給されるならば、UNICODE_STRING DomainName,//OPTIONALがフォレストを見つけるために用いられる。また、供給されるならば、UNICODE_STRING UserName,//OPTIONALがアカウントを見つけるために用いられる。ドメイン名は、マッピングされたユーザ・アカウントをどのドメインが含むかをクライアント（例えば、ユーザがログインしているローカルのマシン）に知らせる。
【００２９】
呼び出し側は、証明書が複数のユーザ・アカウントにマッピングされることを可能にするように、ユーザ名を供給することが許可される。ユーザ名が供給されると、ＫＤＣは当該ユーザ名を用いてユーザ・アカウントを見つけ、証明書がこのアカウントにマッピングされることを検証する。
【００３０】
ユーザ名ヒントが供給されず、ドメイン名が供給されるならば、ドメイン名は、認証のためにＫＤＣを見つけるためにケルベロス・クライアントに用いられ、ＫＤＣは証明書をユーザ・アカウントへマッピングする。subjectAltName拡張子を含まないクライアント証明書をサポートすることが望ましい。こうした証明書はActiveDirectoryアカウントへマッピングされる。アカウント・マッピング問題に対して、包括的且つ拡張可能な解決法が証明書に用意される。
【００３１】
証明書がsubjectAltName/UPN拡張子を含むならば、ＫＤＣは当該拡張子を用いてクライアントをマッピングする。この場合、クライアント証明書はNT_AUTHポリシーを満足することが望ましい。ＵＰＮに基づいてユーザ・オブジェクトが見出されない場合、認証は不成功に終わるべきである。
【００３２】
証明書にＵＰＮがない場合、ＫＤＣは検索のための゛X509:<I><S>″AltSecID名を構築する。この場合、クライアント証明書はNT_AUTHポリシーを満足する必要はない。
【００３３】
証明書にＵＰＮがなく、上記のステップにおいてユーザ・オブジェクトが見つかったことがない場合、サブジェクトの著名な名称に基づいてクライアント・アカウントが検索され、ＫＤＣは検索のための゛X509:<S>″AltSecID名を構築する。この場合、クライアント証明書はNT_AUTHポリシーを満足することが望ましい。
【００３４】
証明書にＵＰＮがなく、上記のステップにおいてユーザ・オブジェクトが見つからない場合、ＫＤＣはサブジェクトと連番とを用いて、検索のための゛X509:<I><SR>″AltSecID名を構築する。この場合、クライアント証明書はNT_AUTHポリシーを満足する必要はない。
【００３５】
証明書にＵＰＮがなく、ユーザ・オブジェクトが見つからず、クライアント証明書がＳＫＩIを含む場合、ＫＤＣは検索のための゛X509:<SKI>″AltSecID名を構築する。この場合、クライアント証明書はNT_AUTHポリシーを満足する必要はない。
【００３６】
証明書にＵＰＮがなく、上記のステップにおいてユーザ・オブジェクトが見つからない場合、ＫＤＣは検索のための゛X509:<SHA1-PUKEY>″AltSecID名を構築する。この場合、クライアント証明書はNT_AUTHポリシーを満足する必要はない。
【００３７】
証明書にＵＰＮがなく、上記のステップにおいてユーザ・オブジェクトが見つからない場合、クライアント・アカウントがSAN/822nameに基づいて検索され、ＫＤＣは検索のための”X509:<RFC822>″AltSecIDを構築する。この場合、クライアント証明書はNT_AUTHポリシーを満足することが望ましい。
【００３８】
留意されるように、上記のステップ及び基準は、単独で又は任意の組み合わせ又は順序で用いられる。追加のステップ及び基準も用いられ得る。アカウントを成功裡に見つける第１のステップ又は基準が成功すると検索が停止することが望ましい。しかし、同一の証明書を異なるユーザ・アカウントへマッピングする２つのマッピング方法が存在する場合には、構成エラーが生じ得る。
【００３９】
留意されるように、クライアント証明書がＵＰＮを持たず、証明書におけるクライアントのＤＮがユーザ・アカウントのＤＮと一致するが、ユーザ・アカウントがマッピングされない場合、認証は不成功であるべきである。
【００４０】
例示のコンピュータ環境
図４は、本発明が実施される適宜のコンピューティング・システム環境８００の例を示している。コンピューティング・システム環境８００は適宜のコンピュータ環境の一例にすぎず、発明の用途及び機能の範囲を限定するものではない。コンピュータ環境８００を、例示の動作環境８００に示す任意の１つの構成要素又は構成要素の組み合わせに関係する依存性又は要件を持つものと解釈してはならない。
【００４１】
本発明は、他の多くの汎用の又は特定用途のコンピューティング・システム環境又は構成と共に動作可能である。本発明と共に使用するのに適したコンピューティング・システム、環境及び／又は構成は、パーソナル・コンピュータ、サーバ・コンピュータ、携帯型又はラップトップ装置、マルチプロセッサ・システム、マイクロプロセッサ型のシステム、セットトップ・ボックス、プログラム可能な家庭用電気機器、ネットワークＰＣ、ミニコンピュータ、メインフレーム・コンピュータ、任意の上記システム及び装置を含む分散型コンピュータ環境を含むが、これらに限定されない。
【００４２】
本発明は、コンピュータによって実行されるプログラム・モジュールのようなコンピュータ実行可能命令の一般的な文脈で記述される。一般に、プログラム・モジュールは、特定のタスクを実施し又は特定の抽象的なデータ形式を実施するルーチン、プログラム、オブジェクト、データ構造等を含む。また、本発明は、通信ネットワーク又は他のデータ伝送媒体を介してリンクされるリモート処理装置によってタスクが実施される分散型コンピュータ環境において実施され得る。分散型コンピュータ環境においては、プログラム・モジュール及び他のデータは、メモリ記憶装置を含むローカルの及びリモートのコンピュータ記憶媒体に配置され得る。
【００４３】
図４を参照すると、本発明を実施するための例示のシステムは、コンピュータ８１０の形の汎用コンピューティング装置を備えている。コンピュータ８１０の構成要素は、処理ユニット８２０、システム・メモリ８３０、及び、システム・メモリを含む種々のシステム構成要素を処理ユニット８２０に接続するシステム・バス８２１を含む。システム・バス８２１は、種々のバス構造を用いたメモリ・バス又はメモリ・コントローラ、ペリフェラル・バス及びローカル・バスを含む複数の型式のバス・アーキテクチャのうちの任意のものであり得る。例えば、こうしたアーキテクチャは産業標準アーキテクチャ（ＩＳＡ）、マイクロチャネル・アーキテクチャ（ＭＣＡ）、エンハンストＩＳＡ（ＥＩＳＡ）バス、ビデオ・エレクトロニクス基準協会（ＶＥＳＡ）バス、周辺コンポーネント相互接続（ＰＣＩ）バス（メザニン・バスとしても知られている）を含むが、これらに限定されない。
【００４４】
典型的には、コンピュータ８１０は種々のコンピュータ読み取り可能媒体を備える。コンピュータ読み取り可能媒体は、コンピュータ８１０によってアクセス可能な任意の利用可能な媒体であり、揮発性及び不揮発性の媒体並びに取り外し可能及び取り外し不可能な媒体を含む。例えば、コンピュータ読み取り可能媒体はコンピュータ記憶媒体及び通信媒体を含むが、これらに限定されない。
【００４５】
コンピュータ記憶媒体は、コンピュータ読み取り可能命令、データ構造、プログラム・モジュール又は他のデータのような情報を記憶するための方法又は技術において実装される揮発性及び不揮発性で取り外し可能及び取り外し不可能な媒体を含む。コンピュータ記憶媒体はＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリ又は他のメモリ技術、ＣＤ−ＲＯＭ、ディジタル・バーサタイル・ディスク（ＤＶＤ）又は他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置又は他の磁気記憶装置、或いは、所望の情報を記憶するのに用いられ且つコンピュータ８１０がアクセスできる任意の他の媒体を含むが、これらに限定されない。
【００４６】
通信媒体は、典型的には、コンピュータ読み取り可能命令、データ構造、プログラム・モジュール又は他のデータを搬送波又は他の移送機構のような変調データ信号において具現するものであり、任意の情報配信媒体を含む。用語「変調データ信号」は、その特性の組の１つ以上を備えた信号又は情報を符号化するように変更された信号を意味する。例えば、通信媒体は、有線ネットワーク又は直接有線接続のような有線媒体や、音響、ＲＦ、赤外線及びその他の無線媒体を含む無線媒体を含むが、これらに限定されない。上記の媒体の任意の組み合わせもコンピュータ読み取り可能媒体の範囲内に含まれる。
【００４７】
システム・メモリ８３０はＲＯＭ８３１及びＲＡＭ８３２のような揮発性及び／又は不揮発性のメモリの形のコンピュータ記憶媒体を含む。基本入力／出力システム８３３（ＢＩＯＳ）は、例えば起動期間にコンピュータ８１０の要素間で情報を転送するのを助ける基本ルーチンを含んでおり、典型的にはＲＯＭ８３１に記憶される。典型的には、ＲＡＭ８３２は、処理ユニット８２０に対して即座にアクセス可能であり及び／又は処理ユニットによって動作されているデータ及び／又はプログラム・モジュールを含む。例えば、図４はオペレーティング・システム８３４、アップリケーション・プログラム８３５、他のプログラム・モジュール８３６及びプログラム・データ８３７を示しているが、これらに限定されない。
【００４８】
また、コンピュータ８１０は他の取り外し可能／取り外し不可能な揮発性／不揮発性のコンピュータ記憶媒体を含む。例示のみであるが、図４は、取り外し不可能な不揮発性磁気媒体との間で読み出し、書き込みを行うハードディスク・ドライブ８４０、取り外し可能な不揮発性磁気ディスク８５２との間で読み出し、書き込みを行う磁気ディスク・ドライブ８５１、及び、ＣＤ−ＲＯＭその他の光媒体のような取り外し可能な不揮発性光ディスク８５６との間で読み取り、書き込みを行う光ディスク・ドライブ８５５を示している。例示の動作環境において使用可能な他の取り外し可能／取り外し不可能な揮発性／不揮発性コンピュータ記憶媒体は、磁気テープ・カセット、フラッシュメモリ・カード、ディジタル・バーサタイル・ディスク、ディジタル・ビデオ・テープ、固体ＲＡＭ等を含むが、これらに限定されない。典型的には、ハードディスク・ドライブ８４１はインターフェース８４０のような取り外し不可能メモリ・インターフェースを介してシステム・バス８２１と接続され、磁気ディスク・ドライブ８５１及び光ディスク・ドライブ８５５は、典型的には、インターフェース８５０のような取り外し可能メモリ・インターフェースによってシステム・バス８２１と接続される。
【００４９】
ドライブとその関連のコンピュータ記憶媒体は、コンピュータ８１０のためのコンピュータ読み取り可能命令、データ構造、プログラム・モジュール及び他のデータの記憶装置を提供する。例えば、図４においては、ハードディスク・ドライブ８４１はオペレーティング・システム８４４、アプリケーション・プログラム８４５、他のプログラム・モジュール８４６及びプログラム・データ８４７を記憶するものとして図示されている。留意されるように、これらの構成要素はオペレーティング・システム８３４、アプリケーション・プログラム８３５、他のプログラム・モジュール８３６及びプログラム・データ８３７と同じであっても、違っていてもよい。ここでオペレーティング・システム８４４、アプリケーション・プログラム８４５、他のプログラム・モジュール８４６及びプログラム・データ８４７に別の番号を付したのは、異なるものであることを示すためである。
【００５０】
ユーザは、マウス、トラックボール、タッチパッドとして通常呼ばれるポインティング・デバイス８６１やキーボード８６２などの入力装置を介して、コンピュータ８１０にコマンド及び情報を入力する。他の入力装置（図示せず）はマイクロホン、ジョイスティック、ゲームパッド、衛星アンテナ、スキャナ等を含み得る。これらの及び他の入力装置は、システムと結合されたユーザ入力インターフェース８６０を介して処理ユニット８２０と接続されることが多いが、パラレル・ポート、ゲーム・ポート又はユニバーサル・シリアル・バス（ＵＳＢ）等の他のインターフェース及びバス構造によって接続されてもよい。また、モニタ８９１及び他の形式の表示装置が、ビデオ・インターフェース８９０のようなインターフェースを介してシステム・バス８２１と接続される。モニタに加えて、コンピュータは、出力周辺インターフェース８９５を介して接続される、スピーカ８９７及びプリンタ８９６のような他の周辺出力装置を備え得る。
【００５１】
コンピュータ８１０は、リモート・コンピュータ８８０のような１つ以上のリモート・コンピュータとの論理接続を用いたネットワーク環境において動作し得る。リモート・コンピュータ８８０はパーソナル・コンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置又は他の共通ネットワーク・ノードであり得、典型的には、コンピュータ８１０に関して上で説明した多くの又は全部の要素を備えるが、図４にはメモリ記憶装置８８１のみが示されている。図示の論理接続はＬＡＮ８７１及びＷＡＮ８７３を含むが、他のネットワークをも含み得る。こうしたネットワーク環境はオフィス、企業規模の広域コンピュータ・ネットワーク、イントラネット及びインターネットにおいて一般的である。
【００５２】
ＬＡＮネットワーキング環境において用いられるとき、コンピュータ８１０はネットワーク・インターフェース又はアダプタ８７０を介してＬＡＮ８７１と接続される。ＷＡＮネットワーキング環境において用いられるとき、典型的には、コンピュータ８１０はモデム８７２や、インターネットのような，ＷＡＮ８７３を介して通信を確立する他の手段を備える。外付け又は内蔵のモデム８７２はユーザ入力インターフェース８６０又は他の適宜の機構を介してシステム・バス８２１と接続される。ネットワーク環境においては、コンピュータ８１０又はその一部に関して図示されているプログラム・モジュールはリモート・メモリ記憶装置に記憶され得る。図４は、メモリ装置８８１上に常駐するものとしてリモート・悪利けーション・プログラム８８５を図示している。理解されるように、図示のネットワーク接続は例示であり、コンピュータ間の通信リンクを確立する他の手段を用いることができる。
【００５３】
上で説明したように、本発明の例示の実施の形態を種々のコンピューティング装置と関連させて説明してきたが、その基礎となる概念は任意のコンピューティング装置又はシステムに対して適用され得る。
【００５４】
ここで記述された種々の技術はハードウェア又はソフトウェアとの関連において、及び、適切であれば、ハードウェアとソフトウェアの組み合わせとの関連において実現され得る。こうして、本発明の方法及び装置、或いは本発明の或る特徴又は一部は、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ、ハードドライブ又は他の任意の機械読み取り可能記憶媒体のような有形媒体において具現化されるプログラム・コード（すなわち命令）の形を取り得、プログラム・コードがコンピュータ等の機械にロードされて実行されるとき、機械は本発明を実施するための装置となる。プログラム可能なコンピュータ上でのプログラム・コードの実行の場合、一般に、コンピューティング装置は、プロセッサと、該プロセッサによって読み取り可能な（揮発性及び不揮発性のメモリ及び／又は記憶素子を含む）記憶媒体と、少なくとも１つの入力装置と、少なくとも１つの出力装置とを備える。所望であれば、プログラムはアセンブリ言語又は機械語で実現される。いずれにしても、言語は編集又は解釈された言語であり、ハードウェア実装と結合され得る。
【００５５】
また、本発明の方法及びシステムは、電線やケーブル、光ファイバ又は他の任意の伝送形式等の伝送媒体を介して伝送されるプログラム・コードの形に具現化される通信によって実施され得る。プログラム・コードがＥＥＰＲＯＭ、ゲートアレイ、プログラム可能論理デバイス（ＰＬＤ）、クライアント・コンピュータ等のマシンによって受信され、ロードされ、実行されるとき、このマシンは本発明を実施するための装置となる。汎用プロセッサ上で実施されるとき、プログラム・コードはプロセッサと組み合わされて、本発明の機能を行使する独自の装置を提供する。さらに、本発明と結合して用いられる記憶技術は必ずハードウェアとソフトウェアとの組み合わせであり得る。
【００５６】
種々の図面の好ましい実施の形態との関連で本発明を説明してきたが、理解されるように、他の同様の実施の形態を用いることができ、本発明から逸脱することなく本発明と同じ機能を実施するために、説明してきた実施の形態に対して修正及び追加を行うことができる。したがって、本発明は任意の単一の実施の形態に限定されるべきではなく、特許請求の範囲にしたがって幅と範囲を解釈されるべきである。
【図面の簡単な説明】
【００５７】
【図１】例示のマッピング方法のフロー図である。
【図２】ハンドシェーク付きの例示のクライアント−サーバ・マッピング・システムの図である。
【図３】他の例示のマッピング方法のフロー図である。
【図４】本発明の特徴が実現される、例示のコンピュータ環境を示すブロック図である。
【特許請求の範囲】
【請求項１】
認証方法であって、
第１のコンピュータ装置から第２のコンピュータ装置へマッピング拡張子インジケータを送出するステップと、
受信した前記マッピング拡張子インジケータに応じて前記第２のコンピュータ装置がマッピング情報を受け入れることができることを知らせるステップと、
前記マッピング情報を前記第２のコンピュータ装置へ送出するステップと、
を備える方法。
【請求項２】
前記マッピング情報に基づいてアカウント又は認証サーバを見つけるステップを更に備える、請求項１に記載の方法。
【請求項３】
前記認証サーバがドメイン・コントローラを備える、請求項２に記載の方法。
【請求項４】
前記アカウント又は前記認証サーバを見つけた後にアプリケーション・データを導出するステップを更に備える、請求項２に記載の方法。
【請求項５】
前記第１のコンピュータ装置から前記第２のコンピュータ装置へ証明書を送出するステップを更に備える、請求項１に記載の方法。
【請求項６】
前記マッピング情報と前記証明書とに基づいてユーザをアカウントへマッピングするステップを更に備える、請求項５に記載の方法。
【請求項７】
前記マッピング情報を用いて前記証明書をユーザ・アカウントへマッピングするステップを更に備える、請求項５に記載の方法。
【請求項８】
前記第２のコンピュータ装置が前記マッピング情報をサポートするかどうかを決定するステップと、サポートする場合に、前記第２のコンピュータ装置が前記マッピング情報を受け入れることができることを知らせるステップと、前記マッピング情報を前記第２のコンピュータ装置へ送出するステップとを更に備える、請求項１に記載の方法。
【請求項９】
認証方法であって、
第１のコンピュータ装置から第２のコンピュータ装置へマッピング情報と証明書とを送出するステップと、
前記マッピング情報に基づいてアカウント又は認証サーバ・コントローラをみつけるステップと、
を備える方法。
【請求項１０】
前記認証サーバがドメイン・コントローラを備える、請求項９に記載の方法。
【請求項１１】
前記マッピング情報がドメイン名ヒント又はユーザ名ヒントを備える、請求項９に記載の方法。
【請求項１２】
前記マッピング情報がプロトコル拡張子メカニズムの形式である、請求項９に記載の方法。
【請求項１３】
前記マッピング情報及び前記証明書に基づいてユーザを認証するステップを更に備える、請求項９に記載の方法。
【請求項１４】
前記マッピング情報を用いて前記証明書をユーザにマッピングするステップを更に備える、請求項９に記載の方法。
【請求項１５】
前記マッピング情報を前記第２のコンピュータ装置へ送出する前に、前記第２のコンピュータ装置が前記マッピング情報をサポートするかどうかを決定するステップを更に備える、請求項９に記載の方法。
【請求項１６】
前記第１のコンピュータ装置に対して、前記第２のコンピュータ装置が前記マッピング情報をサポートを受け入れることができることを知らせるステップを更に備える、請求項１５に記載の方法。
【請求項１７】
マッピング情報と証明書とを含むデータ構造を記憶したコンピュータ読み取り可能な媒体。
【請求項１８】
前記マッピング情報がプロトコル拡張子の形式である、請求項１７に記載のコンピュータ読み取り可能な媒体。
【請求項１９】
前記マッピング情報が、ドメイン名ヒント、ユーザ名ヒント又は前記証明書をアカウントへマッピングするためのデータを備える、請求項１７に記載のコンピュータ読み取り可能な媒体。
【請求項２０】
前記マッピング情報が、前記証明書と該証明書がマッピングされる随意のユーザ名とを供給するケルベロス拡張子である、請求項１７に記載の方法。
【請求項１】
認証方法であって、
第１のコンピュータ装置から第２のコンピュータ装置へマッピング拡張子インジケータを送出するステップと、
受信した前記マッピング拡張子インジケータに応じて前記第２のコンピュータ装置がマッピング情報を受け入れることができることを知らせるステップと、
前記マッピング情報を前記第２のコンピュータ装置へ送出するステップと、
を備える方法。
【請求項２】
前記マッピング情報に基づいてアカウント又は認証サーバを見つけるステップを更に備える、請求項１に記載の方法。
【請求項３】
前記認証サーバがドメイン・コントローラを備える、請求項２に記載の方法。
【請求項４】
前記アカウント又は前記認証サーバを見つけた後にアプリケーション・データを導出するステップを更に備える、請求項２に記載の方法。
【請求項５】
前記第１のコンピュータ装置から前記第２のコンピュータ装置へ証明書を送出するステップを更に備える、請求項１に記載の方法。
【請求項６】
前記マッピング情報と前記証明書とに基づいてユーザをアカウントへマッピングするステップを更に備える、請求項５に記載の方法。
【請求項７】
前記マッピング情報を用いて前記証明書をユーザ・アカウントへマッピングするステップを更に備える、請求項５に記載の方法。
【請求項８】
前記第２のコンピュータ装置が前記マッピング情報をサポートするかどうかを決定するステップと、サポートする場合に、前記第２のコンピュータ装置が前記マッピング情報を受け入れることができることを知らせるステップと、前記マッピング情報を前記第２のコンピュータ装置へ送出するステップとを更に備える、請求項１に記載の方法。
【請求項９】
認証方法であって、
第１のコンピュータ装置から第２のコンピュータ装置へマッピング情報と証明書とを送出するステップと、
前記マッピング情報に基づいてアカウント又は認証サーバ・コントローラをみつけるステップと、
を備える方法。
【請求項１０】
前記認証サーバがドメイン・コントローラを備える、請求項９に記載の方法。
【請求項１１】
前記マッピング情報がドメイン名ヒント又はユーザ名ヒントを備える、請求項９に記載の方法。
【請求項１２】
前記マッピング情報がプロトコル拡張子メカニズムの形式である、請求項９に記載の方法。
【請求項１３】
前記マッピング情報及び前記証明書に基づいてユーザを認証するステップを更に備える、請求項９に記載の方法。
【請求項１４】
前記マッピング情報を用いて前記証明書をユーザにマッピングするステップを更に備える、請求項９に記載の方法。
【請求項１５】
前記マッピング情報を前記第２のコンピュータ装置へ送出する前に、前記第２のコンピュータ装置が前記マッピング情報をサポートするかどうかを決定するステップを更に備える、請求項９に記載の方法。
【請求項１６】
前記第１のコンピュータ装置に対して、前記第２のコンピュータ装置が前記マッピング情報をサポートを受け入れることができることを知らせるステップを更に備える、請求項１５に記載の方法。
【請求項１７】
マッピング情報と証明書とを含むデータ構造を記憶したコンピュータ読み取り可能な媒体。
【請求項１８】
前記マッピング情報がプロトコル拡張子の形式である、請求項１７に記載のコンピュータ読み取り可能な媒体。
【請求項１９】
前記マッピング情報が、ドメイン名ヒント、ユーザ名ヒント又は前記証明書をアカウントへマッピングするためのデータを備える、請求項１７に記載のコンピュータ読み取り可能な媒体。
【請求項２０】
前記マッピング情報が、前記証明書と該証明書がマッピングされる随意のユーザ名とを供給するケルベロス拡張子である、請求項１７に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公表番号】特表２００９−５０１９７３（Ｐ２００９−５０１９７３Ａ）
【公表日】平成２１年１月２２日（２００９．１．２２）
【国際特許分類】
【出願番号】特願２００８−５２１６０１（Ｐ２００８−５２１６０１）
【出願日】平成１８年７月１２日（２００６．７．１２）
【国際出願番号】ＰＣＴ／ＵＳ２００６／０２７１８２
【国際公開番号】ＷＯ２００７／０１１６３７
【国際公開日】平成１９年１月２５日（２００７．１．２５）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
【公表日】平成２１年１月２２日（２００９．１．２２）
【国際特許分類】
【出願日】平成１８年７月１２日（２００６．７．１２）
【国際出願番号】ＰＣＴ／ＵＳ２００６／０２７１８２
【国際公開番号】ＷＯ２００７／０１１６３７
【国際公開日】平成１９年１月２５日（２００７．１．２５）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
[ Back to top ]