[小ネタ] FSx for Windows File Serverの「FSx Active Directory検証ツール」を実行する時にエラーでハマったら

みなさん、こんにちは！
福岡オフィスの青柳です。

みなさん、Amazon FSx for Windows File Serverのファイルシステムを作成する際に、事前に「Amazon FSx Active Directory検証ツール」を使っていますでしょうか？

Active Directory の設定を検証する - Amazon FSx for Windows File Server

「自己管理型 (セルフマネージド) Active Directory」を使用してFSx for Windows File Serverのファイルシステムを作成する場合、Active Directoryのドメインコントローラー側でいくつかの事前設定と、指定されたネットワーク疎通の確保が必要です。

これらの設定・ネットワーク環境が要件通りに整っているかどうかをチェックするために「Amazon FSx Active Directory検証ツール」は有効です。

今回は、私が「Amazon FSx Active Directory検証ツール」を使用した際に実際に遭遇したエラーと、その解決方法についてご紹介します。

「FSx Active Directory検証ツール」を実行する

前述のAWSドキュメントページの内容に従って、検証ツールを実行するEC2 Windowsインスタンス上で検証ツールをダウンロードして実行準備を済ませたものとします。

AWSドキュメントに記載されているサンプル実行例に従って、コマンドを実行します。

# Credential for Amazon FSx service account
$Password = ConvertTo-SecureString 'SERVICE_ACCOUNT_PASSWORD' -AsPlainText -Force
$Credential = New-Object System.Management.Automation.PSCredential ('SERVICE_ACCOUNT_USER', $Password)

$FSxADValidationArgs = @{
    # DNS root of ActiveDirectory domain
    DomainDNSRoot = 'DOMAINNAME.COM'

    # IP v4 addresses of DNS servers
    DnsIpAddresses = @('IP_ADDRESS_1', 'IP_ADDRESS_2')

    # Subnet IDs for Amazon FSx file server(s)
    SubnetIds = @('SUBNET_1', 'SUBNET_2')

    Credential = $Credential
}

$Result = Test-FSxADConfiguration @FSxADValidationArgs

さて、これで検証結果が出力されるのを待ちましたが、、、残念ながらエラーになってしまいました。

エラーその(1) 「Test 1 - Validate EC2 Subnets」でエラーになる

エラーの内容は以下の通りです。

PS> $Result = Test-FSxADConfiguration @FSxADValidationArgs
Testing service account permissions is not currently enabled. If enabled, script will create test Active Directory computer objects in the organizational unit. This will be cleaned up by the script unless delete permissions are not properly configured on the provided service account in which case manual cleanup may be necessary. Do you want to enable testing? [y/n]: y
Running Active Directory validation with following input parameters:

DomainDNSRoot                 : private.example.com
DnsIpAddresses                : {10.0.0.67}
SubnetIds                     : {subnet-08ea9969a59011094, subnet-0a15771e9389b4285}
OrganizationalUnit            :
AdminGroup                    :
TestServiceAccountPermissions : False

Test 1 - Validate EC2 Subnets ...
Found region ap-northeast-1 from EC2 instance metadata
警告: Failed to get EC2 subnets due to
警告: Please validate instance has 'ec2:DescribeSubnets' permission.
Skipping Validate connectivity with DNS Servers ...
Skipping Validate FSx service user credentials ...
Skipping Validate domain properties ...
Skipping Validate organizational unit ...
Skipping Validate Admin Group ...
Skipping Validate that provided EC2 Subnets belong to a single AD Site ...
Skipping Validate connectivity with DNS Servers ...
Skipping Validate FSx service user credentials ...
Skipping Validate 'Create Computer Objects' permission ...
Skipping Validate 'Validated write to DNS host name' permission ...
Skipping Validate 'Validated write to service principal name' permission ...
Skipping Validate 'Reset Password' permission ...
Skipping Validate 'This Organization' list children permission ...
Skipping Validate 'Read and write Account Restrictions' permission ...
Skipping Validate 'Delete Computer Objects' permission ...
15 of 16 tests skipped.
FAILURE - Tests failed. Please see error details below:

