【AD DS】ドメイン環境での認証に関する監査ログについて解説！

Active Directory ドメイン サービスを導入している環境においては、ユーザーの情報は全てドメイン コントローラー上で管理しています。ドメインで管理している Windows 端末にログオンする時は、ドメイン コントローラーに問い合わせして、入力されたユーザー名とパスワードが正しいかを確認して、間違っていなければログオンできます。

大規模のドメイン環境の場合、ドメイン内に複数のドメイン コントローラーが構築されており、多数のユーザーや端末を管理しています。そのような環境で、ドメイン内への各ユーザーのログオン状態やリソースへのアクセス状態を把握するには、AD のログオンに関連する監査ログがどのように記録されるかを把握しておくことは重要です。

今回は、ドメイン環境での認証に関連する監査ログについて紹介します。

AD 認証に関連する監査ログ

AD ドメイン環境の利用において、ドメイン環境で行われるアカウント認証や、アクセス状態を記録する監査ログが定義されています。AD 認証に関連する監査ログは以下の 2 つです。

• ログオン イベントの監査
• アカウント ログオン イベントの監査

グループ ポリシーを使ってドメイン全体に上記 2 つの監査ポリシーを有効にしていれば、AD ドメイン内での「ユーザーのログオン状態」「不審なユーザーからの不正アクセス」「サーバーへのユーザーのアクセス履歴」などのイベントを監査ログとして残すことができるようになります。

この 2 つの監査ログについて、詳細を紹介していきます。

ログオン イベントの監査とは

ログオン イベントの監査とは、Windows OS の端末上で発生したログオンのイベントを記録する監査ログのことです。
そもそも、ログオンっていったい何でしょう？

1. ログオン画面にてパスワードを入力して、デスクトップ画面を表示させた
2. リモート デスクトップ接続により、他端末のデスクトップ画面を表示した
3. ファイル サーバー上の共有フォルダにアクセスした

これらの例のように、Windows OS の端末上のリソースを利用するにあたり、認証情報を渡してアクセスするすべてのイベントのことは「ログオン イベント」として監査されます。

ドメイン環境において、ドメインに参加しているクライアント端末にドメイン ユーザーがログオンした場合に、ログオン イベントがどのように記録されるか見てみましょう。

上図はドメイン ユーザー「ねこまる」がドメイン参加しているクライアント端末にログオンしてファイル共有上の資料にアクセスするシナリオを想定します。

まず、「ねこまる」はクライアント端末のログオン画面よりユーザー名とパスワードを入力してログオンをします。デスクトップ画面が表示されたら、必要な資料を入手するために保存場所であるファイル サーバー上のファイル共有にアクセスします。

このシナリオでは、まず「ねこまる」はクライアント端末のログオン画面に認証情報を入力して、デスクトップ画面を表示してクライアント端末の利用を開始しています。そのため、「ねこまる」はクライアント端末へログオンしたことになります。また、「ねこまる」はクライアント端末の利用を開始した後に、ファイル サーバー上にあるファイル共有にアクセスしています。ドメイン端末ではログオン時の認証情報をファイル サーバーにわたして、ファイル共有へアクセスします。そのため、「ねこまる」はファイル サーバーへもログオンしたことになります。

このように、「ログオン イベントの監査」により、アカウントが端末へアクセスしたことをトレースすることができるようになります。各ユーザーの端末の利用状態や不正アクセスの有無などを確認する方法として有効な監査ログです。

アカウント ログオン イベントの監査とは

アカウント ログオン イベントの監査は、アカウントがドメイン内の端末へログオンするために、ドメイン コントローラーへ認証要求を行ったイベントが記録されます。ログオンとは「コンピューターに自分の身元を示す情報を提示して、接続や利用開始を申請すること」であるため、ドメイン コントローラへ認証情報をわたして、認証を行ってもらうことも「ログオン」のひとつです。

認証方式には様々な種類がありますが、Active Directory ドメイン サービスで構築したドメイン環境において、主に利用される認証方式は以下の 2 つです。

