【解決方法】システム イベント ID 39,40,41,48,49について

PKI

システム イベント(ソース:Kerberos-Key-Distribution-Center) ID 39、40、41、48、49は、証明書を利用した Kerberos 認証で問題があったことを示すイベント ログです。今回は、ID39、40、41、48、49 のイベント ログの意味や必要な対処策について紹介します。

 

証明書を利用した Kerberos 認証の脆弱性について

ドメイン コントローラー(Kerberos Distribution Center(KDC) サービス)で、証明書を利用した Kerberos 認証の要求を受け取った時に、なりすましによる特権昇格の脆弱性が発見されました。この脆弱性は、CVE-2022-34691、CVE-2022-26931 と CVE-2022-26923 の ID で管理されています。

これまで、証明書を利用した Kerberos 認証の処理において、コンピューター名の末尾の ‘$’ は考慮されていませんでした。これが要因で、なりすましで認証に通ることが可能でした。また、ユーザー プリンシパル名(UPN) と sAMAccountName の競合を利用した、他のなりすましを行うことができる脆弱性も確認されております。

この脆弱性の対処として、証明書を利用した Kerberos 認証の処理に対してセキュリティ強化が行われます。このセキュリティ強化では、認証の処理において認証対象となるアカウントと証明書のマッピングの有無を確認する処理が追加されます。この変更により、認証対象のアカウントと証明書のマッピングがない Kerberos 認証は拒否されるようになります。

 

脆弱性の対処の第1段階として、2022 年 5 月にセキュリティ更新プログラム(KB5014754)が公開されました。この更新プログラムをドメイン コントローラーに適用すると、以下のイベント ID が追加されます。以下のイベント ID のいずれかが記録されたら、マッピング情報がない証明書で Kerberos 認証が行われていることを意味します。これは、2023 年 11 月以降に公開される予定のセキュリティ更新プログラムの適用すると、Kerberos 認証が拒否されるようになることが想定されます。

 

KB5014754 で追加されたイベント ログ
 イベント ID 39、40、41、48、49

 

そのため、ご利用のドメイン環境のドメイン コントローラーに上記のいずれかのイベント ログが記録されている状況であれば、2023 年 11 月までを目途に、認証対象のアカウントと証明書のマッピングの作業を完了させる必要があります。

今回の脆弱性の対処(KB5014754)の詳細については、以下の記事でも紹介しております。

関連記事

ドメイン コントローラーでの証明書を利用した Kerberos 認証に関して、なりすましによる特権昇格の脆弱性が確認されました。 この脆弱性の影響への対処として、証明書を利用した Kerberos 認証の処理に対してセキュリティ強化が行わ[…]

今回、追加された各イベントの意味、対処策について紹介します。

 

イベント ID 40 (Windows Server 2008 R2 は ID 48)

ドメイン コントローラーのシステム イベント ログにて、以下のログが記録されることがあります。

ログの名前: System
ソース: Microsoft-Windows-Kerberos-Key-Distribution-Center
イベント ID: 40
レベル: エラー
説明:
キー配布センター (KDC) で、有効なユーザー証明書が見つかりましたが、セキュリティで保護された方法でユーザーにマップできませんでした
(明示的なマッピング、キー信頼マッピング、SID など)。この証明書は、マップ先のユーザーの前に置かれたため、拒否されました。
詳細については、https://go.microsoft.com/fwlink/?linkid=2189925を参照してください。

User: <ユーザー プリンシパル名>
Certificate Subject: <証明書のサブジェクト名>
Certificate Issuer: <証明書の発行者>
Certificate Serial Number: <証明書のシリアル番号>
Certificate Thumbprint: <証明書の拇印>
Certificate Issuance Time: <証明書の有効期間の開始日>
Account Creation Time: <アカウントの作成日>

イベント ID 40 (Windows Server 2008 R2 の場合はイベント ID 48)は、アカウントにマッピングされていない証明書で Kerberos 認証にした場合に記録されます。認証に使用された証明書は、ユーザー アカウントやコンピューター アカウントよりも先に作成されています。

