2026.11.05 セキュリティ

SAML ADの構成手順：AD FSとEntra IDでSSOを張る設定と移行判断

Q: Entra IDのSAMLでsAMAccountNameをNameIDに使えますか？

利用可能です。ADの属性がEntra Connectで同期されていれば、NameIDの元属性に onpremisessamaccountname を選べます。クラウドだけで作った利用者にはこの値が無く、元属性が空のときはUPNが使われる、とMicrosoftのドキュメントにあります。クラウドの利用者が混ざる組織では、従業員IDなど全員が持つ属性を選ぶほうが安全です。

SAML ADの構成手順：AD FSとEntra IDでSSOを張る設定と移行判断

Active Directory（AD）の社員アカウントで自社の業務システムにSAMLでシングルサインオンさせるには、AD本体ではなく、AD FSかMicrosoft Entra IDをIdPとして間に置きます。この記事では、2つのIdPの違いを整理したうえで、Entra IDのエンタープライズアプリに設定する値、AD FSの証明書利用者信頼をPowerShellで登録する手順とクレーム規則の書き方を示す内容です。後半は、AD FSで動いているSAMLアプリをEntra IDへ移すときの棚卸し、移せない構成、切り替え日の作業順と、IdPのメタデータを確かめるPythonコードまで扱います。

まとめ：ADのSAML SSOは新規ならEntra ID、AD FSは移行前提

これから自社システムにSAML SSOを張るなら、IdPはEntra IDにします。ADの利用者とグループはMicrosoft Entra Connectで同期し、自社システムはエンタープライズアプリとして登録します。AD FSのサーバーを新しく建てる理由は、ほとんどの案件で見当たりません。

既にAD FSで動いているアプリは、Entra IDの移行ダッシュボードで「そのまま移せるもの」から順に移します。止まりやすいのは、AD以外の属性ストアを引くクレーム規則と、SAMLのArtifact解決に頼るアプリの2種類です。この2つが残る間だけAD FSを残し、それ以外は計画的に移して廃止します。

どちらのIdPでも、SP側に登録する値は発行者、サインインURL、署名証明書の3つです。切り替え日の失敗の多くは、この3つのうち1つを古いまま残したことが原因です。

Active DirectoryがSAML非対応の理由とAD FS・Entra IDの役割

SAMLの用語とフローはSAMLとは？認証フロー・IdP/SPの仕組みとOAuth・OIDCとの使い分けを実装視点で解説で扱っています。ここではADとSAMLの間に何が入るかに絞ります。

AD本体はKerberosとLDAPで認証しSAMLのIdPは別に立てる構成

ドメインコントローラーが社内で提供する認証は、KerberosとLDAPです。Webブラウザー越しに署名付きのSAMLアサーションを発行する機能は、AD本体にはありません。そのため「SAML AD」と呼ばれる構成は、実際には次のどちらかです。

オンプレミスにAD FSを建て、ADを属性ストアとして利用者を認証しアサーションを発行する
ADの利用者とグループをEntra IDへ同期し、クラウド側のEntra IDがアサーションを発行する

自社システムから見れば、どちらも「SAML 2.0のIdPが1つある」だけです。違いはIdPがどこで動き、誰が保守するかにあります。社内アプリがLDAPでADへ直接問い合わせる方式との違いはLDAPとは？仕組み・Active Directoryとの違いと認証実装をコード付きで解説で比べています。

AD FSとEntra IDをIdPの置き場所と保守の負担で比べた表

観点	AD FS	Entra ID
IdPの置き場所	社内のWindows Server	Microsoftのクラウド
ADとのつながり	ADを直接参照	Entra Connectで同期
SP登録の単位	証明書利用者信頼	エンタープライズアプリ
属性の加工	クレーム規則言語	管理画面の変換関数
多要素認証・条件	AD FSの規則と追加の認証方式	条件付きアクセス
サーバー保守	自社（冗長化・パッチ・証明書）	Microsoft

表の対応関係は、Microsoft LearnのSAMLベースのシングルサインオン：構成と制限事項にあるAD FSとEntra IDの設定の対応表に沿っています。Entra IDそのものの機能と料金体系はMicrosoft Entra ID（旧Azure AD）とは？読み方・ADとの違い・料金と始め方【2026年10月】を参照してください。

Entra IDのエンタープライズアプリで自社システムにSAMLを張る手順

