ラベル Windows Server 2019 の投稿を表示しています。 すべての投稿を表示
ラベル Windows Server 2019 の投稿を表示しています。 すべての投稿を表示

2025年9月2日火曜日

Windows Kerberosに対する脆弱性CVE-2025-26647の続報

複数フェーズからなるADの脆弱性対策「CVE-2025-26647 (Kerberos 認証) の保護」 

という記事を書いていました。

先日続報がリリースされましたので、ご紹介します。

CVE-2025-26647 への対応とその影響について

が日本マイクロソフトのWindowsサポートチームよりリリースされています。この記事によると強制モードの開始日(更新プログラムのリリース日)が2025年10月14日で確定しています。

複数フェーズからなるADの脆弱性対策「CVE-2025-26647 (Kerberos 認証) の保護」 

に記載した通り、強制モードは下記のような状況になります。

このモードになると、ADドメインコントローラーが安全でない証明書を使用してKerberos認証要求を受け取った場合、イベント D 21 がログに記録され、要求が拒否されます。
またAllowNtAuthPolicyBypassレジストリキーに対するMicrosoft のサポートは中止されます。よって監査モードに戻すことはできません。

ということで、証明書認証をお使いの場合は、残り1か月で対応が必要になります。

CVE-2025-26647 (Kerberos 認証) の保護 はサポート情報でした。今回は日本マイクロソフトのWindowsサポートチームによる記事のため、すでにリリース済みの更新プログラムに対する不具合情報が記載されています。各々の不具合情報は、CVE-2025-26647 への対応とその影響について に詳細がございますのでご確認ください。下記では、その不具合情報が、すでに改善済みか否かを抜粋して記載いたします。

  • 2025 年 4 月 8 日の更新プログラムに含まれている不具合は、2025 年 6 月 10 日の更新プログラムで改善済みとのこと。
  • 2025 年 7 月 8 日の更新プログラムに含まれている不具合は、上記とは別とのことです。そのため、今後改善する見込みとのこと。
    ただし、6 月の更新プログラムを適用済みの状態で ID:45 が記録されていない状況であれば、ID:21 イベントによる実影響がないとも記載ありました。


2025年6月30日月曜日

複数フェーズからなるADの脆弱性対策「CVE-2025-26647 (Kerberos 認証) の保護」

CVE-2025-26647 (Kerberos 認証) の保護

上記は、2025年4月8日に公開されました。

本文に記載ありますが、本脆弱性は、3フェーズでADの脆弱性の対策が図られます。上記の内容をサマリして以下に記載します。

  • 脆弱性の概要:NTAuth ストアに存在しない認証局(CA)から発行された証明書を使って Kerberos 認証が行われると、セキュリティ上のリスクが生じる可能性があります。
  • 影響対象:altSecID 属性を使った証明書マッピングを行っているセキュリティプリンシパル。またADドメインコントローラーがこちらの影響を受けます。
  • 対策の段階的導入:

    1. 2025 年 4 月 8 日: 初期展開フェーズ – 監査モード
      初期展開フェーズ(監査モード)として、NTAuth チェックと監査ログ警告イベント(イベントID 45)が有効になります。このイベントID 45は、安全でない証明書を使用して Kerberos 認証要求を受信すると記録されます。
      この記録されたイベントを監視して、NTAuthストアに含まれていない影響を受ける証明機関を特定していくことも必要です。
    2. 2025 年 7 月: 既定で適用されるフェーズ
      このフェーズ(モード)では、NTAuthストアのチェックが既定の動作となります。が、AllowNtAuthPolicyBypassレジストリキー設定を使用することで監査モードに戻すことも可能エス。
      ただしこのモードでは、セキュリティ更新プログラムを完全に無効にする機能は削除されます
    3. 2025 年 10 月: 強制モード
      このモードになると、ADドメインコントローラーが安全でない証明書を使用してKerberos認証要求を受け取った場合、イベント D 21 がログに記録され、要求が拒否されます。
      またAllowNtAuthPolicyBypassレジストリキーに対するMicrosoft のサポートは中止されます。よって監査モードに戻すことはできません。

2024年5月3日金曜日

2024年4月のセキュリティ更新プログラムで、既知の問題が2つ出ています。

おもにWindows Server 2022に影響ありますが、

2024 年 4 月 9 日 — KB5036909 (OS ビルド 20348.2402)

