さっしーの試してみるか3: Active Directory Certificate Service

ラベル Active Directory Certificate Service の投稿を表示しています。すべての投稿を表示

2025年12月14日日曜日

Windows Server ＆ Cloud User Group Japan 第48回勉強会セッション動画「ADDSとADCSのローリングアップグレード」

2025年12月7日日曜日

Windows Server ＆ Cloud User Group Japan 第48回勉強会セッション資料「ADDSとADCSのローリングアップグレード」

ADDSとADCSのローリングアップグレード_ADDS and ADCS Rolling Upgrade by @sshzk

2025年6月30日月曜日

Windows Server Summit 2025のオンデマンドビデオが公開されています。

2025年4月に開催されたWindows Server Summit 2025のオンデマンドビデオが公開されています。

Windows Server Summit 2025

Windows Server 2025だけではなく、AD、AD CS、WAC、Azure Arc、Azure File Syncなどのセッションがありますよ。

2025年2月2日日曜日

Active Directory Certificate ServiceのCA情報などを表示する

検証でAD CSを作るたびにCAの情報をコマンドでダンプしなきゃと思うわけです。いつもやり方を忘れるため、概要を残しておきます。

まず、certutil -cainfo を実行してCAの情報を見ます。

スタンドアロンCAとして構築したことが確認できました。

続いて、

certutil -getreg CA\ValidityPeriod

certutil -getreg CA\ValidityPeriodUnits

を実行して証明書の有効期間を見ます。

5年で設定したことが確認できました。

※なお証明書の有効期間設定に関しては、下記のコマンドにより、証明書サービスの再起動が必要です。
net stop certsvc
net start certsvc
証明書の有効期間設定に関する公式情報は、
証明機関によって発行される証明書の有効期限を変更する
となります。

続いてルートCA証明書の確認です。

※なおルートCA証明書自体は、グループポリシーにてADドメインへ配布するよう設定したことを申し添えます。

GUI上は、下記のダイアログで確認できます。

コマンドで確認するためには、証明書ストアのキーワードが必要なので、 Get-ChildItem Cert:\LocalMachine\ で一覧を取得します。

信頼されたルート証明機関は、Rootなのでさらにそこを深掘りします。Get-ChildItem Cert:\LocalMachine\Root\ を実行して、信頼されたルート証明機関に含まれる証明書の一覧を表示します。

今回構築したルートCAのルートは赤枠のものです。

Get-ChildItem "Cert:\LocalMachine\Root\" |fl

にて、各証明書のプロパティを表示させました。

ルートCA証明書は、2/2/2030 11:18:47 AMまでの有効期間であることがわかります。

以上、簡易ではありますが確認方法をまとめました。

2025年2月11日は、「KB5014754: Windows ドメインコントローラーでの証明書ベースの認証の変更」にご注意ください

胡田(えびすだ)のコンピューター系チャンネル

を拝見していたら、

【AD】時間切れ目前！2025/2/11までに対策必須！ID39警告を無視するとヤバい理由【緊急対策】

がありました。こちら、実際の症状としてイベントID観点で解説されていますね。

実は、当方も同じような記事を書いていますw

複数フェーズで成り立つ「Active Directoryの脆弱性対策」とは――その意図は？　詳細は？
※閲覧には、無料の会員登録が必要です。

です。この中で、「証明書認証に影響する脆弱性対策」を解説しており、2025年2月11日というのは「完全強制フェーズ」の更新プログラム（パッチ）がリリースされる日となっています。こちらの更新プログラムは、

KB5014754: Windows ドメインコントローラーでの証明書ベースの認証の変更

にて情報提供されているものです。この脆弱性に関しては、2022年5月10日から4フェーズを経て完全強制になります。このフェーズを図示したものが下記となります。

ということで、複数フェーズによる脆弱性対策が必要になることから、定期的なパッチ適用が肝要ということです。

2024年12月10日火曜日

EDITF_ATTRIBUTESUBJECTALTNAME2を有効化しないで、SAN属性ありの証明書を発行しましょう

従来、

といった記事で、EDITF_ATTRIBUTESUBJECTALTNAME2を有効化して、SAN属性ありの証明書を発行していました。が、

How to Request a Certificate With a Custom Subject Alternative Name

