そうか、そうか

～とあるSIerの、哀と涙の軌跡～

トップ > AWS > Simple 1500シリーズ The 虎舞竜 ～愛と憎しみのFSxデプロイ失敗編～

Simple 1500シリーズ The 虎舞竜 ～愛と憎しみのFSxデプロイ失敗編～

AWS

皆様、ごきげんよう。私です。

 

先日、会社の同僚の勧めで、「Switch bot」の「Hub mini」という製品を買ってみました。

以前からAmazon Alexaやコンセント制御などをしていたので、これ以上制御するものは特にないかなーと考えていました。

 

ただ、その同僚がエアコンやお掃除ロボットを制御しているのを見て、楽しそうだったので、特に目的もないまま購入してみました。

 

私は照明制御とエアコン制御をしてみましたが、特定条件を満たしたら、自動でリモコン制御を行ってくれるというのは面白いですね。

 

私の場合、

月～金は、朝7:30に暖房を自動で入れ、

月～金は、朝8:20(起床時間)に照明を自動でつける

という条件制御を行いました。

 

これにより、寒い冬の朝もしゃっきり起きられ、生活の質が向上！

仕事もばっちり上手くいき(脳内では)、

給料も上がり(脳内では)、

彼女もできました(以下略)！

 

さぁ！君も！「Hub Mini」で新生活のスタートダッシュを切ろう！

 

 

なんか、進〇ゼミの漫画みたいな煽り文句になったな・・・

 

 

さて、今回はAWSです。

自己管理型ADを使用してFSxをデプロイすると、デプロイに失敗しちゃった件について記載します。

 

 

ここでいきなりですが、結論。

この問題の原因は、

FSx自身でもあり、

自己管理型ADのOSに適用されているパッチの問題でもあります。

 

要は、FSx自身が自己管理型ADのWindows Server OSに適用されているパッチに対応できていない、ということが問題です。

 

ちょ、待てよ！どういう意味？

これでは何のこっちゃだと思うので、順を追って説明しましょう。

 

事象だよーん

自己管理型ADを使用したFSxのデプロイに失敗する。

 

・FSxデプロイに使用するパラメータには何の問題もない(※1)

・AD検証ツール上もAll Successとなる。

アクティブディレクトリの設定の検証 - Amazon FSx for Windows File Server

※1：入力ミスとか、使用不可能文字とか使ってない

 

f:id:gokusan:20220221181747p:plain

 

環境としては、

EC2で構築したWindows Server 2019 の役割に、Active Directoryをぶち込み、

作ったADをFSxで使用する、というAWSとしては想定されたFSx構築方法です。

 

f:id:gokusan:20220220174540p:plain

 

犯人は、お前やぁ

自己管理型Windows Serverには、2021年11月10日にとある累積パッチが適用されています。

ずばり、FSxがデプロイに失敗するのは、このパッチが原因でした。

 

実は、2021年11月10日のパッチは、結構重要なものでして、MS製品の脆弱性に対して修正が行われています。

 

特に、ADに対しては、以下のように記載されています。

2021年11月のセキュリティ更新プログラムには、脆弱性を解決するために、Active Directory における複数のセキュリティ強化が含まれています。このうち、CVE-2021-42287 から保護するためのセキュリティ強化 (KB5008380) および、CVE-2021-42291 から保護するためのセキュリティ強化 (KB5008383) は、今後リリース予定のセキュリティ更新プログラムでセキュリティの強化を強制する予定です。Active Directoryを利用しているお客様は、詳細は下記のサポート技術情報を参照して、必要とされている対応を実施してください。

 

このうち、KB5008380 で対応したPacRequestorEnforcement というレジストリ―キーが問題です。

このレジストリ値、AWSから展開したWindows Serverであれば初期状態として 「2」が設定されています。

0 = 無効

1 = 展開

2 = 強制モード

 

といった感じです。

つまり、強化された認証プロセスが「強制」されている状態です。

 

どうもこのADのセキュリティ強化、かなり大がかりなもののようで、実に3段階のフェーズを経ます。

 

第一フェーズ：2021 年 11 月 10 日

　※レジストリキーの生成

第二フェーズ：2022 年 4 月 13 日

　※レジストリキーを無効にしていた場合は、展開モードに遷移

第三フェーズ：2022 年 7 月 13 日 

　※強化された認証プロセスを強制

 

強制フェーズ状態の2が設定されていると、FSxの展開を妨げてしまうようで、

結果的には、この値を「0」に変更(つまり無効化)すると、FSxの展開が成功しました。

※「0」でなくても「1」でも回避できるようです。

 

なお、AWSに問い合わせたところ、

展開後にこの値を再び2に戻しても特に問題はないとのことでした。

もしくは、2022年3月中旬ごろまでにFSx自身がバージョンアップされ、このアップデートに対応してくれるそうなので、そこからレジストリキーを2に変更してもよい、とのことでした。

なお、レジストリキーの変更に、OS再起動は求められません。

f:id:gokusan:20220220231618p:plain

 

ただ、このレジストリキー、1個だけ注意が必要です。

 

それは、

Q2 さまざまな PacRequestorEnforcement 値を持つ Active Directory ドメイン コントローラーが混在する場合はどうなりますか。

 

A2. PacRequestorEnforcement 値が 0 と 1 のドメイン コントローラーが混在する場合、互いに互換性があります。 PacRequestorEnforcement 値が 1 と 2 のドメイン コントローラーが混在する場合、互いに互換性があります。 PacRequestorEnforcement 値が 0 と 2 のドメイン コントローラーが混在する場合、互いに互換性がなく、断続的なエラーが発生する可能性があります。 詳細については、「レジストリ キー情報」セクションを参照してください。

この赤字の一文です。

すでにこのレジストリキーが2の状態で運用していると、0と2が混在する環境はよろしくないようです。

 

すでに運用している自己管理型ADを用いたFSx展開をお考えの方は、3月中旬以降に展開したほうがよさそうですね。

 

最後に

今回は、自己管理型ADを用いたFSxで引っかかった虎舞竜をお伝えしました。

この事例、調べたんですが全然情報でてこないんだよね…

 

ではでは～