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

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の回復パーティションが一番後ろにあります。

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年7月8日土曜日

Hyper-VホストがサポートするHyper-V仮想マシンの構成バージョンと、Hyper-Vレプリカ

Hyper-VホストがサポートするHyper-V仮想マシン構成バージョンと、Hyper-Vレプリカの関係性を試してみたくなり、ちょっとやってみました。

結論から申し上げますと、「Hyper-VホストがサポートするHyper-V仮想マシンの構成バージョンでなければ、Hyper-Vレプリカは構成できない」です。当たり前ですよね。

今回試したのは、Windows Server 2022でのみサポートされるHyper-V仮想マシン構成バージョンである10のHyper-V仮想マシンをWindows Server 2019にHyper-Vレプリカできるか、です。上記に書いたとおり、「Hyper-Vレプリカは構成できない」が実際の挙動であり、長期サービス ホストでサポートされている VM の構成バージョン の記載とも一致します。

なんでこんな変なことを思いついたかというと、Hyper-Vレプリカを構成すると、レプリカ元のHyper-V仮想マシン構成バージョンで、レプリカ先に仮想マシンを作成するからです。仮想マシンの移行では、レプリカ元が最新バージョンでは無いHyper-Vホスト、レプリカ先が最新バージョンのHyper-Vホストで構成します。このパターンは、レプリカ先が最新バージョンのHyper-VホストでサポートするHyper-V仮想マシン構成バージョンならば、正しく機能しますね。では、この逆はどうなるのかを見てみようということです。結論はわかっちゃいるけど、実際に試してみたい興味が勝りました。

前置きはこれくらいとして、下記の2パターンを記載しておきます。手元の環境は、下記となっています。

  • PET320がWindows Server 2022 Hyper-Vホスト
  • ML110G7がWindows Server 2019 Hyper-Vホスト

Windows Server 2022でのみサポートされるHyper-V仮想マシン構成バージョンである10のHyper-V仮想マシンをWindows Server 2019にHyper-Vレプリカできるか

冒頭の結論通り、このパターンは構成できません。実際の流れを見てましょう。
Windows Server 2022でのみサポートされるHyper-V仮想マシン構成バージョンである10のHyper-V仮想マシンであることを確認しました。
Hyper-Vレプリカの構成要約です。
予想通り、構成できませんね。

Windows Server 2022に配置されているHyper-V仮想マシン構成バージョンである9のHyper-V仮想マシンをWindows Server 2019にHyper-Vレプリカできるか

Windows Server 2019 Hyper-VホストでサポートされるHyper-V仮想マシン構成バージョンである9のHyper-V仮想マシンは、Hyper-Vレプリカを構成できる仮定を見てみました。結論は、実際に構成できました。
Windows Server 2019でもサポートされるHyper-V仮想マシン構成バージョンである9のHyper-V仮想マシンであることを確認しました。
Hyper-Vレプリカの構成要約です。
Hyper-Vレプリカが構成でき、初期レプリカが実行されています。

2022年11月19日土曜日

Windows Admin Center in AzureのAAD認証を試してみます。

Azure AD authentication for Windows Admin Center in Azure is now generally available

AAD認証で、WAC in Azureを開けるようになったということです。

“Windows Admin Center Administrator Login”の役割が割り当てられているのが大前提です。


もう一つ前提があるのですが、後述します。

“Windows Admin Center Administrator Login”の役割が割り当てられているAzure IaaSに対して、つないでみました。

繋がりません。

なぜつながらないのか、Azure Vnetへのルーティングがないからです。
※パブリックIPアドレスで6516ポートが開いている場合(非推奨なポートの開け方ですよ)は、問題無いです。

今回のケースでは、パブリックIPアドレスの6516ポートを開けていないため、Azure Vnet側からWAC in Azureにつなぐ必要がありました。

ということで、Azure Vnetへのルーティングをもっている/Azure VPNのオンプレミス側からつないでみます。

はい、問題無くWAC in Azureにつながりましたね。