非ドメイン環境からAmazon FSx for Windows File Serverのリモート管理をやってみる

しばたです。

Amazon FSx for Windows File Server(以後 FSx for Windows)では一部の設定をPowerShell Remotingを使って行う必要があります。

• Getting Started with the Amazon FSx CLI for Remote Management on PowerShell

この設定作業はFSx for Windowsが参加しているドメイン環境で行うのが基本ですが一時的な作業などで非ドメイン環境から行いたい場合もあるかと思います。
(というか、私がそうしたいと思ったのです。思ってしまったのです...)

本記事では非ドメイン環境からPowerShell Remotingを使ってFSx for Windowsを管理する手順について記載していきます。

はじめに

本記事で試す内容はPowerShell Remotingの仕組みを考えると問題ないはずですが、AWSとしてサポートされている行為かは確認を取っておらず保証されていません。

環境によっては動作しないかもしれませんし、今動作する環境でも将来的に動作しなくなる可能性もありますのでご注意ください。
あくまでもFSx for Windowsのリモート管理はドメイン環境から行うのが基本です。

この点をご理解のうえ以降の内容をお読みください。

FSx for Windows リモート管理の要件

FSx for Windowsのリモート管理に求められる要件はドキュメントに、

• Be able to connect to a Windows compute instance that has network connectivity with your file system.
• Be logged into the Windows compute instance as a member of the file system administrators group. In AWS Managed Microsoft AD, that group is AWS Delegated FSx Administrators. In your self-managed Microsoft AD, that group is Domain Admins or the custom group that you specified for administration when you created your file system. For more information, see Connecting to Your Windows Instance in the Amazon EC2 User Guide for Windows Instances.
• Make sure that your file system's security group inbound rules allows traffic on port 5985.

と記述されています。

かいつまんで説明すると、

• WinRM (TCP 5985)でPowerShellエンドポイントに到達可能である必要がある
• ファイルシステム作成時の管理者グループかDomain Admins、AWS Delegated FSx Administratorsなどのドメイン管理者グループで接続する必要がある

であり、また、これに加えて本記事の検証の結果

• FSx for Windows管理用のコマンドを実行するにはKerberos認証で認証済みである必要がある

ことが分かっています。
非ドメイン環境からこの要件をどうクリアするかがキモとなります。

やってみた

検証環境について

今回は下図に示す非常に簡単な環境を用意しました。

1つのパブリックサブネット上にドメインコントローラーとなるEC2、検証用EC2、検証用FSx for Windows(Single AZ)を用意しました。
これは以前書いたこの記事の環境を流用しています。

環境構築手順は割愛しますが、

• 検証用サーバー (Windows Server 2019)
  • IPアドレス : 10.0.1.217
• ドメインコントローラー 兼 DNSサーバー (Windows Server 2019)
  • ドメイン名 : aws.shibata.tech
  • IPアドレス : 10.0.1.115
• FSx for Windows
  • 管理者ユーザー : fsxadmin@aws.shibata.tech
  • DNS名 : amznfsxobxw336f.aws.shibata.tech (10.0.1.110)
  • PowerShellエンドポイント : amznfsxm8qqrdf9.aws.shibata.tech (10.0.1.225)
  • SMB/WinRMのポートは解放済み

の環境となっています。

(FSx for Windowsの設定はざっくりこんな感じ)

検証用EC2 : 初期状態

初期状態では検証用EC2はドメインに参加してませんし、DNSもAmazon Route 53 Resolver(旧称 Amazon Provided DNS)に向いているため、PowerShellエンドポイントamznfsxm8qqrdf9.aws.shibata.techを名前解決できません。

以下の様に通信先をIPアドレスにしてリモート管理コマンドを実行しても当然エラーとなります。