このイベント ログが記録されている場合、Kerberos 認証は失敗しています。認証に影響がでて、問題が発生している可能性があるため、ただちに対処策を実施してください。
 

イベント ID 40/48 の対処策

イベント ID 40/48 のエラー ログが記録された場合の対処策は以下の通りです。
  • ①アカウントの altSecurityIdentities 属性に証明書の情報を登録
  • ②OID 1.3.6.1.4.1.311.25.2 拡張が付与された証明書を発行

①の方法で、手動でマッピングを行うか、②の方法でマッピング情報がある証明書を発行します。①と②の詳細な手順は、こちらを確認してください。

 

イベント ID 39 (Windows Server 2008 R2 は ID 41)

ドメイン コントローラーのシステム イベント ログにて、以下のログが記録されることがあります。

ログの名前: System
ソース: Microsoft-Windows-Kerberos-Key-Distribution-Center
イベント ID: 39
レベル: ( 互換モード: 警告), ( 強制モード : エラー )
説明:
キー配布センター (KDC) で、有効なユーザー証明書が見つかりましたが、セキュリティで保護された方法でユーザーにマップできませんでした
(明示的なマッピング、キー信頼マッピング、SID など)。このような証明書は、明示的なマッピングを使用して置き換えるか、
ユーザーに直接マップする必要があります。詳細については、https://go.microsoft.com/fwlink/?linkid=2189925を参照してください。

User: <ユーザー プリンシパル名>
Certificate Subject: <証明書のサブジェクト名>
Certificate Issuer: <証明書の発行者>
Certificate Serial Number: <証明書のシリアル番号>
Certificate Thumbprint: <証明書の拇印>

イベント ID 39 (Windows Server 2008 R2 の場合はイベント ID 41)は、アカウントにマッピングされていない証明書で Kerberos 認証にした場合に記録されます。イベント ID 40 との差分は、認証に使用された証明書は、ユーザー アカウントやコンピューター アカウントよりも後に作成されています。

イベント ID 39/41 の対処策

イベント ID 39/41 のエラー ログが記録された場合の対処策は以下の通りです。
  • ①アカウントの altSecurityIdentities 属性に証明書の情報を登録
  • ②OID 1.3.6.1.4.1.311.25.2 拡張が付与された証明書を発行

①の方法で、手動でマッピングを行うか、②の方法でマッピング情報がある証明書を発行します。①と②の詳細な手順は、こちらを確認してください。

厳密に言うと、②については、OID 1.3.6.1.4.1.311.25.2 拡張がない証明書でも、現時点においては認証可能とはなりますが、後述するイベント ID 39 (Windows Server 2008 R2 の場合は ID 41) の警告ログが記録されます。また、2023 年 11 月以降(強制モードに移行)した後には認証はブロックされます。そのため、OID 1.3.6.1.4.1.311.25.2 拡張付きの証明書を再発行してください。

イベント ID 41 (Windows Server 2008 R2 は ID 49)

ドメイン コントローラーのシステム イベント ログにて、以下のログが記録されることがあります。

ログの名前: System
ソース: Microsoft-Windows-Kerberos-Key-Distribution-Center
イベント ID: 41
レベル: エラー
説明:
キー配布センター (KDC) は、有効なユーザー証明書を検出しましたが、マップ先のユーザーとは異なる SID を含んでいます。
その結果、証明書を含む要求が失敗しました。詳細については、https://go.microsoft.com/fwlink/?linkid=2189925を参照してください。

User: <ユーザー プリンシパル名>
User SID: <ユーザーの SID>
Certificate Subject: <証明書のサブジェクト名>
Certificate Issuer: <証明書の発行者>
Certificate Serial Number: <証明書のシリアル番号>
Certificate Thumbprint: <証明書の拇印>
Certificate SID: <証明書の OID 拡張に含まれている SID>