で、下記の通り既知の問題が2つ出ています。文面を引用します。

  1. 2024 年 4 月のセキュリティ更新プログラムをインストールした後の NTLM トラフィックの問題
    ドメイン コントローラー (DC) に 2024 年 4 月のセキュリティ更新プログラム (KB5036909) をインストールすると、 NTLM 認証トラフィックが大幅に増加する可能性があります。 この問題は、環境内のプライマリ ドメイン コントローラーの割合が非常に少なく、NTLM トラフィックが多い組織に影響を与える可能性があります。
    次の手順: 解決に取り組んでおり、今後のリリースで更新プログラムを提供します
    影響を受けるプラットフォーム:
    1. クライアント: なし
    2. サーバー: Windows Server 2022、Windows Server 2019、Windows Server 2016、Windows Server 2012 R2、Windows Server 2012、Windows Server 2008 R2、Windows Server 2008
  2. 2024 年 4 月のセキュリティ更新プログラムをインストールした後、VPN 接続が失敗する可能性があります
    Windows デバイスは、2024 年 4 月のセキュリティ更新プログラム (KB5036909) または 2024 年 4 月のセキュリティ以外のプレビュー更新プログラム をインストールした後、VPN 接続エラーに直面する可能性があります。
    次の手順: 解決に取り組んでおり、今後のリリースで更新プログラムを提供します
    影響を受けるプラットフォーム:
    1. クライアント: Windows 11バージョン 23H2;Windows 11、バージョン 22H2、Windows 11、バージョン 21H2、Windows 10、バージョン 22H2、Windows 10、バージョン 21H2。
    2. サーバー: Windows Server 2022、Windows Server 2019、Windows Server 2016、Windows Server 2012 R2、Windows Server 2012、Windows Server 2008 R2、Windows Server 2008。
いずれにしても、今後の定例なのか、定例外で対応が図られそうですね。

2024年1月20日土曜日

いくつかのOSで回復パーティションサイズを確認した。

Windows 10向けの更新プログラム「KB5034441」が、Windows Update適用時に「0x80070643」エラーとなりました 解消しました!

にて回復パーティションのサイズが重要だとわかりました。また、ITライターの山内氏より下記記事がある旨、ご連絡いただきました。

Windows 10/11で「2024年1月の更新プログラム」のインストールが失敗(エラー0x80070643)! その原因は?

ご連絡いただいた際、下記の情報を連携いただいたこと、申し添えます。上記記事含め、改めて御礼申し上げます。

  • UEFIパーティション要件を鑑みると、最終的に空き52MB+5~15MBのあきがあれば成功するはずだろう。
  • Windows 22H2以前なら+50MBくらいで成功すると思います。Windowsセットアップの既定だと確か83MBくらいの空きで回復パーティションを作る故。

いろいろ情報を教えていただきました。GUIかdiskpartのいずれかで、Windows Server系の回復パーティションの配置やサイズをメモしておきます。

Windows Serve 2016

450MBで先頭に配置されているサーバーがありました。

Windows Serve 2019

全3台で確認したところ、499MBで先頭に配置されているサーバーがありました。
※全3台ともOSインストール時に、手動でパーティション作成していません。おそらくこれはパターンの一つでしょうかね。

Windows Serve 2022

597MBの回復パーティションが一番後ろにあります。

Azure Stack HCI OS 22H2

515MBの回復パーティションが一番後ろにあります。

2024年1月12日金曜日

Azure Arcのオンボードとプロキシサーバー

プロキシーサーバーの配下だとAzure Arc Setupは、インストールに失敗します。

本稿執筆時点のAzure Arc Setupは、構成ボタンが使用不可なんですね。

いずれここに、プロキシーサーバーの設定ができるのではないか、と踏んでいるのですけど。

なぜこんなことに気づいたのかといえば、Azure Arcのオンボードスクリプト生成時にプロキシサーバーを指定するようになっていたからです。さらに書くとプロキシサーバーをPowerShellの$env:HTTPS_PROXY環境変数に設定しておいても、Azure Arcのオンボードスクリプトでは参照しないからでした。
※この挙動に気づくまで数時間ほど無駄にしました。。。

Azure Arcのオンボードスクリプト生成時にプロキシサーバーを指定する画面は、下記の通り。ちなみにプライベートエンドポイントもここで指定できますね。

Azure Arcのオンボードスクリプト内にプロキシーサーバーの情報が記載されていますので、赤枠で囲ってみました。プロキシサーバーの設定がオンボードスクリプト内にコーディングされています。

ということで、Azure Arcのオンボード時は、引き続き注意しながら進めます。

2023年12月24日日曜日

WorkgroupサーバーとHyper-Vクラスター間でHyper-Vレプリカを構成する

必要があり、上記の構成で検証を行いました。

参考としたのは、下記記事です。

WindowsServer2019 Hyper-V ReplicaをWorkGroupで構築した記録-2

上記記事と異なるのは、レプリカ先がHyper-Vクラスターであることです。

試行錯誤した結果、レプリカ先用に作成する証明書は、下記のコマンドラインが必要でした。

