保護されたアカウントを構成する方法について説明します
Pass-the-hash (PtH) 攻撃では、攻撃者はユーザーのパスワード (または他の資格情報の派生物) の基盤となる NTLM ハッシュを使用して、リモートのサーバーまたはサービスに対する認証を行うことができます。 マイクロソフトは以前に、Pass-the-Hash 攻撃を軽減させるための ガイダンスを公開 しています。 Windows Server 2012 R2 には、このような攻撃をさらに軽減するのに役立つ新機能が含まれています。 資格情報の盗用を防ぐのに役立つ、その他のセキュリティ機能の詳細については、「 資格情報の保護と管理」を参照してください。 このトピックでは、次の新機能を構成する方法を説明します。
Windows 8.1 および Windows Server 2012 R2 には、資格情報の盗用を防ぐために役立つ追加の軽減機能が内蔵されています。これらの機能については、以下のトピックで説明しています。
Protected Users
Protected Users は、新しいユーザーや既存のユーザーを追加できる新しいグローバル セキュリティ グループです。 Windows 8.1 デバイスと Windows Server 2012 R2 ホストは、このグループのメンバーと特別な動作をして、資格情報の盗難に対する保護を強化します。 グループのメンバーの場合、Windows 8.1 デバイスまたは Windows Server 2012 R2 ホストは、Protected Users に対してサポートされていない資格情報をキャッシュしません。 このグループのメンバーの場合、追加の保護があるいない Windows 8.1 より前のバージョンの Windows を実行しているデバイスにログオンしている場合。
Windows 8.1 デバイスおよび Windows Server 2012 R2 ホストにサインオンしている Protected Users グループのメンバーは、使用できなくなります。
既定の資格情報の委任 (CredSSP) - プレーンテキストの資格情報は、[既定の資格情報の委任を許可する] ポリシーが有効な場合でもキャッシュされません
Windows ダイジェスト - プレーンテキストの資格情報はそれらが有効な場合でもキャッシュされません
NTLM - NTOWF はキャッシュされません
Kerberos 長期キー - Kerberos チケット保証チケット (TGT) はログオン時に取得され、自動で再取得することはできません
オフラインでのサインオン - キャッシュされたログオン検証は作成されません
ドメインの機能レベルが Windows Server 2012 R2 の場合、グループのメンバーは次の操作ができなくなります。
NTLM 認証を使用した認証
Kerberos 事前認証におけるデータ暗号化標準 (DES) または RC4 暗号スイートの使用
制約なし/制約付き委任を使用した委任
最初の 4 時間の有効期間後のユーザー チケット (TGT) の更新
使用できるグループにユーザーを追加する UI ツール Active Directory 管理センター (ADAC) または Active Directory ユーザーとコンピューター、またはなどのコマンド ライン ツールなど Dsmod グループ, 、または Windows PowerShellAdd-adgroupmember コマンドレットです。 サービスとコンピューターのアカウントは、Protected Users グループのメンバーにしないでください。 これらのアカウントのメンバーシップでは、パスワードまたは証明書が常にホストで利用できるため、ローカル保護が提供されません。
警告
認証の制限には回避策はありません。つまり、Enterprise Admins グループや Domain Admins グループのように高い権限を持つグループのメンバーであっても、Protected Users グループの他のメンバーと同じ制限が適用されます。 このようなグループのすべてのメンバーが Protected Users グループに追加されている場合、それらのすべてのアカウントがロック アウトされる可能性があります。潜在的な影響を十分にテストするまで、高い特権を持つすべてのアカウントを Protected Users グループに追加しないでください。
Protected Users グループのメンバーは、Kerberos で高度暗号化標準 (AES) を使用して認証できる必要があります。 この方法では、Active Directory のアカウントに対する AES キーが必要です。 ビルトイン Administrator は、Windows Server 2008 以降を実行しているドメイン コントローラーでパスワードが変更されない限り、AES キーを持ちません。 また、以前のバージョンの Windows Server が実行されているドメイン コントローラーでパスワードが変更されたアカウントはロック アウトされます。そのため、次のベストプラクティスに従ってください。
すべてのドメイン コントローラーが Windows Server 2008 以降を実行していない限り、ドメインでテストを歯内でください。
ドメインの作成前に作成されたすべてのドメイン アカウントのパスワードを変更してください。 そうしないと、これらのアカウントを認証できません。
アカウントを Protected Users グループに追加する前に各ユーザーのパスワードを変更するか、Windows Server2008 以降を実行しているドメイン コントローラーでパスワードが最近変更されたことを確認してください。
保護されたアカウントを使用するための要件
保護されたアカウントを展開するには、次の要件があります。
Protected Users にクライアント側の制限を提供するには、ホストで Windows 8.1 または Windows Server 2012 R2 を実行する必要があります。 ユーザーは、Protected Users グループのメンバーであるアカウントのみを使用してサインオンする必要があります。 この場合、Protected Users グループは、 プライマリ ドメイン コント ローラー (PDC) エミュレーターの役割を Windows Server 2012 R2 を実行しているドメイン コント ローラーを転送することで作成できます。 そのグループのオブジェクトが他のドメイン コントローラーにレプリケートされた後に、以前のバージョンの Windows Server が実行されているドメイン コントローラーで PDC エミュレーターの役割をホストできます。
Protected Users にドメイン コント ローラー側の制限 (NTLM 認証の使用の制限) およびその他の制限を提供するには、ドメインの機能レベルを Windows Server 2012 R2 にする必要があります。 機能レベルの詳細については、次を参照してください。 Understanding Active Directory ドメイン サービス (AD DS) の機能レベルします。
注意
builtin ドメイン管理者 (S-1-5-<domain>-500) は、Authentication Policy Silo に割り当てられている場合でも、常に Authentication Policies から除外されます。
Protected Users に関連するイベントのトラブルシューティング
このセクションでは、Protected Users に関連するイベントのトラブルシューティングに役立つ新しいログについて説明します。さらに、チケット保証チケット (TGT) の有効期限または委任に関する問題のいずれかのトラブルシューティングを行う際に、Protected Users がどのような影響を与えるかを説明します。
Protected Users 向けの新しいログ
Protected Users に関連するイベントのトラブルシューティングに役立つ 2 つの新しい運用管理ログがある: 保護されたユーザー - クライアントのログと保護されているユーザー エラー - ドメイン コント ローラーのログ。 これらの新しいログはイベント ビューアーにありますが、既定では無効になっています。 ログを有効化するには、[アプリケーションとサービス ログ]、[Microsoft]、[Windows]、[Authentication] の順にクリックし、ログの名前をクリックして [操作] をクリックし (またはログを右クリック)、[ログの有効化] をクリックします。
これらのログのイベント詳細については、「 認証ポリシーと認証ポリシー サイロ」をご覧ください。
TGT の有効期限のトラブルシューティング
通常、ドメイン コントローラーは、次の [グループ ポリシー管理エディター] ウィンドウに表示されるドメイン ポリシーに基づいて、TGT の有効期間と更新を設定します。
![[グループ ポリシー管理エディター] ウィンドウを示すスクリーンショット。](media/how-to-configure-protected-accounts/adds_protectacct_tgtexpiration.png)
Protected Users の場合、次の設定がハードコーディングされています。
ユーザー チケットの最長有効期間:240 分
ユーザー チケット更新の最長有効期間:240 分
委任に関する問題のトラブルシューティング
以前は、Kerberos 委任を使用するテクノロジで問題が発生すると、クライアント アカウントに [アカウントは重要なので委任できない] が設定されているかどうかを確認していました。 しかし、アカウントが Protected Users のメンバーである場合、この設定は Active Directory 管理センター (ADAC) で構成されていない可能性があります。 そのため、委任に関する問題のトラブルシューティングを行う場合は、この設定だけでなくグループ メンバーシップも確認してください。
![[アカウントは重要なので委任できない] チェックボックスが強調表示されているスクリーンショット。](media/how-to-configure-protected-accounts/adds_protectacct_tshootdelegation.gif)
認証試行の監査
Protected Users グループのメンバーの認証試行を明示的に監査するには、セキュリティ ログの監査イベントを引き続き収集するか、または新しい運用管理ログのデータを収集します。 これらのイベント詳細については、「 認証ポリシーと認証ポリシー サイロ」をご覧ください。
サービスとコンピューターに対して DC 側の保護を提供する
サービスおよびコンピューター用のアカウントは、Protected Users のメンバーにすることはできません。 このセクションでは、これらのアカウントに提供できるドメイン コントローラー ベースの保護について説明します。
NTLM 認証の拒否: NTLM ブロック ポリシーを通じてのみ構成できます
Kerberos 事前認証でのデータ暗号化標準 (DES) の拒否: Windows Server 2012 R2 ドメイン コントローラーは、Kerberos でリリースされたすべてのバージョンのWindows が RC4 もサポートしているため、DES 用に構成されていない限り、コンピューター アカウントの DES を受け入れません。
Kerberos 事前認証での RC4 の拒否: 構成できません。
Note
サポートされている暗号化の種類の構成を変更することはできますが、コンピューター アカウントでこれらの設定を変更する場合は、あらかじめターゲット環境でテストすることをお勧めします。
ユーザー チケット (TGT) を最初の 4 時間の有効期間に制限:認証ポリシーを使用します。
制約なし/制約付き委任による委任を拒否:アカウントを制限するには、Active Directory 管理センター (ADAC) を開いて、 [アカウントは重要なので委任できない] チェック ボックスをオンにします。
認証ポリシー
認証ポリシーは AD DS の新しいコンテナーで、認証ポリシー オブジェクトが含まれています。 認証ポリシーを使用すると、資格情報が盗用される可能性を軽減するのに役立つ設定を指定することができます。たとえば、アカウントの TGT の有効期間を制限したり、その他の要求関連の条件を追加できます。
Windows Server 2012 では、ダイナミック アクセス制御により、集約型アクセス ポリシーと呼ばれる Active Directory フォレスト スコープ オブジェクトのクラスが導入され、組織全体でファイル サーバーを構成する簡単な方法が提供されました。 Windows Server 2012 R2では、認証ポリシー (objectClass msDS-AuthNPolicies) と呼ばれる新しいオブジェクト クラスを使用して、Windows Server 2012 R2 ドメインのアカウント クラスに認証構成を適用できます。 次の Active Directory アカウント クラスがあります。
User
Computer
管理されたサービス アカウントおよびグループの管理されたサービス アカウント (GMSA)
クイック Kerberos リフレッシャー
Kerberos 認証プロトコルは、次の 3 種類の交換 (サブプロトコルとも呼ばれます) で構成されます。
認証サービス (AS) 交換 (KRB_AS_*)
チケット保証サービス (TGS) 交換 (KRB_TGS_*)
クライアント/サーバー (AP) 交換 (KRB_AP_*)
AS 交換は、チケット保証チケット (TGT) を要求する事前認証子を作成する、クライアントが、アカウントのパスワードまたは秘密キーを使用する場所です。 これは、ユーザーのサインオン時や、サービス チケットを初めて必要とする場合に発生します。
TGS 交換では、サービス チケットを要求する認証子を作成するアカウントの TGT が使用されています。 これは、認証済みの接続が必要な場合に発生します。
AP 交換は通常、アプリケーション プロトコル内部のデータとして発生し、認証ポリシーの影響を受けません。
詳細についてを参照してください。 「Kerberos バージョン 5 認証プロトコルの動作します。
概要
認証ポリシーは、アカウントに対して構成可能な制限を適用する方法を提供し、サービスおよびコンピューター用のアカウントにも制限を提供することで、Protected Users を補完します。 認証ポリシーは、AS 交換または TGS 交換の間に適用されます。
次の設定を構成することで、最初の認証または AS 交換を制限できます。
TGT の有効期間
ユーザーのサインオンを制限するアクセス制御条件。AS 交換が発生するデバイスでこの条件を満たす必要があります
次の設定を構成することで、チケット保証サービス (TGS) 交換を通じたサービス チケット要求を制限できます。
- クライアント (ユーザー、サービス、コンピューター) または TGS 交換が発生するデバイスで満たす必要があるアクセス制御条件
認証ポリシーを使用するための要件
| ポリシー | 必要条件 |
|---|---|
| TGT の有効期間のカスタマイズ | Windows Server 2012 R2 のドメイン機能レベルのアカウント ドメイン |
| ユーザー サインオンの制限 | - ダイナミック アクセス制御をサポートする Windows Server 2012 R2 のドメイン機能レベルのアカウント ドメイン - ダイナミック アクセス制御をサポートする Windows8、Windows 8.1、Windows Server 2012、または Windows Server 2012 R2 デバイス。 |
| ユーザー アカウントとセキュリティ グループに基づくサービス チケット発行の制限 | Windows Server 2012 R2 のドメイン機能レベルのリソース ドメイン |
| ユーザー要求またはデバイス アカウント、セキュリティ グループ、または要求に基づくサービス チケット発行の制限 | ダイナミック アクセス制御をサポートする Windows Server 2012 R2 ドメインの機能レベルのリソースドメイン |
ユーザー アカウントを特定のデバイスおよびホストに制限する
管理権限を持つ重要なアカウントは、Protected Users グループのメンバーである必要があります。 既定では、Protected Users グループのメンバーになっているアカウントはありません。 このグループにアカウントを追加する前に、ドメイン コントローラーのサポートを構成し、障害となるような問題がないことを保証するための監査ポリシーを作成してください。
ドメイン コントローラーのサポートを構成する
ユーザーのアカウント ドメインは、Windows Server 2012 R2 のドメイン機能レベル (DFL) にする必要があります。 すべてのドメイン コントローラーが WindowsServer 2012 R2 であることを確認してから、Active Directory ドメインと信頼を使用して DFL を WindowsServer 2012 R2 に昇格させます。
ダイナミック アクセス制御のサポートを構成するには
既定のドメイン コントローラー ポリシーで、[コンピューターの構成]、[管理用テンプレート]、[システム]、[KDC] の順に展開し、[有効] をクリックして [要求、複合認証、および Kerberos 防御のキー配布センター (KDC) クライアント サポート] を有効化します。
![[有効] オプションが強調表示されているスクリーンショット。](media/how-to-configure-protected-accounts/adds_protectacct_enablekdcclaims.gif)
[オプション] のドロップダウン リスト ボックスで、[常に信頼性情報を提供する] を選択します。
Note
サポートを構成することもできますが、ドメインは Windows Server 2012 R2 の DFL であるため、DC にクレームを常に提供させると、クレームに対応しないデバイスやホストを使用してクレームに対応するサービスに接続するときに、ユーザーのクレームベースのアクセス チェックを実行できます 。
![[常に要求を提供する] メニュー オプションが強調表示されているスクリーンショット。](media/how-to-configure-protected-accounts/adds_protectacct_alwaysprovideclaims.png)
警告
防御されていない認証要求の失敗を構成すると、Kerberos 防御をサポートしていないオペレーティング システム (Windows 7 以前のオペレーティングシステムなど)、または明示的にサポートを構成していない Windows8 以降のオペレーティング システムからの認証に失敗します。
認証ポリシーのユーザー アカウント監査を ADAC で作成する
Active Directory 管理センター (ADAC) を開きます。
![[認証] ページを示すスクリーンショット。](media/how-to-configure-protected-accounts/adds_protectacct_openadac.gif)
Note
選択した認証ノードは、Windows Server 2012 R2 DFL にあるドメインに表示されます。 ノードが表示されない場合は、Windows Server 2012 R2 DFL にあるドメインのドメイン管理者アカウントを使用して再試行してください。
[認証ポリシー] をクリックし、[新規] をクリックして新しいポリシーを作成します。
認証ポリシーには、既定で適用される表示名が必要です。
監査のみのポリシーを作成するには、[監査ポリシーの制限のみ] をクリックします。
![[監査ポリシーの制限のみ] オプションが強調表示されているスクリーンショット。](media/how-to-configure-protected-accounts/adds_protectacct_newauthnpolicyauditonly.gif)
認証ポリシーは、Active Directory のアカウントの種類に基づいて適用されます。 それぞれの種類に対する設定を構成することで、1 つのポリシーを 3 つのアカウントの種類すべてに適用できます。 次のアカウントの種類があります。
User
Computer
管理されたサービス アカウントおよびグループの管理されたサービス アカウント
キー配布センター (KDC) で使用できる新しいプリンシパルでスキーマを拡張した場合、新しいアカウントの種類は、最も近い派生アカウントの種類から分類されます。
ユーザー アカウントの TGT の有効期間を構成するには、[ユーザー アカウントのチケット保証チケットの有効期間を指定します] チェック ボックスをオンにして、時間を分単位で入力します。
![[ユーザー アカウントのチケット保証チケットの有効期間を指定します] チェック ボックスが強調表示されているスクリーンショット。](media/how-to-configure-protected-accounts/adds_protectacct_tgtlifetime.gif)
たとえば、TGT の最長有効期間を 10 時間にする場合は、画面に示すように「600」と入力します。 TGT の有効期間を構成しない場合、アカウントが Protected Users グループのメンバーであれば、TGT の有効期間および更新は 4 時間に設定されます。 そうでない場合、TGT の有効期間および更新はドメイン ポリシーによって異なります。例として、あるドメインの既定の設定が表示されている [グループ ポリシー管理エディター] ウィンドウを次に示します。
ユーザー アカウントを選択したデバイスに制限するには、[編集] をクリックし、デバイスで必要な条件を定義します。
[アクセス制御条件の編集] ウィンドウで、[条件の追加] をクリックします。
![[条件の追加] が強調表示されているスクリーンショット。](media/how-to-configure-protected-accounts/adds_protectacct_addcondition.png)
コンピューター アカウントまたはグループの条件を追加する
コンピューター アカウントまたはグループを構成するには、ドロップダウン リストで [次のそれぞれに所属する] を選択し、[次のいずれかに所属する] に変更します。
![[次のそれぞれに所属する] リスト ボックスが強調表示されているスクリーンショット。](media/how-to-configure-protected-accounts/adds_protectacct_addcompmember.png)
Note
このアクセス制御では、ユーザーのサインオン元のデバイスまたはホストの条件を定義します。 アクセス制御の用語では、デバイスまたはホストのコンピューター アカウントはユーザーと呼ばれるため、選択できるオプションは [ユーザー] のみです。
[項目の追加] をクリックします。
![[項目の追加] ボタンが強調表示されているスクリーンショット。](media/how-to-configure-protected-accounts/adds_protectacct_addcompadditems.png)
オブジェクトの種類を変更するには、[オブジェクトの種類] をクリックします。
![[オブジェクトの種類] ボタンが強調表示されているスクリーンショット。](media/how-to-configure-protected-accounts/adds_protectacct_changeobjects.gif)
Active Directory 内のコンピューター オブジェクトを選択するには、[コンピューター] をクリックし、[OK] をクリックします。
![[コンピューター] チェック ボックスが強調表示されているスクリーンショット。](media/how-to-configure-protected-accounts/adds_protectacct_changeobjectscomputers.gif)
ユーザーを制限するコンピューターの名前を入力し、[名前の確認] をクリックします。
![[名前の確認] が強調されているスクリーンショット。](media/how-to-configure-protected-accounts/adds_protectacct_changeobjectscompname.gif)
[OK] をクリックし、コンピューター アカウントに対するその他の条件があれば作成します。
完了したら、[OK] をクリックすると、コンピューター アカウントに対する定義済みの条件が表示されます。
![完了時に [OK] を選択する場所を示すスクリーンショット。](media/how-to-configure-protected-accounts/adds_protectacct_addcompdone.png)
コンピューターの要求の条件を追加する
コンピューターの要求を構成するには、[グループ] ドロップダウン リストで要求を選択します。
フォレストにプロビジョニング済みの要求のみを使用できます。
ユーザー アカウントのサインオンを制限する OU の名前を入力します。
完了したら、[OK] をクリックすると、定義済みの条件が表示されます。
コンピューターの要求が見つからない場合のトラブルシューティング
プロビジョニング済みの要求を使用できない場合、[コンピューター] クラスに対してのみ構成されている可能性があります。
たとえばを組織単位 (OU) に基づく認証を制限したいが限り、構成されているコンピューターの コンピューター クラスです。
![[コンピューター] チェック ボックスが強調表示されているスクリーンショット。](media/how-to-configure-protected-accounts/adds_protectacct_restrictcomputers.gif)
要求を使用してユーザーのデバイスへのサインオンを制限できるようにするには、[ユーザー] チェック ボックスをオンにします。
![[ユーザー] チェック ボックスが強調表示されているスクリーンショット。](media/how-to-configure-protected-accounts/adds_protectacct_restrictuserscomputers.gif)
ADAC で認証ポリシーをユーザー アカウントにプロビジョニングする
[ユーザー] アカウントで、[ポリシー] をクリックします。
![[ポリシー] を選択する場所を示すスクリーンショット。](media/how-to-configure-protected-accounts/adds_protectacct_userpolicy.gif)
[このアカウントに認証ポリシーを割り当てます] チェック ボックスをオンにします。
![[このアカウントに認証ポリシーを割り当てます] チェック ボックスが強調表示されているスクリーンショット。](media/how-to-configure-protected-accounts/adds_protectacct_userpolicyassign.gif)
ユーザーに適用する認証ポリシーを選択します。
デバイスおよびホストでダイナミック アクセス制御のサポートを構成する
ダイナミック アクセス制御 (DAC) を構成しなくても、TGT の有効期間を構成することができます。 DAC が必要となるのは、AllowedToAuthenticateFrom および AllowedToAuthenticateTo を確認する場合のみです。
グループ ポリシー エディターまたはローカル グループ ポリシー エディターを使用して、[コンピューターの構成]、[管理用テンプレート]、[システム]、[Kerberos] の順に展開し、[要求、複合認証、および Kerberos 防御の Kerberos クライアント サポート] を有効化します。
![[有効] オプションを選択する場所を示すスクリーンショット。](media/how-to-configure-protected-accounts/adds_protectacct_kerbclientdacsupport.gif)
認証ポリシーのトラブルシューティング
認証ポリシーが直接割り当てられたアカウントの特定
認証ポリシーの [アカウント] セクションには、ポリシーが直接適用されたアカウントが表示されます。
Authentication Policy Failures - Domain Controller 管理ログの使用します。
新しい Authentication Policy Failures - ドメイン コント ローラー 下にある管理ログ アプリケーションとサービス ログ>Microsoft>Windows>認証 、により、認証ポリシーのエラーを検出する容易に作成されました。 このログは、既定では無効になっています。 有効にするには、ログの名前を右クリックし、[ログの有効化] をクリックします。 新しいイベントは、既存の Kerberos TGT やサービス チケットの監査イベントの内容とよく似ています。 これらのイベント詳細については、「 認証ポリシーと認証ポリシー サイロ」をご覧ください。
Windows PowerShell を使用した認証ポリシーの管理
次のコマンドは、TestAuthenticationPolicy という名前の認証ポリシーを作成します。 UserAllowedToAuthenticateFrom パラメーターは、ユーザーが someFile.txt という名前のファイルに含まれる SDDL 文字列によって認証できるデバイスを指定します。
PS C:\> New-ADAuthenticationPolicy testAuthenticationPolicy -UserAllowedToAuthenticateFrom (Get-Acl .\someFile.txt).sddl
次のコマンドは、Filter パラメーターで指定されるフィルターと一致するすべての認証ポリシーを取得します。
PS C:\> Get-ADAuthenticationPolicy -Filter "Name -like 'testADAuthenticationPolicy*'" -Server Server02.Contoso.com
次のコマンドは、指定された認証ポリシーの Description および UserTGTLifetimeMins プロパティを変更します。
PS C:\> Set-ADAuthenticationPolicy -Identity ADAuthenticationPolicy1 -Description "Description" -UserTGTLifetimeMins 45
次のコマンドは、Identity パラメーターで指定される認証ポリシーを削除します。
PS C:\> Remove-ADAuthenticationPolicy -Identity ADAuthenticationPolicy1
次のコマンドは、Get-ADAuthenticationPolicy コマンドレットで Filter パラメーターを使用し、適用されていない認証ポリシーをすべて取得します。 結果セットは、パイプを使用して Remove-ADAuthenticationPolicy コマンドレットに渡されます。
PS C:\> Get-ADAuthenticationPolicy -Filter 'Enforce -eq $false' | Remove-ADAuthenticationPolicy
認証ポリシー サイロ
認証ポリシー サイロは、ユーザー、コンピューター、およびサービス アカウント向けの AD DS 内の新しいコンテナー (objectClass msDS-AuthNPolicySilos) です。 このコンテナーは、重要なアカウントを保護するのに役立ちます。 すべての組織は、Enterprise Admins、Domain Admins、および Schema Admins グループのメンバーを保護する必要があります。攻撃者がフォレスト内にアクセスするためにこれらのアカウントを使用する可能性があるためです。その一方で、その他のアカウントも保護が必要になる場合があります。
一部の組織では、ワークロードを分離するために、ワークロードに固有のアカウントを作成し、ローカルおよびリモートの対話型ログオンと管理者特権を制限するグループ ポリシー設定を適用しています。 認証ポリシー サイロは、ユーザー、コンピューター、および管理されたサービス アカウント間の関係を定義する方法を作成することで、このような作業を補完します。 アカウントが所属できるのは 1 つのサイロのみです。 それぞれのアカウントの種類に対して認証ポリシーを構成することで、次の項目を制御できます。
更新不可の TGT の有効期間
TGT を返すためのアクセス制御条件 (注: Kerberos 防御が必須であるため、システムに適用することはできません)
サービス チケットを返すためのアクセス制御条件
また、認証ポリシー サイロのアカウントにはサイロ要求があり、ファイル サーバーなど、要求に対応するリソースでアクセス制御を行うために使用できます。
サービス チケットの発行を制御するために、次の情報に基づいて新しいセキュリティ記述子を構成できます。
ユーザー、ユーザーのセキュリティ グループ、またはユーザーの要求
デバイス、デバイスのセキュリティ グループ、およびデバイスの要求
リソースの Dc には、この情報を取得するには、ダイナミック アクセス制御が必要です。
ユーザー要求:
ダイナミック アクセス制御をサポートする Windows 8 以降のクライアント
ダイナミック アクセス制御と要求をサポートするアカウント ドメイン
デバイスおよびデバイス セキュリティ グループ:
ダイナミック アクセス制御をサポートする Windows 8 以降のクライアント
複合認証用に構成されたリソース
デバイス要求:
ダイナミック アクセス制御をサポートする Windows 8 以降のクライアント
ダイナミック アクセス制御と要求をサポートするデバイス ドメイン
複合認証用に構成されたリソース
認証ポリシーは、個々のアカウントに適用する代わりに、認証ポリシー サイロのすべてのメンバーに適用できます。また、サイロ内の異なるアカウントの種類に個別の認証ポリシーを適用することもできます。 たとえば、ある認証ポリシーを高い権限を持つユーザー アカウントに適用し、別のポリシーをサービス アカウントに適用できます。 認証ポリシー サイロを作成するには、事前に少なくとも 1 つの認証ポリシーを作成する必要があります。
Note
認証ポリシーは、認証ポリシー サイロのメンバーに適用できますが、サイロとは無関係に適用して特定のアカウント スコープを制限することもできます。 たとえば、1 つのアカウントまたは少数のアカウント セットを保護するため、それらのアカウントをサイロに追加せずに、ポリシーを直接設定できます。
認証ポリシー サイロを作成するには、Active Directory 管理センターまたは Windows PowerShell を使用します。 既定では、認証ポリシー サイロのみサイロ ポリシーの監査を指定することと同じ、 WhatIf Windows PowerShell コマンドレットのパラメーターです。 この場合、ポリシー サイロの制限は適用されませんが、監査が生成され、制限が適用された場合にエラーが発生するかどうかが示されます。
Active Directory 管理センターを使用して認証ポリシー サイロを作成するには
Active Directory 管理センターを開き、[認証] をクリックして [認証ポリシー サイロ] を右クリックし、[新規]、[認証ポリシー サイロ] の順にクリックします。
[表示名] にサイロの名前を入力します。 [許可されたアカウント] で [追加] をクリックし、アカウントの名前を入力して、[OK] をクリックします。 ユーザー、コンピューター、またはサービス アカウントを指定できます。 次に、すべてのプリンシパルに 1 つのポリシーを使用するか、またはそれぞれのプリンシパルの種類に個別のポリシーを使用するかを指定して、ポリシーの名前を指定します。
Windows PowerShell を使用した認証ポリシー サイロの管理
次のコマンドは、認証ポリシー サイロ オブジェクトを作成して適用します。
PS C:\>New-ADAuthenticationPolicySilo -Name newSilo -Enforce
次のコマンドは、Filter パラメーターで指定されたフィルターに一致する認証ポリシー サイロをすべて取得します。 出力は Format-Table コマンドレットに渡され、ポリシーの名前と各ポリシーの Enforce の値が表示されます。
PS C:\>Get-ADAuthenticationPolicySilo -Filter 'Name -like "*silo*"' | Format-Table Name, Enforce -AutoSize
Name Enforce
---- -------
silo True
silos False
次のコマンドは、Get-ADAuthenticationPolicySilo コマンドレットで Filter パラメーターを使用して、適用されていない認証ポリシー サイロをすべて取得し、パイプを使用してフィルターの結果を Remove-ADAuthenticationPolicySilo コマンドレットに渡します。
PS C:\>Get-ADAuthenticationPolicySilo -Filter 'Enforce -eq $False' | Remove-ADAuthenticationPolicySilo
次のコマンドは、User01 という名前のユーザー アカウントに Silo という名前の認証ポリシー サイロへのアクセスを許可します。
PS C:\>Grant-ADAuthenticationPolicySiloAccess -Identity Silo -Account User01
次のコマンドは、User01 という名前のユーザー アカウントの Silo という名前の認証ポリシー サイロへのアクセスを取り消します。 Confirm パラメーターが $False に設定されているため、確認メッセージは表示されません。
PS C:\>Revoke-ADAuthenticationPolicySiloAccess -Identity Silo -Account User01 -Confirm:$False
次の例では、最初に Get-ADComputer コマンドレットを使用して、Filter パラメーターで指定されるフィルターに一致するコンピューター アカウントをすべて取得します。 このコマンドの出力は Set-ADAccountAuthenticatinPolicySilo に渡され、Silo という名前の認証ポリシー サイロと AuthenticationPolicy02 という名前の認証ポリシーが割り当てられます。
PS C:\>Get-ADComputer -Filter 'Name -like "newComputer*"' | Set-ADAccountAuthenticationPolicySilo -AuthenticationPolicySilo Silo -AuthenticationPolicy AuthenticationPolicy02