イベント ID 41 (Windows Server 2008 R2 の場合はイベント ID 49)は、Kerberos 認証に使用された証明書に OID 1.3.6.1.4.1.311.25.2 拡張が付与された証明書が使用されているものの、認証要求を行っているアカウントの SID と証明書の OID の拡張に記載されている SID が異なる場合に記録されます。

イベント ID 39/41 の対処策

認証を行ったアカウントと、証明書に記載されているアカウントの SID が異なるため、そもそも正しいユーザーが証明書を利用して Kerberos 認証を行っているのかご確認ください。正しいユーザーではない場合は、拒否されるべきであるため、特に対処は必要ありません。

もし、正しいユーザーが証明書を利用している場合は、以下の対処策を実施して、認証対象のアカウントと証明書のマッピングを行います。

  • ①アカウントの altSecurityIdentities 属性に証明書の情報を登録
  • ②OID 1.3.6.1.4.1.311.25.2 拡張が付与された証明書を発行

①の方法で、手動でマッピングを行うか、②の方法でマッピング情報がある証明書を発行します。①と②の詳細な手順は、こちらを確認してください。

 

対処策

認証要求を行うアカウントと証明書のマッピングは以下の2通りの方法があります。いずれかの方法で、マッピングの作業を行えば、今回の脆弱性の対応を行うことができます。

①アカウントの altSecurityIdentities 属性に証明書の情報を登録

ユーザー アカウントもしくはコンピューター アカウントに、そのアカウントが利用する証明書をマッピングします。具体的には、アカウントの altSecurityIdentities 属性に証明書に関する情報を登録します。

altSecurityIdentities 属性に登録する、証明書のマッピング情報の記述形式には複数の種類が用意されています。いずれの種類の記述形式で、証明書の情報を登録しても問題はありませんが、種類ごとにセキュリティの強度が異なっております。

マッピングの記述の種類 

記述形式 

セキュリティ強度 

注記

X509IssuerSubject 

“X509:<I>IssuerName<S>SubjectName” 

 

X509SubjectOnly 

“X509:<S>SubjectName” 

 

X509RFC822 

“X509:<RFC822>user@contoso.com” 

Email アドレス

X509IssuerSerialNumber 

“X509:<I>IssuerName<SR>1234567890” 

推奨

X509SKI 

“X509:<SKI>123456789abcdef” 

強 

 

X509SHA1PublicKey 

“X509:<SHA1-PUKEY>123456789abcdef” 

強 

 

セキュリティ強化が行われた後に、ドメイン コントローラーにて Kerberos 認証に成功するには、altSecurityIdentities 属性にセキュリティ強度が “強” となっている記述形式でマッピング情報が登録されている必要があります。マイクロソフトが推奨している記述の種類は “X509IssuerSerialNumber” となります。

X509IssuerSerialNumber のマッピング情報を登録するには、証明書の「発行者」と「シリアル番号」の情報が必要です。アカウントと証明書のマッピングの登録の手順は以下の通りです。

1. 証明書の情報の確認

ユーザー アカウントもしくはコンピューター アカウントと証明書をマッピングするために、マッピング情報の登録に必要な証明書の「発行者」と「シリアル番号」を確認します。アカウントが利用する証明書を開いて、[詳細] タブより「発行者」と「シリアル番号」を確認します。

 

上図の証明書の場合、「発行者」と「シリアル番号」は以下の通りとなります。

シリアル番号 ‎1d 00 00 00 06 66 82 bb 6a f3 5b 79 9b 00 00 00 00 00 06
発行者 CN=test01-TEST01DC01-CA,DC=test01,DC=local

 

2. 発行者のデータを加工

X509IssuerSerialNumber の記述形式でマッピング情報に含める発行者のデータは、証明書に記載されているデータを逆順で並べ替えたデータである必要があります。発行者の名前をカンマ(,)で区切り、逆順に並べ替えを行います。例えば、発行者名が A,B,C,D の場合は、D,C,B,A というように逆順に並べ替えをします。

上図の例の「発行者」を並べ替えをすると以下のようになります。

 

