AD FS シングル サイン オンの設定

適用対象: Windows Server (サポートされているすべてのバージョン)

シングル サインオン (SSO) では、追加の資格情報が求められることなく、一度の認証でユーザーが複数のリソースにアクセスできます。 この記事では、SSO AD FS の既定の動作と、この動作をカスタマイズできる構成設定について説明します。

サポートされるシングル サインオンの種類

AD FS では、複数の種類のシングル サインオン エクスペリエンスがサポートされています。

  • セッション SSO

    セッション SSO を使用すると、特定のセッション中にユーザーがアプリケーションを切り替えたときの追加のプロンプトが不要になります。 特定のセッションが終了すると、ユーザーは資格情報の入力を再度求められます。 セッション SSO Cookie は、認証されたユーザーに対して書き込まれます。

    AD FS では、ユーザーのデバイスが登録されていない場合、セッション SSO Cookie が既定で設定されます。 ブラウザー セッションが終了し、再起動された場合、このセッション Cookie は削除され、有効でなくなります。

  • 永続的な SSO

    永続的な SSO では、永続的な SSO Cookie が有効である限り、ユーザーがアプリケーションを切り替えたときに、プロンプトがさらに表示されることはありません。 永続的な SSO Cookie は、認証されたユーザーに対して書き込まれます。 永続的な SSO とセッション SSO の違いは、永続的な SSO はさまざまなセッション間で維持できることです。

    AD FS では、デバイスが登録されている場合、永続的な SSO Cookie が設定されます。 AD FS では、ユーザーが [サインインしたままにする] オプションを選択した場合も、永続的な SSO Cookie が設定されます。 永続的な SSO Cookie が無効になった場合は、拒否され、削除されます。

  • アプリケーション固有の SSO

    OAuth シナリオでは、更新トークンを使用して、特定のアプリケーションのスコープ内でユーザーの SSO 状態を維持します。

    AD FS は、登録済みデバイスの永続的な SSO Cookie の有効期間に基づいて、更新トークンの有効期限を設定します。 既定では、Windows Server 2012 R2 の AD FS の Cookie の有効期間は 7 日間です。 Windows Server 2016 での AD FS の既定の Cookie 有効期間は、デバイスを使用して 14 日以内に AD FS リソースにアクセスする場合、最大 90 日間です。

デバイスが登録されていないが、ユーザーが [サインインしたままにする] オプションを選択した場合、更新トークンの有効期限は、[サインインしたままにする] の永続的な SSO Cookie の有効期間と等しくなります。 永続的な SSO Cookie の有効期間は、既定では 1 日で、最大 7 日間です。 それ以外の場合、更新トークンの有効期間はセッション SSO Cookie の有効期間 (既定では 8 時間) と等しくなります。

登録済みデバイスのユーザーは、永続的な SSO が無効にされていない限り、常に永続的な SSO を取得します。 登録されていないデバイスの場合は、[サインインしたままにする] (KMSI) 機能を有効にすると、永続的な SSO を実現できます。

Windows Server 2012 R2 で、[サインインしたままにする] のシナリオで PSSO を有効にするには、この修正プログラムをインストールする必要があります。これは、Windows RT 8.1、Windows 8.1、Windows Server 2012 R2 の 2014 年 8 月の更新プログラムのロールアップの一部でもあります。

タスク PowerShell 説明
永続的な SSO を有効/無効にする Set-AdfsProperties –EnablePersistentSso <Boolean> 永続的な SSO は既定で有効になっています。 無効になっている場合、PSSO Cookie は作成されません。
[サインインしたままにする] を有効/無効にする Set-AdfsProperties –EnableKmsi <Boolean> [サインインしたままにする] 機能は既定で無効になっています。 有効になっている場合、AD FS サインイン ページに [サインインしたままにする] の選択肢がユーザーに表示されます

AD FS 2016 - シングル サインオンと認証済みデバイス

AD FS 2016 では、要求元が登録済みデバイスから認証している場合、PSSO が変更され、最大 90 日になりますが、14 日 (デバイスの使用期間) 以内に認証する必要があります。 既定では、登録済みのデバイスを使用するユーザーが初めて資格情報を指定した後に、そのデバイスを使用して少なくとも 14 日に 1 回 AD FS リソースにアクセスすれば、最大 90 日間シングル サインオンできます。 15 日後、ユーザーは資格情報の入力を求められます。

永続的な SSO は既定で有効になっています。 無効になっている場合、PSSO Cookie は作成されません。

Set-AdfsProperties –EnablePersistentSso <Boolean\>

デバイスの使用期間 (既定では 14 日) は、AD FS プロパティ DeviceUsageWindowInDays によって管理されます。

Set-AdfsProperties -DeviceUsageWindowInDays

シングル サインオンの最長期間 (既定では 90 日) は、AD FS プロパティ PersistentSsoLifetimeMinsによって管理されます。

Set-AdfsProperties -PersistentSsoLifetimeMins

認証されていないデバイスにサインインしたままにする

登録されていないデバイスの場合、シングル サインオン期間は、サインインしたままにする (KMSI) 機能の設定によって決まります。 KMSI は既定で無効になっていますが、AD FS プロパティ KmsiEnabled を True に設定すると有効にできます。

Set-AdfsProperties -EnableKmsi $true

KMSI が無効になっている場合、既定のシングル サインオン期間は 8 時間です。 シングル サインオン期間は、SsoLifetime プロパティを使用して構成できます。 プロパティは分単位で測定されるため、既定値は 480 です。

Set-AdfsProperties –SsoLifetime <Int32\>

