SAML認証のトラブルシューティング

はじめに

SplunkでSAML認証を利用していると、ログイン時に次のようなエラーが表示されることがあります。

1. Verification of SAML assertion using the IDP's certificate provided failed. Error: failed to verify signature with cert
   
2. Saml response does not contain group information.
   

1つ目は、IdP (Identity Provider)から送られてきたSAMLレスポンスの署名検証に失敗したことを意味します。

2つ目は、SAML Responseに含まれるグループ情報をSplunkがロールに結びつけられなかったことを意味します。

代表的な原因としては、例えば次のようなものが考えられます。

• IdP (Identity Provider)側でSAML証明書がローテーションされたが、Splunk側に新しいメタデータが反映されていない
• SAMLレスポンスの<X509Certificate>に含まれる証明書と、Splunkが信頼している証明書が一致していない
• IdP側の構成ミス(想定外の証明書で署名されている、など)
• SAML Responseにgroupsクレームは入っているが、Splunk側のRole alias / SAML Groups設定と噛み合っていない

SAMLのIdPとしてはOkta、OneLogin、PingFederateなど様々な製品を利用できますが、本記事では Microsoft Entra IDを具体例として 設定例やSAMLResponseの中身を紹介します。なお、本記事中の画面キャプチャはSplunk Cloudを用いていますが、切り分け手順や確認観点はSplunk Enterprise環境でも同様に有効です。

ここで扱う「クレーム(claim)」は、SAML / OAuth2全体で使われる一般的な概念です。本記事では、IdPから送られてくるユーザー属性(メールアドレスやグループなど)を、SAMLの用語に合わせて「クレーム(claim)」と呼びます。

他のIdPをご利用の場合も、

「IdP側でどのクレーム（属性）が構成されているか」→「SAMLResponseにどう出てくるか」→「Splunk側でどう解釈されるか」

という考え方・流れは共通ですので、自環境に置き換えてご覧いただければと思います。

本記事では、こうしたSAMLに関するエラーが出たときに以下3つの観点で、切り分け手順をまとめます。

1. ブラウザの開発者ツールからSAMLResponseを取得する
2. SAMLResponse内のAttribute / X.509証明書を確認する
3. 証明書の有効期限・一致状況をopensslでチェックする

1. ブラウザの開発者ツールからSAMLResponseを取得する

まずは、Splunkに届いているSAMLResponseの中身を実際に確認します。

1. エラーが再現するブラウザで、開発者ツール(DevTools)を開きます。

   • Chrome / Edge: F12 → Networkタブ

2. Networkタブを開いた状態で、SAMLユーザーでSplunkへのログインを試みます。

3. https://<Splunk Server URL>/saml/acsへの POSTリクエスト を探します。

4. 該当リクエストを選択し、Payloadタブを開きます。

5. SAMLResponseというフィールドに、Base64エンコードされた長い文字列が入っているので、これをコピーします。
   例）SAMLResponse（一部）

   PHNhbWxw...
   

2. SAMLResponseをデコード・整形して中身を確認する

コピーしたSAMLResponseを、コマンドラインでデコードしてXMLとして整形します。

Linux / macOS / WSL環境などで：

$ echo 'PHNhbWxw...（省略）...' \
  | base64 -d \
  | xmllint --format - 2>/dev/null

これで、きれいにインデントされたSAMLResponseが表示されます。

確認したい主なポイントは次の3つです。

1. <Issuer> (IdPのエンドポイント)
2. <AttributeStatement>内のAttribute / AttributeValue (クレーム)
3. <Signature> → <KeyInfo> → <X509Certificate>

3. Attribute名・値が想定通りか(IdP側のクレーム設定と突き合わせ)

今回のIdP側の設定例は次の通りです。

3-1. IdPの「属性とクレーム」設定例(Entra ID)

※本節の設定は、執筆時点のMicrosoftEntra IDの画面に基づく一例です。最新の推奨設定については、各IdPベンダーの公式ドキュメントを参照してください。

必要な要求

• クレーム名：一意のユーザー識別子 (NameID)
• 種類：SAML
• 値：user.userprincipalname
• フォーマット：nameid-format:emailAddress

追加の要求

3-2. SAMLResponseとの突き合わせ

xmllintで整形したSAMLResponseの中に、例えば次のようなブロックがあるかを確認します。

<Subject>
 <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
  samltest@XXXXX.onmicrosoft.com
 </NameID>
...
</subject>
<AttrobuteStatement>
...
<Attribute Name="http://schemas.microsoft.com/identity/claims/displayname">
 <AttributeValue>samltest</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.microsoft.com/ws/2008/06/identity/claims/groups">
 <AttributeValue>groupid</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">
 <AttributeValue>samltest@XXXXX.onmicrosoft.com</AttributeValue>
</Attribute>
... 
</AttributeStatement>

ここで確認したいのは：

• Attribute NameがEntra側設定と一致しているか
  groups、name 、emailaddressなど
• 値が期待通りか
  UPN、メールアドレス、Group Object IDなど

この時点で、IdPから送られてくるSAMLの中身自体は正しいかを切り分けられます。

• 「Verification of SAML assertion〜」の場合：

  • Attributeが正しくても署名検証で失敗するなら、「証明書」側を確認する

• 「Saml response does not contain group information.」の場合：

  • groups Attributeがあるか／値が期待通りかが特に重要