Name         Value
----         -----
GetEc2Subnet {subnet-08ea9969a59011094, subnet-0a15771e9389b4285}

Please address all errors and warnings above prior to re-running validation to confirm fix.
Please refer to the included Troubleshooting Guide (TROUBLESHOOTING.md) for each warning and error.

「Test 1 - Validate EC2 Subnets」で「警告」が発生しています。
テスト結果は「FAILURE」になってしまいました。

原因： EC2インスタンスに「AmazonEC2ReadOnlyAccess」権限が付与されていなかった

エラーメッセージの内容を読めば何となく想像できますが、検証ツールの前提条件で指定されていた以下の点を行っていなかったことが原因でした。

• EC2インスタンスに、IAMポリシー「AmazonEC2ReadOnlyAccess」の権限を付与したインスタンスプロファイルを設定する

検証を行うためにec2:DescribeSubnets権限が必要ということなのですね。

AWSドキュメントをよく読めば、この前提条件についてはちゃんと記載されているのですが、よく読んでいなかったり慌てていたりすると、ついついこのようなミスを犯してしまいます。

エラー(2) 「Test 10 - Validate 'Create Computer Objects' permission」でエラーになる

EC2インスタンスに「AmazonEC2ReadOnlyAccess」権限を付与した後、気を取り直して、再度「検証ツール」を実行しました。

今度は「Test 1」～「Test 9」までは正常に実行されましたが、「Test 10」でエラーになってしまいました。

Test 10 - Validate 'Create Computer Objects' permission ...
警告: Unable to create a computer object using the following AD Domain Controller: ad01.private.example.com (10.0.0.67)
警告: Please verify service account has 'Create Computer Objects' permission on CN=Computers,DC=private,DC=example,DC=com
Skipping Validate 'Validated write to DNS host name' permission ...
Skipping Validate 'Validated write to service principal name' permission ...
Skipping Validate 'Reset Password' permission ...
Skipping Validate 'This Organization' list children permission ...
Skipping Validate 'Read and write Account Restrictions' permission ...
Skipping Validate 'Delete Computer Objects' permission ...
6 of 16 tests skipped.
FAILURE - Tests failed. Please see error details below:

Name                                  Value
----                                  -----
UnauthorizedCreateComputerObjectsOnOU CN=Computers,DC=private,DC=example,DC=com

Please address all errors and warnings above prior to re-running validation to confirm fix.
Please refer to the included Troubleshooting Guide (TROUBLESHOOTING.md) for each warning and error.

FSx for Windows File ServerファイルシステムがActive Directoryドメインに参加するためには、Active Directory上に「コンピューターオブジェクト」を作成する権限が必要です。

「Test 10」では、この権限が正しく設定されているかどうかを検証しているのですが、そこで何か問題が発生したようです。

原因： 検証ツールのオプションパラメーター「OrganizationalUnit」を指定していなかった

FSx for Windows File Serverファイルシステムの作成時、「自己管理型Microsoft Active Directory」の設定で「ファイルシステムを結合する組織単位 (OU)」を指定する個所があります。

この時、私はデフォルトのOUではなくOU=FSx,OU=AWS,DC=private,DC=example,DC=comを指定しました。
そして、AWSドキュメントの手順に従って、上記のOUに対してFSxサービスアカウントへの「制御の委任」の設定を行いました。

一方、今回発生したエラーメッセージを読むと、以下のようになっています。

警告: Please verify service account has 'Create Computer Objects' permission on CN=Computers,DC=private,DC=example,DC=com</code>

Active Directoryのディレクトリー階層においてコンピューターオブジェクトがデフォルトで作成されるコンテナ「Computers」がチェックの対象になっているようです。

検証ツールがチェック対象とするOUを明示的に指定するには、以下の例のようにOrganizationalUnitオプションパラメーターを指定する必要があります。