3. シリアル番号のデータを加工

X509IssuerSerialNumber の記述形式でマッピング情報に含めるシリアル番号のデータは、証明書に記載されているデータをバイトスワップ(1バイトずつ区切って逆順に並べること)します。

上図の例の「シリアル番号」をバイトスワップすると以下のようになります。

 

4. アカウントの altSecurityIdentities 属性にマッピング情報を登録

X509IssuerSerialNumber の記述形式に従って、成形したデータを当てはめると以下の通りとなります。

X509:<I>DC=local,DC=test01,CN=test01-TEST01DC01-CA<SR>0600000000009b795bf36abb66060000001d
X509IssuerSerialNumber の記述形式の証明書のマッピング情報を、対象のアカウントの altSecurityIdentities 属性に登録します。
1) 任意のドメイン コントローラーに管理者権限をもつユーザーでログオンします。
2) 管理者権限で PowerShell を開きます。
3) 以下の PowerShell のコマンドレットを実行して、対象のアカウントの altSecurityIdentities 属性にマッピング情報を登録します。
■ユーザー アカウントの場合
set-aduser ‘DomainUser’ -replace @{altSecurityIdentities=”X509:<I>DC=local,DC=test01,CN=test01-TEST01DC01-CA<SR>050000000000f7ec22653c7b2e13050000001d” }
 
■コンピューター アカウントの場合
set-adcomputer ‘Computer’ -replace @{altSecurityIdentities=”X509:<I>DC=local,DC=test01,CN=test01-TEST01DC01-CA<SR>050000000000f7ec22653c7b2e13050000001d”}

 

 

②OID 1.3.6.1.4.1.311.25.2 拡張が付与された証明書を発行

証明書にユーザー アカウントやコンピューター アカウントの情報をマッピングします。具体的には、証明書の 1.3.6.1.4.1.311.25.2” という項目に、AD アカウントの SID の情報を登録します。

証明書を発行するエンタープライズの証明機関に、2021 年 5 月以降のセキュリティ更新プログラム(KB5014754)を適用します。KB5014754 の更新プログラムは、発行する証明書に 1.3.6.1.4.1.311.25.2” という拡張項目を含めることができる機能を追加しております。

エンタープライズ CA は Active Directory と連携して動作するため、証明書の発行要求を行ったアカウントの情報も把握できます。そのため、証明書の発行要求がきたら、ドメイン コントローラーからアカウントの SID 情報を自動で入手して、”1.3.6.1.4.1.311.25.2” という拡張項目に含めた証明書を発行するという動作になります。

発行される証明書に 1.3.6.1.4.1.311.25.2” という拡張項目を含めるには、証明書の発行に利用する証明書テンプレートにて、[サブジェクト名] タブにて “Active Directory の情報から構築する” が有効になっている必要があります。この設定になっている証明書テンプレートを指定して証明書を発行すると、発行される証明書には、”1.3.6.1.4.1.311.25.2″ という OID の拡張機能に、証明書の発行要求を行ったアカウントの SID が追加されます。


エンタープライズ CA に KB5014754 を適用した後、”1.3.6.1.4.1.311.25.2″ という OID の拡張機能を含む証明書を再発行してください。


※ AD アカウントの SID の情報がマッピングされた証明書です。
“1.3.6.1.4.1.311.25.2” の拡張項目の値にアカウントの SID のデータが含まれております。

 

Kerberos 認証を行うアカウントがコンピューターである場合、コンピューター証明書を発行し、ユーザーである場合はユーザー証明書を発行します。エンタープライズ CA で証明書を行う場合、[証明書の登録ウィザード] で証明書を発行要求を送信できますが、コンピューター証明書の発行要求は証明書を利用するコンピューター上で、ユーザー証明書の発行要求は証明書を利用するユーザーが発行要求を行ってください。

 

(1) もしくは (2) のいずれかの方法で、アカウントと証明書のマッピング情報を登録しておけば、セキュリティ強化した後も Kerberos 認証はそのまま成功します。