New-SelfSignedCertificate -Subject s2dws2019hvr.sshzk2016.local -DnsName "s2dws2019hvr.sshzk2016.local","g2ws2019s2d01.sshzk2016.local","g2ws2019s2d02.sshzk2016.local" -CertStoreLocation "Cert:\localMachine\My" -HashAlgorithm SHA256 -KeyAlgorithm RSA -KeyLength 2048 -KeyExportPolicy Exportable -NotAfter 2028/12/31 -Signer $rootCert

Hyper-Vレプリカブローカー:s2dws2019hvr.sshzk2016.local
各クラスターノード:g2ws2019s2d01.sshzk2016.local,g2ws2019s2d02.sshzk2016.local

-DnsNameオプションへ、Hyper-Vレプリカブローカーと各クラスターノードを指定したのは、
に下記の記載があったからです。
---

Replica Server Certificate Requirements

To enable a server to receive replication traffic, the certificate in the replica server must meet the following conditions

  • Enhanced Key Usage  must support both Client and Server authentication
  • Set the Subject field or the Subject Alternative Name using one of the following methods:
    • For a SAN certificate, set the Subject Alternative Name’s DNS Name to the replica server name (e.g.: replica1.contoso.com ). If the replica server is part of cluster, the Subject Alternative Name of the certificate must contain the replica server name and  FQDN of the HVR Broker (install this certificate on all the nodes of the cluster.)

(or)

  • Set the Subject field to the replica server name (e.g.: replica1.contoso.com ). If the replica server is part of cluster, ensure that a certificate with the subject field set to the FQDN of the HVR Broker is installed on  all the nodes of the cluster.

(or)

---
作成した証明書は、.pfxと.cerとしてエクスポートしました。

.pfxファイルは、各クラスターノードにインポートし、Hyper-Vレプリカブローカーに証明書として登録しました。
特に問題なく、設定できました。
.cerは、レプリカ元にインポートしました。

各仮想マシンのレプリカは、レプリカ先への認証ダイアログが表示されること、改めてレプリカ元の証明書再指定が表示されることがあるものの、問題なくできました。

レプリカ先からみたレプリカの状態も正常です。

2024年1月24日追記
$rootCert = ls Cert:\LocalMachine\My\証明書の拇印
で自己署名ルート証明書を変数に代入できますね。
※lsは、Get-ChildItemのエイリアスですね。

2023年10月21日土曜日

azcmagent connectでテナントIDを非明示とした場合、全く違うテナントに接続し、connectが失敗する事もあり

頻繁に発生する現象ではないと思いますが、テナントIDを非明示とした場合、全く違うテナントに接続した挙動を見つけましたので、書いておきます。
※別で持っているOffice 365のテナントIDかと思ったが違いました。

こんなメッセージが出て、Azure Arc 対応サーバーの登録が失敗するようになりました。

メッセージは、「終了コード:  AZCM0042: Failed to Create Resource」なのですが、最高の権限を使っていることから、権限周りは考えにくく。

ログファイルは、"C:\ProgramData\AzureConnectedMachineAgent\Log\azcmagent.log"ですので、確認してみました。401のあたりからさかのぼっていくと、こんなメッセージがありました。

time="2023-10-21T09:56:56+09:00" level=debug msg="Azure response" Body="{\"error\":{\"code\":\"InvalidAuthenticationTokenTenant\",\"message\":\"The access token is from the wrong issuer 'https://sts.windows.net/f8cdef31-マスキングしてます/'. It must match the tenant 'https://sts.windows.net/2156436d-マスキングしてます/' associated with this subscription. Please use the authority (URL) 'https://login.windows.net/2156436d-マスキングしてます' to get the token. Note, if the subscription is transferred to another tenant there is no impact to the services, but information about new tenant could take time to propagate (up to an hour). If you just transferred your subscription and see this error message, please try back later.\"}}" Error Code=InvalidAuthenticationTokenTenant Operation=GET Status Code=401

上記赤字部分で別テナントへなぜか接続してますね。別のテナントだと権限がないわけで、エラーコートとしてはそうなります。

解決方法は、--tenant-idオプションにてテナントIDを明示的に指定します。

登録失敗が解消しました!

2023年10月7日土曜日

Azure MonitorとAzure Arcエージェントをアンインストールする その2

Azure MonitorとAzure Arcエージェントをアンインストールする の続きで、下記について確認します。
※あいにくAzure Portalから拡張の削除を指示したため、削除完了の画面ショットは無し。。。

  • Azure CLIによる削除
  • Azure PowerShellによる削除

Azure CLIによる削除

az connectedmachine extension list で現況を確認します。

az connectedmachine extension delete を使います。


Azure PowerShellによる削除

Get-AzConnectedMachineExtension で現況を確認します。

Remove-AzConnectedMachineExtension を使います。


