保護されたアカウントを構成する方法について説明します

Pass-the-hash (PtH) 攻撃では、攻撃者はユーザーのパスワード (または他の資格情報の派生物) の基盤となる NTLM ハッシュを使用して、リモートのサーバーまたはサービスに対する認証を行うことができます。 Microsoft has previously published guidance to mitigate pass-the-hash attacks. Windows Server 2012 R2 には、このような攻撃をさらに軽減するのに役立つ新機能が含まれています。 資格情報の盗用を防ぐのに役立つ、その他のセキュリティ機能の詳細については、「 資格情報の保護と管理」を参照してください。 この記事では、次の新機能を構成する方法について説明します。

• Protected Users

• Authentication policies

• 認証ポリシー サイロ

Windows 8.1 と Windows Server 2012 R2 に組み込まれている追加の軽減策は、資格情報の盗難から保護するために役立ちます。この軽減策については、次の記事で説明します。

• リモート デスクトップのための制限付き管理モード

• LSA Protection

Protected Users

Protected Users は、新しいユーザーや既存のユーザーを追加できる新しいグローバル セキュリティ グループです。 Windows 8.1 デバイスと Windows Server 2012 R2 ホストは、このグループのメンバーと特別な動作をして、資格情報の盗難に対する保護を強化します。 グループのメンバーの場合、Windows 8.1 デバイスまたは Windows Server 2012 R2 ホストは、Protected Users に対してサポートされていない資格情報をキャッシュしません。 このグループのメンバーの場合、追加の保護があるいない Windows 8.1 より前のバージョンの Windows を実行しているデバイスにログオンしている場合。

Members of the Protected Users group who are signed-on to Windows 8.1 devices and Windows Server 2012 R2 hosts can no longer use:

• 既定の資格情報の委任 (CredSSP) - プレーンテキストの資格情報は、[既定の資格情報の委任を許可する] ポリシーが有効な場合でもキャッシュされません

• Windows ダイジェスト - プレーンテキストの資格情報はそれらが有効な場合でもキャッシュされません

• NTLM - NTOWF はキャッシュされません

• Kerberos 長期キー - Kerberos チケット保証チケット (TGT) はログオン時に取得され、自動で再取得することはできません

• オフラインでのサインオン - キャッシュされたログオン検証は作成されません

ドメインの機能レベルが Windows Server 2012 R2 の場合、グループのメンバーはもはや次のことを行えません。

• NTLM 認証を使用した認証

• Kerberos 事前認証におけるデータ暗号化標準 (DES) または RC4 暗号スイートの使用

• 制約なし/制約付き委任を使用した委任

• 最初の 4 時間の有効期間後のユーザー チケット (TGT) の更新

To add users to the group, you can use UI tools such as Active Directory Administrative Center (ADAC) or Active Directory Users and Computers, or a command-line tool such as Dsmod group, or the Windows PowerShellAdd-ADGroupMember cmdlet. Accounts for services and computers should not be members of the Protected Users group. これらのアカウントのメンバーシップでは、パスワードまたは証明書が常にホストで利用できるため、ローカル保護が提供されません。

Protected Users グループのメンバーは、Kerberos で高度暗号化標準 (AES) を使用して認証できる必要があります。 この方法では、Active Directory のアカウントに対する AES キーが必要です。 ビルトイン Administrator は、Windows Server 2008 以降を実行しているドメイン コントローラーでパスワードが変更されない限り、AES キーを持ちません。 また、以前のバージョンの Windows Server が実行されているドメイン コントローラーでパスワードが変更されたアカウントはロック アウトされます。そのため、次のベストプラクティスに従ってください。

• すべてのドメイン コントローラーが Windows Server 2008 以降を実行していない限り、ドメインでテストを歯内でください。

• Change password for all ___domain accounts that were created before the ___domain was created. そうしないと、これらのアカウントを認証できません。

• Change password for each user before adding the account to the Protected Users group or ensure that the password was changed recently on a ___domain controller that runs Windows Server 2008 or later.

保護されたアカウントを使用するための要件

保護されたアカウントを展開するには、次の要件があります。

• 保護されたユーザーに対してクライアント側の制限を提供するには、ホストで Windows 8.1 または Windows Server 2012 R2 を実行する必要があります。 ユーザーは、Protected Users グループのメンバーであるアカウントのみを使用してサインオンする必要があります。 この場合、保護されたユーザー グループは、 プライマリ ドメイン コントローラー (PDC) エミュレーターの役割を 、Windows Server 2012 R2 を実行するドメイン コントローラーに転送することによって作成できます。 そのグループのオブジェクトが他のドメイン コントローラーにレプリケートされた後に、以前のバージョンの Windows Server が実行されているドメイン コントローラーで PDC エミュレーターの役割をホストできます。

