Pass-the-hash (PtH) 攻撃では、攻撃者はユーザーのパスワード (または他の資格情報の派生物) の基盤となる NTLM ハッシュを使用して、リモートのサーバーまたはサービスに対する認証を行うことができます。 Microsoft は、パス ハッシュ攻撃を軽減するためのガイダンスを以前 に公開 しました。 Windows Server 2012 R2 には、このような攻撃をさらに軽減するのに役立つ新機能が含まれています。 資格情報の盗用を防ぐのに役立つ、その他のセキュリティ機能の詳細については、「 資格情報の保護と管理」を参照してください。 この記事では、次の新機能を構成する方法について説明します。
Windows 8.1 と Windows Server 2012 R2 に組み込まれている追加の軽減策は、資格情報の盗難から保護するために役立ちます。この軽減策については、次の記事で説明します。
保護されたユーザー
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) の更新
ユーザーをグループに追加するには、Active Directory 管理センター (ADAC) や Active Directory ユーザーとコンピューターなどの UI ツール 、 Dsmod グループなどのコマンド ライン ツール、または Windows PowerShellAdd-ADGroupMember コマンドレットを使用できます。 サービスとコンピューターのアカウントを Protected Users グループのメンバーに することはできません 。 これらのアカウントのメンバーシップでは、パスワードまたは証明書が常にホストで利用できるため、ローカル保護が提供されません。
Warning
認証の制限には回避策はありません。つまり、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 以降を実行していない限り、ドメインでテストを歯内でください。
ドメインが作成される前に作成されたすべてのドメイン アカウントのパスワードを変更します。 そうしないと、これらのアカウントを認証できません。
保護されたユーザー グループにアカウントを追加する前に、各ユーザーのパスワードを変更するか、Windows Server 2008 以降を実行するドメイン コントローラーでパスワードが最近変更されたことを確認します。
保護されたアカウントを使用するための要件
保護されたアカウントを展開するには、次の要件があります。
保護されたユーザーに対してクライアント側の制限を提供するには、ホストで Windows 8.1 または Windows Server 2012 R2 を実行する必要があります。 ユーザーは、Protected Users グループのメンバーであるアカウントのみを使用してサインオンする必要があります。 この場合、保護されたユーザー グループは、 プライマリ ドメイン コントローラー (PDC) エミュレーターの役割を 、Windows Server 2012 R2 を実行するドメイン コントローラーに転送することによって作成できます。 そのグループのオブジェクトが他のドメイン コントローラーにレプリケートされた後に、以前のバージョンの Windows Server が実行されているドメイン コントローラーで PDC エミュレーターの役割をホストできます。
保護されたユーザーのドメイン コントローラー側の制限、つまり NTLM 認証の使用やその他の制限を提供するには、ドメインの機能レベルが Windows Server 2012 R2 である必要があります。 機能レベルの詳細については、「 AD DS の機能レベルとは」をご覧ください。
Note
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 の有効期間と更新を設定します。
保護されたユーザーの場合、次の設定がハードコーディングされています。
ユーザー チケットの最長有効期間:240 分
ユーザー チケット更新の最長有効期間:240 分
委任に関する問題のトラブルシューティング
以前は、Kerberos 委任を使用するテクノロジで問題が発生すると、クライアント アカウントに [アカウントは重要なので委任できない] が設定されているかどうかを確認していました。 ただし、アカウントが 保護されたユーザーのメンバーである場合は、Active Directory 管理センター (ADAC) でこの設定が構成されていない可能性があります。 そのため、委任に関する問題のトラブルシューティングを行う場合は、この設定だけでなくグループ メンバーシップも確認してください。
認証試行の監査
Protected Users グループのメンバーに対する認証試行を明示的に監査するには、引き続きセキュリティ ログ監査イベントを収集するか、新しい運用管理ログのデータを収集します。 これらのイベント詳細については、「 認証ポリシーと認証ポリシー サイロ」をご覧ください。
サービスとコンピューターに対して DC 側の保護を提供する
サービスとコンピューターのアカウントを 保護されたユーザーのメンバーにすることはできません。 このセクションでは、これらのアカウントに提供できるドメイン コントローラー ベースの保護について説明します。
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 認証プロトコルの動作します。
Overview
認証ポリシーは、アカウントに対して構成可能な制限を適用する方法を提供し、サービスおよびコンピューター用のアカウントにも制限を提供することで、Protected Users を補完します。 認証ポリシーは、AS 交換または TGS 交換の間に適用されます。
次の設定を構成することで、最初の認証または AS 交換を制限できます。
TGT の有効期間
ユーザーのサインオンを制限するアクセス制御条件。AS 交換が発生するデバイスでこの条件を満たす必要があります
次の設定を構成することで、チケット保証サービス (TGS) 交換を通じたサービス チケット要求を制限できます。
- TGS 交換元のクライアント (ユーザー、サービス、コンピューター) またはデバイスが満たす必要があるアクセス制御条件
認証ポリシーを使用するための要件
Policy | Requirements |
---|---|
TGT の有効期間のカスタマイズ | Windows Server 2012 R2 のドメイン機能レベルのアカウント ドメイン |
ユーザー サインオンの制限 | - ダイナミック アクセス制御をサポートする Windows Server 2012 R2 のドメイン機能レベルのアカウント ドメイン - 動的アクセス制御がサポートされている Windows 8、Windows 8.1、Windows Server 2012、または Windows Server 2012 R2 デバイス |
ユーザー アカウントとセキュリティ グループに基づくサービス チケット発行の制限 | Windows Server 2012 R2 のドメイン機能レベルのリソース ドメイン |
ユーザー要求またはデバイス アカウント、セキュリティ グループ、または要求に基づくサービス チケット発行の制限 | ダイナミック アクセス制御をサポートする Windows Server 2012 R2 ドメインの機能レベルのリソースドメイン |
ユーザー アカウントを特定のデバイスおよびホストに制限する
管理特権を持つ価値の高いアカウントは、 Protected Users グループのメンバーである必要があります。 既定では、 保護されたユーザー グループのメンバーであるアカウントはありません。 このグループにアカウントを追加する前に、ドメイン コントローラーのサポートを構成し、障害となるような問題がないことを保証するための監査ポリシーを作成してください。
Warning
認証ポリシーとサイロには、いくつかの制限があります。 その有効性を最大限に高め、ネットワーク セキュリティを維持するには、次のベスト プラクティスを検討してください。
- クライアント コンピューターとドメイン コントローラーが常にネットワークに接続されていることを確認します。
- 認証ポリシーを構成した後、保護されたアカウントのパスワードを変更して、クライアント コンピューターで以前にキャッシュされた資格情報を無効にします。
- キャッシュされたログオンを可能な限り無効にして、資格情報の再利用のリスクをさらに軽減します。
ドメイン コントローラーのサポートを構成する
ユーザーのアカウント ドメインは、Windows Server 2012 R2 のドメイン機能レベル (DFL) にする必要があります。 すべてのドメイン コントローラーが Windows Server 2012 R2 であることを確認し、Active Directory ドメインと信頼を使用して DFL を Windows Server 2012 R2 に 上げます 。
ダイナミック アクセス制御のサポートを構成するには
既定のドメイン コントローラー ポリシーで、[ 有効] をクリックして、コンピューターの構成で クレーム、複合認証、Kerberos 防御のキー配布センター (KDC) クライアントサポートを 有効にします 。管理用テンプレート |システム |KDC。
[ オプション] のドロップダウン リスト ボックスで、[ 常に要求を指定する] を選択します。
Note
サポートされている 構成も可能ですが、ドメインは Windows Server 2012 R2 DFL にあるため、DC が常にクレームを提供することで、クレーム対応ではないデバイスとホストを使用してクレーム対応サービスに接続するときに、ユーザーのクレームベースのアクセス チェックを実行できます。
Warning
非装甲認証要求の失敗を構成すると、Kerberos 防御をサポートしていないオペレーティング システム、例えば Windows 7 やそれ以前のもの、およびサポートが明示的に設定されていない Windows 8 以降のオペレーティング システム、から認証エラーが発生します。
認証ポリシーのユーザー アカウント監査を ADAC で作成する
Active Directory 管理センター (ADAC) を開きます。
Note
選択した 認証 ノードは、Windows Server 2012 R2 DFL にあるドメインに対して表示されます。 ノードが表示されない場合は、Windows Server 2012 R2 DFL にあるドメインのドメイン管理者アカウントを使用して再試行してください。
[ 認証ポリシー] をクリックし、[ 新規 ] をクリックして新しいポリシーを作成します。
認証ポリシーには、既定で適用される表示名が必要です。
監査のみのポリシーを作成するには、 [監査ポリシーの制限のみ]をクリックします。
認証ポリシーは、Active Directory のアカウントの種類に基づいて適用されます。 それぞれの種類に対する設定を構成することで、1 つのポリシーを 3 つのアカウントの種類すべてに適用できます。 次のアカウントの種類があります。
User
Computer
管理されたサービス アカウントおよびグループの管理されたサービス アカウント
キー配布センター (KDC) で使用できる新しいプリンシパルでスキーマを拡張した場合、新しいアカウントの種類は、最も近い派生アカウントの種類から分類されます。
ユーザー アカウントの TGT の有効期間を構成するには、 [ユーザー アカウントのチケット保証チケットの有効期間を指定します] チェック ボックスをオンにして、時間を分単位で入力します。
たとえば、10 時間の最大 TGT 有効期間が必要な場合は、次のように 「600 」と入力します。 TGT 有効期間が構成されていない場合、アカウントが Protected Users グループのメンバーである場合、TGT の有効期間と更新は 4 時間です。 そうでない場合、TGT の有効期間および更新はドメイン ポリシーによって異なります。例として、あるドメインの既定の設定が表示されている [グループ ポリシー管理エディター] ウィンドウを次に示します。
デバイスを選択するようにユーザー アカウントを制限するには、[ 編集 ] をクリックして、デバイスに必要な条件を定義します。
[アクセス制御条件の編集] ウィンドウで、 [条件の追加]をクリックします。
コンピューター アカウントまたはグループの条件を追加する
コンピューター アカウントまたはグループを構成するには、ドロップダウン リストで [次のそれぞれに所属する] を選択し、 [次のいずれかに所属する]に変更します。
Note
このアクセス制御では、ユーザーのサインオン元のデバイスまたはホストの条件を定義します。 アクセス制御の用語では、デバイスまたはホストのコンピューター アカウントがユーザーであるため、 ユーザー のみが選択できます。
[ アイテムの追加] をクリックします。
オブジェクトの種類を変更するには、[ オブジェクトの種類] をクリックします。
Active Directory でコンピューター オブジェクトを選択するには、[ コンピューター] をクリックし、[ OK] をクリックします。
ユーザーを制限するコンピューターの名前を入力し、[ 名前の確認] をクリックします。
[OK] をクリックし、コンピューター アカウントに対するその他の条件があれば作成します。
完了したら、[ OK ] をクリックすると、コンピューター アカウントに対して定義された条件が表示されます。
コンピューターの要求の条件を追加する
コンピューターの要求を構成するには、[グループ] ドロップダウン リストで要求を選択します。
フォレストにプロビジョニング済みの要求のみを使用できます。
ユーザー アカウントのサインオンを制限する OU の名前を入力します。
完了したら、[OK] をクリックすると、ボックスに定義されている条件が表示されます。
コンピューターの要求が見つからない場合のトラブルシューティング
要求がプロビジョニングされているが使用できない場合は、 コンピューター クラスに対してのみ構成できます。
たとえば、既に構成されているコンピューターの組織単位 (OU) に基づいて認証を制限し、 コンピューター クラスに対してのみ認証を制限したいとします。
ユーザーのサインオンをデバイスに制限するために要求を使用できるようにするには、[ ユーザー ] チェック ボックスをオンにします。
ADAC で認証ポリシーをユーザー アカウントにプロビジョニングする
ユーザー アカウントで、[ポリシー] をクリックします。
[このアカウントに認証ポリシーを割り当てます] チェック ボックスをオンにします。
ユーザーに適用する認証ポリシーを選択します。
デバイスおよびホストでダイナミック アクセス制御のサポートを構成する
ダイナミック アクセス制御 (DAC) を構成しなくても、TGT の有効期間を構成することができます。 DAC が必要となるのは、AllowedToAuthenticateFrom および AllowedToAuthenticateTo を確認する場合のみです。
グループ ポリシーまたはローカル グループ ポリシー エディターを使用して、有効にする 信頼性情報、複合認証および Kerberos 防御の Kerberos クライアント サポート コンピューターの構成 |管理用テンプレート |システム |Kerberos:
認証ポリシーのトラブルシューティング
認証ポリシーが直接割り当てられたアカウントの特定
認証ポリシーの [アカウント] セクションには、ポリシーが直接適用されたアカウントが表示されます。
Authentication Policy Failures - Domain Controller 管理ログの使用します。
認証ポリシーによる障害をより簡単に特定するために、アプリケーションとサービス ログ >>>に新たにAuthentication Policy Failures - Domain Controller という管理用ログが作成されました。 このログは、既定では無効になっています。 有効にするには、ログ名を右クリックし、[ログの 有効化] をクリックします。 新しいイベントは、既存の 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
このコマンドは、指定された認証ポリシーの説明と 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 を使用します。 既定では、認証ポリシー サイロはサイロ ポリシーのみを監査します。これは、Windows PowerShell コマンドレットで WhatIf パラメーターを指定することと同じです。 この場合、ポリシー サイロの制限は適用されませんが、監査が生成され、制限が適用された場合にエラーが発生するかどうかが示されます。
Active Directory 管理センターを使用して認証ポリシー サイロを作成するには
Active Directory 管理センターを開き、 [認証]をクリックして [認証ポリシー サイロ]を右クリックし、 [新規]、 [認証ポリシー サイロ]の順にクリックします。
[表示名] に、サイロの名前を入力します。 [許可されたアカウント] で、[追加] をクリックし、アカウントの名前を入力して、[OK] をクリックします。 ユーザー、コンピューター、またはサービス アカウントを指定できます。 次に、すべてのプリンシパルに 1 つのポリシーを使用するか、またはそれぞれのプリンシパルの種類に個別のポリシーを使用するかを指定して、ポリシーの名前を指定します。
Windows PowerShell を使用した認証ポリシー サイロの管理
次のコマンドは、認証ポリシー サイロ オブジェクトを作成して適用します。
PS C:\>New-ADAuthenticationPolicySilo -Name newSilo -Enforce
このコマンドは、 Filter パラメーターで指定されたフィルターに一致するすべての認証ポリシー サイロを取得します。 次に、出力が Format-Table コマンドレットに渡され、ポリシーの名前と各ポリシーの [強制 ] の値が表示されます。
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-ADAccountAuthenticationPolicySilo に渡され、 Silo という名前の認証ポリシー サイロと AuthenticationPolicy02 という名前の認証ポリシーが割り当てられます。
PS C:\>Get-ADComputer -Filter 'Name -like "newComputer*"' | Set-ADAccountAuthenticationPolicySilo -AuthenticationPolicySilo Silo -AuthenticationPolicy AuthenticationPolicy02