Azure MonitorとAzure Arcエージェントをアンインストールする

検証時のリソース都合により、常時起動する仮想マシンを減らす準備として、Azure MonitorとAzure Arcエージェントをアンインストールします。

やり方は、エージェントのアンインストールに沿って進めます。
またAzure Monitorエージェントのアンインストール拡張機能を削除するでも、拡張機能のアンインストールが言及されています。
※拡張機能の管理は、Azure CLIPowerShell、または Azure Resource Manager テンプレートでもできます。自動化の観点ではこれらのほうが良いですね。

まずは、Azure Arc対応サーバーの拡張機能を削除します。先にAzure Monitorエージェントを削除し、それ以外はまとめて削除しています。
※結構時間かかります。あと、Azure Arcエージェントとの接続がオフラインになっていると失敗するようです。

拡張機能のアンインストールが完了したら、Azure Arc対応サーバー側にリモートデスクトップ接続を行います。

強制削除の意味合いで、azcmagent disconnect --force-local-only を管理者権限にて起動したコマンドプロンプトで実行します。
※Azureリリースごと削除ならば、--force-local-onlyは、不要です。今回は強制削除を確認するのが目的でした。

Azure Arcエージェントをアンインストールします。
※Windows Server 2019は、この画面からやるとアンインストールに失敗しますが。

気を取り直して「プログラムと機能」から削除します。

Azure PotralのAzure Arc対応サーバーに戻ります。該当リソースの概要画面に移動します。接続していない旨のメッセージが出ていることを確認後、リソースを削除します。

削除完了。

Azure MonitorとAzure Arcエージェントをアンインストールする その2 へ続く。

2023年10月2日月曜日

Azure Connected Machine Agentの手動アップグレード

Azure Connected Machine Agentは、Windows Updateからアップグレード可能です。

本題。
Azure PortalからAzure Arc対応サーバーを開きます。
サーバー名をクリック→「問題の診断と解決」→「構成とセットアップ」→「サーバーをAzure Arcに接続できない」を選択すると、最新版ではないサーバーの一覧を確認できます。
またこのページから、Azure Connected Machine Agent最新版を入手できます。

対象のサーバーを確認します。以前のAzure Connected Machine Agentです。
Azure Connected Machine Agent最新版をインストールします。
インストール後に、azcmagent showを実行します。最新版になっていますね。


補足)Azure Connected Machine agentのサポートOSについては、こちらをご確認ください。

2023年9月18日月曜日

Windows UpdateにてWindows Admin Center 2306へアップグレードできます。

Windows Admin Center version 2306 is now generally available!

が2023年6月20日(現地時間)リリースされてから約3カ月。ようやくWindows UpdateにてWindows Admin Center 2306へアップグレードできます。

※たまたま確認できたのが英語版OSということです。日本語版でも同様に確認できるのではないでしょうか。


2023年9月10日日曜日

Azure Arc対応サーバーをAzure Monitorに関連付ける その3

Azure Arc対応サーバーをAzure Monitorに関連付ける その1 と

Azure Arc対応サーバーをAzure Monitorに関連付ける その2 の続き。

ポリシー割り当てを削除後、再作成します。


割り当てを再作成します。
改めて、割り当ての修復を確認します。
まだ出ない。。。

別のポリシーを比較対象としてみます。こちらのポリシーは、アクセス許可でロールが出ています。

修復タスクも表示できます。
リージョンが異なるぐらいか。

ポリシー割り当てを再削除後、再々作成します。

「システム割り当ての場所」は、既定値であるEast USのままとします。
システム割り当てマネージドIDのリージョンを変えてみましたが、効果無し。。。
ということで、「Windows Arc 対応マシンには Azure Monitor エージェントがインストールされている必要がある」は、監査しかできないのかも。

改めてポリシーを当たっていると「Azure Monitor エージェントを実行するように Windows Arc 対応マシンを構成する」というのがありました。
こちらを割り当ててみます。

「DeployIfNotExist」がいます。これは大丈夫そうか。
※調べている中で、ポリシー定義を設定する を見ていました。これが、割り当てるべきポリシーなのか否かの判断ポイントだったようです。
マネージドIDに対するアクセス許可で、ロールの定義が表示されました。ということで、割り当てるポリシーはこちらのようですね。(とりあえずシステム割り当てIDの場所は、East USとします)
確認できたので「作成」をクリックします。
結果、もろもろ作成できました。
ポリシーのコンプライアンスで、「Azure Monitor エージェントを実行するように Windows Arc 対応マシンを構成する」が表示されています。
実際に、Azure Arc対応サーバー(というか、画面を見る感じだと、Azure Arc対応マシン と言ったほうが良いのか)で、Azure MonitorエージェントがInstalledになるかは、次回確認します。