• Kerberos 認証
• NTLM 認証

どちらの認証方式を利用した場合でも、ドメイン コントローラーで行われたアカウントの認証の結果が記録されます。

AD 認証に関する監査ログの設定手順

[1] ログオン イベントの監査の設定手順

ログオン イベントの監査を有効にする設定は以下の通りです。

パス：[コンピューターの構成] – [ポリシー] – [Windows の設定] – [セキュリティの設定] – [ローカル ポリシー] – [監査ポリシー]
ポリシー名：[ログオン イベントの監査]
設定値：[これらのポリシーの設定を定義する] をチェック、[成功] と [失敗] の両方をチェック

ただし、ログオン イベントの監査は既定で有効であるため、上記のポリシーを設定は必須ではありません。
現在のログオン イベントの監査ログの設定状態は、auditpol コマンドにて確認できます。

ログオン イベントの監査ログの設定状態を確認したい端末上で実行してください。
ユーザーが実際に利用しようとする端末が確認対象となります。(クライアント端末やファイルサーバーなど)

auditpol /get は監査ポリシーの設定状態を確認するコマンドです。
auditpol コマンドの実行結果の “ログオン” の項目にて、”成功および失敗” となっていれば、対象の端末にてログオン イベントの監査ログの設定が有効になっています。

[2] アカウント イベント ログの監査の設定手順

アカウント ログオン イベントの監査を有効にする設定は以下の通りです。

パス：[コンピューターの構成] – [ポリシー] – [Windows の設定] – [セキュリティの設定] – [ローカル ポリシー] – [監査ポリシー]
ポリシー名：[アカウント ログオン イベントの監査]
設定値：[これらのポリシーの設定を定義する] をチェック、[成功] と [失敗] の両方をチェック

現在のログオン イベントの監査ログの設定状態は、auditpol コマンドにて確認できます。
ドメイン コントローラー上で以下のコマンドを実行してください。

auditpol のコマンドで、「Kerberos サービス チケット操作」「Kerberos 認証サービス」「資格情報の確認」の項目が “成功および失敗” となっていれば、対象のドメイン コントローラーでアカウント ログオン イベントの監査ログの設定が有効になっています。

AD 認証に関連する監査ログ一覧

ログオン イベントとアカウント ログオン イベントの監査を有効にしているドメイン環境において、着目するべき主要な監査ログの一覧は以下の通りです。

ID 4624 と ID 4625 は、ユーザーが実際にログオンした端末上に記録されます。ID 4624 は正常にログオンできた時、また、ID 4625 はログオンに失敗した時に記録されます。

ID 4768 と ID 4771 は、Kerberos 認証にてアカウントの認証を行ったドメイン コントローラー上に記録されます。ID 4768 は正常にアカウントが認証できた時、また ID 4771 はアカウントの認証に失敗した時に記録されます。

ID 4776 は NTLM 認証にてアカウントの認証を行ったドメイン コントローラー上に記録されます。NTLM 認証の場合、アカウントの認証に成功した場合、失敗した場合のどちらのパターンにも同じ 4776 の監査ログが記録されます。ただし、アカウントの認証に成功した場合は “成功の監査”、アカウントの認証に失敗した場合は “失敗の監査” として記録されます。

今回紹介するシナリオは、ドメイン コントローラーが 4 台あるドメイン nekomaru.local の環境でのログオン イベントの動作をみていきます。

①コンソール ログオン(成功)

ユーザー「ねこねこ」が PC01 のクライアント端末にコンソール ログオンして成功した時のシナリオです。

ドメインに参加しているクライアント端末にログオンする時、まず、ユーザー「ねこねこ」はログオン画面からユーザー名とパスワードを入力して認証を行います。クライアント端末 PC 01 はドメイン コントローラーを探し、みつかったドメイン コントローラー DC01 に入力されたユーザー名とパスワードで認証要求を行います。この時、Kerberos 認証が利用されます。