※セキュリティで保護された LDAP 証明書にサブジェクトの別名を追加するから上記にリンク有ります。

という公式情報があるよと同僚から教えてもらいました。上記リンクから文面引用するとEDITF_ATTRIBUTESUBJECTALTNAME2を有効化するのはリスク有とのこと。。。

警告
Adding a SAN attribute to the RequestAttributes section of RequestPolicy.inf also requires that the CA is configured to accept SAN attributes by enabling EDITF_ATTRIBUTESUBJECTALTNAME2, which can put your PKI at risk for impersonation attacks.
Whenever possible, specify SAN information by using certificate extensions instead of request attributes to avoid enabling EDITF_ATTRIBUTESUBJECTALTNAME2.
Do not enable EDITF_ATTRIBUTESUBJECTALTNAME2 on an enterprise CA.
For more information about risks and mitigations, see Security best practices for allowing SANs in certificates.

じゃあ、どうするのということで、

How to Request a Certificate With a Custom Subject Alternative Name

を何度も読み返しました。結果、To create a RequestPolicy.inf file の内容を編集すればよいことに気づきました。上記文面でその該当箇所を太字で強調してみました。

To create a RequestPolicy.inf file の内容を抜粋すると、

[Extensions]
; If your client operating system is Windows Server 2008, Windows Server 2008 R2, Windows Vista, or Windows 7
; SANs can be included in the Extensions section by using the following text format. Note 2.5.29.17 is the OID for a SAN extension.
2.5.29.17 = "{text}"
_continue_ = "dns=www01.fabrikam.com&"
_continue_ = "dn=CN=www01,OU=Web Servers,DC=fabrikam,DC=com&"
_continue_ = "url=https://www.fabrikam.com&"
_continue_ = "ipaddress=172.31.10.134&"
_continue_ = "email=hazem@fabrikam.com&"
_continue_ = "upn=hazem@fabrikam.com&"
_continue_ = "guid=f7c3ac41-b8ce-4fb4-aa58-3d1dc0e36b39&"

この内容から、

