VMware Toolsの脆弱性の評価は、CVSSv3基本スコアで、CVE-2023-34057は「7.8」（Important）。ゲスト仮想マシンへのローカルユーザーアクセスを持つ悪意のある攻撃者が、仮想マシン内の権限を昇格できる可能性があるとのこと。
「VMware」のゲストOS向けアプリ「VMware Tools」に重大な脆弱性 ～対策版への更新を – 窓の杜 (impress.co.jp)
https://forest.watch.impress.co.jp/docs/news/1543401.html
脆弱性が修正されたバージョンへのVMware Toolsの更新が必要。
対象となるVMware Toolsのバージョン 12.xx、11.xx、10.3.x
脆弱性対応されたバージョン 12.3.5
https://www.vmware.com/security/advisories/VMSA-2023-0024.html
ダウンロードのURLは下記。ダウンロードには、VMwareのCUSTOMER CONNECTのアカウントが必要。
Veeam Backup ＆ Replicaiton のユーザは、Veeam上にユーザを作るわけではなく、Veeamの管理サーバがインストールされたWindowsのローカルアカウントもしくは、ドメインアカウントを使用する。
アカウント追加の手順としては、
1. Windowsに新しくユーザを登録する。
2. 追加したWindowsアカウントのパスワードを登録する。
3. Veeam backup でメインメニューから「Users and Roles」を選択する
4. 「Add」をクリックする
5. 「User or group」フィールドで、ユーザー名またはユーザーグループの名前を「ドメイン\ユーザー名」の形式で入力する。
6. 「Role」リストから、割り当てるロールを選択する。
7. 「OK」をクリックする。
8. Veeam Backupへのログインを試す。
参考：
https://helpcenter.veeam.com/jp/archive/backup/110/hyperv/users_roles.html
NPSサーバ再起動後に、Meraki APからNPSへのRADIUS認証でエラーが発生するようになった。そのときの対応のメモ。
802.1X Failed authentication (EAP failure)一応、Meraki APの再起動をやってみたが効果なし。Merakiの管理画面から、RADIUS認証を試してみるとエラーになった。RADIUS認証が影響していることが分かったので、RADIUS認証サーバであるWindowsのNPSサーバ側を調べた。
NPS（ネットワークポリシーサーバー）側のログは、イベントビューアーの「Windowsログ」の「セキュリティ」に下記のログがあった。
サーバーで拡張認証プロトコル（EAP）の種類を処理できないため、クライアントを認証できませんでしたRADUISであるNPSサーバまでの通信は行われており、RADUIS認証の中で、ユーザの認証ができていないため、接続が拒否されていることがわかった。NPSサーバに対象を絞って、調査した。
NPSサーバの管理画面で、「NAPを構成する」をクリックしてウィザードを開始してみると、「認証方法の構成」で「NPSサーバー証明書」が「なし」で選択できないことがわかった。つまりサーバ証明書がない（失効していても同じ状態）のが原因なので、これを解消するために対応した。
いろいろと試した結果、結論しては、先の作業で解消した。
1. NPSのサーバで、管理ツールから「証明機関」を開く。
2. ローカルの証明サーバを選んで、右クリック。
3. 「すべてのタスク」から「CA証明書の書き換え」を選択する。
4. 証明書の書き換えで再発行する。
5. NPSサーバ（サービス）を再起動する。
これで、NPSからADのディレクトリに対して、認証ができるようになり、PEAPの認証が正常に行えるようになった。
MicrosoftがWindows環境におけるVBScript（VBS）を非推奨にすると発表した。将来的には、VBScriptの実行環境が削除されるとのこと。
「VBScript」は非推奨に、将来のWindowsリリースで削除
https://forest.watch.impress.co.jp/docs/news/1537619.html
しぶとく残ると思われていたIE11も廃止されたので、VBScriptも確実に削除されるだろう。いずれ出るであろうWindows 12は、削除されていてもおかしくはないかも。そう考えると、明確な言及はないけれど、2，3年くらいで無くなるという覚悟が必要そうだ。
タイトルのままだが、systeminfoは、Windows XPから追加されたコマンド。Windows 2000（Windows 2000 Server）には、systeminfoがないので注意。
Windows Server 2022で作成したAD（機能レベル2016）に、Windows 2000 Serverを参加させようとしたが、エラーによりドメインに参加できなかった。
ドメイン "xxxxxx.domain" に参加中に次のエラーが発生しました：
指定されたネットワーク名は利用できません。原因は、CIFSなどのプロトコルのバージョンが低いもの（セキュリティリスクがあるもの）を許可していないためと思われる。参加できるかどうかの実験だったので、通常状態ではWindows Server 2022で作成したADに、Windows 2000 Serverは参加できない、という結果が出たので満足。
ファイルサーバのデータ移行をしていて、共有からアクセスするとアクセス権のないファイルやフォルダが表示されない（アクセス権のないファイルやフォルダが見えない）、という状況があった。
気になって調べてみると、SMBのプロトコルバージョンやCIFSバージョンの問題ではなく、Windowsのフォルダ設定で、「アクセス許可設定に基づいた列挙を有効にする」の設定にチェックが入っている（オンになっている）と、アクセス権のないフォルダやファイルは表示されなくなる。設定中に、オンにしてしまっていたようだ。「アクセス許可設定に基づいた列挙を有効にする」の設定のチェックボックスでチェックを外して保存すれば、アクセス権のないフォルダやファイルも見えるようになる。
「アクセス許可設定に基づいた列挙を有効にする」の設定は以下。
１．「サーバーマネージャー」を開く
２．サイドメニューから「ファイル サービスと記憶域サービス」を開く
３．サイドメニューから「共有」を開く
４．表示された共有一覧から、対象の共有名を選んで、右クリックからプロパティを開く
５．プロパティの中の「設定」を開く
６．「アクセス許可設定に基づいた列挙を有効にする」を確認する、必要に応じて、チェックのオン・オフを行う
Windows Server 2022の既定値も調べてみたが、「アクセス許可設定に基づいた列挙を有効にする」（Access Based Enumeration）は、既定値はオフ。
なお、マイクロソフトのドキュメントによると、「一部の環境では、アクセス ベースの列挙を有効にすると、サーバーの CPU 使用率が高くなり、ユーザーの応答時間が遅くなります。」とのことなので、特別な要件がなければ、オフの方がよさそうだ。
参考：
IntelのCPUに「Downfall Attacks」と呼ばれる脆弱性が見つかったとのこと。
第6世代Skylakeから第11世代Rocket LakeおよびTiger LakeまでのIntelプロセッサを使っているコンピュータが対象になるとのこと。この脆弱性を悪用すると、Gather Data Samplingを使用して他のユーザーからデータやその他の機密情報を盗み出すことができるようだ。
Linuxについては、Gather Data Samplingを無効化する方法が公開されているがパフォーマンスが低下するようだ。Windowsについては、Microsoftが対策中のようだ。今後の動きは注目しておきたい。
参考
Windows Serverの役割として、DNSサーバを追加したときの設定ファイル（ゾーンファイル）の保存。Windows Server 2008 R2, Windows Server 2019, Windows Server 2022のDNSサーバで確認したが、全部同じ保存パスだった。「ZONE 名.dns」のファイルが、ゾーンファイル。
■設定ファイルの保存場所
%SYSTEMROOT%\system32\dnsC:\Windows\System32\dns「ZONE 名.dns」というファイルがあり、これがゾーンファイルの形式になっている。中身はテキストなので、テキストエディタで開けば確認はできる。バックアップが必要ならば、このファイルをバックアップする。テキスト形式なので、subversionやGitに登録して、差分管理することも可。
Windows Server 2022で新しく作成したActive Directory（AD）のドメイン機能レベルはWindows Server 2016。
Windows Server 2019やWindows Server 2022では新しく、ドメイン機能レベルは追加されていないため、機能レベルはWindows Server 2016で作成される。