• 保護されたユーザーのドメイン コントローラー側の制限、つまり NTLM 認証の使用やその他の制限を提供するには、ドメインの機能レベルが Windows Server 2012 R2 である必要があります。 機能レベルの詳細については、「 AD DS の機能レベルとは」をご覧ください。

Protected Users に関連するイベントのトラブルシューティング

このセクションでは、Protected Users に関連するイベントのトラブルシューティングに役立つ新しいログについて説明します。さらに、チケット保証チケット (TGT) の有効期限または委任に関する問題のいずれかのトラブルシューティングを行う際に、Protected Users がどのような影響を与えるかを説明します。

Protected Users 向けの新しいログ

Protected Users に関連するイベントのトラブルシューティングに役立つ 2 つの新しい運用管理ログがある: 保護されたユーザー - クライアントのログと保護されているユーザー エラー - ドメイン コント ローラーのログ。 これらの新しいログはイベント ビューアーにありますが、既定では無効になっています。 ログを有効化するには、[アプリケーションとサービス ログ]、[Microsoft]、[Windows]、[Authentication] の順にクリックし、ログの名前をクリックして [操作] をクリックし (またはログを右クリック)、[ログの有効化] をクリックします。

これらのログのイベント詳細については、「 認証ポリシーと認証ポリシー サイロ」をご覧ください。

TGT の有効期限のトラブルシューティング

通常、ドメイン コントローラーは、次の [グループ ポリシー管理エディター] ウィンドウに表示されるドメイン ポリシーに基づいて、TGT の有効期間と更新を設定します。

For Protected Users, the following settings are hard-coded:

• ユーザー チケットの最長有効期間:240 分

• ユーザー チケット更新の最長有効期間:240 分

委任に関する問題のトラブルシューティング

以前は、Kerberos 委任を使用するテクノロジで問題が発生すると、クライアント アカウントに [アカウントは重要なので委任できない] が設定されているかどうかを確認していました。 However, if the account is a member of Protected Users, it might not have this setting configured in Active Directory Administrative Center (ADAC). そのため、委任に関する問題のトラブルシューティングを行う場合は、この設定だけでなくグループ メンバーシップも確認してください。

認証試行の監査

To audit authentication attempts explicitly for the members of the Protected Users group, you can continue to collect security log audit events or collect the data in the new operational administrative logs. これらのイベント詳細については、「 認証ポリシーと認証ポリシー サイロ」をご覧ください。

サービスとコンピューターに対して DC 側の保護を提供する

Accounts for services and computers cannot be members of Protected Users. このセクションでは、これらのアカウントに提供できるドメイン コントローラー ベースの保護について説明します。

• NTLM 認証の拒否: NTLM ブロック ポリシーを通じてのみ構成できます

• Kerberos 事前認証でのデータ暗号化標準 (DES) の拒否: Windows Server 2012 R2 ドメイン コントローラーは、Kerberos でリリースされたすべてのバージョンのWindows が RC4 もサポートしているため、DES 用に構成されていない限り、コンピューター アカウントの DES を受け入れません。

• Kerberos 事前認証での RC4 の拒否: 構成できません。

  Note

  サポートされている暗号化の種類の構成を変更することはできますが、コンピューター アカウントでこれらの設定を変更する場合は、あらかじめターゲット環境でテストすることをお勧めします。

• ユーザー チケット (TGT) を最初の 4 時間の有効期間に制限:認証ポリシーを使用します。

• 制約なし/制約付き委任による委任を拒否:アカウントを制限するには、Active Directory 管理センター (ADAC) を開いて、 [アカウントは重要なので委任できない] チェック ボックスをオンにします。

  

Authentication policies

認証ポリシーは 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 交換元のクライアント (ユーザー、サービス、コンピューター) またはデバイスが満たす必要があるアクセス制御条件

認証ポリシーを使用するための要件

ユーザー アカウントを特定のデバイスおよびホストに制限する

A high-value account with administrative privilege should be a member of the Protected Users group. By default, no accounts are members of the Protected Users group. このグループにアカウントを追加する前に、ドメイン コントローラーのサポートを構成し、障害となるような問題がないことを保証するための監査ポリシーを作成してください。

ドメイン コントローラーのサポートを構成する