認証要求が送信されたドメイン コントローラー DC01 にて、「ねこねこ」のユーザー名とパスワードが正しいかを確認して、正しければ認証成功となります。この時、DC01 に Keberos 認証に成功したことを示すイベント ID 4768 が記録されます。また、DC01 は PC01 へ認証成功したことを通知します。

PC01 は DC01 から認証成功したという通知を受け取ったため、ねこねこのログオンを許可してデスクトップ画面を表示します。この時、PC01 には端末へのログオンに成功したことを示すイベント ID 4624 が記録されます。

②コンソール ログオン失敗

ユーザー「ねこねこ」が PC01 のクライアント端末にコンソール ログオンして失敗した時のシナリオです。

ドメインに参加しているクライアント端末にログオンする時、まずユーザー「ねこねこ」はログオン画面からユーザー名とパスワードを入力して認証を行います。クライアント端末 PC 01 はドメイン コントローラーを探し、みつかったドメイン コントローラー DC01 に入力されたユーザー名とパスワードで認証要求を行います。この時、Kerberos 認証が利用されます。

認証要求が送信されたドメイン コントローラー DC01 にて、「ねこねこ」のユーザー名とパスワードが正しいかを確認した結果、正しくない場合は認証失敗となります。この時、DC01 に Kerberos 認証に失敗したことを示すイベント ID 4771 が記録されます。また、ドメイン コントローラーは認証に失敗した場合、PDC エミュレーターの役割をもつドメイン コントローラーへ認証要求を転送します。PDC エミュレーターの役割をもつドメイン コントローラーは最新のパスワードの情報を保持しているため、そのドメイン コントローラーでも認証失敗しないか確認します。これは、パスワード変更によるドメイン コントローラー間の複製遅延の影響を受けないようにするためです。PDC エミュレーターの DC02 でも、ユーザー名とパスワードが正しいかを確認した結果、正しくない場合は認証失敗となります。この時、DC02 に Kerberos 認証に失敗したことを示すイベント ID 4771 が記録されます。PDC エミュレーターでも認証に失敗した場合は、DC01 はクライアント端末へ認証失敗したことを通知します。

PC01 は DC01 から認証失敗したという通知を受け取ったため、ログオン画面に「ユーザー名かパスワードが正しくありません。入力し直してください。」というエラー メッセージを表示して、ログオンを拒否します。この時、PC01 には端末へのログオンに失敗したことを示すイベント ID 4625 が記録されます。

③ NTLM 認証でのネットワーク ログオンの場合

ユーザー「ねこねこ」が PC01 のクライアント端末からファイル サーバの共有フォルダへした時のシナリオです。
共有フォルダのパスの指定において、ファイル サーバーを IP アドレスで指定すると NTLM 認証が利用されます。このシナリオのように、ネットワークを通じて、別端末にアクセスして利用することをネットワーク ログオンと呼びます。

クライアント端末にログオンして作業中に、ファイル サーバーの共有フォルダに保存されている資料を参照します。この時、エクスプローラーを開いて、ファイル サーバーの IP アドレスを指定し、共有フォルダのパスへアクセスしたとします(例：\\192.168.1.10\shared)。アクセス先のパスの指定において、FQDN ではなく IP アドレスを指定すると、認証方式には NTLM 認証が利用されます。

NTLM 認証では、アクセス先のファイル サーバーへ直接、認証情報を送信します。アクセス先のファイル サーバーは、クライアントから送信されてきた認証情報に問題がないかは確認できないので、認証情報をドメイン コントローラーへ転送します。

認証要求が送信されたドメイン コントローラー DC01 にて、「ねこねこ」のユーザー名とパスワードが正しいかを確認して、正しければ認証成功となります。この時、DC01 に NTLM 認証に成功したことを示すイベント ID 4768 が記録されます。また、DC01 はファイル サーバーへ認証成功したことを通知します。

ファイル サーバーは DC01 から認証成功したという通知を受け取ったら、クライアントへ転送します。このフローによりクライアント端末はファイル共有にアクセスすることが許可されます。また、ファイル サーバーにアクセスした時に、ファイル サーバー上にネットワーク ログオンされたことを示す ID 4624 が記録されます。