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となる。

参考

人気の投稿