2026年1月28日水曜日

Proxmoxバージョンアップ手順 (8.4→9.1)

Proxmoxのサポートポリシーは、メジャーバージョンのリリース後、おおよそ3年となる。

Proxmoxは現在バージョン8と9がサポート期間となっているが、バージョン8については、2026年8月がEOLとなっており、バージョンアップ対応が必要となる。

本記事では、Proxmoxをバージョン8からバージョン9にバージョンアップする手順を記載する。

環境

Proxmoxのバージョンは以下の通り。バージョンアップ作業では再起動が必要であるため、仮想マシンは事前に停止させておくこと。

  • バージョンアップ前Proxmox: 8.4.14
  • バージョンアップ後Proxmox: 9.1.4

バージョンアップ手順

1. 最新までアップデートを実施

まずは、現在のProxmoxを最新化しておく。

apt update
apt dist-upgrade

2. チェックスクリプトpve8to9実行

バージョンアップの各種チェックを行うスクリプトとしてpve8to9が用意されているのでこちらを実行する。

最後にサマリーが表示されるが、通常はいくつかのWARNINGSとFAILURESが出力される。必ずしもすべて解消しなければならないものではないので、以降の手順で私が遭遇したエラーに対する対応を記載する。

# pve8to9

~(中略)~

= SUMMARY =

TOTAL:    58
PASSED:   38
SKIPPED:  13
WARNINGS: 4
FAILURES: 1

3. (必要な場合) GRUBの設定修正

以下エラーは、「EFI の「リムーバブルメディア用ブートローダー」が存在するが、今後 GRUB の更新対象にならない可能性がある」ことに対する警告となる。

WARN: Removable bootloader found at '/boot/efi/EFI/BOOT/BOOTX64.efi', but GRUB packages not set up to update it!
Run the following command:
echo 'grub-efi-amd64 grub2/force_efi_extra_removable boolean true' | debconf-set-selections -v -u
Then reinstall GRUB with 'apt install --reinstall grub-efi-amd64'

対処としては、メッセージに記載の通りのコマンドを実行して修正するだけでよい。

echo 'grub-efi-amd64 grub2/force_efi_extra_removable boolean true' | debconf-set-selections -v -u
apt install --reinstall grub-efi-amd64

4. (必要な場合) systemd-bootパッケージの削除

以下エラーは、「Proxmox の想定ブートローダー(GRUB)とは別系統の systemd-boot が同居しており、 今後のブートローダー更新や OS アップグレードで問題を起こす構成になっている」ことに対する警告となる。

FAIL: systemd-boot meta-package installed. This will cause problems on upgrades of other boot-related packages. 
Remove 'systemd-boot' See https://pve.proxmox.com/wiki/Upgrade_from_8_to_9#sd-boot-warning for more information.

対処としては、systemd-bootパッケージをアンインストールする。

apt remove systemd-boot

5. リポジトリの修正

Debian 12 (Bookworm)からDebian 13 (Trixie)へリポジトリの変更を行う。

sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/pve-enterprise.list

また、Debian 13 (Trixie)用のpve-no-subscriptionリポジトリの追加を行う。

cat > /etc/apt/sources.list.d/proxmox.sources << EOF
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF

6. チェックスクリプトpve8to9再実行

バージョンアップの直前に再度チェックスクリプトを実行しておく。私の場合は1件WARNINGSを残しているが、バージョンアップ作業には影響がなさそうなので無視して進めることにする。

# pve8to9

~(中略)~

= SUMMARY =

TOTAL:    57
PASSED:   43
SKIPPED:  9
WARNINGS: 1
FAILURES: 0

7. バージョンアップ

バージョンアップを実行する。多数のパッケージダウンロードとインストールが発生するため、完了までは15分程度要した。

apt update
apt dist-upgrade

途中、入力を求められる場面があるため、以下の通り進める。

Configuration file '/etc/issue'

Configuration file '/etc/issue'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** issue (Y/I/N/O/D/Z) [default=N] ? ★そのままエンター。

Configuring libc6:amd64

There are services installed on your system which need to be restarted 
when certain libraries, such as libpam, libc, and libssl, are upgraded. 
Since these restarts may cause interruptions of service for the system, 
you will normally be prompted on each upgrade for the list of services you wish to restart.  
You can choose this option to avoid being prompted; instead, 
all necessary restarts will be done for you automatically so you can avoid being asked questions on each library upgrade.                                                               
                                                                                                                                            
Restart services during package upgrades without asking?                                                                                    
                                                                                                                                            
<Yes>    <No>
↑★「Yes」を選択。

/usr/share/chrony/chrony.conf

lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu Modified configuration file tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
x A new version (/usr/share/chrony/chrony.conf) of configuration file /etc/chrony/chrony.conf is available, but the version installed   x
x currently has been locally modified.                                                                                                  x
x                                                                                                                                       x
x What do you want to do about modified configuration file chrony.conf?                                                                 x
x                                                                                                                                       x
x                                         install the package maintainer's version                                                      x
x                                         keep the local version currently installed                                                    x
x                                         show the differences between the versions                                                     x
x                                         show a side-by-side difference between the versions                                           x
x                                         show a 3-way difference between available versions                                            x
x                                         do a 3-way merge between available versions                                                   x
x                                         start a new shell to examine the situation                                                    x
x                                                                                                                                       x
x                                                                                                                                       x
x                                                                <Ok>                                                                   x
x                                                                                                                                       x
mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj

↑★「keep the local version currently installed」を選んでエンター。

Configuration file '/etc/lvm/lvm.conf'

 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** lvm.conf (Y/I/N/O/D/Z) [default=N] ? Y ★「Y」を入力しエンター。

8. 再起動

Proxmoxを再起動する。

reboot

9. aptリポジトリのフォーマット最新化

最後にaptのリポジトリ設定を新しいフォーマットに変換するコマンドを実行しておく。

apt modernize-sources

参考

2026年1月17日土曜日

Entra JoinしたWindows 11デバイスにEntra IDでリモートデスクトップ接続する手順