Entra ID側の作業は、自社システムを「ギャラリー以外のアプリ」として追加し、シングルサインオンの方式にSAMLを選ぶところから始まります。前提として、ADの利用者とグループがMicrosoft Entra ConnectでEntra IDへ同期されている必要があります。

基本的なSAML構成の識別子と応答URLを自社システムの値にそろえる

エンタープライズアプリケーションのSAMLシングルサインオンを有効にする手順では、作業者にクラウドアプリケーション管理者、アプリケーション管理者、サービスプリンシパルの所有者のいずれかのロールを求めています。「基本的なSAML構成」で入れる値は次の3つです。

識別子（エンティティID）：自社システムのentityID。アサーションのAudienceに入る
応答URL（Assertion Consumer Service URL）：自社システムがSAMLResponseを受けるURL
サインオンURL：利用者が自社システムのログインを始めるURL。SP起点のログインで使う

識別子は1文字違えばAudienceの検証で弾かれます。末尾のスラッシュの有無まで、自社システムの設定と同じ文字列にしてください。なお、SAMLのSSOを構成できるのはシングルテナントのアプリかギャラリーのアプリだけで、マルチテナントのアプリでは設定欄が淡色表示になる、と同じ手順書に注記があります。

ADから同期した属性をNameIDとクレームに出すときの選び方

SAMLトークンクレームをカスタマイズする手順によると、Entra IDは既定でユーザープリンシパル名（UPN）をNameIDに入れ、メールアドレスと姓名もクレームとして送ります。自社システムの利用者IDがUPNと一致しないときは、NameIDの元になる属性を変えます。

選べる属性には、user.mail、employeeid、ADから同期したonpremisessamaccountname、拡張属性1〜15などがあります。旧来の業務システムが「ドメイン名なしのログインID」で利用者を持っているなら、onpremisessamaccountnameを選ぶか、UPNにExtractMailPrefix()を当ててドメイン部分を外します。1つのクレームに重ねられる変換は、最大2つまでです。

NameIDの形式は、SAML要求にNameIDPolicyがあればその指定が優先されます。指定が無いときに管理画面で選んだ形式が使われる、という順序です。形式の食い違いでログインが失敗したときの切り分けはSAML NameIDFormatとメタデータの不一致でSSOが失敗する原因の切り分けにまとめています。

自社システムへ登録する発行者・サインインURL・メタデータURL

逆方向、つまり自社システム側に登録するEntra IDの値は、テナントIDを埋めたパターンで決まります。

IdPの発行者（Issuer）：https://sts.windows.net/{tenant-id}/
IdPのサインインURL：https://login.microsoftonline.com/{tenant-id}/saml2
IdPのサインアウトURL：サインインURLと同じ値
メタデータURL：テナントのメタデータのURLに?appid={application-id}を付けたもの

値の出典は前出の構成と制限事項のページにある「IdPの設定のマッピング」の表で、{tenant-id}には管理センターの概要に出るテナントIDが入ります。メタデータURLはappidを付けて取ってください。フェデレーションメタデータの説明にあるテナント単位のメタデータには、テナント共通の鍵が並びます。エンタープライズアプリの署名証明書は、そのアプリ用に作られた別の証明書です。メタデータの要素の読み方はSAMLメタデータとは：EntityDescriptorの読み方と署名証明書の更新手順で解説しました。

AD FSの証明書利用者信頼をPowerShellで登録しクレーム規則を書く

AD FSを使い続ける環境で自社システムを追加する場合の作業です。管理コンソールのウィザードでも登録できますが、検証環境と本番で同じ設定を再現するにはPowerShellで書いておくほうが確実です。

Add-AdfsRelyingPartyTrustで信頼とACSのエンドポイントを作る

自社システムがメタデータのURLを公開しているなら、Add-AdfsRelyingPartyTrustに-MetadataUrlを渡すだけで登録できます。公開していない場合は、New-AdfsSamlEndpointでACSのエンドポイントを作ってから、識別子と一緒に渡します。

# 1) 自社システムがメタデータを公開している場合
Add-AdfsRelyingPartyTrust -Name "業務システム" `
  -MetadataUrl "https://app.example.co.jp/saml/metadata" `
  -AutoUpdateEnabled $true -MonitoringEnabled $true