$FSxADValidationArgs = @{
    # DNS root of ActiveDirectory domain
    DomainDNSRoot = 'DOMAINNAME.COM'

    # IP v4 addresses of DNS servers
    DnsIpAddresses = @('IP_ADDRESS_1', 'IP_ADDRESS_2')

    # Subnet IDs for Amazon FSx file server(s)
    SubnetIds = @('SUBNET_1', 'SUBNET_2')

    # Specify an organizational unit
    OrganizationalUnit = 'OU=FSx,OU=AWS,DC=private,DC=example,DC=com'

    Credential = $Credential
}

この後、再度Test-FSxADConfigurationコマンドレットを実行したところ、今度は正常にテストを完走させることができました。

なお、OrganizationalUnitオプションを正しく指定しているのにもかかわらず「Test 10」以降がエラーとなる場合、FSxサービスアカウントに正しく権限が与えられていない可能性が考えられます。
その場合は、FSxサービスアカウントへの「制御の委任」の設定の手順が正しかったかどうかなど、確認してみてください。

検証ツールに同梱されている「README.md」と「TROUBLESHOOTING.md」を読もう！

今回私がハマったエラーについては、検証ツールのzipファイルを解凍した時に含まれている「README.md」と「TROUBLESHOOTING.md」に解決策が書かれていました。

「README.md」は、検証ツールのコマンドレッドのオプションパラメーターに関して、AWSドキュメントに記載されていないものも含めて詳細な説明が書かれています。

「TROUBLESHOOTING.md」は、文字通り、検証ツールの実行時に問題が発生した時の対処方法について書かれています。

「README.md」を読むと、例えば、今回は紹介しませんでしたが、他にも以下のようなオプションパラメーターが用意されていることが分かります。

• AdminGroup： FSxの管理者グループを指定する
• TestServiceAccountPermissions： サービスアカウントの権限を検証するかどうか (True/False)
• TranscriptDirectory： 検証ツールの実行結果を出力する (フォルダーパスを指定)

※ TestServiceAccountPermissionsオプションについて

サービスアカウントがActive Directory上で必要な権限を正しく付与されているかどうかを検証するために、Active Directory上に実際にコンピューターオブジェクトを作成するテストを実施します。 このテストを実施しない (スキップしたい) 場合にはTestServiceAccountPermissionsオプションでFalseを指定します。

ただし、TestServiceAccountPermissionsの指定に関わらず、検証ツールの実行時に「サービスアカウントの権限を検証するかどうか」を訪ねるメッセージが表示されます。

Testing service account permissions is not currently enabled. If enabled, script will create test Active Directory computer objects in the organizational unit. This will be cleaned up by the script unless delete permissions are not properly configured on the provided service account in which case manual cleanup may be necessary. Do you want to enable testing? [y/n]:

サービスアカウントの権限の検証を実施するか否かは、このメッセージへの応答で決まるようです。
したがって、TestServiceAccountPermissionsオプションの指定はあまり意味が無いかもしれません。

おわりに

「自己管理型 (セルフマネージド) Active Directory」を使用してFSx for Windows File Serverのファイルシステムを作成する場合、もし作成時にトラブルが発生しても、Active Directoryが自分の部門で管理しているのであれば対応するのは難しくないかもしれません。

しかし、他部門や他社がActive Directoryを管理しているような場合には、トラブルシューティングを依頼して実施してもらうのに手続きや調整で時間がかかってしまうことが考えられます。

そのような場合に、ファイルシステムを作成する前に「Amazon FSx Active Directory検証ツール」を実行して問題点を潰しておけば、トラブルが発生する可能性を下げることができます。

皆さんも、自己管理型Active Directoryを使ってFSx for Windows File Serverを構築する際は、是非とも「FSx Active Directory検証ツール」の利用を検討してみてください！

最後になりましたが、「Amazon FSx Active Directory検証ツール」の使い方、検証項目の説明などについては、しばたの執筆したブログ記事で詳細に紹介されています。
こちらも併せて参照してみてください。

と言うか、AWSドキュメントだけでなく、最初にこのブログもちゃんと読んでいれば、エラーでハマらずに済んだんや！！(ちゃんちゃん)