Entra Joinで管理しているWindows 11のデバイスは、ローカルアカウントを使えば今まで通りリモートデスクトップ接続することが可能だが、Entra IDでログインする場合は、少し工夫が必要となる。

本記事では、Entra JoinしたWindows 11デバイスにEntra IDでリモートデスクトップ接続する手順を記載する。なお、接続手順は2パターンある。

環境

本環境を構築した際のOSバージョンは以下の通り。Windows 11は仮想マシンで構築している。

  • デバイス : Windows 11 24H2 ※仮想マシン

手順①:「Webアカウントを使用して、リモートコンピューターにサインインする」のオプションを使う

1. Entra IDのユーザーを「Remote Desktop Users」または「Administrators」グループに所属させる

Entra IDのユーザーはGUIからはローカルのグループに所属させることはできない。したがって、以下のようにnet localgroupコマンドで追加を行う。コマンド実行には管理者権限が必要となる。

PS C:\Users\test> net localgroup "Remote Desktop Users" /add "AzureAD\tuser001@test.com"
コマンドは正常に終了しました。

追加後、念のためGUIでも確認しておこう。「コンピューターの管理 > ローカルユーザーとグループ」を開いてみると、「Entraのドメイン名\ユーザー名」でグループにEntra IDのユーザーが追加されているはずだ。

2. リモートデスクトップ接続の設定を変更

「リモートデスクトップ接続」の「詳細設定」タブにある「Webアカウントを使用して、リモートコンピューターにサインインする」を有効にする。

3. リモートデスクトップ接続実施

Webアカウントによるリモートデスクトップ接続を行い場合は、IPアドレスの接続は許可されずホスト名によるログインが必要となる。

なお、IPアドレスで接続しようとすると、以下のようなエラーで接続に失敗する。

4. ユーザー・パスワード入力

通常のリモートデスクトップ接続とは異なり、よくあるEntra IDでログインする際のユーザー・パスワードの入力画面が表示される。


入力内容に問題なければ、リモートデスクトップ接続に成功し、接続先デバイスのOS画面が表示される。

手順②:CredSSPを無効化する

1. Entra IDのユーザーを「Remote Desktop Users」または「Administrators」グループに所属させる

これは手順①と同じなので割愛する。

2. 接続先デバイスでネットワークレベル認証 (NLA) を無効化

接続先となるWindows 11のデバイスで、「設定 > システム > リモートデスクトップ」より、「デバイスが接続にネットワークレベル認証を使用することを要求する (推奨)」のチェックを外す。これによりネットワークレベル認証 (NLA) を無効化する。

3. リモートデスクトップ接続設定

リモートデスクトップ接続を開き、接続先のコンピューター名 (IPアドレスでも可) とEntra IDのアカウントを入力する。Entra IDのアカウントは「ユーザー名@ドメイン名」の形で入力すること。入力後、「名前を付けて保存」にて*.rdpファイルを保存する。

保存したファイル (*.rdp) のファイルをメモ帳などで開き、enablecredsspsupport:i:0の行を最下行に追記する。

この設定は、「クライアントが認証に資格情報セキュリティ サポート プロバイダー (CredSSP) を使用するかどうかを指定する」設定となり、0を指定することで無効化する。

screen mode id:i:1
use multimon:i:0

~(中略)~

username:s:AzureAD\tuser001@test.com
enablecredsspsupport:i:0 ←★追記

4. リモートデスクトップ接続実施

保存したファイル (*.rdp) をダブルクリックし、リモートデスクトップ接続をすると、通常はリモートデスクトップ接続クライアントで聞かれる認証画面ではなく、通常のWindows 11のログイン画面が表示され、ユーザー・パスワード入力ができるようになる。

5. ユーザー・パスワード入力

ユーザー名にはEntra IDのユーザー名を入力するが、「azuread\ユーザー名@ドメイン名」の名前で入力する。「azuread」と入力することでサインイン先がEntra IDとなる。

なお、*.rdpのファイル内で事前に「azuread\ユーザー名@ドメイン名」を入れたユーザー名で設定したとしても、必ず手入力で「azuread」の入力が必要となるので注意すること。

以上で、Entra JoinしたWindows 11デバイスにEntra IDでリモートデスクトップ接続する手順は完了となる。

参考

2026年1月5日月曜日

Entra JoinしたWindows 11端末をEntra KerberosでファイルサーバーにSSOさせる

Entra Kerberosを設定すると、Entra Joinしている端末からもオンプレADのドメイン上のファイルサーバーにSSOし、ファイルアクセスができるようになる。

本記事では、Entra JoinしたWindows 11端末をEntra KerberosでファイルサーバーにSSOさせる手順を記載する。

環境

本環境を構築した際のOSバージョンは以下の通り。Windows 11は仮想マシンで構築している。

  • デバイス : Windows 11 24H2 ※仮想マシン

1. Entra Kerberosを構成する

SSOさせるための前提条件として、「①Entra ConnectによるオンプレユーザーをEntra IDへ同期」させ、「②Entra Kerberosを構成」する必要がある。Entra IDで認証した際に、オンプレADの認証に必要な「部分的なTGT」を受け取ることで、オンプレADの認証を処理させるためだ。

Entra Connectの設定手順は、以下URLを参照すること。

Entra Kerberosの設定手順は、以下URLの「クラウド信頼とEntra Kerberosについて」を参照すること。

Entra Join手順

1. 設定画面へ遷移

[設定] > [アカウント] > [職場または学校にアクセスする]を選択する。