# PowerShellエンドポイントに対し Get-FSxSmbShare を実行してみるサンプル
$params = @{
    ComputerName = '10.0.1.225'
    ScriptBlock = {
        # ここに実行したい管理コマンドを記述
        Get-FSxSmbShare
    }
    ConfigurationName = 'FSxRemoteAdmin'
    SessionOption = (New-PSSessionOption -UICulture 'en-US')
}
Invoke-Command @params

検証用EC2 : 設定変更

このため、PowerShellエンドポイントに対する名前解決とKerberos認証の通信のために、DNSサーバーの設定をドメインコントローラーに向けてやります。
やり方はなんでも良いですが今回はPowerShellから以下の様にしています。

# DNSサーバーの設定を変更
$client = Get-NetAdapter | Get-DnsClient
$client | Set-DnsClientServerAddress -ServerAddresses ('10.0.1.115')
# 変更後内容の確認
$client | Get-DnsClientServerAddress -AddressFamily IPv4

結果この様にDNSサーバーのアドレスが10.0.1.115になっています。

この状態であればPowerShellエンドポイントamznfsxm8qqrdf9.aws.shibata.techはちゃんと名前解決できます。

検証用EC2 : 動作確認

これでドメインに参加してなくてもFSx for Windowsのリモート管理を行えます。

PowerShellエンドポイントに対する名前解決が可能になっていますのでコマンドの通信先はホスト名で指定してやります。
そして、非ドメイン環境からの接続になるため認証情報と認証方式を明示する必要もあります。

最初に実行したコマンドであれば以下の様に直してやればOKです。

# 非ドメイン環境からの接続なので認証情報を明示してやる
$cred = Get-Credential 'fsxadmin@aws.shibata.tech'

$params = @{
    # エンドポイント名はちゃんとホスト名で指定
    ComputerName = 'amznfsxm8qqrdf9.aws.shibata.tech'
    # 認証情報を指定
    Credential = $cred
    # 認証方式をKerberos認証に明示
    Authentication = 'Kerberos'
    ScriptBlock = {
        # ここに実行したい管理コマンドを記述
        Get-FSxSmbShare
    }
    ConfigurationName = 'FSxRemoteAdmin'
    SessionOption = (New-PSSessionOption -UICulture 'en-US')
}
Invoke-Command @params

リモートセッションの接続も可能です。

# Invoke-Command だけでなく Enter-PSSession も可能
$cred = Get-Credential 'fsxadmin@aws.shibata.tech'
$params = @{
    # エンドポイント名はちゃんとホスト名で指定
    ComputerName = 'amznfsxm8qqrdf9.aws.shibata.tech'
    # 認証情報を指定
    Credential = $cred
    # 認証方式をKerberos認証に明示
    Authentication = 'Kerberos'
    ConfigurationName = 'FSxRemoteAdmin'
    SessionOption = (New-PSSessionOption -UICulture 'en-US')
}
Enter-PSSession @params

あとはよしなにFSx for Windowsを管理してください。

補足 : SessionOptionパラメーターについて

本記事で紹介しているコマンドに

SessionOption = (New-PSSessionOption -UICulture 'en-US')

を付けていますが、これはトラブルシューティングにある通り、FSx for WindowsのPowerShellエンドポイントに英語以外のロケールで接続するとエラーになるのを回避するために必要となります。
ConfigurationNameの設定同様おまじないだと思って設定しておけばよいかと思います。

最後に

以上となります。

改めて必要な設定についてまとめると、

• FSx for Windowsのリモート管理にはKerberos認証を用いたPowerShell Remotingが要求される
  • このためDNSサーバーの設定変更が必須
• 非ドメイン環境からの実行のため、PowerShellコマンドで認証情報(-Credential)と認証方式(-Authentication)を明示する

となります。

この点を押さえておけば非ドメイン環境からでも問題なくPowerShell Remotingによる管理ができるハズです。
とはいえ、最初に述べた通りこの手順は無保証ですので、正常に動作しない場合は無理をせずドメイン環境に切り替えてください。