# 2) メタデータが無い場合：ACSを作って手で登録する
$acs = New-AdfsSamlEndpoint -Binding "POST" -Protocol "SAMLAssertionConsumer" `
  -Uri "https://app.example.co.jp/saml/acs" -IsDefault $true -Index 0

Add-AdfsRelyingPartyTrust -Name "業務システム" `
  -Identifier "https://app.example.co.jp/saml/metadata" `
  -SamlEndpoint $acs -ProtocolProfile "SAML" `
  -SignatureAlgorithm "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" `
  -SamlResponseSignature "AssertionOnly" `
  -AccessControlPolicyName "Permit everyone" `
  -IssuanceTransformRulesFile "C:\adfs\rules-app.txt"

-ProtocolProfileの既定値はWS-FederationとSAMLの両用（WsFed-SAML）です。SAMLだけで使うアプリで明示する値はSAMLです。-AutoUpdateEnabledを$trueにすると、メタデータの変更が信頼の設定へ自動で反映される代わりに、メタデータで上書きされる項目が読み取り専用になります。-SamlResponseSignatureは、自社システムのライブラリがアサーションの署名だけを検証するならAssertionOnly、応答全体も見るならMessageAndAssertionを選びます。

発行変換規則でADのmailと姓名をSAMLの属性とNameIDに出す

上の-IssuanceTransformRulesFileで読み込む規則ファイルの例です。書式は要求規則言語の役割に沿っています。1つ目の規則でADの属性を取り出し、2つ目でメールアドレスをNameIDに変換します。

@RuleName = "ADのmail・姓名を取り出す"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
 => issue(store = "Active Directory",
          types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
                   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
                   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"),
          query = ";mail,givenName,sn;{0}", param = c.Value);

@RuleName = "メールアドレスをNameID(emailAddress形式)にする"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"]
 => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
          Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType,
          Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"]
            = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress");

規則は条件と発行文を=>でつなぎ、末尾をセミコロンで区切ります。issueは出力に載せる発行で、addは後続の規則だけが使う値を足す発行です。ここでaddや正規表現の条件を多用すると、後でEntra IDへ移すときに、移行ダッシュボードが「追加の手順が必要」と判定する原因になります。将来の移行を見込むなら、AD属性の取り出しと単純な変換だけで書いておきます。

AD FSからEntra IDへSAMLアプリを移す棚卸しと切り替えの作業順

MicrosoftのAD FSからMicrosoft Entra IDへの移行ステージは、運用アプリがAD FSで認証している現状から、テスト用インスタンスの付け替えを経て、運用アプリをEntra IDに向けるまでの4段階で進める流れです。ここでは、その前に必要な棚卸しと、切り替え日の作業を具体化します。

AD FSアプリケーション移行のダッシュボードで移せるアプリを3つに分ける

AD FSアプリケーションの移行を使うには、Entra ID P1またはP2のライセンスと、オンプレミスへのEntra ConnectとConnect HealthのAD FSエージェントの導入が必要です。エージェントがAD FSの構成とサインインの監査ログを読み、証明書利用者信頼ごとに次の3つの状態を付けます。

移行準備完了：構成がEntra IDで完全にサポートされ、そのまま移せる
要確認：一部の設定はそのまま移せないが、移行の妨げにはならない
追加の手順が必要：Entra IDが一部の設定をサポートしておらず、今の状態では移せない

一覧に出るのは、過去30日間にサインインがあった証明書利用者信頼だけです。Office 365などMicrosoft関連の信頼も表示されません。月末や期末にしか使わない業務システムは一覧から漏れるので、PowerShellのGet-AdfsRelyingPartyTrustで全件を書き出し、ダッシュボードの一覧と突き合わせてください。ワンクリックの移行で作られるのはSAMLのアプリだけで、署名証明書と条件付きアクセスのポリシーは移りません。

Entra IDに移せないクレーム規則と別の手段で置き換える項目

構成と制限事項のページは、現時点で移行できない機能としてWS-TrustのActAsパターンとSAMLのArtifact解決の2つを挙げています。クレーム規則では、AD以外の属性ストア（SQLなど）から値を引く規則が最も重い障害です。Entra IDはADかEntra ID以外のストアからクレームを取得しないためです。

それ以外は置き換えの手段があります。AD FSの承認規則や多要素認証の規則は条件付きアクセスへ移し、正規表現による値の変換はExtract()やRegexReplace()などの変換関数へ書き直します。Entra IDで同期されていない属性（たとえば独自に拡張したADの属性）は、先にEntra Connectの同期対象へ加えないとクレームの値の選択肢に現れません。

署名証明書とIdPのURLを切り替える日の本番作業手順と戻し方

Entra ID側でアプリを作っただけでは、自社システムへのサインインは何も変わりません。切り替えは、自社システム側のIdP設定を書き換えた瞬間に起きます。作業は次の順で行います。

Entra IDのアプリに、ADから同期した移行対象の利用者グループを割り当てる
テスト用の自社システムをEntra IDに向け、NameIDと属性の値をAD FSのときと突き合わせる
本番の自社システムで、発行者・サインインURL・署名証明書の3つを同時にEntra IDの値へ書き換える
代表の利用者でログインを確かめ、失敗したら3つの値をAD FSの値に戻す
数週間おいてAD FSの該当する証明書利用者信頼を無効にし、問題が無ければ削除する

手順2の突き合わせには、ブラウザー拡張でSAMLResponseを採取する方法が手早く使えます。採取と読み方はSAML-tracerの使い方：SSO失敗の原因を採取した通信から切り分けるで解説しました。手順4で戻せるよう、切り替え前のAD FSの値は必ず控えておいてください。

Entra IDのメタデータで発行者と署名証明書を確かめる検査コード

切り替え日の手順3で入れる値は、手入力よりメタデータから取り出したほうが誤りを減らせます。次のentra_meta_check.pyは標準ライブラリだけで動き、Entra IDのメタデータからentityID、SSOのURL、署名証明書のSHA-1拇印を表示します。拇印の照合先は、Entra管理センターの「SAML署名証明書」に表示される値です。

import base64, hashlib, sys, urllib.request
import xml.etree.ElementTree as ET

NS = {
    "md": "urn:oasis:names:tc:SAML:2.0:metadata",
    "ds": "http://www.w3.org/2000/09/xmldsig#",
}
BIND = "urn:oasis:names:tc:SAML:2.0:bindings:"


def load(tenant, app_id=None):
    """Entra IDのフェデレーションメタデータを取得する（appidを付けるとアプリ単位の証明書になる）"""
    url = f"https://login.microsoftonline.com/{tenant}/federationmetadata/2007-06/federationmetadata.xml"
    if app_id:
        url += f"?appid={app_id}"
    with urllib.request.urlopen(url, timeout=20) as r:
        return ET.fromstring(r.read())


def main(tenant, app_id=None):
    root = load(tenant, app_id)
    print("entityID(発行者):", root.get("entityID"))
    idp = root.find("md:IDPSSODescriptor", NS)
    for e in idp.findall("md:SingleSignOnService", NS):
        print("SSO", e.get("Binding").replace(BIND, ""), ":", e.get("Location"))
    for kd in idp.findall("md:KeyDescriptor", NS):
        if kd.get("use") not in (None, "signing"):
            continue
        for c in kd.findall(".//ds:X509Certificate", NS):
            der = base64.b64decode("".join(c.text.split()))
            # 管理センターに表示される拇印はSHA-1の16進表記
            print("署名証明書の拇印(SHA-1):", hashlib.sha1(der).hexdigest().upper())


if __name__ == "__main__":
    main(*sys.argv[1:])

Python 3.14.10で、Microsoftのドキュメントで例に使われるcontosoテナントをappidなしで指定して実行した結果です（2026年11月5日時点）。

> python entra_meta_check.py contoso.onmicrosoft.com
entityID(発行者): https://sts.windows.net/31537af4-6d77-4bb9-a681-d2394888ea26/
SSO HTTP-Redirect : https://login.microsoftonline.com/31537af4-6d77-4bb9-a681-d2394888ea26/saml2
SSO HTTP-POST : https://login.microsoftonline.com/31537af4-6d77-4bb9-a681-d2394888ea26/saml2
署名証明書の拇印(SHA-1): BC481730A462F081CAC006E8048B5288E02982AA
署名証明書の拇印(SHA-1): AF2071FBAE63368C47E05407FFACDAACD8DA35FE
署名証明書の拇印(SHA-1): 5EAB60DF4C877AB84B87950EF3CFB834C6E5CD60
署名証明書の拇印(SHA-1): C47F43247DCDD3CE8082CF092FA210CDE421D69F
署名証明書の拇印(SHA-1): EF3B3ACD84E4F60E63FDBEDEEC8B565BE1DA00BE

発行者とサインインURLが前の章の表のパターンどおりに出ています。一方、テナント単位では署名証明書が5枚並び、同じ日に繰り返した実行では6枚の回もありました。自社システムに貼るべき1枚はここからは決まりません。実際の作業では2番目の引数にアプリのアプリケーションIDを渡し、そのアプリの証明書の拇印が管理センターの表示と一致するかを確かめます。

証明書の期限にも注意してください。フェデレーション証明書の管理によると、Entra IDが自動で作るSAML署名証明書の有効期間は3年で、期限の60日前、30日前、7日前に通知メールが送られます。通知先は既定でアプリを追加した管理者だけなので、運用担当の配布リストを加えておきます。

SAML ADの構成をAD FSに残す条件とEntra IDへ寄せる場面

受託開発で認証基盤の相談を受けたときの結論を、条件付きで書きます。

AD FSを残すのは外部属性ストアやArtifact解決に依存する間だけ

AD FSを残してよいのは、次のどちらかに当たるアプリが残っている間に限ります。

クレーム規則がSQLなどAD以外の属性ストアから値を引いていて、自社システム側でその値を持てない
アプリがSAMLのArtifact解決やWS-TrustのActAsに依存していて、改修の予定が立たない

どちらにも当たらないなら、新規も既存もEntra IDへ寄せます。AD FSを残すと、サーバーの冗長化、Windows Serverの更新、トークン署名証明書の更新が自社に残り、利用者から見た機能は何も増えません。移行先のIdPとしてKeycloakなどを自前で建てる選択肢との比較はSAML 2.0 IdPの構築手順：KeycloakとIDaaSの選び方とSP登録・属性マッピングで扱っています。

移行を見送るべき失敗パターンと自社業務システム側で先に直すこと

見送るべき典型は、自社システムが利用者をsAMAccountNameで持っているのに、Entra IDの既定のNameID（UPN）のまま切り替えるケースです。全員が「利用者が見つからない」で弾かれるか、最悪の場合はJIT作成の機能で別人の新規アカウントが量産されます。NameIDの元属性を決め、テストで突き合わせるまでは切り替えない、というのが最低条件です。

自社システムに複数の取引先のIdPを受け入れる予定があるなら、IdPの付け替えより先に、SP側でテナントごとにIdPを設定できる作りへ直します。設計はSAML連携の実装手順：自社SaaSにテナント別IdP設定とJITを組み込むで解説しました。AD FSの棚卸しからEntra IDへの切り替え、業務システム側のSAML対応の改修までは、一創の認証基盤・ID管理システム開発で設計から運用まで対応しています。

よくある質問

ADの利用者でSAML SSOを組むときに出やすい質問をまとめました。

Active Directoryだけで自社システムにSAML SSOはできますか？

できません。ADのドメインコントローラーはKerberosとLDAPで認証する仕組みで、SAMLのアサーションを発行するIdPの機能を持っていないためです。オンプレミスにAD FSを建てるか、ADの利用者をMicrosoft Entra ConnectでEntra IDへ同期し、Entra IDをIdPにします。自社システムから見ると、どちらもSAML 2.0のIdPとして同じように扱えます。

AD FSとEntra IDのどちらをSAMLのIdPに選べばよいですか？

新しく組むならEntra IDを選びます。サーバーの保守が不要で、多要素認証や接続元による制御を条件付きアクセスでまとめて設定できます。AD FSを選ぶ理由が残るのは、AD以外の属性ストアから値を引くクレーム規則や、SAMLのArtifact解決に頼るアプリがある場合です。その場合も、移行の期限を決めて残すのが前提です。

Entra IDのSAMLでsAMAccountNameをNameIDに使えますか？

利用可能です。ADの属性がEntra Connectで同期されていれば、NameIDの元属性にonpremisessamaccountnameを選べます。クラウドだけで作った利用者にはこの値が無く、元属性が空のときはUPNが使われる、とMicrosoftのドキュメントにあります。クラウドの利用者が混ざる組織では、従業員IDなど全員が持つ属性を選ぶほうが安全です。

AD FSの署名証明書はEntra IDへ移行されますか？

移行されません。AD FSアプリケーションの移行ウィザードは、識別子と応答URL、クレーム、利用者グループの割り当てを移しますが、署名証明書は対象外です。Entra IDはアプリごとに有効期間3年の自己署名証明書を新しく作ります。切り替え日には、この新しい証明書を自社システムに登録し直す作業が必ず発生します。

AD FSの移行ダッシュボードに表示されないアプリがあるのはなぜですか？

一覧の対象が、過去30日間に利用者のサインインがあった証明書利用者信頼に限られているためです。Office 365などMicrosoft関連の信頼も表示されません。四半期に1回しか使わない業務システムは、ここから漏れます。Connect HealthのAD FSエージェントが動いているかも確かめたうえで、Get-AdfsRelyingPartyTrustで全件を書き出して突き合わせてください。