[職場または学校のアカウントを追加」を選択する。

2. Entra Joinに必要な認証情報の入力

「職場または学校アカウントのセットアップ」では、中央の「電子メールアドレス」のテキストボックスに入力して進めたくなるが、画面下部の[このデバイスをMicrosoft Entra IDに参加させる]のリンクを選んで登録する点に注意しよう。

Microsoftアカウントの認証画面に遷移するので、Entra IDのユーザー・パスワードを入力する。

「これがあなたのネットワークであることを確認してください」では「参加する」を選択する。

完了すると、「<テナント名>のEntra IDに接続しました」と表示される。

Entra管理センターでも、デバイスが「Microsoft Entra joined」と表示される。

以上で、Entra Joinは完了となる。

ファイルサーバーへのSSOでのアクセス確認

オンプレADにドメイン参加したWindows 11に共有フォルダを作成し、これをファイルサーバー相当としてSSOによる接続確認を行う。使用するユーザーと共有フォルダの設定は以下の通り。なお、使用するユーザーは、オンプレAD上に存在するユーザーをEntra Connectで同期しておく必要がある。

  • 使用するユーザー : tuser002
  • 共有タブ : tuser002のみフルコントロール
  • セキュリティタブ : tuser002のみフルコントロール

まず、ローカルアカウントでデバイスにログインしたのち、共有フォルダにアクセスする。当然「アクセスできません」のエラーとなる。

次に、フルコントロールを許可している「tuser002」のアカウントにてログインし、共有フォルダにアクセスする。今度は、エラーとならず共有フォルダにアクセスに成功できた。

以上で、Entra JoinしたWindows 11端末をEntra KerberosでファイルサーバーにSSOさせることの設定手順と確認は完了となる。

2025年12月27日土曜日

Linuxでオレオレ認証局作ってオレオレ証明書作る手順

サーバー証明書はきちんとしたものを用意しようとするとお金と手間暇がかかるので、検証用としては不向きである。以前のRHEL 7以前は、CAという証明書作成用のスクリプトがあって、それを用いた手順は過去記事にしてある。

しかし、RHEL 8以降は同梱されなくなったため、今回はLinuxのopensslコマンドを用いて、オレオレ認証局作ってオレオレ証明書作る手順を記載する。

環境

環境は以下の通り。OpenSSLだけあれば認証局と証明書は作成できる。

  • OS : AlmaLinux release 9.4
  • OpenSSL : OpenSSL 3.0.7

オレオレ認証局(CA)作成手順

1. CA用のディレクトリを作成

CA用のディレクトリを以下構成で任意の場所に作成する。

pki/
├─ ca/
│  ├─ private/
│  ├─ certs/
│  ├─ newcerts/
│  ├─ index.txt
│  ├─ serial
│  └─ openssl.cnf
└─ server/
mkdir pki
cd pki/
mkdir -p ca/{private,certs,newcerts} server

CAが署名する際に必要となるファイルとして、index.txtserialのファイルを事前に作成しておく。index.txtは空のファイルを、serialは任意の数字1行を記載したファイルを作成する。

touch ca/index.txt
echo 1000 > ca/serial

2. 設定ファイルopenssl.cnfを作成

openssl.cnfはデフォルトのものをコピーして、必要な個所を書き換える。

cp /etc/pki/tls/openssl.cnf ca/

書き換え箇所は以下の通り。

設定項目 設定値 説明
dir ./ca CA証明書の読み込みパスのベースとなるディレクトリを指定。
certificate $dir/certs/ca.crt CA証明書の保存場所を指定。
private_key $dir/private/ca.key CAの秘密鍵の保存場所を指定。
copy_extensions copy 証明書作成時にCSRに含まれる拡張属性(サブジェクト代替名(SAN)も拡張属性に含まれる)の値を引き継ぐかどうかの設定。copyにすることで引き継ぐよう設定する。
default_days 3650 証明書の有効期限。オレオレ証明書を定期的に更新する必要性はないため、10年に設定する。
extendedKeyUsage serverAuth, clientAuth, codeSigning, emailProtection [ usr_cert ]セクションに追記する。CA署名時にextendedKeyUsage (EKU)の拡張属性を付与させる。
policy policy_anything CA証明書とCSR証明書のサブジェクトの一致、不一致をどこまで許容するかを設定する。policy_anythingにすることで、サブジェクトで設定するCSTOなどが一致しなくても証明書の作成が可能となる。

3. CA用の秘密鍵と証明書を作成

CA用の秘密鍵作成する。アルゴリズムは、楕円曲線デジタル署名アルゴリズム「ECDSA P-256」を用いる。RSA 2048ビットと同程度の暗号強度でありながら、鍵長を短くでき、処理も高速というメリットがある。

openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:P-256 -out ca/private/ca.key
chmod 600 ca/private/ca.key

秘密鍵に対応する証明書を作成する。この証明書がいわゆるCA証明書となり、Windowsであれば、「信頼されたルート証明機関」に登録することで、ブラウザなどで証明書エラーを出なくすることができる。
※Linuxの場合は過去記事を参照。

openssl req -key ca/private/ca.key -new -x509 -days 3650 -addext keyUsage=critical,keyCertSign,cRLSign \
  -subj "/C=JP/ST=Tokyo/O=MyPrivateCA/CN=MyRootCA" -out ca/certs/ca.crt

作成した証明書の内容は以下コマンドで確認できる。

openssl x509 -in ca/certs/ca.crt -text -noout

実行結果例は以下の通り。

# openssl x509 -in ca/certs/ca.crt -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            6b:1b:16:0b:64:c0:f1:49:ec:de:d0:e6:bc:3e:c9:95:de:6f:6c:20
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: C = JP, ST = Tokyo, O = MyPrivateCA, CN = MyRootCA
        Validity
            Not Before: Dec 26 22:55:06 2025 GMT
            Not After : Dec 24 22:55:06 2035 GMT
        Subject: C = JP, ST = Tokyo, O = MyPrivateCA, CN = MyRootCA
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:32:0e:69:35:ef:eb:31:29:25:30:64:63:97:64:
                    68:22:7d:d3:67:4e:21:82:91:9d:45:94:c5:d1:2c:
                    12:e8:0a:dd:50:2e:3d:ee:44:18:9d:69:f8:9c:8e:
                    21:3c:ec:06:bc:36:be:4f:5f:63:e6:04:33:22:55:
                    6c:dd:47:0a:6a
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                7E:68:99:E9:DB:F1:A9:6C:A0:CA:6E:A2:E8:53:AD:22:33:B4:D2:69
            X509v3 Authority Key Identifier:
                7E:68:99:E9:DB:F1:A9:6C:A0:CA:6E:A2:E8:53:AD:22:33:B4:D2:69
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
    Signature Algorithm: ecdsa-with-SHA256
    Signature Value:
        30:45:02:21:00:aa:1a:20:c2:e3:37:c7:63:99:97:5a:36:31:
        af:96:84:51:8f:93:46:e6:42:ac:7b:a0:39:5f:c2:ff:85:1a:
        c1:02:20:36:a2:23:1d:85:ff:58:1a:95:f7:e0:0e:29:3a:0b:
        1e:db:bd:e9:78:ff:c7:2b:f9:b5:19:ff:2e:0c:15:4d:32

以上で、CA用の秘密鍵と証明書を作成は完了となる。

オレオレ証明書作成手順

「秘密鍵作成→CSR作成→CAにて署名」の順に対応する。

以下コマンドの証明書ファイル名(filename)、サブジェクト(subj)、サブジェクト代替名(subjectAltName)を適切なものに変更して、上から順に流せばよい。

# 証明書ファイル名
cd ~/pki/
filename="server"

# 秘密鍵作成
openssl genrsa -out server/${filename}.key 2048
chmod 600 server/${filename}.key

# CSR作成
openssl req -new -key server/${filename}.key -out server/${filename}.csr \
  -subj "/C=JP/ST=Tokyo/O=test/CN=example.test.com" \
  -addext "subjectAltName=DNS:example.test.com,IP:192.168.1.1"

# 署名
openssl ca -batch -config ca/openssl.cnf -in server/${filename}.csr -out server/${filename}.crt

# 確認 (*.keyが秘密鍵、*.crtがSSL証明書)
ls -l server/

以上で、Linuxでオレオレ認証局作ってオレオレ証明書作る手順は完了となる。

参考

2025年12月24日水曜日

Windows Timeサービスの時刻同期を正しく設定する手順【Windows 10・Windows Server 2016以降対応】

数年前の記事となるが、Windows Server 2008 R2環境における時刻同期方法について記事にした。

あれからWindows Serverも2012、2012 R2、2016、2019、2022とバージョンアップを重ねてきているので、再度Windows 10及びWindows Server 2016以降における正しい時刻同期の設定方法を調べてみた。

以前の手順では、トリガーサービスの停止や「SpecialPollInterval」のレジストリ値の変更などが必要となっており煩雑となっていた。今回いろいろ調べてみたところ、Windows Server 2016以降ではw32tmのコマンドで設定するだけでよく、前回に比べてシンプルな手順となった。

Windowsの時刻設定

1. Windows Timeサービスが起動していることを確認

まずは、時刻同期をするための前提条件となるWindows Timeサービスの起動設定と状態を確認する。

私の環境で確認したところ、Windows 10では「スタートアップの種類」が「手動」になっておりサービスが起動していなかった。逆に、Windows Server 2016以降では、「自動起動」となっておりサービスも起動しており対処は不要だった。

サービスが起動していない場合は、以下コマンドにて「スタートアップの種類」を「自動起動」への変更と、サービスの起動を行う。

PS C:\> Set-Service -Name W32Time -StartupType Automatic
PS C:\> Start-Service -Name W32Time

Windows Timeサービスの起動状態を確認するには、PowerShellで以下コマンドを実行する。以下状態となっていれば問題なくWindows Timeサービスが起動している。

  • Status : Running
  • StartType : Automatic
PS C:\> Get-Service -Name W32Time | select Name, DisplayName, Status, StartType

Name    DisplayName   Status StartType
----    -----------   ------ ---------
W32Time Windows Time Running Automatic

2. 時刻同期先を「0x8」のフラグを付けて指定する

PowerShell (またはコマンドプロンプト) を管理者として開き、以下のようにコマンドを実行する。コマンドのオプションの意味は以下の通り。

オプション 説明
/config 設定を変更する際に指定。
/update 設定変更を即時に反映。
/manualpeerlist:"<同期先NTPサーバ>,<フラグ>" 同期先のNTPサーバを指定する (フラグについては後述する)。ダブルクォート ("") で囲まないとうまく設定が反映されないので注意。複数の同期先を指定する場合は、空白区切りにて記載する。
/syncfromflags:<同期方式> 手動で同期先を指定する場合は、「MANUAL」を指定する。なお、ドメイン環境においてドメインコントローラと同期する場合は「DOMHIER」を指定する。

以下コマンド実行例となる。「コマンドは正しく完了しました。」と表示されればOK。

PS C:\> w32tm /config /update /manualpeerlist:"ntp.nict.jp,0x8 ntp.jst.mfeed.ad.jp,0x8" /syncfromflags:MANUAL
コマンドは正しく完了しました。

フラグは以下の設定を選択することができる。

設定値 説明
0x1 「SpecialPollInterval」のレジストリ値で設定した秒数にて、一定間隔で同期する方式。
0x8 NTPクライアントモードで同期。RFC1305に準拠した同期。最初の同期は短いタイミングで同期を行い、以降は徐々に同期間隔を長くするという方式。同期間隔は「MinPollInterval」と「MaxPollInterval」のレジストリ値にて設定される。
0x9 NTPクライアントモードで同期。0x1と同様に一定間隔で同期。

Windows Server 2008時代は0x9のフラグを設定することが多かったが、現在は0x8で設定するのが推奨となる。
※理由は後述する「【補足】Windows Timeサービスのフラグに0x9を指定してはいけない理由」を参照いただきたい。

3. 設定確認

一度w32tm /resyncにて手動で同期しておく。その後、問題なく同期されていることをw32tm /query /statusで確認する。最終正常同期時刻が更新されていれば、問題なく時刻同期されている。

PS C:\> w32tm /resync
再同期コマンドをローカル コンピューターに送信しています
コマンドは正しく完了しました。

PS C:\> w32tm /query /status
閏インジケーター: 0 (警告なし)
階層: 3 (二次参照 - (S)NTP で同期)
精度: -6 (ティックごとに 15.625ms)
ルート遅延: 0.0044629s
ルート分散: 8.2163946s
参照 ID: 0xC0A82117 (ソース IP:  192.168.33.23)
最終正常同期時刻: 2020/08/19 10:43:57 ←★
ソース: 192.168.33.23,0x8
ポーリング間隔: 7 (128s)

【補足】Windows Timeサービスのフラグに0x9を指定してはいけない理由

Windows Timeサービスでは「LargePhaseOffset」というレジストリ値の設定があり、この値で設定した時間よりも時刻のずれが生じた場合、「Spike」というステータスに遷移し時刻同期が停止する。「LargePhaseOffset」はデフォルトで 50000000 (単位は100ナノ秒なので5秒) で設定されている。
※本題ではないが「LargePhaseOffset」の単位が「ミリ秒」という情報もあるが、実機で確認した限りでは「100ナノ秒」が単位としては正しいようだ。

通常は「Spike」の後「Unset」と呼ばれるSTEPモードで時刻同期を行うステータスに遷移するが、フラグに0x9が指定されている場合 (SpecialPollIntervalで設定された一定の間隔による時刻同期が実行されている場合) は「Unset」に遷移せず、二度と時刻同期に成功しなくなるという問題が存在する。詳細は以下のMicrosoftのKBに記載がある。

なお、Windows TimeサービスのSpikeへ遷移する動作については、以下のMicrosoftのブログの記事にて非常に詳細に説明されている。

この問題はフラグに0x8を設定した場合は発生しないため、時刻同期のフラグは0x9ではなく0x8で設定することが推奨となる。

参考

変更履歴

  • 2020/9/5 新規作成
  • 2025/12/24 手動での同期手順を追加
2025年12月19日金曜日

Windows Hello for Business (WHfB) をクラウド信頼で認証するよう構成する手順

前回はEntra Connectを使って、Windowsデバイスをハイブリッド参加させる手順を記載した。

今回は、Windows Hello for Business (WHfB) をクラウド信頼で認証するよう構成する手順を記載する。

環境

本環境を構築した際のOSバージョンは以下の通り。Windows 11は仮想マシンで構築しているため、Windows Helloは顔認証は使えない。したがって、PINの認証ができることまでを確認する。

  • Entra Connect : 2.5.190.0
  • オンプレAD : Windows Server 2022
  • デバイス : Windows 11 24H2 ※仮想マシン

前提として、Entraハイブリッド参加の構成が完了している必要がある。設定できていない場合は、以下手順を参考に設定を行うこと。

クラウド信頼とEntra Kerberosについて

WHfBは認証方式に「キー信頼」、「証明書信頼」、「クラウド信頼」(「クラウドトラスト」だったり「クラウドKerberos信頼」と表現されることもある)の3つの方式が存在する。

今回は後者の「クラウド信頼」で設定する。クラウド信頼には、Entra Kerberosの仕組みを使用する。そもそも、クラウド信頼認証とは何か、については、Microsoftの以下サイトに記載の図が比較的わかりやすい。

ざっくりな説明とはなるが、Windows HelloにてEntra IDに認証を求め、その認証結果をオンプレ側のADに連携することで、クラウドとオンプレ環境のどちらに対してもSSOができるようになる仕組みとなる。以下に図示する。

Entra Kerberosの設定は、基本的には以下のMicrosoftの手順に従って実行する。いろんなサイトにコマンドは乗っているが、以下のサイトの情報が事前事後の情報確認手順が含まれており確実な手順だと思ったので採用した。

Entra Kerberosの設定手順

インターネットからPowerShellのモジュールのインストールをするため、インターネットに接続できる環境で実行すること。コマンド実行は、ドメインに参加している端末でもサーバーでもどちらでも構わない。私は、Entra Connectを導入しているWindows Server 2022にて実行した。

1. PowerShellの実行ポリシーをBypassに変更

PowerShellの実行ポリシーをBypassに変更して、コマンド実行ができるようにする。

Set-ExecutionPolicy Bypass -Scope Process -Force

2. モジュールをインストール

AzureADHybridAuthenticationManagementのモジュールをインストールする。途中「信頼されていないリポジトリ」の確認がされる場合があるが、「y」を入力してインストールする。

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Install-PackageProvider -Name NuGet -Force
if (@(Get-PSRepository | ? {$_.Name -eq "PSGallery"}).Count -eq 0){
    Register-PSRepository -DefaultSet-PSRepository -Name "PSGallery" -InstallationPolicy Trusted
}
Install-Module -Name PowerShellGet -Force
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

3. 設定前確認

設定変更前に、現在の設定を確認する。コマンド実行時に認証画面が表示されるので、以下に記載の権限を持つアカウントを指定すること。

$domain = "<ドメイン名>"

$domainCred = Get-Credential
※認証画面が表示されるのでオンプレの管理者(Domain Admins)を指定する。

$cloudUserName = "<Entraのグローバル管理者>"

Get-AzureAdKerberosServer -Domain $domain -DomainCredential $domainCred -UserPrincipalName $cloudUserName
※認証画面が表示されるのでEntraのグローバル管理者を指定する。

実際の実行結果は以下の通り。すべて空白で実行結果が表示されることを確認する。

PS C:\Windows\system32> Get-AzureAdKerberosServer -Domain $domain -DomainCredential $domainCred -UserPrincipalName $cloudUserName

Id                 :
UserAccount        :
ComputerAccount    :
DisplayName        :
DomainDnsName      :
KeyVersion         :
KeyUpdatedOn       :
KeyUpdatedFrom     :
CloudDisplayName   :
CloudDomainDnsName :
CloudId            :
CloudKeyVersion    :
CloudKeyUpdatedOn  :
CloudTrustDisplay  :

4. Entra Kerberos信頼を設定

事前確認でコマンドを問題なく実行できたら、いよいよEntra Kerberos信頼を設定する。特にエラーがなければ、数秒でコマンドが正常終了する(特に実行結果は表示されない)。

このコマンドを実行すると、AzureADKerberosのコンピューターアカウントがDomain ControllersのCNに作成される。

Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $cloudUserName -DomainCredential $domainCred -SetupCloudTrust

5. 設定後確認

設定後の確認のため、再度設定値を確認する。

Get-AzureAdKerberosServer -Domain $domain -DomainCredential $domainCred -UserPrincipalName $cloudUserName

実行結果は以下の通り。事前確認の際は空白だったが、Entra Kerberosの設定後は値が表示されることが確認できる。

PS C:\Windows\system32> Get-AzureAdKerberosServer -Domain $domain -DomainCredential $domainCred -UserPrincipalName $cloudUserName

Id                 : 18631
UserAccount        : CN=krbtgt_AzureAD,OU=MyUsers,DC=test,DC=com
ComputerAccount    : CN=AzureADKerberos,OU=Domain Controllers,DC=test,DC=com
DisplayName        : krbtgt_18631
DomainDnsName      : test.com
KeyVersion         : 17153
KeyUpdatedOn       : 2025/12/15 10:41:30
KeyUpdatedFrom     : ad001.test.com
CloudDisplayName   : krbtgt_18631
CloudDomainDnsName : test.com
CloudId            : 18631
CloudKeyVersion    : 17153
CloudKeyUpdatedOn  : 2025/12/15 10:41:30
CloudTrustDisplay  : Microsoft.AzureAD.Kdc.Service.TrustDisplay

GUIでも確認しておこう。「Active Directory ユーザーとコンピューター」を開きDomain ControllersのCNを選択する。ここにAzureADKerberosのコンピューターアカウントが登録されている。

6. Entra Connectの同期を待つ

設定後、AzureADKerberosのコンピューターアカウント情報をクラウドに同期させる必要があることから、Entra Connectの同期を待つ。通常30分毎に同期となるが、コマンドで手動同期もできる。せっかちな人は手動で同期をしておこう。

Start-ADSyncSyncCycle -PolicyType Delta

以上で、Entra Kerberosの設定は完了となる。

Windows Hello for Business (WHfB) 設定手順

続けてWHfBの設定を行う。

1. GPOにてWHfBのグループポリシーを設定

設定はGPOでもIntuneでも可能だが、今回はGPOで行う。

「グループポリシーの管理」でGPOを作成し、以下グループポリシーの設定を行う。

  • 設定場所:コンピューターの構成 > ポリシー > 管理用テンプレート > Windowsコンポーネント > Windows Hello for Business
設定 状態 備考
Windows Hello for Business の使用 有効
オンプレミス認証にクラウドトラストを使用する 有効
ハードウェアのセキュリティ デバイスを使用する 有効 必須ではなく推奨項目。

2. ポリシーを適用

Windows 11の端末にログインし、以下コマンドでグループポリシーの適用を行う。適用後、端末を再起動しよう。

gpupdate /force

3. ログイン時に顔認証やPINの登録画面に遷移することを確認

再度ログインした際に、顔認証やPINの登録画面に自動的に遷移すれば成功となる。私の検証環境では、Windows 11は仮想マシンで作成しているので、顔認証は求められず、PINの設定が求められるようになった。

もし、顔認証やPINの登録画面に遷移しない場合は、イベントビューアーにて「アプリケーションとサービスログ > Microsoft > Windows > User Device Registration > Admin」でエラーや警告メッセージが出てないか確認しよう。

特に、以下のような「Windows Hello for Business のプロビジョニング」に関するメッセージがログイン時に出力されているはず。

いくつかパターンがあるが、以下★箇所が「Yes」になっていれば、設定としては問題ないはず。しばらく時間を置くと解決したりする。

Windows Hello for Business のプロビジョニングが起動されます。 
デバイスは Microsoft Entra 参加済み (またはハイブリッド参加済み): Yes ★
ユーザーが Microsoft Entra 資格情報でログオンしました: Yes 
Windows Hello for Business ポリシーが有効になっています: Yes ★
Windows Hello for Business のログオン後のプロビジョニングが有効になっています: Yes 
このデバイスは Windows Hello for Business のハードウェア要件に合致しています: Yes ★
ユーザーがリモート デスクトップ経由でコンピューターに接続されていません: Yes 
オンプレミス認証ポリシーのユーザー証明書が有効になっています: No 
マシンは none ポリシーに準拠しています。 
オンプレミスの認証ポリシーに対するクラウドの信頼が有効になっています: Yes ★
ユーザー アカウントに Cloud to OnPrem TGT があります: Yes 
詳細については、https://go.microsoft.com/fwlink/?linkid=832647 を参照してください。

逆に言えば、1日放置しても解消されない場合は、何らかの前提条件が満たされていない可能性がある。その場合は、上記の★箇所でYesとなっていない箇所の前提が満たされているかを確認しよう。
※例えば、「ハイブリッド参加済み」の確認は、Entra管理センターやdsregcmd /statusコマンドで確認することができる。

以下はdsregcmd /statusの実行結果例となる。★箇所が「YES」であることを確認する。

+----------------------------------------------------------------------+
| Device State                                                         |
+----------------------------------------------------------------------+

             AzureAdJoined : YES ★
          EnterpriseJoined : NO
              DomainJoined : YES ★

以上で、Windows Hello for Business (WHfB) をクラウド信頼で構成する手順は完了となる。

参考

2025年11月26日水曜日

Entra Connectを用いてWindows 11端末をハイブリッド参加させる手順

自宅環境ではEntra Connect (旧Azure AD Connect)を使って、オンプレADのユーザー情報をEntra IDへ同期する構成としている。今まではユーザー情報を同期させて、そのユーザーでM365環境にログインするといった用途ぐらいにしか使用しておらず、「ただ同期するだけ」の状態だった。

ただし、Entra Connectを使うと、オンプレのドメインに所属しつつ、Entra環境にも参加する「Entraハイブリッド参加 (Entra Hybrid Join)」という構成にすることができる。これをすると、オンプレADにログインすれば、M365へSSOできたり、M365の機能と連携して、デバイスのセキュリティ強化を行うことができる。

本記事では、Entra Connectを用いてWindows 11端末をハイブリッド参加させる手順を記載する。

環境

  • Entra Connect : 2.5.79.0
  • オンプレAD : Windows Server 2016
  • デバイス : Windows 11 24H2

Entraハイブリッド参加手順

1. Entra Connectにて「ハイブリッド参加の構成」の設定を行う

Entra Connectで「ハイブリッド参加の構成」が未実施の場合に作業を実施する。
※私の環境はEntra Connectをかなり古いバージョンの頃に初期構築したこともあり、本作業が未実施だった。

Entra Connectがインストールされているサーバーにログインし、Entra Connectの画面を開く。

「デバイスオプションの構成」を開く。

「Microsoft Entra IDに接続する」は、グローバル管理者のユーザー、パスワードを入力する。

「デバイスオプション」にて「ハイブリッドMicrosoft Entra ID参加の構成」を選択する。

「デバイスのオペレーティングシステム」では、「Windows 10以降のドメインに参加しているデバイス。」を選択する。
※さすがにWindows 10以前のOS (例:Windows 8など)を使っている環境はもう存在しないと思われるため。

「SCPの構成」では、以下を設定する。

  • 認証サービス : Microsoft Entra ID
  • エンタープライズ管理者 : ドメインのエンタープライズ管理者権限のユーザー、パスワードを入力

以上でハイブリッド構成が開始され、最後に「構成が完了しました」と表示されれば問題ない。

2. グループポリシーのテンプレートの最新化

GPOを設定するのだが、私の環境はWindows Server 2016という古い環境 (2026年中に更改予定)のため、設定したいポリシーがデフォルトでは存在しない

その場合は、以下URLから最新のポリシーテンプレートファイルをダウンロードし適用しておくこと。

https://www.microsoft.com/en-us/download/details.aspx?id=108394
Administrative Templates (admx) for Windows 11 Sep 2025 Update.msi

上記msiファイルをインストールすると、C:\Program Files (x86)\Microsoft Group Policy\Windows 11 Sep 2025 Update (25H2)\PolicyDefinitionsにファイルが展開されるので、\\<ドメイン名>\SYSVOL\<ドメイン名>\Policies\PolicyDefinitionsに以下ファイルをコピーする。

  • *.admx
  • en-USフォルダ
  • ja-JPフォルダ

3. GPOにてデバイスのEntra参加を有効化

以下GPOを作成し、Entraハイブリッド参加対象のコンピューターアカウントが登録されているOUにリンクさせる。

  • コンピューターの構成 → 管理用テンプレート → Windows コンポーネント → デバイス登録
    • ドメインに参加しているコンピューターをデバイスとして登録する : 有効
  • コンピューターの構成 → 管理用テンプレート → Windows コンポーネント → MDM
    • 既定のAzure AD資格情報を使用して自動のMDM登録を有効にします : 有効

4. デバイスにてハイブリッド参加

グループポリシーの適用のため、デバイスを再起動しておく。

ハイブリッド参加の確認は、dsregcmdコマンドを用いて実施する。以下★箇所がYESになっていれば問題ない。なお、EnterpriseJoinedは「オンプレAD FSによる参加」の状態を示す項目となり、ハイブリッド参加の場合は、NOのままで問題ない。

PS C:\> dsregcmd /status

+----------------------------------------------------------------------+
| Device State                                                         |
+----------------------------------------------------------------------+

             AzureAdJoined : YES ★
          EnterpriseJoined : NO
              DomainJoined : YES ★
                DomainName : TEST
           Virtual Desktop : NOT SET
               Device Name : DESKTOP-E05C3GD.test.local

もし登録されていない場合は、以下コマンドで登録を試みる。エラーが出る場合は、トラブルシュートが必要となるが、内容によるのでここでは割愛する。

PS C:\> dsregcmd /debug /join

最後に、Entra管理センターでも、対象のデバイスの状況を確認する。Entra管理センターの「デバイス」>「すべてのデバイス」にて対象のデバイスを確認し、「参加の種類」が「Microsoft Entra hybrid joined」となっていればOKとなる。

参考

2024年11月7日木曜日

DELL周辺機器レビュー③ (Dell Bluetooth®トラベル マウス – MS700)

Dell Technologies Japan様(@DellTechJapan)の「【A】テレワークを快適にする周辺機器セット」のモニタープレゼントに当選し、以下3つの製品を提供いただいた。

それぞれの使用感をレビューしたいと思う。本記事ではDell Bluetooth®トラベル マウス – MS700 のレビューを記載する。

「Dell Bluetooth®トラベル マウス – MS700」レビュー

大きさなど

本マウスは単4電池 x 2本必要となる。動作確認用として電池付きなのがありがたい。



電池の蓋はマグネット式になっており、電池が落下しないようストッパーが付いている。

大きさは通常のマウスと同じくらいの大きさとなる。手元のマウスと比べてみると、若干薄い程度でほぼ同じ大きさとなっていた。

本体を捻ることで電源ON/OFFができる

このマウスの特徴として、本体を捻ることで電源ON/OFFができる。

通常の使用時は普通のマウスと同じ程度の厚みがある。

本体を捻り電源をOFFにすると、薄くコンパクトになる。そのため、持ち運び時にかさばることがない。

また、電源OFFの状態からONの状態に戻すと、すぐにPCでマウスが認識されるため、認識待ちなどでストレスを感じることはなく使用することができた。

マウスホイール

マウスホイールはホイール式ではなく、タッチセンサー式となっている。スクロール時の動かし方はホイールとは同じではあるが、物理的なホイールがないことで最初は違和感を感じる可能性がある。ただ、慣れればホイールと遜色なく操作はできそうだ。

総評

Dell EcoLoop Pro バックパック 15 の総評として、メリット・デメリットを以下にまとめる。

メリット

  • 電源ON時は、通常のマウスと同じ程度の厚みがあり、マウス操作時に違和感を感じにくい。
  • 電源OFF時は、本体が薄くなりコンパクトになる。

デメリット

  • マウスホイールがタッチセンサー式となるため、慣れるまではスクロール操作に違和感を感じる可能性がある。
2024年11月5日火曜日

DELL周辺機器レビュー② (Dell EcoLoop Pro バックパック 15)

Dell Technologies Japan様(@DellTechJapan)の「【A】テレワークを快適にする周辺機器セット」のモニタープレゼントに当選し、以下3つの製品を提供いただいた。

それぞれの使用感をレビューしたいと思う。本記事ではDell EcoLoop Pro バックパック 15 のレビューを記載する。

「Dell EcoLoop Pro バックパック 15」レビュー

大きさと容量

大きさとしては幅31cm x 高さ44cm x 奥行17cmとなっており、重量は660gとなる。第一印象としては奥行きがスリムで非常に軽く、ノートPCや周辺機器などを十分に入れるだけの容量があるか心配になるほどだった。

実際は、十分な容量があり、ノートPC、マウス、ヘッドセットに加え、モバイルバッテリーやケーブル類など、通勤や客先移動時に必要な仕事道具を問題なく収納して持ち運ぶことができる(さらに、季節的に薄手の上着ぐらいなら問題なく収納できた)。

また、ペットボトル用のメッシュ状の収納ポケットが左右にあり、折りたたみ傘、ペットボトルの飲み物なども、バックパックの中に入れることなく持ち運ぶことができる。

収納スペース

背中側からPC収納スペース、周辺機器収納スペース、小物類収納スペースの大きく3つの区画に分かれている。

面白い点として、キーボードやヘッドセットといったマークが収納スペースに貼り付けてあった。マークに従い、周辺機器収納スペースには、ヘッドセットなどを入れ、小物類収納スペースにはマウスやその他財布などを収納すると、仕事道具を整理して収納することができる(当然自分好みで収納場所は変えてもよい)。

PC収納スペース

一番背中側のPC用スペースは、15.6インチまでのPCに対応しており非常に広いスペースが確保されている。写真は13インチのノートPCを入れた状態となるが、見ての通りスペースには余裕があり、追加でモバイルモニターなども収納できそうだ。

背中側

背中側はメッシュ状のクッション素材となっており、夏場などで背中が熱くなる際も、蒸れにくくなりそうだ。また、スーツケース用のストラップも付いている。

総評

Dell EcoLoop Pro バックパック 15 の総評として、メリット・デメリットを以下にまとめる。

メリット

  • 一見コンパクトながら、十分な容量を備える。満員電車などでも邪魔になりにくい。
  • PCを常に持ち運ぶような働き方を想定した収納スペースを備えており、周辺機器を整理した状態で持ち運ぶことができる。
  • 金額もリーズナブル(6,780円)

デメリット

  • 特に大きなデメリットはないが、強いて言えば、技術書などで分厚い本などを入れようとした場合、収納場所を工夫する必要があるかもしれない。
2024年11月4日月曜日

DELL周辺機器レビュー① (Dell Pro 有線 ANC ヘッドセット – WH5024)

Dell Technologies Japan様(@DellTechJapan)の「【A】テレワークを快適にする周辺機器セット」のモニタープレゼントに当選し、以下3つの製品を提供いただいた。

それぞれの使用感をレビューしたいと思う。本記事ではDell Pro 有線 ANC ヘッドセット – WH5024のレビューを記載する。

「Dell Pro 有線 ANC ヘッドセット – WH5024」レビュー

音声とマイクについて

本ヘッドセットは、無線ではなく有線接続専用のヘッドセットとなる。無線でないためヘッドセットを付けながら動き回るといったことはできないが、ヘッドセット自体はバッテリーなどが搭載不要であることから、軽量になっている印象となる(その代わり、ケーブル分の重量は増えてしまうが)。

数日使ってみたが、音声やマイクの性能は十分で、Web会議で相手の音や自分の音が聞こえにくいということはなかった。また、ANC(アクティブノイズキャンセリング)がよい感じに周りの音を減少してくれるので、オフィスなどで多少周りが騒がしい環境であっても、問題なくWeb会議ができそうだ。

収納ケース

収納ケースが付いており持ち運び時に有線ケーブルが散らからず、便利になっている。

イヤーパッド

イヤーパッドはクッション性が十分にあり、長時間使用しても耳が痛くなりにくくなっている。また、アーム部分が耳の角度に応じて回転するため、きちっと耳にフィットする。

有線ケーブルとコントローラー

無線ではなく有線となり、いわゆるイヤホンプラグではなくUSBケーブルによる接続となる。USBはType-CだけでなくType-Aへの変換コネクターが付属している。

コントローラーが付いており、手元でマイクミュートのON/OFFや音量調整ができる。Web会議などで相手の環境の音が小さく、音量を上げたい場合などにおいて手元ですぐに音量調整できるのはありがたい。

「Dell Peripheral Manager」による細かな管理

USB接続をすると、Windows 11においては自動的に「Dell Peripheral Manager」のインストールが求められる。本ソフトウェアを用いることで、ヘッドセットの細かな設定ができるようになるため、特に問題がなければインストールした方が便利だろう。

なお、本ヘッドセットはマイクON/OFF時に音声ガイダンスで案内がされるのだが、ガイダンスがWeb会議中の会話と干渉するため、人によっては音声ガイダンスをOFFにしたい場合もあると思われる(私がそうだった)。本ソフトウェアを用いることで、音声ガイダンスのON/OFFが設定可能となる。

総評

Dell Pro 有線 ANC ヘッドセット – WH5024の総評として、メリット・デメリットを以下にまとめる。

メリット

  • イヤーパッドのクッション性が高く、アーム部分も稼働することで長時間のWeb会議でも痛くなりにくい。
  • 手元にコントローラーがあり、簡単にマイクON/OFFや音量調整ができる。
  • ANCが優秀で多少騒がしい環境でもWeb会議ができる。
  • 「Dell Peripheral Manager」で音声ガイダンスを無効化などの細かな設定ができる。

デメリット

  • 有線接続なので使用中に席を離れることができない。
  • 音声ガイダンスを無効に知るとANCのON/OFFの状態が判断しづらい。

人気の投稿