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

システム イベント(ソース：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 認証は拒否されるようになります。

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

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

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

関連記事

【Windows】証明書を利用した認証における脆弱性の対処について

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

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

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

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

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

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

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

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

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

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

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

イベント 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)

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

イベント 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 拡張が付与された証明書を発行

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

対処策

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

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

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

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

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

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

1. 証明書の情報の確認

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

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

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

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

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

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

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

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

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

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

②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 で証明書を行う場合、[証明書の登録ウィザード] で証明書を発行要求を送信できますが、コンピューター証明書の発行要求は証明書を利用するコンピューター上で、ユーザー証明書の発行要求は証明書を利用するユーザーが発行要求を行ってください。