ユーザーのアカウント ドメインは、Windows Server 2012 R2 のドメイン機能レベル (DFL) にする必要があります。 すべてのドメイン コントローラーが Windows Server 2012 R2 であることを確認し、Active Directory ドメインと信頼を使用して DFL を Windows Server 2012 R2 に 上げます 。

ダイナミック アクセス制御のサポートを構成するには

1. In the Default Domain Controllers Policy, click Enabled to enable Key Distribution Center (KDC) client support for claims, compound authentication and Kerberos armoring in Computer Configuration | Administrative Templates | System | KDC.

   

2. Under Options, in the drop-down list box, select Always provide claims.

   Note

   Supported can also be configured, but because the ___domain is at Windows Server 2012 R2 DFL, having the DCs always provide claims allows user claims-based access checks to occur when using non-claims aware devices and hosts to connect to claims-aware services.

   

   Warning

   非装甲認証要求の失敗を構成すると、Kerberos 防御をサポートしていないオペレーティング システム、例えば Windows 7 やそれ以前のもの、およびサポートが明示的に設定されていない Windows 8 以降のオペレーティング システム、から認証エラーが発生します。

認証ポリシーのユーザー アカウント監査を ADAC で作成する

1. Active Directory 管理センター (ADAC) を開きます。

   

   Note

   The selected Authentication node is visible for domains that are at the Windows Server 2012 R2 DFL. ノードが表示されない場合は、Windows Server 2012 R2 DFL にあるドメインのドメイン管理者アカウントを使用して再試行してください。

2. Click Authentication Policies, and then click New to create a new policy.

   

   認証ポリシーには、既定で適用される表示名が必要です。

3. 監査のみのポリシーを作成するには、 [監査ポリシーの制限のみ]をクリックします。

   

   認証ポリシーは、Active Directory のアカウントの種類に基づいて適用されます。 それぞれの種類に対する設定を構成することで、1 つのポリシーを 3 つのアカウントの種類すべてに適用できます。 次のアカウントの種類があります。

   • User

   • Computer

   • 管理されたサービス アカウントおよびグループの管理されたサービス アカウント

   キー配布センター (KDC) で使用できる新しいプリンシパルでスキーマを拡張した場合、新しいアカウントの種類は、最も近い派生アカウントの種類から分類されます。

4. ユーザー アカウントの TGT の有効期間を構成するには、 [ユーザー アカウントのチケット保証チケットの有効期間を指定します] チェック ボックスをオンにして、時間を分単位で入力します。

   

   For example, if you want a 10-hour maximum TGT lifetime, enter 600 as shown. If no TGT lifetime is configured, then if the account is a member of the Protected Users group, the TGT lifetime and renewal is 4 hours. そうでない場合、TGT の有効期間および更新はドメイン ポリシーによって異なります。例として、あるドメインの既定の設定が表示されている [グループ ポリシー管理エディター] ウィンドウを次に示します。

   

5. To restrict the user account to select devices, click Edit to define the conditions that are required for the device.

   

6. [アクセス制御条件の編集] ウィンドウで、 [条件の追加]をクリックします。

   

コンピューター アカウントまたはグループの条件を追加する

1. コンピューター アカウントまたはグループを構成するには、ドロップダウン リストで [次のそれぞれに所属する] を選択し、 [次のいずれかに所属する]に変更します。

   

   Note

   このアクセス制御では、ユーザーのサインオン元のデバイスまたはホストの条件を定義します。 In access control terminology, the computer account for the device or host is the user, which is why User is the only option.

2. Click Add items.

   

3. To change object types, click Object Types.

   

4. To select computer objects in Active Directory, click Computers, and then click OK.

   

5. Type the name of the computers to restrict the user, and then click Check Names.

   

6. [OK] をクリックし、コンピューター アカウントに対するその他の条件があれば作成します。

   

7. When done, then click OK and the defined conditions appear for the computer account.

   

コンピューターの要求の条件を追加する

1. コンピューターの要求を構成するには、[グループ] ドロップダウン リストで要求を選択します。

   

   フォレストにプロビジョニング済みの要求のみを使用できます。

2. ユーザー アカウントのサインオンを制限する OU の名前を入力します。

   

3. 完了したら、[OK] をクリックすると、ボックスに定義されている条件が表示されます。

   

コンピューターの要求が見つからない場合のトラブルシューティング

If the claim has been provisioned, but is not available, it might only be configured for Computer classes.