[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=www01.fabrikam.com"

だけにすればよい感じでした。実際に試した要求用テキストファイルは、下記の通りです。;がコメントアウトの箇所で、SAN属性はコメントアウトしました。

[NewRequest]
Subject = "CN=contosowac2.contoso.local"
Exportable = TRUE
KeyLength = 2048
KeySpec = 1
KeyUsage = 0xA0
MachineKeySet = True
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = CMC
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1
[Extensions]
;https://learn.microsoft.com/ja-jp/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff625722(v=ws.10)#security-best-practices-for-allowing-sans-in-certificates
; If your client operating system is Windows Server 2008, Windows Server 2008 R2, Windows Vista, or Windows 7
; SANs can be included in the Extensions section by using the following text format. Note 2.5.29.17 is the OID for a SAN extension.
2.5.29.17 = "{text}"
_continue_ = "dns=contosowac2.contoso.local"
[RequestAttributes]
;SAN="dns=contosowac2.contoso.local"
; ???Enterprise CA ??
CertificateTemplate = WebServer

証明書は、EDITF_ATTRIBUTESUBJECTALTNAME2を無効化した状態

certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc

で発行しました。問題無く、使用できました。

ここまで調べたり試したりしたところで、

AD CS で SAN (サブジェクトの別名) を追加するリスク

という記事があるのを知りました。ということで、EDITF_ATTRIBUTESUBJECTALTNAME2の有効化は今後止めていきたいですね。

2024年8月4日日曜日

Windows Admin Center (v2) Public Preview build has been updated! で証明書の差し替えはどうなった？

インストールウィザードを使う従来のやり方ではダメなようです。プログラムと機能には、アンインストールしか表示されません。。。

PowerShell Moduleは、いくつか使えそうです。

Configrationフォルダー内を見てみたら、Update-WACClusterNodeConfiguration.ps1があります。改めてクラスター対応を図るつもりなのかもしれないですね。

"C:\Program Files\WindowsAdminCenter\PowerShellModules\Microsoft.WindowsAdminCenter.Configuration\Microsoft.WindowsAdminCenter.Configuration.psm1"
"C:\Program Files\WindowsAdminCenter\PowerShellModules\Microsoft.WindowsAdminCenter.ManagementTools\Microsoft.WindowsAdminCenter.ManagementTools.psm1"
"C:\Program Files\WindowsAdminCenter\PowerShellModules\Microsoft.WindowsAdminCenter.PowerShellTools\Microsoft.WindowsAdminCenter.PowerShellTools.psm1"

をインポートしてみました。証明書関連のコマンドレットなどを探してみます。

# Get-Command の出力を取得し、特定の文字列を含むコマンドをフィルター
$filteredCommands = Get-Command | Where-Object { $_.Source -like "*WindowsAdmin*" }| Where-Object { $_.Name -like "*certificate*" }
# フィルター結果を表示
$filteredCommands

CommandType Name Version Source

----------- ---- ------- ------

Function Add-WACCertificates 0.0 Microsoft.WindowsAdminCenter.Configuration

Function Get-WACCertificateSubjectName 0.0 Microsoft.WindowsAdminCenter.Configuration

Function Get-WACSelfSignedCertificate 0.0 Microsoft.WindowsAdminCenter.Configuration

Function Import-WACBuildSignerCertificate 0.0 Microsoft.WindowsAdminCenter.Configuration

Function New-WACSelfSignedCertificate 0.0 Microsoft.WindowsAdminCenter.Configuration

Function Remove-WACSelfSignedCertificate 0.0 Microsoft.WindowsAdminCenter.Configuration

Function Set-WACCertificateAcl 0.0 Microsoft.WindowsAdminCenter.Configuration

Function Set-WACCertificateSubjectName 0.0 Microsoft.WindowsAdminCenter.Configuration

Get-WACCertificateSubjectNameを実行してみました。インストール時の自己署名証明書のみですね。

あてずっぽうで、Set-WACCertificateSubjectNameに生成した証明書のサブジェクトを指定してみた。証明書は置き換わったようだ。

では、Webブラウザからアクセスしてみるとどうなのか？まだ置き換わっていなかった。

Windows Admin Centerのサービスを再起動してみます。

サービス再起動後しばし待ちます。

しばらく経過後、サービスが落ちてる。。。

サービス起動後もしばらくたつとサービスが止まってます。

自己署名証明書に戻して、サービス起動してみましょう。元通りになりました。

おそらくサブジェクトの指定方法がまずいような気がしますが、さて。。。

公式情報が無いので、これ以上の探索はいったん止めておきます。プレビュー時点では、最初に証明書を用意しておいたほうが良さそうですね。従来通りGUIで証明書を差し替えるのか、PowerShellによって証明書を差し替えるのかは、GAされた後に改めて確認します。

とおもったのですが、PowerShellモジュールのサンプルをのぞいてみることに。

CNのみや、拇印でも行けそう。CNのみで試してみます。

しばらく待つとサービス落ちる。

拇印で指定してみます。

しばらく待ってみたが、サービス落ちてない。

Test-NetConnection -port 443 g2ws2022wacpv2.sshzk2016.local　も疎通しています。

なかなか画面が開かない。。。

自己署名証明書に戻しました。サービス再起動後でもすぐに画面開きますね。

証明書要求の書式が良くないのだろうか。
※書式自体は、従来のWindows Admin Centerで利用していたものを流用しています。

2022年10月10日月曜日

Hyper-V VMの仮想TPM用証明書をフェールオーバークラスターの全ノードに配置する

またひとつ、勉強になった件。

とある理由により、仮想マシンにWindows 11 Enterpriseを入れたわけです。Windows 11は、TPMが必要なので、仮想マシンハードウェアで仮想TPMを有効化しました。

で、これらの仮想マシンは、Azure Stack HCI OSによるAzure Stack HCIクラスターで動作しています。

この仮想マシン群が、うまくライブマイグレーションしないことに気づきました。
フェールオーバークラスターマネージャーでイベント出てます。

当該Hyper-Vノードのイベントログにもちらりほらりとイベントが出ています。

で、色々見ていく中で、下記のイベントを見つけました。

イベントID 24008, Microsoft-Windows-Hyper-V-VMMS

The version of the device 'Microsoft Virtual TPM Device' of the virtual machine 'g2w11e02' is not compatible with device on physical computer 'CONTOSOAX64001'. (Virtual machine ID 8A7E2A27-631D-4038-9993-40BCED805E48)