さっしーの試してみるか3: 7月 2024

2024年7月26日金曜日

Active DirectoryのKerberos認証に対する新たな3段適用更新プログラムがリリースされていました

CVE-2021-42287 で追加されたイベントメッセージ ID 35 , 37 と脆弱性対応の流れについて

で、Active DirectoryのKerberos認証に対する3段適用更新プログラムは、収束したと思っていました。ですが、教えていただいた話からKerberos認証に対する新たな3段適用更新プログラムがリリースされていました。それは、

KB5037754: CVE-2024-26248 および CVE-2024-29056 に関連する PAC 検証の変更を管理する方法

です。最大深刻度は重要なのですが、すべてのWindowsに適用が必要とのこと。つまりActive Directoryドメインコントローラー含むWindows ServerとWindowsクライアントが対象になります。
※もちろんサポートライフサイクルから外れているものは、もうどうしようもないと思いますい。拡張セキュリティ更新プログラム(ESU)が残っている場合は、その限りではないとも思います。

KB5037754: CVE-2024-26248 および CVE-2024-29056 に関連する PAC 検証の変更を管理する方法

は、今年の4月9日に最初のセキュリティ更新プログラムがリリースされました。このリリースでは互換モードです。上記リンクより文面引用します。

最初のデプロイフェーズは、2024 年 4 月 9 日にリリースされた更新プログラムから始まります。この更新プログラムは、CVE-2024-26248 および CVE-2024-29056 で説明されている特権の脆弱性の昇格を防ぐ新しい動作を追加しますが、環境内の Windows ドメインコントローラーと Windows クライアントの両方が更新されない限り、適用されません。

新しい動作を有効にし、脆弱性を軽減するには、Windows 環境全体 (ドメインコントローラーとクライアントの両方を含む) が更新されていることを確認する必要があります。監査イベントは、更新されていないデバイスを識別するためにログに記録されます。

2024年10月15日以降にリリースされるセキュリティ更新プログラムでは、強制モードすなわち、既定でセキュリティで保護された動作になるそうです。

最後に、2025年4月8日以降にリリースされるセキュリティ更新プログラムは、互換モードを一切サポートしません。

以上、パッチマネジメントは計画的に進める必要ありです。Active Directoryドメインコントローラーのローリングアップグレード時になって、慌てないようにしたいものです。。。

2024年7月20日土曜日

Azure Update ManagementからAzure Update Managerに移行する際の留意点

Log AnalyticsとAzure AutomationをベースにしたAzure Update Managementのリタイヤが、2024年8月31日と迫っています。下図の赤枠内がそれです。

移行方法については、

Automation Update Management から Azure Update Manager に移行する

に記載があります。

幾つか留意点がありましたので、本稿にまとめておきます。
※インストールのステップバイステップは、失敗例含めて勉強会で説明しようと思います。

前提条件 2: PowerShell スクリプトを実行してユーザー ID とロールの割り当てを作成する（移行用スクリプト）

AutomationAccountResoudeIdは、下記の通りJSONビューからコピーします。
前提条件にある通り、az PowerShellモジュールが必要です。インストールを忘れていると下記のエラーに遭遇します。
az PowerShellモジュールのインストールが結構時間を要します。az PowerShellモジュールが多数あるためです。当方の環境では、完了までに30分ほどかかりました。
移行用スクリプト内のConnect-AzAccountが認証用にWebブラウザを起動できない模様で、デバイス認証するようメッセージが出てエラーになりました。
致し方ないので、スクリプトを改変し下図の通りデバイス認証を加えました。。。

手順 1: マシンとスケジュールの移行移行用ランブックを起動するとパラメーターの設定が必要です。

2024/07/21追記手順は、ランブックのインポートを行う流れです。が移行画面の「今すぐ移行する」をクリックするとランブックが開くため、インポートは不要になっています。
※「手順 2: Automation Update Management ソリューションからのデボード」もインポートしないで進められます。

上記パラメーターの設定での留意点は、下記の通りです。

AutomationAccountResoudeIdは、下記の通りJSONビューからコピーします。
UserManagedServiceIdentityClientIdは、移行用スクリプトで作成されたUser assignedなマネジメントIDのクライアントIDをコピーします。
注）オブジェクトIDをセットしてはいけません。
ResoruceGroupNameForMaintenanceConfigurationsは、空欄のままではダメです。
移行先のリソースグループ名を指定します。こちら必須パラメーターの方が良くないか？！

手順 2: Automation Update Management ソリューションからのデボード

こちらは特に問題なく進みます。が、対象サーバーのMicorosoft Monitoring AgentとLog Analytics ワークスペースの関連付けは、解除されません。またMicorosoft Monitoring Agentは、アンインストールされません。各々の操作が必要です。

対象サーバーのMicorosoft Monitoring AgentとLog Analytics ワークスペースの関連付け解除は、下記のダイアログから実施します。
Micorosoft Monitoring Agentのアンインストールは、プログラムと機能などから行います。

2024年7月13日土曜日

Azure Stack HCI 23H2のプロキシ設定例のタイプミスと思われる箇所

Configure proxy settings for Azure Stack HCI, version 23H2 の