Let's say you wanted to restrict authentication based on the organizational unit (OU) of the computer, which was already configured, but only for Computer classes.

For the claim to be available to restrict User sign-on to the device, select the User check box.

ADAC で認証ポリシーをユーザー アカウントにプロビジョニングする

1. From the User account, click Policy.

   

2. [このアカウントに認証ポリシーを割り当てます] チェック ボックスをオンにします。

   

3. ユーザーに適用する認証ポリシーを選択します。

   

デバイスおよびホストでダイナミック アクセス制御のサポートを構成する

ダイナミック アクセス制御 (DAC) を構成しなくても、TGT の有効期間を構成することができます。 DAC が必要となるのは、AllowedToAuthenticateFrom および AllowedToAuthenticateTo を確認する場合のみです。

グループ ポリシーまたはローカル グループ ポリシー エディターを使用して、有効にする 信頼性情報、複合認証および Kerberos 防御の Kerberos クライアント サポート コンピューターの構成 |管理用テンプレート |システム |Kerberos:

認証ポリシーのトラブルシューティング

認証ポリシーが直接割り当てられたアカウントの特定

認証ポリシーの [アカウント] セクションには、ポリシーが直接適用されたアカウントが表示されます。

Authentication Policy Failures - Domain Controller 管理ログの使用します。

認証ポリシーによる障害をより簡単に特定するために、アプリケーションとサービス ログ >Microsoft >Windows >認証に新たにAuthentication Policy Failures - Domain Controller という管理用ログが作成されました。 このログは、既定では無効になっています。 To enable it, right-click the log name and click Enable Log. 新しいイベントは、既存の Kerberos TGT およびサービス チケット監査イベントの内容に似ています。 これらのイベント詳細については、「 認証ポリシーと認証ポリシー サイロ」をご覧ください。

Windows PowerShell を使用した認証ポリシーの管理

This command creates an authentication policy named TestAuthenticationPolicy. The UserAllowedToAuthenticateFrom parameter specifies the devices from which users can authenticate by an SDDL string in the file named someFile.txt.

PS C:\> New-ADAuthenticationPolicy testAuthenticationPolicy -UserAllowedToAuthenticateFrom (Get-Acl .\someFile.txt).sddl

This command gets all authentication policies that match the filter that the Filter parameter specifies.

PS C:\> Get-ADAuthenticationPolicy -Filter "Name -like 'testADAuthenticationPolicy*'" -Server Server02.Contoso.com

This command modifies the description and the UserTGTLifetimeMins properties of the specified authentication policy.

PS C:\> Set-ADAuthenticationPolicy -Identity ADAuthenticationPolicy1 -Description "Description" -UserTGTLifetimeMins 45

This command removes the authentication policy that the Identity parameter specifies.

PS C:\> Remove-ADAuthenticationPolicy -Identity ADAuthenticationPolicy1

This command uses the Get-ADAuthenticationPolicy cmdlet with the Filter parameter to get all authentication policies that are not enforced. The result set is piped to the Remove-ADAuthenticationPolicy cmdlet.

PS C:\> Get-ADAuthenticationPolicy -Filter 'Enforce -eq $false' | Remove-ADAuthenticationPolicy

認証ポリシー サイロ

認証ポリシー サイロは、ユーザー、コンピューター、およびサービス アカウント向けの AD DS 内の新しいコンテナー (objectClass msDS-AuthNPolicySilos) です。 このコンテナーは、重要なアカウントを保護するのに役立ちます。 すべての組織は、Enterprise Admins、Domain Admins、および Schema Admins グループのメンバーを保護する必要があります。攻撃者がフォレスト内にアクセスするためにこれらのアカウントを使用する可能性があるためです。その一方で、その他のアカウントも保護が必要になる場合があります。

一部の組織では、ワークロードを分離するために、ワークロードに固有のアカウントを作成し、ローカルおよびリモートの対話型ログオンと管理者特権を制限するグループ ポリシー設定を適用しています。 認証ポリシー サイロは、ユーザー、コンピューター、および管理されたサービス アカウント間の関係を定義する方法を作成することで、このような作業を補完します。 アカウントが所属できるのは 1 つのサイロのみです。 それぞれのアカウントの種類に対して認証ポリシーを構成することで、次の項目を制御できます。

1. 更新不可の TGT の有効期間

2. TGT を返すためのアクセス制御条件 (注: Kerberos 防御が必須であるため、システムに適用することはできません)

3. サービス チケットを返すためのアクセス制御条件

