皆さんこんにちは。国井です。
ADFSテキスト全文公開チャレンジの15回目は設定したクレームルールの確認方法とWindows Server 2016以降で搭載されたアクセス制御ポリシーについてです。
■ ■ ■
クレームルールを作成するにあたり、私たちが知りたい情報のひとつにクレームルールでどのような値をとるか？があります。ADFS サーバーからトークンが発行されたとき、どのようなクレームとその値が入るかについては、イベント ビューアのセキュリティログで確認することができます。利用する場合には次の方法で有効にします。
■Auditpol コマンドで「生成されたアプリケーション」ログの生成を有効にする
ADFS サーバーのコマンドプロンプトで次のように入力し、生成されたアプリケーションログを有効にします。
auditpol.exe /set /subcategory:”生成されたアプリケーション” /failure:enable /success:enable
■サービスアカウントに対して、[セキュリティ監査の生成] 権利を割り当てる
ADFS サーバーのコンピューターアカウントが保存されている OU またはドメインにリンクされた GPO (グループ ポリシー) を利用して、ADFS サーバーのサービス アカウントに対する [セキュリティ監査の生成] 権利を割り当てます。グループポリシーから割り当てることも可能です。
■記録するイベント種類を定義する
ADFS 管理ツールのフェデレーション サービスのプロパティから、記録するイベント種類を定義します。特に、成功の監査と失敗の監査はトラブルシューティングに有効であるため、トラブルシューティング時には有効にして利用します。
前のページで記載されている手順に従い、セキュリティログで ADFS 操作のログ (成功の監査と失敗の監査) を有効にすると、ADFS サーバー内の各規則で発行されるクレームについて、その詳細を確認できます。以下では、Windows Server 2012 R2 で発行されるイベント ログについて解説します。
■クライアントが ADFS サーバーを経由して認証を行うとき
この時点では、まだクレームは発行されませんが、ADFS サーバーのセキュリティ ログにイベント ID 4624 のログが生成されます。この後のクレーム発行の流れを追跡するときの起点として利用します。
■受け付け変換規則によるクレーム発行 (発行前)
受け付け変換規則では、一般的に Active Directory に保存されている情報をもとにクレームを発行します。Active Directory から取得した情報がある場合、その情報はイベント ID 501 で確認できます。
一方、イベント ID 299 では ActivityID や InstanceID といった ID 番号が確認できるため、この後のクレーム発行の流れを追跡するときに利用できます。
■受け付け変換規則によるクレーム発行 (発行後)
受け付け変換規則によってクレームが発行されると、その結果はイベント ID 500 で確認できます。これにより受け付け変換規則で設定した規則が管理者の思惑通りに動作しているか、についての検証ができます。
■発行承認規則による処理
発行承認規則によって、トークンそのものの発行を拒否された場合、イベント ID 324 が記録されます。これにより発行承認規則で設定した規則が管理者の思惑通りに動作しているか、についての検証ができます。
■発行変換規則によるクレーム発行 (発行後)
発行変換規則によってクレームが発行されると、その結果はイベント ID 500 で確認できます。これにより受け付け変換規則で設定した規則が管理者の思惑通りに動作しているか、についての検証ができます。また、同時に発行されるイベント ID 299 のログを参照することにより、イベント ID 500 のログが受け付け変換規則で発行されたものか、または発行変換規則で発行されたものかの判定ができます。
なお、Windows Server 2016 ではトークン発行に関わるイベント ログはアクセス制御ポリシーの実行結果に関するものをイベント ID 1202、発行変換規則に関するものをイベント ID 1200 に集約し、記録されます。
Windows Server 2016 では、受け付け変換規則、発行承認規則、発行変換規則の 3 種類の規則のうち、発行承認規則は Windows Server 2012 R2 スタイルのクレームルールによるアクセス制御方法と、Windows Server 2016 スタイルのアクセス制御ポリシーによるアクセス制御方法を選択できるようになっています。
アクセス制御ポリシーを選択した場合、GUI 画面からアクセス制御のための設定ができるため、クレームルールを記述することなく簡単にルールを設定できるメリットがあります。
■アクセス制御ポリシーの定義
クレームルールのスタイルによる運用では、証明書利用者信頼の中で個別にクレームルールを記述していました。この方法では、複数の証明書利用者信頼で同じクレームルールを記述したい場合、同じルールを2度書かなければならず、面倒でした。Windows Server 2016 のアクセス制御ポリシーでは、クレームルールに相当する内容を [アクセス制御ポリシー] という独立した領域の中で管理することができます。
設定したアクセス制御ポリシーは、証明書利用者信頼と関連付けて利用できるため、複数の証明書利用者信頼で同じクレームルールを記述したい場合でも、1つのルール (ポリシー) だけ記述すれば十分です。
Windows Server 2016 では、Windows Server 2012 R2 スタイルのクレームルールによるアクセス制御方法と、Windows Server 2016 スタイルのアクセス制御ポリシーのどちらでアクセス制御を行うか選択できますが、両方を同時に利用することができません。そのため、Windows Server 2012 R2 からの移行を検討している場合には、クレームルールを段階的に移行せず、すべてのルールを一度に移行するような移行方法を検討してください。
アクセス制御ポリシーによる設定項目には、ビルトインとして用意されている項目と、管理者が独自に定義して利用する項目があります。ビルトインの項目には次のようなものがあります。
■すべてのユーザーを許可し、特定のグループに MFA を要求
■すべてのユーザーにイントラネットアクセスを許可
■すべてのユーザーを許可
■すべてのユーザーを許可し、認証されていないデバイスから MFA を要求
■すべてのユーザーを許可し、MFA を要求
■特定のグループを許可
■すべてのユーザーを許可し、エクストラネットアクセスで MFA を要求
■すべてのユーザーを許可し、MFA を要求して、デバイスの自動登録を許可
これらの項目以外のポリシーを必要とする場合、管理者が独自にポリシーを定義します。
管理者が独自にアクセス制御ポリシーを定義する場合、ADFS 管理ツールからアクセス制御ポリシーを新規作成し、[規則エディター] からアクセス許可 (または拒否) を設定します。
[規則エディター] では、あらかじめよく使われる設定項目が用意されており、例えば、特定の IP アドレス範囲からのアクセスのみを許可する場合、[規則エディター] の [特定ネットワークから] を選択して、IP アドレス帯を定義します。
一方、設定したい項目が [規則エディター] の中に無い場合は、[特定要求が要求にある] 項目を使用します。前のページで登場した次のケースの場合、次のように設定します。
■OS が Windows 10 の場合
OS に関する情報は、x-ms-client-user-agent (クライアント ユーザー エージェント) クレームに格納されている情報を使用します。そのため、[クライアント ユーザー エージェント] [が次の値と等しい] [Windows NT 10.0] と設定します。
■Exchange ActiveSync 接続を許可する場合
クライアントがクラウドへの接続に利用したアプリケーションの情報は、x-ms-client-application (クライアント アプリケーション) クレームに格納されている情報を使用します。そのため、[クライアント アプリケーション] [が次の値と等しい] [Microsoft.Exchange.ActiveSync] と設定します。
編集後記
今回はイベントビューアでクレームルール処理のログを参照する方法を紹介しましたが、Windows Server 2016からログがおまとめの表示になったんですよね。これに関しては見やすい！なんで詳細なログを消すんだ！など、色々な意見があったことを思い出しました。
ただ、Windows Server 2016でも詳細なログは追加設定で表示するように構成することもできるので必要な方は事前に設定してご利用ください。