KMSI が有効になっている場合、既定のシングル サインオン期間は 24 時間です。 KMSI が有効になっているシングル サインオン期間は、KmsiLifetimeMins プロパティを使用して構成できます。 プロパティは分単位で測定されるため、既定値は 1440 です。

Set-AdfsProperties –KmsiLifetimeMins <Int32\>

多要素認証 (MFA) の動作

AD FS では、比較的長い期間のシングル サインオンが提供されます。 以前のサインオンが (MFA ではなく) プライマリ資格情報に基づいているが、現在のサインオンには MFA が必要な場合に、AD FS で追加の認証 (多要素認証) を求めるメッセージが表示されることに注意することが重要です。 この動作は、SSO の構成に関係ありません。 AD FS は、認証要求を受信すると、まず SSO コンテキスト (Cookie など) があるかどうかを判断し、次に MFA が必要かどうかを判断します。 たとえば、認証要求が外部からの場合は MFA が必要です。 このような場合、AD FS は、SSO コンテキストに MFA が含まれているかどうかを評価します。 そうではない場合は、MFA が求められます。

PSSO の失効

AD FS では、セキュリティを保護するために、次の条件が満たされた場合、以前に発行された永続的な SSO Cookie は拒否されます。

  • ユーザーがパスワードを変更する

  • 永続的な SSO 設定は AD FS で無効になっています。

  • 紛失または盗難にあった場合、管理者によってデバイスが無効になります。

  • AD FS では、登録済みユーザーに発行された永続的な SSO Cookie を受け取りますが、ユーザーまたはデバイスは登録されなくなりました

  • AD FS では、登録済みユーザーの永続的な SSO Cookie を受け取りますが、ユーザーは再登録されます。

  • AD FS では、[サインインしたままにする] の結果として発行され永続的な SSO Cookie を受け取りますが、[サインインしたままにする] の設定は AD FS で無効になっています

  • AD FS では、登録済みユーザーに発行された永続的な SSO Cookie を受け取りますが、認証中にデバイス証明書が見つからないか、変更されています

  • AD FS 管理者が永続的な SSO のカットオフ時間を設定しました。 カットオフ時間が構成されている場合、AD FS では、この時間より前に発行された永続的な SSO Cookie は拒否されます

永続的な SSO Cookie を拒否するには、ユーザーが AD FS で再度認証するために資格情報を指定する必要があります。

カットオフ時間を設定するには、次の PowerShell コマンドレットを実行します。

Set-AdfsProperties -PersistentSsoCutoffTime <DateTime>

Office 365 ユーザーが SharePoint Online にアクセスできるように PSSO を有効にする

PSSO を有効にして構成すると、AD FS はユーザー認証の直後に永続的な Cookie を作成します。 PSSO では、Cookie がまだ有効である限り、後続のセッションで再認証する必要がなくなります。

ユーザーは、Office 365 と SharePoint Online に対する追加の認証プロンプトを回避することもできます。 Microsoft Entra ID と SharePoint Online で永続化をトリガーするように、AD FS で次の 2 つの要求ルールを構成します。 Office 365 ユーザーが SharePoint Online にアクセスできるように PSSO を有効にするには、この修正プログラムをインストールします。 これは、Windows RT 8.1、Windows 8.1、Windows Server 2012 R2 の 2014 年 8 月の更新プログラムのロールアップの一部です。

InsideCorporateNetwork 要求をパススルーするための発行変換規則

@RuleTemplate = "PassThroughClaims"
@RuleName = "Pass through claim - InsideCorporateNetwork"
c:[Type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork"]
=> issue(claim = c);
A custom Issuance Transform rule to pass through the persistent SSO claim
@RuleName = "Pass Through Claim - Psso"
c:[Type == "https://schemas.microsoft.com/2014/03/psso"]
=> issue(claim = c);

要約:

シングル サインオン エクスペリエンス ADFS 2012 R2
デバイスは登録されていますか?
ADFS 2016
デバイスは登録されていますか?
いいえ いいえ しかし KMSI はい いいえ いいえ しかし KMSI はい
SSO=>更新トークンの設定=> 8 時間 n/a n/a 8 時間 n/a n/a
PSSO=>更新トークンの設定=> n/a 24 時間 7 日間 n/a 24 時間 最大 90 日間と 14 日間ウィンドウ
トークンの有効期間 1 時間 1 時間 1 時間 1 時間 1 時間 1 時間

登録済みのデバイスですか? PSSO/永続的な SSO を取得します。

登録されていないデバイスですか? SSO を取得します。

登録済みデバイスではなく KMSI ですか? PSSO/永続的な SSO を取得します。

条件:

  • [x] 管理者が KMSI 機能を有効にした [AND]
  • [x] ユーザーがフォームのサインイン ページの [KMSI] チェック ボックスを選択する

  AD FS では、新しい更新トークンの有効性が前のトークンよりも長い場合にのみ、新しい更新トークンが発行されます。 トークンの最大有効期間は 84 日ですが、AD FS では、14 日間のスライディング ウィンドウでトークンが有効な期間が維持されます。 更新トークンが通常の SSO 時間である 8 時間有効な場合、新しい更新トークンは発行されません。

理解を深める:

LastPasswordChangeTimestamp 属性が同期されていないフェデレーション ユーザーには、最長有効期間の値が 12 時間の更新トークンとセッション Cookie が発行されます。

Microsoft Entra ID では古い認証情報に関連するトークンを取り消すタイミングを判断できないため、最大期日経過値セッション Cookie と更新トークンが発行されます。 この動作は、変更されたパスワードなどが原因で発生する可能性があります。 ユーザーおよび関連付けられているトークンまだ有効であることを確認するために、Microsoft Entra ID でより頻繁にチェックする必要があります。