Azure AD / 発送 SAML セットアップ手順

Last updated: June 19, 2026

    このドキュメントでは、Microsoft の Azure SAML サービスを使用して L2L 発送にログインするように L2L を設定する方法を説明します。

    ステップ 1: L2L SAML 設定を作成する

    まず、発送と Azure 間の SAML 信頼関係を定義する新しい SAML 設定を作成します。[customer].leading2lean.com にログインし、セットアップ → IT セットアップ → SAML SSO 設定に移動します。新規追加 リンクをクリックします。

    新しい SAML 設定を追加 ページで、次の情報を入力します。

    • コード: すべての発送 SAML 設定の中で一意のコードである必要があり、発送の SAML URL で使用されます。
    • 表示名: 発送のログインページに表示されるユーザー向けのテキストです。
    • IdP ユーザー命名属性: ユーザーが発送にログインする方法を選択する必要があります。メール を選択する場合、発送ユーザーアカウントのメールアドレスが Azure ユーザーアカウントに設定されているメールアドレスと同じである必要があり、ユーザー名 を選択する場合、発送のユーザー名が Azure のユーザー名と一致する必要があります。
    • ここでは他のすべてのフィールドを空白のままにして、保存 をクリックします。残りのフィールドは、以下のステップ 3 で Azure アプリケーションの値を使用して設定します。
    • 次に、作成した新しい SAML 設定をクリックします。次のステップでは、SP Initiate、SP SSO URL、SP SLO URL、および SP Entity ID を使用します。

    ステップ 2: Azure で新しいアプリケーションを作成する

  1. 新しいアプリケーションを作成する
    1. すべてのアプリケーション → 新しいアプリケーションに移動します。新しいアプリケーション をクリックします。ギャラリー以外のアプリケーション を選択します。新しいアプリケーションに名前を付け、追加 をクリックします。
  2. シングルサインオンの構成 を選択し、SAML を選択します。
  3. セクション 1: 次の L2L URL を Azure アプリケーションに入力します。末尾のスラッシュを必ず含めてください。
    L2L URLAzure アプリケーション設定
    SP Entity ID識別子 (エンティティ ID)
    SSO URL応答 URL
    SSO URLサインオン URL
    SLO URLログアウト URL
  4. セクション 2: 一意のユーザー識別子を設定します。
    1. L2L の IdP ユーザー命名属性 に メール を選択した場合は、user.mail を選択します。
    2. L2L の IdP ユーザー命名属性 に ユーザー名 を選択した場合は、user.userprincipalname を選択します。

IdP 起点 SSO に関する注意: IdP 起点 SSO をサポートするアプリケーションでは、Microsoft Azure/Entra により、「My Apps」Web ポータルを通じて登録済みアプリケーションに認証してアクセスできます。L2L は IdP 起点 SSO をネイティブではサポートしていませんが、Azure/Entra のログイン URLをIdP SSO URLではなくL2L SP Initiate URLを使用するように設定することで、この機能をエミュレートできます。

手順 3: L2L SAML 設定を更新する

  • Azure Application のセクション 3から証明書(Base 64)をダウンロードし、L2L のSAML Config Detail 画面のx509 Public Certificate in PEM formatタブにあるIdP Certificate Informationフィールドにコピーして貼り付けます。
  • Azure Application のセクション 4にある次の Azure URL を L2L のSAML Config Detail画面に入力します:
    Azure URLL2L SAML Config Detail
    ログイン URLIdP SSO URL
    Azure AD 識別子IdP エンティティ ID
    ログアウト URL

    IdP SLO URL

    手順 4: L2L でユーザーを設定する

    ここで、ユーザーを SAML 設定に関連付けます。新しい SAML 設定を使用するようにユーザーを設定するまで、SAML を使用することはできません。これには 2 つの方法があります。

    一度に 1 ユーザーずつ
    ユーザーの編集画面で適切なSAML Config設定を選択します。ユーザーごとに選択できるSAML Config設定は 1 つだけです。
    ユーザー移行ツール
    サイトに登録されているすべてのユーザーが認証に SAML を使用する場合は、SAML 移行ツールを使用できます。これはSAML Config Detail画面の下部にあります。アカウントを移行ボタンをクリックして、指示に従います。

    手順 5: テスト

  • https://[customer].leading2lean.com に移動し、新しい SSO ボタンをクリックします。このボタンのタイトルは、上記の L2L 設定にある表示名から取得されます。
    1. プロンプトが表示されたら、認証情報を入力します。
    2. L2L 発送にログインしていることを確認します
  • 発送からログアウトする
    1. L2L 発送からログアウトしていることを確認します

    トラブルシューティング

    ログアウトできない
    ユーザーがSAMLルートを使用してL2Lに正常にログインできる場合がありますが、ログアウトできないことがあります。この場合は、L2LのSAML Config Detail → IdP SLO URLフィールドで次のログアウトURLを使用してみてください:
    https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0
    ログインできない
    AzureとL2Lの間で想定される認証方法に不一致がある場合、次のエラーが表示されることがあります:

    "AADSTS75011: Authentication method 'X509, MultiFactor, X509Device' by which the user authenticated with the service doesn't match the requested authentication method "Password, ProtectedTransport". Contact the Leading2Lean application owner."

    デフォルトでは、L2LはSP-InitリクエストのrequestedAuthnContext フィールドを通じて、認証方法Password, ProtectedTransport を適用します。AzureがX509, Multifactor, X509Device 認証を許可するように設定されていて、ユーザーがこの方法で認証した場合、その後SSOを使用してL2Lへのログインを試みると、L2Lはそれを受け入れず、Azureはこのエラーを表示します。 

    SAML Configページには、requestedAuthnContext フィールドを変更できる2つの新しいオプション設定があります。これらは、SAML ConfigページのAdvanced Settingsタブにある新しいBehavior Settings セクションの下にあります。これらのオプション設定には次のものがあります:

    - requestedAuthnContextを無効化
    - requestedAuthnContextに「Unspecified」を含める(実験的)



    Azureが独自の認証要件を適用できるようにするには, これらのオプションのいずれかを選択します。このエラーを解決するには、まずrequestedAuthnContextにUnspecifiedを含める(実験的) を有効にすることをお勧めします。エラーが解決されない場合、または新しいエラーが生成された場合は、このオプションを無効にしてrequestedAuthnContextを無効化オプションを有効にします。これらの設定を変更した後は、必ず設定を保存してください。保存後、L2Lからログアウトし、SSOで再度ログインしてみてください。 

    重要な注意: これらのオプションはいずれも、認証方法を独自に適用する完全な権限をIdentity Providerに与えます。これらのオプションは相互排他的でもあるため、同時に有効にするのは2つのうち1つだけにしてください。

    SAMLの実装には、異なるアイデンティティプロバイダー(IdP)間で固有の柔軟性があります。一部のIdPはrequestedAuthnContext の値を無視し、デフォルトの認証方法で処理を続行します。Unspecified を利用可能な任意の認証方法を使用する明示的なリクエストとして扱うIdPもあります。また、Password, ProtectedTransportやMFAなど、事前設定された認証方法をデフォルトとして使用する場合もあります。 

    このような固有の柔軟性があるため、組織がサポートする任意の方法(ユーザー名/パスワード、MFA、証明書ベースなど)でIdPによる認証を行った後、SSOを介してL2Lにアクセスを試み、これらのオプションを十分にテストすることが重要です。