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の認証が正常に行えるようになった。
Cisco NEXUS でVPC構成（VLAN多数）、VMware ESXiによる仮想化、F5 BIG-IPの仮想ロードバランサ、ロードバランサの配下に複数のアプリケーションサーバ、という構成で、ロードバランサの下のAPサーバに通信がうまくできない、という状態が発生した。
状況を切り分けしてみると、下記のような状態になった。
端末→ESXi→Cisco NEXUS （A）→ESXi→BIG-IP→アプリサーバ（X） ・・・ 通信OK
端末→ESXi→Cisco NEXUS （A）→ESXi→BIG-IP→アプリサーバ（Y） ・・・ 通信OK
端末→ESXi→Cisco NEXUS （B）→ESXi→BIG-IP→アプリサーバ（X） ・・・ 通信NG
端末→ESXi→Cisco NEXUS （B）→ESXi→BIG-IP→アプリサーバ（Y） ・・・ 通信NG
※Cisco NEXUSは、2台（AとB）で、VPC（Virtual Port Channel）構成で、L3の役割を行っている。基本的に、VLANを超えるときは、必ずL3のNEXUSを通過する。
※端末と、APサーバ、BIG-IP仮想ロードバランサは、それぞれ別のネットワークに属する。
最初は、L3スイッチである、NEXUSの設定を疑ったのだが、AとBで差異はなく、VPCとしての動作も問題がなかった。BIG-IPを経由しなければ、AとBのどちらのNEXUSを通過しても問題発生しない。
BIG-IPの仮想ロードバランサでの通信制御が不具合につながっている可能性が高いことがわかった。BIG-IP仮想ロードバランサの設定を見ていくと、「Auto Last Hop」の設定がONになっており、これが影響していることがわかった。上位のスイッチであるL3のNexusは2台あるので、アクセスしてきたアクセス経路に通信を返す、のが正しいように見える。しかし、VPC構成になっているで、仮想MACアドレスで制御されているのため、アクセス元のスイッチに返してしまうと、経路が途中で変わってしまい、アクセス元の端末までパケットが届かない。
BIP-IPのほうも、上位スイッチが冗長構成を行っている場合は、「Auto Last Hop」の設定は、オフ（無効）にすることが推奨されている。「Auto Last Hop」の設定をオフにすることで、無事に、AとBのどちらのNexusを経由しても、BIP-IP仮想ロードバランサの下のAPサーバと通信できるようになった。
「Auto Last Hop」の設定は、BIG-IP仮想ロードバランサの設定画面で、
「System」→「Configuration」→「Local Traffic」
の順に選択する。Generalのプロパティに、「Auto Last Hop」の項目があるので、「Enabled」のチェックを外して保存する。
Auto Last Hopの説明
MicrosoftがWindows環境におけるVBScript（VBS）を非推奨にすると発表した。将来的には、VBScriptの実行環境が削除されるとのこと。
「VBScript」は非推奨に、将来のWindowsリリースで削除
https://forest.watch.impress.co.jp/docs/news/1537619.html
しぶとく残ると思われていたIE11も廃止されたので、VBScriptも確実に削除されるだろう。いずれ出るであろうWindows 12は、削除されていてもおかしくはないかも。そう考えると、明確な言及はないけれど、2，3年くらいで無くなるという覚悟が必要そうだ。
また、小まめにGitLab CEのアップデートをやり忘れて、apt updateでのアップデートでエラーになった。今回は、GitLab CE 16.2から、GitLab CE １6.4.1へのアップデートだ。
apt upgradeで発生したエラー（一部抜粋）は下記。
gitlab preinstall: It seems you are upgrading from 16.2 to 16.4.
gitlab preinstall: It is required to upgrade to the latest 16.3.x version first before proceeding.
gitlab preinstall: Please follow the upgrade documentation at https://docs.gitlab.com/ee/update/index.html#upgrade-paths
dpkg: アーカイブ /tmp/apt-dpkg-install-33WUrh/15-gitlab-ce_16.4.1-ce.0_amd64.deb の処理中にエラーが発生しました (--unpack):
new gitlab-ce package pre-installation script subprocess returned error exit status 1
処理中にエラーが発生しました:
/tmp/apt-dpkg-install-33WUrh/15-gitlab-ce_16.4.1-ce.0_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)まずは、GitLabのサイトで、アップグレードできるパスを調べる。
これによると、一度、16.3.5にアップグレードしてから、この時点の最新にアップグレードする必要があるとのこと。
アップグレードパス ： 16.2 → 16.3.5 → 16.4.1
これを実行したコマンドは下記。段階的にアップデートして、最後に、GitLabを再起動する。
sudo apt update
sudo apt upgrade gitlab-ce=16.3.5-ce.0
sudo apt upgrade gitlab-ce=16.4.1-ce.0
sudo gitlab-ctl restart何度もやっているので、作業自体はこなれた感じだ。
タイトルのままだが、systeminfoは、Windows XPから追加されたコマンド。Windows 2000（Windows 2000 Server）には、systeminfoがないので注意。
SQL Serverで、個別のデータベースに対して、権限を与えても、SQL Server エージェントのジョブの部分はSQL Server Management Studio（SSMS）には、「SQL Server エージェント」も「ジョブ」も表示されない。これの権限は、データベースの権限とは別につける必要がある。
SQL Serverのジョブ（SQL Server エージェント）に権限を付ける一番簡単な方法は、以下の操作でsysadmin権限の付与を行う。
これで権限が付与されるので、権限を与えたユーザで、SSMSで接続して、「SQL Server エージェント」と「ジョブ」が表示されることを確認する。
もし、SQL Server エージェントだけの権限を与える必要がある場合は、データベースの「msdb」にあるロールを割り当てる。
選択できるロールの概要は以下。
SQLAgentUserRole
→SSMSで接続したときに、SQL Serverエージェントが表示される。
表示されるのは、接続ユーザの権限があるもののみ。
SQLAgentReaderRole
→SSMSで接続したときに、SQL Serverエージェントが表示される。
他のユーザのSQL Serverのジョブも表示される。
メニューで、ジョブが実行できるように見えるが、実行すると権限がないものはエラーになる。
SQLAgentOperatorRole
→SSMSで接続したときに、SQL Serverエージェントが表示される。
SQL Serverのジョブの表示や実行ができる。
Windows Server 2022で作成したAD（機能レベル2016）に、Windows 2000 Serverを参加させようとしたが、エラーによりドメインに参加できなかった。
ドメイン "xxxxxx.domain" に参加中に次のエラーが発生しました：
指定されたネットワーク名は利用できません。原因は、CIFSなどのプロトコルのバージョンが低いもの（セキュリティリスクがあるもの）を許可していないためと思われる。参加できるかどうかの実験だったので、通常状態ではWindows Server 2022で作成したADに、Windows 2000 Serverは参加できない、という結果が出たので満足。
Veeam Backup＆ Replicationで設定できるイミュータブル期間（データの変更を禁止する不変期間）を調べてみた。
https://helpcenter.veeam.com/jp/docs/backup/vsphere/hardened_repository.html?ver=110
バックアップファイルは、構成された期間（最小7日、最大— 9999）の間イミュータブルになります。イミュータビリティ期間は、アクティブなバックアップチェーンに対してのみ延長されます。 バックアップに複数のチェーンがある場合、Veeam Backup & Replicationは、チェーン内の古いバックアップのイミュータビリティを延ばしません。
https://helpcenter.veeam.com/jp/docs/backup/vsphere/hardened_repository.html?ver=110
上記がVeeamのサイトにあるので、イミュータブル期間の最大期間は、9999日。無限にはできない。年にすると、 27.38年になる。