Windows 認証での資格情報の処理
適用対象: Windows Server 2022、Windows Server 2019、Windows Server 2016
IT 担当者向けのこのリファレンス トピックでは、Windows 認証資格で資格情報がどのように処理されるかについて説明します。
Windows 資格情報の管理とは、オペレーティング システムがサービスまたはユーザーから資格情報を受け取り、将来認証先に提示するためにその情報を保護するプロセスです。 ドメインに参加しているコンピューターの場合、認証先はドメイン コントローラーです。 認証に使用される資格情報は、証明書、パスワード、PIN など、ユーザー身元をなんらかの形で証明するためのデジタル文書です。
既定では、Windows の資格情報は、ローカル コンピューターのセキュリティ アカウント マネージャー (SAM) データベース、またはドメインに参加しているコンピューター上の Active Directory に対して、Winlogon サービスを介して検証されます。 認証情報は、ログオン ユーザー インターフェースのユーザー入力、またはアプリケーション プログラミング インターフェース (API) 経由でプログラムによってに収集され、認証先に提示されます。
ローカル セキュリティ情報は、HKEY_LOCAL_MACHINE\SECURITY の下のレジストリに格納されます。 格納される情報には、ポリシー設定、既定のセキュリティ値、アカウント情報 (キャッシュされたログオン資格情報など) が含まれます。 SAM データベースのコピーもここに格納されますが、書き込み禁止になっています。
次の図は、ログオンを成功させるためにユーザーまたはプロセスを認証するために必要なコンポーネントと、システムにおける資格情報の通過経路を示しています。
次の表では、認証プロセスにおけるログオン時に資格情報を管理する各コンポーネントについて説明しています。
すべてのシステムの認証コンポーネント
| コンポーネント | 説明 |
|---|---|
| ユーザー ログオン | Winlogon.exe は、セキュリティで保護されたユーザー操作を管理するための実行可能ファイルです。 Winlogon サービスは、セキュリティで保護されたデスクトップ (ログオン UI) のユーザー アクションによって収集された資格情報を Secur32.dll 経由でローカル セキュリティ機関 (LSA) に渡し、Windows オペレーティング システムのログオン プロセスを開始します。 |
| アプリケーションのログオン | 対話型ログオンを必要としないアプリケーションまたはサービスのログオン。 ユーザーによって開始されるほとんどのプロセスは、Secur32.dll を使用してユーザー モードで実行されます。一方、サービスなど、起動時に開始されるプロセスは、Ksecdd.sys を使用してカーネル モードで実行されます。 ユーザー モードとカーネル モードの詳細については、このトピックの「アプリケーションとユーザー モード」または「サービスとカーネル モード」を参照してください。 |
| Secur32.dll | 認証プロセスの基盤となる複数の認証プロバイダー。 |
| Lsasrv.dll | LSA サーバー サービスは、セキュリティ ポリシーを適用し、LSA のセキュリティ パッケージ マネージャーとしても機能します。 LSA には Negotiate 関数が含まれており、これは成功するプロトコルを判断した後に NTLM または Kerberos プロトコルを選択します。 |
| セキュリティ サポート プロバイダー | 1 つ以上の認証プロトコルを個別に呼び出すプロバイダーのセット。 既定のプロバイダー セットは、Windows オペレーティング システムのバージョンごとに変更でき、カスタム プロバイダーを記述することもできます。 |
| Netlogon.dll | Net Logon サービスが実行するサービスは次のとおりです。 - コンピューターからドメイン コントローラーへのセキュリティで保護されたチャネル (Schannel とは異なります) を維持します。 |
| Samsrv.dll | ローカルのセキュリティ アカウントを格納し、ローカルに保存されたポリシーを実施し、API をサポートするセキュリティ アカウント マネージャー (SAM) です。 |
| Registry | レジストリには、SAM データベースのコピー、ローカル セキュリティ ポリシー設定、既定のセキュリティ値、およびシステムからのみアクセス可能なアカウント情報が含まれます。 |
このトピックは、次のセクションで構成されています。
ユーザー ログオンのための資格情報の入力
Windows Server 2008 および Windows Vista では、Graphical Identification and Authentication (GINA) アーキテクチャが資格情報プロバイダー モデルに置き換えられたため、ログオン タイルを使用してさまざまなログオンの種類を列挙することができるようになりました。 この両方のモデルの詳細については、以下のとおりです。
Graphical Identification and Authentication アーキテクチャ
Graphical Identification and Authentication (GINA) アーキテクチャは、Windows Server 2003、Microsoft Windows 2000 Server、Windows XP、および Windows 2000 Professional オペレーティング システムに適用されています。 これらのシステムでは、対話型ログオン セッションが行われるたびに、Winlogon サービスの個別のインスタンスが作成されます。 GINA アーキテクチャは、Winlogon によって使用されるプロセス領域に読み込まれ、資格情報を受け取って処理し、LSALogonUser を介して認証インターフェイスを呼び出します。
対話型ログオンの Winlogon のインスタンスは、セッション 0 で実行されます。 セッション 0 は、システム サービスや、ローカル セキュリティ機関 (LSA) プロセスを含む他の重要なプロセスをホストします。
次の図は、Windows Server 2003、Microsoft Windows 2000 Server、Windows XP、および Microsoft Windows 2000 Professional の認証プロセスを示しています。
資格情報プロバイダー アーキテクチャ
資格情報プロバイダー アーキテクチャは、このトピックの冒頭にある適用対象リストで指定されているバージョンに適用されます。 これらのシステムでは、資格情報プロバイダーを使用することで、資格情報の入力アーキテクチャが拡張可能な設計に変更されました。 これらのプロバイダーは、セキュリティで保護されたデスクトップ上に表示される様々なログオン タイルで表され、同じユーザーの異なるアカウントや異なる認証方法 (パスワード、スマート カード、生体認証など) など、任意の数のログオン シナリオに対応します。
資格情報プロバイダー アーキテクチャでは、Winlogon は Secure Attention Sequence イベントを受け取った後、常にログオン UI を開始します。 ログオン UI は、プロバイダーが列挙するように構成されているさまざまな資格情報の種類の数について、各資格情報プロバイダーに対してクエリを実行します。 資格情報プロバイダーは、これらのタイルの 1 つを既定に指定することができます。 すべてのプロバイダーによってタイルが列挙されると、ログオン UI によってユーザーに表示されます。 ユーザーはタイルを操作して資格情報を指定します。 ログオン UI からこれらの資格情報が送信され、認証が行われます。
資格情報プロバイダーは強制メカニズムではありません。 これは、資格情報を収集し、シリアル化するために使用されます。 ローカル セキュリティ機関と認証パッケージでは、セキュリティが強制されます。
資格情報プロバイダーはコンピューターに登録され、以下の機能を担当します。
認証に必要な資格情報の記述。
外部認証機関との通信とロジックの処理。
対話型ログオンとネットワーク ログオン用の資格情報のパッケージ化。
対話型ログオンとネットワーク ログオン用の資格情報のパッケージ化には、シリアル化のプロセスが含まれます。 資格情報をシリアル化することで、ログオン UI に複数のログオン タイルを表示できます。 そのため、組織は、カスタマイズされた資格情報プロバイダーを使用して、ユーザー、ログオン先のシステム、ログオン前のネットワークへのアクセス、ワークステーションのロックまたはロック解除ポリシーなどのログオン表示を制御することができます。 資格情報プロバイダーは、1 つのコンピューター上に複数存在することができます。
シングル サインオン (SSO) プロバイダーは、標準の資格情報プロバイダーとして、または Pre-Logon-Access Provider として開発できます。
Windows の各バージョンには、既定の資格情報プロバイダー 1 つと、SSO プロバイダーとも呼ばれる既定の Pre-Logon-Access Provider (PLAP) が 1 つ含まれています。 SSO プロバイダーを使用することで、ユーザーはローカル コンピューターにログオンせずにネットワークに接続することができます。 このプロバイダーが実装されている場合、プロバイダーによってログオン UI のタイルの列挙は行われません。
SSO プロバイダーは、以下のようなシナリオで使用することを想定しています。
ネットワーク認証とコンピューターのログオンが、異なる資格情報プロバイダーによって処理されている場合。 このシナリオのバリエーションには、以下のようなものが含まれます。
ユーザーは、コンピューターにログオンする前に仮想プライベート ネットワーク (VPN) に接続するなど、ネットワークに接続することができるが、この接続を行う必要はない場合。
ローカル コンピューターの対話型認証で使用される情報を取得するために、ネットワーク認証が必要な場合。
複数のネットワーク認証の後に、他のシナリオのいずれかが続く場合。 たとえば、ユーザーがインターネット サービス プロバイダー (ISP) で認証を受け、VPN で認証を受けた後、ユーザー アカウントの資格情報を使用してローカルにログオンする場合などです。
キャッシュされた資格情報が無効で、ユーザーを認証するためにローカル ログオンする前に、VPN を経由してリモート アクセス サービス接続を行う必要がある場合。
ドメイン ユーザーがドメインに参加しているコンピューターにローカル アカウントを設定しておらず、対話型ログオンを完了する前に VPN 接続によってリモート アクセス サービス接続を確立する必要がある場合。
ネットワーク認証とコンピューターのログオンが同じ資格情報プロバイダーによって処理されている場合。 このシナリオでは、ユーザーはコンピューターにログオンする前にネットワークに接続する必要があります。
ログオン タイルの列挙
資格情報プロバイダーは、次のようなインスタンスにおいてログオン タイルを列挙します。
このトピックの最初の [適用対象] 一覧で指定されているオペレーティング システムの場合。
資格情報プロバイダーは、ワークステーションのログオン用のタイルを列挙します。 ローカル セキュリティ機関で認証を受けるため、資格情報は通常、資格情報プロバイダーによってシリアル化されます。 このプロセスにより、各ユーザーおよび各ユーザーのターゲット システムに固有のタイルが表示されます。
ログオンと認証のアーキテクチャを使用すると、ユーザーは資格情報プロバイダーによって列挙されたタイルを使用してワークステーションのロックを解除できます。 通常、現在ログオンしているユーザーが既定のタイルとなりますが、複数のユーザーがログオンしている場合は、多数のタイルが表示されます。
資格情報プロバイダーは、パスワードや PIN などの個人情報を変更するユーザーの要求に応答してタイルを列挙します。 通常、現在ログオンしているユーザーが既定のタイルとなりますが、複数のユーザーがログオンしている場合は、多数のタイルが表示されます。
資格情報プロバイダーは、リモート コンピューターでの認証に使用されるシリアル化された資格情報に基づいてタイルを列挙します。 資格情報 UI では、ログオン UI、ワークステーションのロック解除、またはパスワードの変更とは異なるインスタンスが使用されます。 そのため、資格情報 UI のインスタンス間で状態情報をプロバイダーに保持することはできません。 この構造では、資格情報が正しくシリアル化されていることを前提として、リモート コンピューターのログオンごとに 1 つのタイルが生成されます。 このシナリオは、ユーザー アカウント制御 (UAC) でも使用されます。これにより、コンピューターの動作に影響を与える可能性のある操作や、コンピューターの他のユーザーに影響を与える可能性のある設定を変更する前に、ユーザーに許可または管理者パスワードを求めることで、コンピューターへの不正な変更を防止することができます。
次の図は、このトピックの冒頭にある適用対象の一覧で指定されているオペレーティング システムの資格情報プロセスを示しています。
アプリケーションとサービス ログオンのための資格情報の入力
Windows 認証は、ユーザーの操作を必要としないアプリケーションやサービスの資格情報を管理するように設計されています。 ユーザー モードのアプリケーションでは、アクセスできるシステム リソースが制限されますが、サービスはシステム メモリや外部デバイスに無制限にアクセスできます。
システム サービスとトランスポート レベルのアプリケーションは、Windows のセキュリティ サポート プロバイダー インターフェイス (SSPI) を介してセキュリティ サポート プロバイダー (SSP) にアクセスし、システム上で利用できるセキュリティ パッケージの列挙、パッケージの選択、およびそのパッケージを使用して認証された接続を確保する機能を提供します。
クライアントまたはサーバー接続が認証されている場合:
接続のクライアント側のアプリケーションは、SSPI 関数
InitializeSecurityContext (General)を使用してサーバーに資格情報を送信します。接続のサーバー側のアプリケーションは、SSPI 関数
AcceptSecurityContext (General)で応答します。SSPI 関数
InitializeSecurityContext (General)とAcceptSecurityContext (General)は、認証を成功または失敗させるために必要なすべての認証メッセージの交換が完了するまで繰り返されます。接続が認証されると、サーバー上の LSA はクライアントからの情報を使用して、アクセス トークンを含むセキュリティ コンテキストを構築します。
その後、サーバーは SSPI 関数
ImpersonateSecurityContextを呼び出して、サービスの偽装スレッドにアクセス トークンをアタッチできます。
アプリケーションとユーザー モード
Windows のユーザー モードは、I/O 要求を適切なカーネル モード ドライバーに渡す 2 つのシステムで構成されます。これは、さまざまな種類のオペレーティング システム向けに記述されたアプリケーションを実行する環境システムと、環境システムに代わってシステム固有の機能を操作する統合システムです。
統合システムは、環境システムに代わってオペレーティング システム固有の機能を管理し、セキュリティ システム プロセス (LSA)、ワークステーション サービス、およびサーバー サービスで構成されます。 セキュリティ システム プロセスは、セキュリティ トークンを処理し、リソースのアクセス許可に基づいてユーザー アカウントへのアクセス許可を許可または拒否し、ログオン要求を処理してログオン認証を開始し、オペレーティング システムが監査する必要があるシステム リソースを決定します。
アプリケーションは、ローカル システム (SYSTEM) のセキュリティ コンテキストを含む、アプリケーションを任意のプリンシパルとして実行できるユーザー モードで実行できます。 また、アプリケーションは、アプリケーションをローカル システム (SYSTEM) のセキュリティ コンテキストで実行できるカーネル モードで実行することもできます。
SSPI は、認証、メッセージの整合性、およびメッセージのプライバシーのために統合セキュリティ サービスを取得するために使用される API である、 Secur32.dll モジュールを通じて利用できます。 これは、アプリケーションレベルのプロトコルとセキュリティ プロトコルの間の抽象化レイヤーを提供します。 アプリケーションによって、ユーザーを識別または認証する方法や、ネットワーク上を移動するデータを暗号化する方法が異なるため、SSPI では、さまざまな認証および暗号化機能を含むダイナミックリンク ライブラリ (DLL) にアクセスする方法を提供しています。 これらの DLL は、セキュリティ サポート プロバイダー (SSP) と呼ばれています。
管理されたサービス アカウントと仮想アカウントは、Microsoft SQL Server やインターネット インフォメーション サービス (IIS) などの重要なアプリケーションに、独自のドメイン アカウントの分離機能を提供し、管理者がこれらのアカウントのサービス プリンシパル名 (SPN) と資格情報を手動で管理しなくて済むよう、Windows Server 2008 R2 および Windows 7 で導入されました。 これらの機能と認証における役割の詳細については、Windows 7 および Windows Server 2008 R2 の管理されたサービス アカウントに関するドキュメントと管理されたサービス アカウントのグループ化に関する概要のページを参照してください。
サービスとカーネル モード
ほとんどの Windows アプリケーションは、それを起動したユーザーのセキュリティ コンテキストで実行されますが、これはサービスには当てはまりません。 ネットワークや印刷サービスなど、多くの Windows サービスは、ユーザーがコンピューターを起動したときにサービス コントローラーによって起動されます。 これらのサービスは、ローカル サービスまたはローカル システムとして実行され、最後の人間のユーザーがログオフした後も実行され続ける可能性があります。
Note
サービスは通常、ローカル システム (SYSTEM)、ネットワーク サービス、またはローカル サービスと呼ばれるセキュリティ コンテキストで実行されます。 Windows Server 2008 R2 では、ドメイン プリンシパルであるマネージド サービス アカウントで実行されるサービスが導入されました。
サービスを起動する前に、サービス コントローラーがサービス用に指定されたアカウントを使用してログオンし、LSA による認証のためにサービスの資格情報を提示します。 Windows サービスは、サービス コントローラー マネージャーがサービスを制御するために使用できるプログラム インターフェイスを実装します。 Windows サービスは、システム起動時に自動的に開始するか、サービス コントロール プログラムを使用して手動で開始できます。 たとえば、Windows クライアント コンピューターがドメインに参加すると、コンピューター上のメッセンジャー サービスがドメイン コントローラーに接続され、セキュリティで保護されたチャネルが開かれます。 サービスで認証された接続を行うには、リモート コンピューターのローカル セキュリティ機関 (LSA) が信頼する資格情報が必要です。 ネットワーク内の他のコンピューターと通信する場合、LSA はローカル システムとネットワーク サービスのセキュリティ コンテキストで実行されている他のすべてのサービスと同様に、ローカル コンピューターのドメイン アカウントの資格情報を使用します。 ローカル コンピューター上のサービスは SYSTEM として実行されるため、LSA に認証情報を提示する必要はありません。
Ksecdd.sys ファイルは、これらの認証情報を管理、暗号化し、LSA へのローカルプロシージャ呼び出しを使用します。 ファイルの種類は DRV (ドライバー) で、カーネルモードのセキュリティ サポート プロバイダー (SSP) として知られており、このトピックの冒頭の適用対象リストで指定されたバージョンでは、FIPS 140-2 のレベル 1 に準拠しています。
カーネル モードには、コンピューターのハードウェアおよびシステム リソースへのフル アクセスが割り当てられています。 カーネル モードは、ユーザーモードのサービスやアプリケーションが、オペレーティング システムのアクセスすべきでない重要な領域にアクセスするのを阻止します。
ローカル セキュリティ機関
ローカル セキュリティ機関 (LSA) は、ユーザーを認証してローカル コンピューターにログオンする、保護されたシステム プロセスです。 さらに、LSA はコンピューター上のローカル セキュリティのすべての側面 (これらの側面は総称してローカル セキュリティ ポリシーと呼ばれています) に関する情報を保持し、名前とセキュリティ ID (SID) の間の変換に使用されるさまざまなサービスを提供します。 セキュリティ システム プロセスであるローカル セキュリティ機関サーバー サービス (LSASS) は、コンピューター システムで有効なセキュリティ ポリシーとアカウントを追跡します。
LSA は、ユーザー アカウントの発行元が次の 2 つの機関のどちらであるかに基づいて、ユーザーの ID を検証します。
ローカル セキュリティ機関。 LSA は、同じコンピューターにあるセキュリティ アカウント マネージャー (SAM) データベースを確認することで、ユーザー情報を検証できます。 ワークステーションまたはメンバー サーバーには、ローカル ユーザー アカウント、およびローカル グループに関する情報を格納できます。 ただし、これらのアカウントは、そのワークステーションまたはコンピューターへのアクセスにのみ使用できます。
ローカル ドメインまたは信頼されたドメインのセキュリティ機関。 LSA は、アカウントを発行した事業体に接続し、アカウントが有効であること、および要求がアカウント保持者から発信されたものであることの検証を要求します。
ローカル セキュリティ機関サブシステム サービス (LSASS) は、Windows セッションがアクティブなユーザーの代わりに資格情報をメモリに保存します。 保存された資格情報により、ユーザーは、それぞれのリモート サービスのために資格情報を再度入力せずに、ファイル共有、Exchange Server メールボックス、SharePoint サイトなどのネットワーク リソースにシームレスにアクセスできます。
LSASS は、以下を含む複数の形式の資格情報を保存できます。
可逆的に暗号化されたプレーンテキスト
Kerberos チケット (TGT (ticket-granting tickets)、サービス チケット)
NT ハッシュ
LAN Manager (LM) ハッシュ
ユーザーがスマート カードを使用して Windows にログオンした場合、LSASS にはプレーン テキストのパスワードは保存されず、代わりにアカウントの対応する NT ハッシュ値とスマート カードのプレーンテキストの PIN が保存されます。 対話型ログオンに必要なスマート カードに対してアカウント属性が有効な場合は、元のパスワード ハッシュではなく、ランダム NT ハッシュ値がアカウントのために自動的に生成されます。 属性の設定時に自動的に生成されたパスワード ハッシュは変更されません。
ユーザーが LAN Manager (LM) ハッシュと互換性のあるパスワードを使用して Windows ベースのコンピューターにログオンした場合、この認証子はメモリ内に存在します。
プレーンテキストの資格情報を必要とする資格情報プロバイダーが無効な場合でも、プレーンテキストの資格情報をメモリに保存することは無効にできません。
保存された資格情報は、最後の再起動後に開始され、閉じられていないローカル セキュリティ機関サブシステム サービス (LSASS) ログオン セッションと直接関連付けられます。 たとえば、ユーザーが以下のいずれかを実行すると、保存された LSA 資格情報を使用した LSA セッションが作成されます。
コンピューター上のローカル セッションまたはリモート デスクトップ プロトコル (RDP) セッションにログオンする
RunAs オプションを使用してタスクを実行する
コンピューターでアクティブ Windows サービスを実行する
スケジュールされたタスクまたはバッチ ジョブを実行する
リモート管理ツールを使用してローカル コンピューターでタスクを実行する
状況によっては、SYSTEM アカウントのプロセスのみがアクセスできる機密データである LSA シークレットがハード ディスク ドライブに格納されます。 これらのシークレットの一部は、再起動後も保持される必要がある資格情報で、ハード ディスク ドライブに暗号化された形式で保存されます。 LSA シークレットとして保存される資格情報には以下が含まれます。
コンピューターの Active Directory Domain Services (AD DS) アカウントのパスワード
コンピューターで構成されている Windows サービスのアカウント パスワード
構成済みのスケジュールされたタスクのアカウント パスワード
IIS アプリケーション プールと Web サイトのアカウント パスワード
Microsoft アカウントのパスワード
Windows 8.1 から導入されたクライアント オペレーティング システムでは、保護されていないプロセスによるメモリの読み取りやコード インジェクションを防止できるよう LSA に追加の保護が提供されています。 この保護機能により、LSA によって格納、管理されている資格情報のセキュリティが強化されます。
これらの追加の保護の詳細については、LSA の追加の保護を構成する方法に関するページを参照してください。
キャッシュされた資格情報と検証
検証メカニズムは、ログオン時の資格情報の提示に依存します。 ただし、コンピューターがドメイン コントローラーから切断されており、ユーザーがドメイン資格情報を提示している場合、Windows の検証メカニズムではキャッシュされた資格情報のプロセスが使用されます。
ユーザーがドメインにログオンするたびに、Windows では指定された資格情報がキャッシュされ、オペレーション システムのレジストリのセキュリティ ハイブに格納されます。
キャッシュされた資格情報により、ユーザーは、そのドメイン内のドメイン コントローラーに接続することなく、ドメイン メンバーにログオンできます。
資格情報の保存と検証
異なるリソースへのアクセスに 1 組の資格情報を使用することが常に望ましいとは限りません。 たとえば、管理者がリモート サーバーにアクセスするときに、ユーザー資格情報ではなく、管理者資格情報を使用したいと思う場合などが該当します。 同様に、ユーザーが銀行口座などの外部リソースにアクセスする場合は、ドメインの資格情報とは異なる資格情報のみを使用できます。 以降のセクションでは、現在のバージョンの Windows オペレーティング システムと、Windows Vista および Windows XP オペレーティング システムの間の資格情報管理の違いについて説明します。
リモート ログオンの資格情報プロセス
リモート デスクトップ プロトコル (RDP) は、Windows 8 で導入されたリモート デスクトップ クライアントを使用して、リモート コンピューターに接続するユーザーの資格情報を管理します。 プレーンテキスト形式の資格情報は、ホストが認証プロセスの実行を試みるターゲット ホストに送信され、成功した場合は、ユーザーを許可されたリソースに接続します。 RDP では資格情報はクライアントに格納されませんが、ユーザーのドメイン資格情報は LSASS に格納されます。
Windows Server 2012 R2 および Windows 8.1 で導入された Restricted Admin モードを使用すると、リモート ログオンのシナリオのセキュリティを強化することができます。 このリモート デスクトップ用のモードを使用すると、クライアント アプリケーションがリモート ホストへの認証を行う際に、NTOWF (NT one-way function) によるネットワーク ログオンのチャレンジ応答を実行するか、Kerberos サービス チケットを使用するようになります。 資格情報はリモート ホストに提供されないため、管理者が認証されても、LSASS に管理者の各アカウントの資格情報は保存されません。 代わりに、管理者にはセッションのコンピューター アカウントの資格情報が付与されます。 管理者の資格情報はリモート ホストには提供されないため、アクションはコンピューター アカウントとして実行されます。 リソースの利用もコンピューター アカウントに制限されるため、管理者は自分のアカウントでリソースにアクセスすることはできません。
自動再起動サインオンの資格情報プロセス
ユーザーが Windows 8.1 デバイスにサインインすると、ユーザーの資格情報は LSA によって、LSASS.exe からのみアクセスできる、暗号化されたメモリに保存されます。 ユーザーの不在時に Windows Update によって自動的に再起動が開始された際は、これらの資格情報を使用してユーザーの自動ログオンが構成されます。
再起動時に、ユーザーは自動的に Autologon メカニズムによってサインインされ、その後、ユーザー セッションを保護するためにコンピューターはロックされます。 ロックは Winlogon によって開始されますが、資格情報の管理は LSA によって行われます。 自動的にサインインし、コンソール上のユーザー セッションをロックすることで、ユーザーのロック画面アプリケーションは再起動され、利用可能になります。
ARSO の詳細については、Winlogon Automatic Restart Sign-On (ARSO) に関するページを参照してください。
Windows Vista および Windows XP のユーザー名およびパスワードの保存
Windows Server 2008、Windows Server 2003、Windows Vista、および Windows XP では、コントロール パネルの [ユーザー名およびパスワードの保存] を使用することで、スマート カードで使用する X.509 証明書や Windows Live 認証情報 (現在は Microsoft アカウントと呼ばれています) など、複数のログオン認証情報の管理、使用を簡略化することができます。 ユーザーのプロファイルの一部である資格情報は、必要になるまで格納されます。 この操作により、1 つのパスワードが漏洩しても、すべてのセキュリティが損なわれることがないため、リソース単位のセキュリティを向上させることができます。
ユーザーがログオンし、サーバー上の共有などのパスワードで保護されたリソースにさらにアクセスしようとした際、ユーザーの既定のログオン資格情報がアクセスを得るのに十分でない場合は、[ユーザー名およびパスワードの保存] が照会されます。 正しいログオン情報を持つ別の認証情報が [ユーザー名およびパスワードの保存] に保存されている場合、これらの認証情報がアクセスに使用されます。 それ以外の場合、ユーザーは新しい資格情報を入力するように求められます。この資格情報は、ログオン セッションの後半または後続のセッションで再利用できるように保存できます。
次の制限事項が適用されます。
[ユーザー名およびパスワードの保存] に特定のリソースに対する無効または不正な資格情報が含まれている場合、そのリソースへのアクセスは拒否され、[ユーザー名およびパスワードの保存] ダイアログ ボックスは表示されません。
[ユーザー名およびパスワードの保存] には、NTLM、Kerberos プロトコル、Microsoft アカウント (旧 Windows Live ID)、および Secure Sockets Layer (SSL) 認証用の資格情報のみが保存されます。 Internet Explorer の一部のバージョンでは、基本認証用に独自のキャッシュを保持しています。
これらの認証情報は、\Documents および Settings\Username\Application Data\Microsoft\Credentials ディレクトリに格納される、ユーザーのローカル プロファイルの暗号化された部分となります。 その結果、ユーザーのネットワーク ポリシーで移動ユーザー プロファイルがサポートされている場合、これらの資格情報はユーザーと一緒に移動できます。 ただし、2 台のコンピューターにユーザーの [ユーザー名およびパスワードの保存] がコピーされており、これらのコンピューターのどちらか一方のリソースに関連付けられた資格情報を変更した場合、その変更は 2 台目のコンピューターの [ユーザー名およびパスワードの保存] には伝搬されません。
Windows 資格情報コンテナーと資格情報マネージャー
資格情報マネージャーは、ユーザー名とパスワードを保存、管理するためのコントロール パネル機能として、Windows Server 2008 R2 および Windows 7 で導入されました。 資格情報マネージャーを使用すると、ユーザーはセキュリティで保護された Windows 資格情報コンテナー内に、他のシステムや Web サイトに関連する資格情報を格納することができます。 Internet Explorer の一部のバージョンでは、Web サイトへの認証にこの機能が使用されています。
資格情報マネージャーを使用した資格情報管理は、ローカル コンピューター上でユーザーが制御します。 ユーザーは、サポートされるブラウザーや Windows アプリケーションにサインインする必要があるときに便利なように、それらのリソースに資格情報を保存および格納することができます。 資格情報は、コンピューター上のユーザーのプロファイルの下にある暗号化された特別なフォルダーに保存されます。 Web ブラウザーやアプリなど、(資格情報マネージャー API を使用して) この機能をサポートするアプリケーションは、ログオン プロセス中に他のコンピューターや Web サイトに対して適切な資格情報を提示することができます。
Web サイト、アプリケーション、または別のコンピューターから NTLM または Kerberos プロトコルによる認証が要求されると、[既定の資格情報を更新する] または [パスワードを保存する] チェック ボックスが表示されたダイアログ ボックスが表示されます。 ユーザーが資格情報をローカルに保存できるようにするこのダイアログ ボックスは、Credential Manager API をサポートするアプリケーションによって生成されます。 ユーザーが [パスワードを保存する] チェック ボックスをオンにすると、資格情報マネージャーで使用中の認証サービスに対するユーザーのユーザー名、パスワード、および関連情報が追跡されるようになります。
次にそのサービスを使用するときは、資格情報マネージャーによって、Windows 資格情報コンテナーに格納された資格情報が自動的に入力されます。 それが受け付けられない場合は、ユーザーは正しいアクセス情報の入力を要求されます。 新しい資格情報でアクセスが許可されると、資格情報マネージャーによって以前の資格情報が新しい資格情報で上書きされ、新しい資格情報が Windows 資格情報コンテナーに格納されます。
セキュリティ アカウント マネージャー データベース
セキュリティ アカウント マネージャー (SAM) は、ローカルのユーザー アカウントとグループを保存するデータベースです。 これは、すべての Windows オペレーティング システムに備わっていますが、コンピューターがドメインに参加している場合、Active Directory は Active Directory ドメインでドメイン アカウントを管理します。
たとえば、Windows オペレーティング システムを実行するクライアント コンピューターは、人間のユーザーがログオンしていない場合でも、ドメイン コントローラーと通信することで、ネットワーク ドメインに参加できます。 通信を開始するには、コンピューターがドメイン内にアクティブなアカウントを持っている必要があります。 コンピューターからの通信を受け入れる前に、ドメイン コントローラーの LSA はコンピューターの ID を認証し、人間のセキュリティ プリンシパルの場合と同じようにコンピューターのセキュリティ コンテキストを構築します。 このセキュリティ コンテキストでは、ネットワーク上の特定のコンピューター、ユーザー、サービス、またはコンピューター上のユーザーまたはサービスの ID と機能を定義します。 たとえば、セキュリティ コンテキストに含まれるアクセス トークンは、アクセス可能なリソース (ファイル共有やプリンターなど) と、そのプリンシパル (ユーザー、コンピューター、サービス) がそのリソースで実行できるアクション (読み取り、書き込み、変更など) を定義します。
ユーザーまたはコンピューターのセキュリティ コンテキストは、ユーザーがサーバーや、ユーザー自身の主なワークステーション以外のワークステーションにログオン場合など、コンピューターごとに異なる場合があります。 また、管理者がユーザーの権利やアクセス許可を変更する場合など、セッションごとに異なることもあります。 さらに、ユーザーやコンピューターがスタンドアロン、ネットワーク内、または Active Directory ドメインの一部として動作している場合も、セキュリティ コンテキストは通常異なります。
ローカル ドメインと信頼されたドメイン
2 つのドメイン間に信頼関係が存在する場合、各ドメインの認証メカニズムは、他のドメインから渡される認証の有効性に依存します。 信頼は、受信認証要求が信頼できる機関 (信頼されるドメイン) からのものであることを確認することにより、リソース ドメイン (信頼するドメイン) 内の共有リソースへの制御されたアクセスを提供するのに役立ちます。 信頼はこのようにして、検証された認証要求のみがドメイン間を移動できるようにするブリッジとして機能します。
特定の信頼が認証要求を渡す方法は、その構成方法によって異なります。 信頼関係は、信頼されたドメインから信頼するドメイン内のリソースへのアクセスを提供することで一方通行にするか、または、各ドメインから他のドメイン内のリソースへのアクセスを提供することで双方向にすることもできます。 信頼はまた非推移的でもあります。この場合、信頼は 2 つの信頼パートナー ドメイン間にのみ存在します。または推移的な場合、信頼はいずれかのパートナーが信頼する他のドメインに自動的に拡張されます。
認証に関するドメインとフォレストの信頼関係の詳細については、委任認証と信頼関係に関するページを参照してください。
Windows 認証における証明書
公開キー基盤 (PKI) とは、組織が通信やビジネス トランザクションを安全に行うためのソフトウェア、暗号化テクノロジ、プロセス、サービスの組み合わせを指します。 通信やビジネス トランザクションをセキュリティで保護するために使用される PKI の機能は、認証されたユーザーと信頼されたリソースの間でのデジタル証明書の交換の上に成り立っています。
デジタル証明書は、所属している事業体、それを発行した事業体、一意のシリアル番号または他の一意の ID、発行日および有効期限、およびデジタル指紋に関する情報を含む電子文書です。
認証とは、リモート ホストを信頼できるかどうかを判断するプロセスです。 信頼を確立するには、リモート ホストが受け入れ可能な認証証明書を提供する必要があります。
リモート ホストは、証明機関 (CA) から証明書を取得することによって信頼性を確立します。 CA は、さらに上位の機関から証明書を取得することができ、これによって信頼チェーンが形成されます。 証明書が信頼できるかどうかを判断するには、アプリケーションでルート CA の身元を確認し、それが信頼できるかどうかを判断する必要があります。
同様に、リモート ホストまたはローカル コンピューターは、ユーザーまたはアプリケーションによって提示された証明書が本物であるかどうかを判断する必要があります。 LSA および SSPI を通じてユーザーによって提示された証明書は、ローカル コンピュータ上 (ローカル ログオンの場合)、ネットワーク上、または Active Directory 内の証明書ストアを通じてドメインにおける信頼性が評価されます。
証明書を生成するために、認証データは Secure Hash Algorithm 1 (SHA1) などのハッシュ アルゴリズムを通じて、メッセージ ダイジェストを生成します。 メッセージ ダイジェストは、送信者の秘密キーを使用してデジタル署名され、メッセージ ダイジェストが送信者によって生成されたことを証明します。
Note
Windows 7 および Windows Vista では SHA1 が既定ですが、Windows 8 では SHA2 に変更されました。
スマート カード認証
スマート カード テクノロジは、証明書ベースの認証の一例です。 スマート カードを使用したネットワークへのログオンでは、ドメインに対してユーザーを認証する際に暗号化ベースの識別と所有権証明を使用するため、強力な認証形式になっています。 Active Directory 証明書サービス (AD CS) は、各スマート カードにログオン証明書を発行することで、暗号化ベースの ID を提供します。
スマート カード認証の詳細については、Windows スマート カードのテクニカル リファレンスに関するページを参照してください。
仮想スマート カード テクノロジは、Windows 8 で導入されました。 これは、スマート カードの証明書を PC に格納し、デバイスの改ざん防止トラステッド プラットフォーム モジュール (TPM) セキュリティ チップを利用して保護します。 この方法では、PC がスマート カードとなり、認証を行うためにユーザーの PIN を受け取る必要があります。
リモート認証とワイヤレス認証
リモートおよびワイヤレスでのネットワーク認証も、認証に証明書を使用するテクノロジです。 インターネット認証サービス (IAS) と仮想プライベート ネットワーク サーバーは、EAP-TLS (Extensible Authentication Protocol-Transport Level Security)、PEAP (Protected Extensible Authentication Protocol)、または IPsec (Internet Protocol security) を使用して、仮想プライベート ネットワーク (VPN) やワイヤレス接続など、さまざまな種類のネットワーク アクセスに対して証明書ベースの認証を実行します。
ネットワークでの証明書ベースの認証の詳細については、ネットワーク アクセスの認証と証明書に関するページを参照してください。