4. SAML Response内のX.509証明書を確認する

署名検証エラー(failed to verify signature with cert)の場合、重要なのはどの証明書で署名されているかです。これはSAMLResponse内の<Signature>セクションから確認できます。

SAMLResponseから、次のようなブロックを探します。

<Signature xmlns=>
  ...
  <KeyInfo>
   <X509Data>
    <X509Certificate>MIIC8D...</X509Certificate>
   </X509Data>
  </KeyInfo>
</Signature>

以降では、<X509Certificate>部分(Base64)を環境変数X509_CERTIFICATEに入れて、opensslで確認します。

5. opensslで証明書の有効期限と一致状況を確認する

5-1. 証明書の有効期限を確認する

# X509_CERTIFICATE変数にBase64文字列をセットした前提

$ echo "$X509_CERTIFICATE" \
  | base64 -d \
  | openssl x509 -inform der -noout -dates 

notBefore=Feb 16 05:13:11 2023 GMT
notAfter=Feb 20 04:28:54 2025 GMT

• notAfterが すでに過去 になっていれば、IdP署名証明書が期限切れの状態です。
  今回、「Verification of SAML assertion using the IDP's certificate provided failed. Error: failed to verify signature with cert」というエラーについては、証明書のnotAfterが過去日付となっており、有効期限切れであることが確認できます。IdP側でSAML署名証明書を新しい証明書に更新し、そのメタデータをSplunk側に反映することで、エラーは解消されます。
  

5-2. 指紋(拇印)を確認する

```
$ echo "$X509_CERTIFICATE" \
  | base64 -d \
  | openssl x509 -inform der -noout -fingerprint -sha1
SHA1 Fingerprint=12:34:56:78:AB...

この値を、Entra IDの「拇印(Thumbprint)」の証明書と比較します。

よくあるパターン

• IdP側でSAML署名証明書をローテーションしたが、新しいFederation Metadata XMLをSplunkにインポートしていない

• その結果：

  • IdP：新証明書で署名
  • Splunk：旧証明書を信頼
    → 署名検証に失敗し、本文のエラーになる

6.「 Saml response does not contain group information.」を調査するときの追加チェック

同じSAMLResponseから、グループ情報の有無も確認できます。

6-1. groups Attributeが入っているか

AttributeStatementに、次のようなブロックがあるかを確認します。

<Attribute Name="http://schemas.microsoft.com/ws/2008/06/identity/claims/groups">
 <AttributeValue>groupid-1</AttributeValue>
 <AttributeValue>groupid-2</AttributeValue>
 <AttributeValue>groupid-3</AttributeValue>
</Attribute>

• ここにGroup Object ID (GUID)が入っていれば、IdPからはグループ情報が送られていることが分かります。
• Attributeが存在しない場合は、Entra側のクレーム設定(user、groups)を見直す必要があります。

6-2. Splunk側のRole aliasとSAML Groups

SAMLResponseにgroupsが入っているのにエラーになる場合は、Splunk側設定との噛み合わせを確認します。

1. Role alias (SAML設定 → Aliasセクション)

   Role alias = http://schemas.microsoft.com/ws/2008/06/identity/claims/groups
   

   この設定で、SplunkはEntra IDのgroupsクレームをロール決定用のグループ情報として認識します。

2. SAML Groups（Group Name → Roleマッピング）

   • SAMLResponseに含まれるGroup Object ID (例：12345-6789)を、SAML Groupsの Group Name として登録
   • そのGroupに対してuserなどのSplunkロールを割り当てる

この登録が漏れていると、SAMLResponseにgroupsは存在していても、Splunk側で有効なロールに変換できず、「Saml response does not contain group information.」が発生します。

今回のケースでは、SAMLResponseに含まれていたGroup Object IDがSAML GroupsのGroup Nameとして登録されていないユーザーでログインしたため、このエラーが発生していました。

7. まとめ(トラブルシューティングの流れ)

本記事で扱った以下2種類のエラーはいずれも、SAMLResponseを実際に見て中身を確認することで、切り分けることができます。

1. Verification of SAML assertion using the IDP's certificate provided failed. Error: failed to verify signature with cert

2. Saml response does not contain group information.

チェックフローとしては、次のように整理できます。

1. ブラウザのDevToolsからSAMLResponseを取得する

2. Issuer / Attribute (クレーム) / Signature / groupsを確認する

3. <X509Certificate>を取り出し、opensslで有効期限、fingerprint、Issuerなどを確認する

4. IdP側のSAML署名証明書設定と比較し、

   • 証明書が期限切れかどうか
   • Splunkが取り込んでいるメタデータと一致しているかどうかを切り分ける

5. groups Attributeの有無・値を確認し、

   • Entraの「属性とクレーム」（user.groups）と一致しているか
   • Splunk側のRole alias / SAML Groups設定と噛み合っているかを確認する

この一連の手順により、

• 「IdP側の証明書の問題なのか」
• 「Splunk側のメタデータやRole aliasの問題なのか」
• 「どの証明書・どのグループ情報でSAMLが動いているのか」

を具体的に確認できるようになります。

本記事の内容は、あくまで代表的な構成を前提とした一例ですが、SAMLトラブル発生時に「何を確認し、どの順番で進めるべきか」を検討する際の参考情報としてご活用いただければ幸いです。