また、認証ポリシー サイロのアカウントにはサイロ要求があり、ファイル サーバーなど、要求に対応するリソースでアクセス制御を行うために使用できます。

サービス チケットの発行を制御するために、次の情報に基づいて新しいセキュリティ記述子を構成できます。

• ユーザー、ユーザーのセキュリティ グループ、またはユーザーの要求

• デバイス、デバイスのセキュリティ グループ、およびデバイスの要求

リソースの Dc には、この情報を取得するには、ダイナミック アクセス制御が必要です。

• User claims:

  • ダイナミック アクセス制御をサポートする Windows 8 以降のクライアント

  • ダイナミック アクセス制御と要求をサポートするアカウント ドメイン

• デバイスおよびデバイス セキュリティ グループ:

  • ダイナミック アクセス制御をサポートする Windows 8 以降のクライアント

  • 複合認証用に構成されたリソース

• Device claims:

  • ダイナミック アクセス制御をサポートする Windows 8 以降のクライアント

  • ダイナミック アクセス制御と要求をサポートするデバイス ドメイン

  • 複合認証用に構成されたリソース

認証ポリシーは、個々のアカウントに適用する代わりに、認証ポリシー サイロのすべてのメンバーに適用できます。また、サイロ内の異なるアカウントの種類に個別の認証ポリシーを適用することもできます。 たとえば、ある認証ポリシーを高い権限を持つユーザー アカウントに適用し、別のポリシーをサービス アカウントに適用できます。 認証ポリシー サイロを作成するには、事前に少なくとも 1 つの認証ポリシーを作成する必要があります。

認証ポリシー サイロを作成するには、Active Directory 管理センターまたは Windows PowerShell を使用します。 By default, an authentication policy silo only audits silo policies, which is equivalent to specifying the WhatIf parameter in Windows PowerShell cmdlets. この場合、ポリシー サイロの制限は適用されませんが、監査が生成され、制限が適用された場合にエラーが発生するかどうかが示されます。

Active Directory 管理センターを使用して認証ポリシー サイロを作成するには

1. Active Directory 管理センターを開き、 [認証]をクリックして [認証ポリシー サイロ]を右クリックし、 [新規]、 [認証ポリシー サイロ]の順にクリックします。

   

2. In Display name, type a name for the silo. In Permitted Accounts, click Add, type the names of the accounts, and then click OK. ユーザー、コンピューター、またはサービス アカウントを指定できます。 次に、すべてのプリンシパルに 1 つのポリシーを使用するか、またはそれぞれのプリンシパルの種類に個別のポリシーを使用するかを指定して、ポリシーの名前を指定します。

   

Windows PowerShell を使用した認証ポリシー サイロの管理

次のコマンドは、認証ポリシー サイロ オブジェクトを作成して適用します。

PS C:\>New-ADAuthenticationPolicySilo -Name newSilo -Enforce

This command gets all the authentication policy silos that match the filter that is specified by the Filter parameter. The output is then passed to the Format-Table cmdlet to display the name of the policy and the value for Enforce on each policy.

PS C:\>Get-ADAuthenticationPolicySilo -Filter 'Name -like "*silo*"' | Format-Table Name, Enforce -AutoSize

Name  Enforce
----  -------
silo     True
silos   False

This command uses the Get-ADAuthenticationPolicySilo cmdlet with the Filter parameter to get all authentication policy silos that are not enforced and pipe the result of the filter to the Remove-ADAuthenticationPolicySilo cmdlet.

PS C:\>Get-ADAuthenticationPolicySilo -Filter 'Enforce -eq $False' | Remove-ADAuthenticationPolicySilo

This command grants access to the authentication policy silo named Silo to the user account named User01.

PS C:\>Grant-ADAuthenticationPolicySiloAccess -Identity Silo -Account User01

This command revokes access to the authentication policy silo named Silo for the user account named User01. Because the Confirm parameter is set to $False, no confirmation message appears.

PS C:\>Revoke-ADAuthenticationPolicySiloAccess -Identity Silo -Account User01 -Confirm:$False

This example first uses the Get-ADComputer cmdlet to get all computer accounts that match the filter that the Filter parameter specifies. The output of this command is passed to Set-ADAccountAuthenticationPolicySilo to assign the authentication policy silo named Silo and the authentication policy named AuthenticationPolicy02 to them.

PS C:\>Get-ADComputer -Filter 'Name -like "newComputer*"' | Set-ADAccountAuthenticationPolicySilo -AuthenticationPolicySilo Silo -AuthenticationPolicy AuthenticationPolicy02