Configure proxy settings for Environment Variables

ですが、プロキシ設定例のタイプミスと思われる箇所あります。下記に引用し該当開所を赤字表記します。

# If a proxy server is needed, execute these commands with the proxy URL and port.

[Environment]::SetEnvironmentVariable("HTTPS_PROXY","http://ProxyServerFQDN:port", "Machine")

$env:HTTPS_PROXY = [System.Environment]::GetEnvironmentVariable("HTTPS_PROXY","Machine")

[Environment]::SetEnvironmentVariable("HTTP_PROXY","http://ProxyServerFQDN:port "Machine")

$env:HTTP_PROXY = [System.Environment]::GetEnvironmentVariable("HTTP_PROXY","Machine")

$no_proxy = "<bypassliststring>"

[Environment]::SetEnvironmentVariable("NO_PROXY",$no_proxy,"Machine")

$env:NO_PROXY = [System.Environment]::GetEnvironmentVariable("NO_PROXY","Machine")

赤字表記している箇所では、"が閉じていないのと、,が足りてないです。不足している文字を補った正しい表記は、下記になるかと（補完した箇所を赤字表記します）。

[Environment]::SetEnvironmentVariable("HTTP_PROXY","http://ProxyServerFQDN:port", "Machine")

すでにプルリクエストしているのでそのうち直ると思います。

2024年7月7日日曜日

Windows Server 2025 preview時点での最小のCPU互換性

注）Windows Server 2025 preview時点での情報に基づくおおよその情報です。正式版リリース時には、変更される可能性があります。

手元にあるノートPCで、Windows Server 2025 previewをインストールできるものとできないものに分かれました。
※インストールできたからといって、デバイスドライバーが足りずフル機能が使えない場合もありました、念の為。

Windows Server 2025 プレビュー前提条件のシステム要件をクリックすると下記ページに辿り着きました。

Windows Server のハードウェア要件

上記に記載のCPU要件とWindows Server 2025 Previewをプロンプトに与える形で、複数のGen AIを使って調べてみました。複数のGen AIで回答が微妙にぶれていますので、少々正確性には欠けると思います。が、Windows Server 2025 previewをインストールできる最小限のCPUはおおよそ下記では無いかと考えています。訂正あればコメントください。

Intel製Core 2 Duo E6000シリーズ以降、Core 2 Quadシリーズ以降（Core 2 Quad Q9500シリーズ以降と回答あったGen AIあり）、Xeon 3000シリーズ
AMD製Phenom X4 9400シリーズ、Phenom II X4 900シリーズ、Athlon II X4 600シリーズ、AMD FXシリーズ、AMD Opteron 4100シリーズ、AMD Aシリーズ

上記以降のCPUは問題なく対応可能でしょう。ということでおおよそ2008年から2009年リリース以降のCPUであれば、お試しでインストールは可能と考えられます。もちろん最新のCPUを使うのが推奨です。

2024年07月08日追記1

Intel製Core 2 Duo E6000シリーズ以降は、第一世代のデスクトップパソコン向けCore 2 Duoで2006年8月5日に販売開始されていました。

2024年07月08日追記2

上記の記事を書くきっかけになったのは、手元にある2台のノートPCにWindows Server 2025 Previewをインストールしようとしたことです。2台のノートPCに搭載されているCPU名について、coreinfoで採取しました。

Surface Pro 2には、Windows Server 2025 Previewがインストールできました。がいくつかのデバイスは認識せず、BluetoothとWireless NICが使えません。CPU名は、下記の通りでした。
Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz
Intel64 Family 6 Model 69 Stepping 1, GenuineIntel
上記より古いノートPCに、インストールメディアからWindows Server 2025 Previewをインストールしようとしてもbootを繰り返しました。つまりセットアップウィザードは全く起動せずでした。BIOSとの相性が関係している可能性もありますね。
CPU名は、下記の通りで2008年1月に販売開始でした。
Intel(R) Core(TM)2 Duo CPU P9400 @ 2.40GHz
Intel64 Family 6 Model 23 Stepping 6, GenuineIntel

2024年07月13日追記3

Linuxディストリビューションでも同じようなことがあるのか、みてみました。

Fedora 40：インストーラー起動
AlmaLinux 8.10, Rocky Linux 8.10：インストーラー起動
なおCentOS 8系はサポート切れに伴うのかダウンロードできず、未確認です。
AlmaLinux 9.4, Rocky Linux 9.4, CentOS Stream 9：kernel panicにてインストーラー起動失敗

インストーラーのkernelバージョンは、どこかに書いてあるのだろうか。

※kvmを調べてみようと思ったので、RHELクローン 8.x系を使ってみることとします。

2024年07月14日追記4
Windows Server 2025 Previewのインストールメディアを再作成し、Intel(R) Core(TM)2 Duo CPU P9400 @ 2.40GHz に対してインストールを再試行しました。結果は、以前と同様です。古いPCなりの最新版BIOSではありますが、BIOSなりCPUがインストール要件を満たしていない可能性があるか、そのまた別の可能性もあるかもしれませんね。Windows Server 2025のGA時に前提条件がどう変わるかを興味深くみていきたいです。