皆さんこんにちは。国井です。
ADFSトレーニングテキスト全文公開チャレンジの13回目は、いよいよクレームルール言語の話です。クレームルール言語について基本的な仕組みについて解説します。

■ ■ ■

第 4 章では、ADFS サーバーでトークンに含まれるクレームをカスタマイズしたり、認可を行う条件をカスタマイズしたり、する方法について解説します。このようなカスタマイズはクレームルール言語と呼ばれる言語を直接編集して行います。そのため、第 4 章ではクレーム ルール言語の書き方と具体的なサンプルを紹介します。

ADFS サーバーを経由して、Office 365 またはその他のクラウド サービスへアクセスする場合、Azure ADも経由するため、私たちは Office 365 またはその他のクラウド サービスへのアクセス制御を行うときにはActive Directory、ADFS サーバー、Azure AD、クラウドサービス (Office 365) の 4 か所でアクセス制御のための設定を行うことができます。

■Active Directory ドメイン サービス
Active Directory ではユーザー名とパスワードをベースにした認証を行い、その結果に基づいてADFS サーバーではトークンを発行するため、資格情報による認証というアクセス制御が行えます。

■ADFS サーバー
ADFS サーバーではトークンの中に含まれる情報に基づいてアクセス可否を判定するクレームルールの他、多要素認証による本人確認や、あらかじめ登録されたデバイスからのアクセスのみを許可するデバイス認証によるアクセス制御が行えます。

クレーム ルールには主な規則として、受け付け変換規則、発行承認規則、発行変換規則があります。
受け付け変換規則では発行承認規則で使用するクレームを発行するための規則、
発行承認承認規則ではアクセス許可を定義するための規則、
発行変換規則ではユーザーに対して発行するトークンに格納するクレームを定義するための規則をそれぞれ定義しています。
受け付け変換規則、発行承認規則、発行変換規則では、クレームルール自体を作成しなくても利用可能なルールの作成方法が用意されています。次のページから、それぞれの規則で作成可能なクレームルールの種類について解説します。

要求規則を利用してセットするクレームを定義する場合、これまで要求規則テンプレートから、あらかじめ決められたテンプレートを選択して定義していました。要求規則テンプレートから作成した規則 (ルール) は ADFS の中で解釈するためにクレームルール言語と呼ばれる言語に置き換えて処理しています。
要求規則テンプレートから作成したルールは、すべてクレームルール言語として格納されており、[規則の編集] 画面から [規則言語の表示] をクリックして、その内容を確認できます。

クレーム ルール言語はテンプレートから作成したルールを参照するだけでなく、自分で直接作成・編集することができます。クレームルール言語を作成するときは、要求規則テンプレートから [カスタム規則を使用して要求を送信] を選択して作成します。
クレームルール言語の作成には、あらかじめ用意された言語体系があるので、それに従ってルールを記述します。また、他のルールからクレームルール言語の内容をコピーして新しいルールを作成することも可能です。

クレーム ルールは CP または RP の受け付け変換規則、発行承認規則、発行変換規則の 3つの規則でトークンの中に実装するクレームを定義します。3つの規則は、受け付け変換規則→発行承認規則→発行変換規則の順で処理され、それぞれの規則で作成または承認されたトークンを Output Claim Set、次の規則が受け取るトークンを Input Claim Set と呼びます。そのため、発行承認規則の Output Claim Set と発行変換規則の Input Claim Set は同じ内容といえます。
また、それぞれの規則の中で複数のルールが定義されている場合、個々のルールは順序 1 から順番に処理され、処理結果はトークン内のクレームとして加算されていきます。

編集後記

先週は仕事が忙しくて2日間公開できないタイミングがありました。そのおかげで年内にすべて公開することはほとんど無理な状況になりましたが、公開しておけば今じゃなくても、いつか誰かの役に立つのではないかと思い、地道にやっていくことにしました。今週も毎日更新でいきますので、よろしくお願いします。

皆さんこんにちは。国井です。
ADFSトレーニングテキスト全文公開チャレンジの14回目はクレームルール言語のルールについて解説します。

■ ■ ■

クレームルール言語は、クレームを発行するための条件を記す条件部分と、発行するクレームに関する情報 (発行内容や発行方法など) を記す発行部分から構成されています。2 つの構成要素は => の記号で結ばれており、=> の手前に条件部分、=> の後ろに発行部分をそれぞれ記述します。
条件部分または発行部分には次の基本構文を利用することができます。

■条件部分の基本構文：Exists([A])
条件部分で、「A が存在する場合」という条件指定をするときは、Exists([A]) と指定します。Exists は省略可能な構文で、省略するときは [A] と記述します。

■条件部分の基本構文：Not Exists([A])
条件部分で、「A が存在しない場合」という条件指定をするときは、Not Exists([A]) と指定します。

■条件部分の基本構文：c:[A]
条件部分で A で扱った内容を変数にセットし、発行部分で活用したい場合には、c:[A] と指定します。たとえば、パススルーするときには c:[A] => issue(claim.c); のように記述することで、A の内容がそのままクレームとして発行されます。(発行部分の記述方法については後述します)

■条件部分の基本構文：Count[A]>=B
条件部分で扱うクレーム (A) に含まれる値の個数 (B) を数えて条件とする場合には、Count[A]>=B と指定します。たとえば、メールアドレスが複数ある場合を指定するときには、Count[“http://xxxx/mail”]>=2 のように指定します。また、等号、不等号は自由に組み合わせて利用することができるのでメールアドレスが 1 つしかない場合を指定するときには Count[“http://xxxx/mail”]<2 と指定することも可能です。

■条件部分の基本構文：&&
条件部分で複数の条件を指定するときは && を使います。A と B の条件を満たす場合という指定をするときは Exists([A]) && Exists([B]) と記述することができます。複数の条件を組み合わせる構文には AND 条件を示す && だけが利用可能で、OR 条件を指定することはできません。そのため、OR 条件を指定するときはルールセット内のルール自体を複数にして対応します。

■発行部分の基本構文：Issue(A) / Add(A)
発行部分で特定の情報をクレームにセットするときは Issue(A) または Add(A) を指定します。Issue(A) は Output Claim Set への発行、Add(A) Input Claim Set への発行を意味します。(詳細は後のページで解説します)

クレームルール言語を使ってカスタムルールを直接記述する場合、前のページで解説した基本構文を使用し、構文内で具体的な条件または発行する情報を記述します。ここでは、具体的な例を基に構文内の記述方法を確認します。

■条件部分
Exists([ ]) の基本構文を使用しているので、クレームへの有無をチェックしています。チェックするクレームは Type と Value を使って指定します。Type はクレームの種類 (要求の種類) を表しており、ADFS 管理ツールの [要求記述] で指定されている要求の種類 (URL 形式で指定されている情報) を指定します。一方、Value は値を表します。ここでの例では、title クレーム (要求の種類名 http://schemas.example.com/claims/title) の値が部長の場合、という条件指定になります。
また、条件部分でイコールを記述するときは == のようにイコールを 2 つ重ねて記述します。

■発行部分
=> の後は Issue で始まっているので Output Claim Set へのクレーム発行を表します。発行するクレームの種類 (要求の種類) と値には、条件部分と同じく Type と Value を使います。そのため、今回の例では role クレーム (要求の種類名
http://schemas.microsoft.com/ws/2008/06/identity/claims/role) に値として manager をセットするというクレーム発行になります。
また、発行部分でイコールを記述するときはイコールを 1 つだけ記述します。

ここまで確認してきた基本構文と構文内の記述方法をもとに、具体的なクレームルールの記述例をいくつか確認します。

■条件を指定しないで役割クレームに manager の値を発行
条件を指定しない場合には、=> の後だけを記述します。=> の前に何も記述しなければ、無条件にissue( ) 部分で指定したクレームが発行されます。

■役職が設定されていない場合、役職クレームに一般社員の値を発行
基本構文でも確認したように、トークン内に条件部分で指定したクレームが存在しない場合、Not Exists([ ]) を使用します。ここでの例では Not Exists 内に Value を指定していないので、役職クレームに何も入っていない場合 (つまり役職クレームがない場合) になりますが、Value を指定した場合には特定の値が存在しない場合という条件指定になります。

■役職が部長の場合、役職クレームを発行
条件部分で、c:[ ] を指定した場合、[ ] 内に入る情報がそのまま変数 c にセットされます。発行部分で変数 c を利用するときは claim=c と指定することで条件部分の [ ] 内の内容がクレームとして発行されます。

■役職が部長の場合、役割クレームにも役職クレームと同じ値を発行
条件部分でセットした変数 c のうち、値の部分だけを発行に活用したい場合、発行部分で値を指定するときに c.Value とします。これにより role クレームに部長の値がセットされます。

■役職と名前を組み合わせた値を指定名クレームとして発行
条件部分で使用する変数 c は複数使用することができます。それぞれの条件を c1[ ]、c2[ ] とすることで、変数 c1 と c2 にクレームの情報がセットされるため、発行部分では 2 つの変数からクレーム発行の手続きを行うことができます。また、変数の値は発行部分で組み合わせて利用することも可能です。

■Input Claim Set に含まれるクレームをそのまま発行
条件部分で何も指定しなければ無条件にクレームが発行されることを前のページで解説しましたが、発行部分では発行するクレームの情報を手動で指定しなければなりません。そのため、Input Claim Set に含まれる情報をすべて Output Claim Set にパススルーする場合には c:[ ] => Issue(claim=c) と指定します。

発行承認規則で使われるルールの場合、他の規則とは異なり、許可または拒否の判定を行います。許可または拒否の判定は、許可/拒否のクレームを発行することで判断します。発行承認規則の後続の規則である、発行変換規則では許可のクレームが発行されていることを確認し、発行変換規則の処理を開始します。また、拒否のクレームが発行されている場合、明示的に発行変換規則の処理を拒否するように構成できます。
許可または拒否のクレームを発行する場合、上記のルールを記述します。
また、発行承認規則で複数のルールが設定されている場合、いずれかの許可ルールに該当すれば、アクセスを許可することになりますが、いずれかの拒否ルールに該当する場合は優先順位や許可ルールに関わりなく拒否される点に注意してください。

発行部分では Issue または Add が利用できることを前のページで解説しました。Issue と Add はいずれもクレームに値を発行することができますが、Issue はOutput Claim Set に対して、Add はInput Claim Set に対して、それぞれ発行する違いがあります。
Output Claim Set は規則 (ルールセット) による処理が完了した結果、記録されるクレームの集合であるため、一度クレームに値をセットすると、後から値を変更したり、取り消したりすることができません。
一方、Input Claim Set はこれからルールセットで処理する内容が記録されるクレームの集合です。そのため、Add ルールでクレームを発行することで、最終的な結果としてクレームを発行するのではなく、後続のルールが使用するための値としてクレームを仮置きしておくことができます。
たとえば、上記の例では最初に Add ルールで role クレームに manager という値をセットしています。しかし、Input Claim Set への発行なので、この時点では Output Claim Set にはまだ何も記録されていません。続く Issue ルールでは title クレームに 部長という値をセットしています。これにより、Output Claim Set に初めてクレームが発行されたことになります。

正規表現とは、いくつかの文字列をひとつの文字列で表現する表現方法で、クレームルールの中では特定の条件に合致する文字列を発見するために使用します。
たとえば、条件部分で example.com ドメインを持つメールアドレスを指定する場合、ドメイン内のすべてのユーザーのメールアドレスを条件として指定することは事実上不可能です。そこで、正規表現を使って Value=~”@example\.com$” と指定すれば、たったひとつのルールで条件を簡単に指定できるメリットがあります。
正規表現には様々な表現方法といくつかのルールがあります。

■正規表現を含む文字列を扱うときはイコールとして =~ と表現する
条件部分の値に正規表現が含まれる場合、Value=~”@example\.com$” のように本来 == とするイコールを=~ と表現します。

■正規表現で使われる文字列で先頭には^、最後には$を使う
正規表現では*を利用して任意の文字列を指定することができます。逆に先頭もしくは最後に文字列がこれ以上含まれないことを示すときには^または$を使います。

■正規表現では大文字、小文字を区別する
正規表現では入力した文字について大文字/小文字を区別します。区別をしないで表現する場合は文字列の先頭に(?i)を記入します。なお、2 バイト文字の場合、大文字 / 小文字のように区別する要素はありません。

■特殊文字の前には \ (バックスラッシュ) を入れる
正規表現で特殊文字 (主にドット) を扱う場合、特殊文字の前に \ マークを入れてください。

■ 条件を使用するときは | (パイプ) を入れる
正規表現でどちらかの文字を含む、という条件を設定するときは | を使って表現します。

■特定範囲の文字または数字の指定には [ ] を使う
特定範囲の文字・数字が含まれることを指定する場合、[ ] を使います。0 から 9 までの数字を指定する場合なら [0-9]、アルファベットの a または b が含まれることを指定する場合なら [ab] のように指定します。また文字数や桁数を指定する場合は { } を使います。2 桁の数字なら [0-9]{2} のように指定します。

■特定範囲の文字または数字が含まれないことを指定する場合は [^] を使う
特定範囲の文字・数字が含まれないことを指定する場合、[^] を使います。たとえば、6 から 8 までの数字が含まれないように指定する場合なら [^6-8] と指定します。

■任意の数字を指定する場合は \d を使う
すべての数字 (10 進数) を指定する方法として、[0-9] を紹介しましたが、代わりに \d と指定することもできます。その他、英数字を表す \w、英数字以外を表す \W、空白文字を表す \s、空白文字以外を表す \S などがあります。

■IP アドレスを指定する場合は \b を使う
IP アドレスを指定する場合は、.を\.と記述します。

例：IP アドレス 192.168.1.1
192\.168\.1\.1

例：IP アドレス 192.168.1.1 または 192.168.1.2
192\.168\.1\.1\b|\b192\.168\.1\.2

例：192.168.1.0/24 サブネット内の任意の IP アドレスを指定
192\.168\.1\.([1-9]|[1-9][0-9]|1[0-9][0-9]|2[0-5][0-9])

その他、利用可能な正規表現の一覧はマイクロソフトWebサイトより確認できます。

Office 365 へのアクセスを行う場合、トークンにはあらかじめ決められたものをクレームとして実装するため、私たちがカスタマイズを行うことはありません。一方、Office 365 へのアクセス許可を制御する発行承認規則は自由にカスタマイズできるため、発行承認規則を利用して、様々なアクセス制御を行うことができます。その際、次のポイントを抑えた上で、発行承認規則を活用してください。

■5 つの追加要求規則
Office 365 の SSO 設定の一環としてNew-MsolFederatedDomain または
Convert-MsolDomainToFederated コマンドレットを実行すると、次の要求記述が登録され、ADFS のクレーム ルールで利用できるようになります。

① X-MS-Forwarded-Client-IP : Office 365 に接続された末端の端末の IP アドレス

② X-MS-Client-Application : Office 365 に接続したプロトコル (アプリケーション)

③ X-MS-Client-User-Agent : Office 365 に接続したクライアントの User-Agent

④ X-MS-Proxy : Proxyサーバー経由でのアクセスであるか (プロキシサーバーのホスト名)

⑤ X-MS-Endpoint-Absolute-Path : パッシブプロファイルまたはアクティブ プロファイル

5 つの追加された要求規則は受け付け変換規則に、これらの要求規則がトークンに含まれるよう、ルールが設定されています。そのため、発行承認規則の前提条件である受け付け変換規則の設定は行う必要はありません。

■シナリオ : 外部アクセスをすべてブロックする
社外からのアクセスをブロックし、社内からのアクセスのみを許可する場合、Web アプリケーション プロキシを経由しないアクセスのみを許可することになります。その場合には、X-MS-Proxy に値が入っていることを確認することで、社外からのアクセスであるとみなします。

exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”])

=> issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

■シナリオ : Exchange ActiveSync 以外の外部アクセスをすべてブロックする
Exchange ActiveSync による接続を行う場合には、X-MS-Client-Application の値に Exchange ActiveSync を利用していることを示す値 (正確には、Microsoft.Exchange.ActiveSync) が入ります。X-MS-Client-Application の値を、前のシナリオで登場した社外からのアクセスをブロックするルールと共に確認することで、シナリオの条件を設定できます。(ただし、先進認証で接続する場合は X-MS-Client-Application の値が設定されないケースがあることにご注意ください)

exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”]) &&

NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”, Value==”Microsoft.Exchange.ActiveSync”])

=> issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

■シナリオ : Firefox によるアクセスを許可する
特定のブラウザーによるアクセスのみを許可したい場合、X-MS-Client-User-Agent を利用します。User-Agent 内では Firefox の文字列以外にも様々な文字列が含まれるため、「Firefox という文字列が含まれる場合」となるような条件になるよう、正規表現を活用します。(参考までに Microsoft Intune で使用する Managed Browser の場合、UserAgent には「ManagedBrowser」という文字列が入ります。)

exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “(?i)Firefox”])

=> issue(Type = “http://schemas.microsoft.com/authorization/claims/permit”, Value = “true”);

これまでに解説した issue 部で deny としているルールを作成する場合、deny の条件に当てはまるもの以外は、すべて許可するルールを別途作成してください。最後にすべて許可するルールを作らないと、すべて拒否されてしまう点に注意してください。

■シナリオ : 社内からのブラウザー アクセスのみ許可する
ブラウザー アクセスの場合、利用するブラウザーがまちまちなので、X-MS-Client-User-Agent を利用することができません。そのため、ブラウザー アクセスを行うときのエンドポイント URL に着目し、URL に /adfs/ls/wia が含まれる場合にはブラウザー アクセスであると判定します。

exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value == “/adfs/ls/wia”])

=> issue(Type = “http://schemas.microsoft.com/authorization/claims/permit”, Value = “true”);

■シナリオ : Windows 10 のみアクセスを許可する
特定の OS によるアクセスのみを許可したい場合、X-MS-Client-User-Agent を利用します。User-Agent 内では Windows 10 の場合には Windows NT 10.0 という文字列が含まれるため、「Windows 10 という文字列が含まれる場合」となるような条件になるよう、正規表現を活用します。

exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “(?i)Windows NT 10.0”])

=> issue(Type = “http://schemas.microsoft.com/authorization/claims/permit”, Value = “true”);

そのほかの OS では次のような文字列を利用します (iOS/Android の場合、後続の文字列にバージョン番号が入ります)。

■シナリオ : ブラウザー アクセスおよび先進認証のみ許可する
先進認証を利用していないアプリケーションからのアクセスをブロックする場合、その反対となるブラウザーアクセスまたは先進認証による通信を許可するようにルールを設定し、その他の通信に対する許可を与えないように設定します。そこで、X-ms-endpoint-absolute-path を利用して、URL に /adfs/ls または /adfs/oauth2 が含まれる場合にはブラウザー アクセスまたは先進認証のアクセスであると判定します。

c:[Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value =~ “(/adfs/ls)|(/adfs/oauth2)”]

=> issue(Type = “http://schemas.microsoft.com/authorization/claims/permit”, Value = “true”);

SharePoint Online への先進認証だけを許可
Office アプリによる SharePoint Online へのアクセスの場合、上記のクレームルールでは先進認証であるか識別できません。SharePoint Online へのアクセスを先進認証のみに限定する場合、SharePoint 管理センターより先進認証のみを許可する設定を有効にすることで対応してください。

クレームルールにおける IP アドレスの指定
X-MS-Forwarded-Client-IP 要求規則を利用してクレームルールを作成する場合、値として IP アドレスを指定します。指定する IP アドレスが複数になるときは、該当する複数のIP アドレスをすべて指定しなければならないため、正規表現を利用して IP アドレスの範囲を定義するのが一般的です。また、IP アドレスの範囲を指定するときには、マイクロソフトの Web サイトからダウンロード可能な Client Access Policy Builder を利用することも有効です。Client Access Policy Builder は PowerShell スクリプトで、指定した IP アドレス帯に対応するクレームルールを自動的に作成してくれます。なお、Client Access Policy Builder を実行するときは、Windows PowerShell ISE から起動すること、そして「Set-ExecutionPolicy Unrestricted」コマンドレットを実行してから実行する必要がある点にも注意してください。

■Client Access Policy Builder
https://gallery.technet.microsoft.com/office/Client-Access-Policy-30be8ae2

日本国外からのアクセスを拒否するルール
X-MS-Forwarded-Client-IP クレームに含まれる IP アドレスが日本で使われている IPアドレスであることを調べれば、日本国内/国外のアクセスを識別できます。しかし、日本で使用されている IP アドレス帯は非常に多く、クレームルールで制御することは現実的ではありません。例えば、AWS Route53 の Geolocation Routing を利用してフェデレーションサービス名の名前解決に日本国内と国外で異なるレコードを割り当て、国外からのアクセスを事実上拒否するような方法が現実的です。

編集後記

クレームルール言語の話でした。Windows Server 2016以降ではクレームルール言語は知らなくてもGUIベースでルールを書けるようになったので便利なのですが、発行承認規則以外の規則のカスタマイズをする場合は相変わらずクレームルール言語を直接書かなければなりません。ということで、利用することもまだまだあるだろうと思い、今回は掲載してみました。参考になれば幸いです。

皆さんこんにちは。国井です。
ADFSテキスト全文公開チャレンジの15回目は設定したクレームルールの確認方法とWindows Server 2016以降で搭載されたアクセス制御ポリシーについてです。

■ ■ ■

クレームルールを作成するにあたり、私たちが知りたい情報のひとつにクレームルールでどのような値をとるか？があります。ADFS サーバーからトークンが発行されたとき、どのようなクレームとその値が入るかについては、イベント ビューアのセキュリティログで確認することができます。利用する場合には次の方法で有効にします。

■Auditpol コマンドで「生成されたアプリケーション」ログの生成を有効にする
ADFS サーバーのコマンドプロンプトで次のように入力し、生成されたアプリケーションログを有効にします。

auditpol.exe /set /subcategory:”生成されたアプリケーション”　/failure:enable /success:enable

■サービスアカウントに対して、[セキュリティ監査の生成] 権利を割り当てる
ADFS サーバーのコンピューターアカウントが保存されている OU またはドメインにリンクされた GPO (グループ ポリシー) を利用して、ADFS サーバーのサービス アカウントに対する [セキュリティ監査の生成] 権利を割り当てます。グループポリシーから割り当てることも可能です。

■記録するイベント種類を定義する
ADFS 管理ツールのフェデレーション サービスのプロパティから、記録するイベント種類を定義します。特に、成功の監査と失敗の監査はトラブルシューティングに有効であるため、トラブルシューティング時には有効にして利用します。

前のページで記載されている手順に従い、セキュリティログで ADFS 操作のログ (成功の監査と失敗の監査) を有効にすると、ADFS サーバー内の各規則で発行されるクレームについて、その詳細を確認できます。以下では、Windows Server 2012 R2 で発行されるイベント ログについて解説します。

■クライアントが ADFS サーバーを経由して認証を行うとき
この時点では、まだクレームは発行されませんが、ADFS サーバーのセキュリティ ログにイベント ID 4624 のログが生成されます。この後のクレーム発行の流れを追跡するときの起点として利用します。

■受け付け変換規則によるクレーム発行 (発行前)
受け付け変換規則では、一般的に Active Directory に保存されている情報をもとにクレームを発行します。Active Directory から取得した情報がある場合、その情報はイベント ID 501 で確認できます。
一方、イベント ID 299 では ActivityID や InstanceID といった ID 番号が確認できるため、この後のクレーム発行の流れを追跡するときに利用できます。

■受け付け変換規則によるクレーム発行 (発行後)
受け付け変換規則によってクレームが発行されると、その結果はイベント ID 500 で確認できます。これにより受け付け変換規則で設定した規則が管理者の思惑通りに動作しているか、についての検証ができます。

■発行承認規則による処理
発行承認規則によって、トークンそのものの発行を拒否された場合、イベント ID 324 が記録されます。これにより発行承認規則で設定した規則が管理者の思惑通りに動作しているか、についての検証ができます。

■発行変換規則によるクレーム発行 (発行後)
発行変換規則によってクレームが発行されると、その結果はイベント ID 500 で確認できます。これにより受け付け変換規則で設定した規則が管理者の思惑通りに動作しているか、についての検証ができます。また、同時に発行されるイベント ID 299 のログを参照することにより、イベント ID 500 のログが受け付け変換規則で発行されたものか、または発行変換規則で発行されたものかの判定ができます。
なお、Windows Server 2016 ではトークン発行に関わるイベント ログはアクセス制御ポリシーの実行結果に関するものをイベント ID 1202、発行変換規則に関するものをイベント ID 1200 に集約し、記録されます。

Windows Server 2016 では、受け付け変換規則、発行承認規則、発行変換規則の 3 種類の規則のうち、発行承認規則は Windows Server 2012 R2 スタイルのクレームルールによるアクセス制御方法と、Windows Server 2016 スタイルのアクセス制御ポリシーによるアクセス制御方法を選択できるようになっています。
アクセス制御ポリシーを選択した場合、GUI 画面からアクセス制御のための設定ができるため、クレームルールを記述することなく簡単にルールを設定できるメリットがあります。

■アクセス制御ポリシーの定義
クレームルールのスタイルによる運用では、証明書利用者信頼の中で個別にクレームルールを記述していました。この方法では、複数の証明書利用者信頼で同じクレームルールを記述したい場合、同じルールを2度書かなければならず、面倒でした。Windows Server 2016 のアクセス制御ポリシーでは、クレームルールに相当する内容を [アクセス制御ポリシー] という独立した領域の中で管理することができます。

設定したアクセス制御ポリシーは、証明書利用者信頼と関連付けて利用できるため、複数の証明書利用者信頼で同じクレームルールを記述したい場合でも、1つのルール (ポリシー) だけ記述すれば十分です。
Windows Server 2016 では、Windows Server 2012 R2 スタイルのクレームルールによるアクセス制御方法と、Windows Server 2016 スタイルのアクセス制御ポリシーのどちらでアクセス制御を行うか選択できますが、両方を同時に利用することができません。そのため、Windows Server 2012 R2 からの移行を検討している場合には、クレームルールを段階的に移行せず、すべてのルールを一度に移行するような移行方法を検討してください。

アクセス制御ポリシーによる設定項目には、ビルトインとして用意されている項目と、管理者が独自に定義して利用する項目があります。ビルトインの項目には次のようなものがあります。

■すべてのユーザーを許可し、特定のグループに MFA を要求

■すべてのユーザーにイントラネットアクセスを許可

■すべてのユーザーを許可

■すべてのユーザーを許可し、認証されていないデバイスから MFA を要求

■すべてのユーザーを許可し、MFA を要求

■特定のグループを許可

■すべてのユーザーを許可し、エクストラネットアクセスで MFA を要求

■すべてのユーザーを許可し、MFA を要求して、デバイスの自動登録を許可

これらの項目以外のポリシーを必要とする場合、管理者が独自にポリシーを定義します。

管理者が独自にアクセス制御ポリシーを定義する場合、ADFS 管理ツールからアクセス制御ポリシーを新規作成し、[規則エディター] からアクセス許可 (または拒否) を設定します。
[規則エディター] では、あらかじめよく使われる設定項目が用意されており、例えば、特定の IP アドレス範囲からのアクセスのみを許可する場合、[規則エディター] の [特定ネットワークから] を選択して、IP アドレス帯を定義します。
一方、設定したい項目が [規則エディター] の中に無い場合は、[特定要求が要求にある] 項目を使用します。前のページで登場した次のケースの場合、次のように設定します。

■OS が Windows 10 の場合
OS に関する情報は、x-ms-client-user-agent (クライアント ユーザー エージェント) クレームに格納されている情報を使用します。そのため、[クライアント ユーザー エージェント] [が次の値と等しい] [Windows NT 10.0] と設定します。

■Exchange ActiveSync 接続を許可する場合
クライアントがクラウドへの接続に利用したアプリケーションの情報は、x-ms-client-application (クライアント アプリケーション) クレームに格納されている情報を使用します。そのため、[クライアント アプリケーション] [が次の値と等しい] [Microsoft.Exchange.ActiveSync] と設定します。

編集後記

今回はイベントビューアでクレームルール処理のログを参照する方法を紹介しましたが、Windows Server 2016からログがおまとめの表示になったんですよね。これに関しては見やすい！なんで詳細なログを消すんだ！など、色々な意見があったことを思い出しました。
ただ、Windows Server 2016でも詳細なログは追加設定で表示するように構成することもできるので必要な方は事前に設定してご利用ください。

皆さんこんにちは。国井です。
ADFSテキスト全文公開チャレンジの16回目は第5章から証明書認証についてです。

■ ■ ■

第 5 章では、安全に ID 連携を実装するために利用可能な様々なオプションについて解説します。

クラウドサービスを中心としたワークスタイルでは、ファイアウォールのようなネットワーク中心のセキュリティ対策ではなく、オンプレミス/クラウドを問わず利用される ID 中心のセキュリティ対策が重要とされています。資格情報を複数回入力することがないシングルサインオンは、それ自体が強力なセキュリティ対策と言えますが、さらに強化していくために利用可能な機能について、この章では以下の 3 点を取り上げます。

■多要素認証
資格情報だけでなく、物理的なデバイスを利用して本人確認を行うことにより、なりすましを防いで認証を強化します。

■デバイス認証
あらかじめ登録されたデバイスを利用してサインインを行った時だけ認証・認可を許可する方法です。

■条件付きアクセスによるデバイス認証
Azure AD の条件付きアクセスを利用して、あらかじめ登録されたデバイスよる接続のみを許可する方法です。

注釈
デバイス認証はWindows 8.1までのデバイスをターゲットとした方法なので、ここでは割愛します。

ADFS サーバーによる ID 連携では、シングルサインオンを実現できることを本書では解説してきましたが、サインイン自体は従来通りユーザー名とパスワードを利用していました。ところがユーザー名とパスワードによるサインインでは第三者にその内容が知られてしまった場合、不正アクセスの可能性が高まります。
こうした問題に対処するため、ADFS ではユーザー名とパスワードに追加の認証要素を加えた、多要素認証をサポートしています。多要素認証では、携帯電話やデバイスにインストールされた証明書など、物理的にデバイスを所有していることを前提とした認証方法であり、ユーザー名とパスワードのように知っていれば誰でもサインインできるようなものに比べて、より安全にサインインすることができます。
Office 365 (Azure AD) で多要素認証を実装する場合、ADFS サーバーで多要素認証を実装する方法と、Azure AD で多要素認証を実装する方法があり、いずれかの方法で多要素認証を実装することができます。

■ADFS サーバーと Azure AD の多要素認証の違い
ADFS サーバーによる多要素認証と Azure AD による多要素認証は、多要素認証に使用可能な認証要素が異なるほか、多要素認証を利用する条件設定の方法が異なります。Azure AD ではユーザーを単位として多要素認証の使用/不使用を設定しますが、ADFS サーバーの場合にはクレーム ルールを使用して多要素認証利用のための条件を細かく設定できる点が異なります。
次のページから認証要素と多要素認証利用の条件設定について解説します。

ADFS と Azure AD の多要素認証では、多要素認証に利用する認証要素は異なり、ADFS では証明書、Azure AD ではモバイルアプリ、携帯電話による通話、ショートメッセージ (SMS) をそれぞれ利用することができます。

■証明書
信頼されたルート証明機関に登録された認証局から発行されたユーザー証明書を保有するデバイスであることを確認し、追加の認証とする方法です。証明書はデバイスにインストールして利用するため、証明書を利用した多要素認証はデバイス認証の一環として利用することがあります。

■モバイルアプリ
Azure Authenticator と呼ばれるスマートフォン向けのアプリを利用し、アプリに表示されるメッセージに応答することで、追加の認証とする方法です。

■通話
あらかじめ登録した電話番号に通話を行い、ガイダンスに従って＃を押すことで、追加の認証とする方法です。

■SMS
あらかじめ登録した電話番号に SMS を送信し、SMS に記載された番号を入力することで、追加の認証とする方法です。

以上の方法のほか、ADFS サーバーでは拡張プロバイダー用の API が用意されており、追加のプロバイダーを開発することにより、任意の方法で多要素認証を実装することができます。また、Azure AD では ADFS 用の拡張プロバイダーとして、モバイルアプリ、通話、SMS が利用できるプロバイダーを提供しており、組み合わせて利用することにより、ADFS サーバーからモバイルアプリ、通話、SMS のいずれかを利用した多要素認証を実装することも可能です。詳しくは後のページで解説します。

注釈
ADFSと共に多要素認証を利用する方法として、もともとこのテキストではAzure MFA Serverについて解説が書かれていましたが、現在では利用できなくなってしまったので、Azure MFA Serverなしで利用可能な「証明書」についてのみ後続で解説します。

ADFS サーバーで多要素認証を実装する場合、多要素認証を行うために必須となる ADFS サーバーの設定のほか、証明書による多要素認証を行う場合に必要となる設定、多要素認証プロバイダーを利用する場合に必要となる設定がそれぞれあります。

①多要素認証の有効化
ADFS サーバーで多要素認証を有効にするには、有効化の設定が必要です。有効化の設定は ADFS サーバー全体もしくは証明書利用者信頼の単位で行うことができます。

②多要素認証実行の条件
Azure AD による多要素認証はユーザー単位での設定ですが、ADFS による多要素認証は多要素認証を行う条件を細かく定義することができます。

③認証局の準備

④ユーザー証明書の発行
証明書を利用して多要素認証を行う場合、事前に多要素認証を利用するデバイスに対してユーザー証明書を配布しておく必要があります。

⑤多要素認証プロバイダーの有効化
Azure AD の多要素認証プロバイダーを利用して多要素認証を行う場合、Azure AD の多要素認証プロバイダーを有効化し、オンプレミスにインストールする MFA Server コンポーネントをダウンロードしておきます。
(※証明書認証を行う場合は不要なので、後続のページでは解説を割愛します)

次のページから個々の項目について、具体的な設定を確認します。

証明書認証で使用する認証局
多要素認証で証明書認証を選択する場合、認証局には Active Directory 証明書サービスの他、様々な認証局を利用することができます。本手順では、Active Directory 証明書サービスのエンタープライズ CA とスタンドアロン CA の場合に分けて解説しますが、Active Directory 証明書サービス以外の認証局を利用する場合はスタンドアロン CA の手順を行ってください。

ADFS サーバーで多要素認証を行う場合、最初の設定として多要素認証の有効化を行います。多要素認証の有効化は ADFS 管理ツールの [サービス] – [認証方法] から設定します (Windows Server 2012 R2 の場合は [認証ポリシー] または [証明書利用者信頼ごと] を展開し、多要素認証の編集画面から設定)。
有効化するときは、多要素認証の実行方法と多要素認証の実行条件を指定します。
多要素認証の実行方法では、証明書認証または Azure MFA (MFA Server) のいずれかを選択します。
一方 Windows Server 2016 の場合、実行条件はアクセス制御ポリシーの中で定義します。アクセス制御ポリシーのアクセスを許可する条件として多要素認証を行う条件を定義し、条件に合致する場合の挙動として「Multi-Factor Authenticationを要求する」を選択します。
(Windows Server 2012 R2 の場合は多要素認証の実行方法を設定する画面と同じ画面で設定します)

ADFS サーバーではトークン発行に関わる通信は、すべて TCP 443 を使用していますが、証明書認証に関わる通信だけは TCP 49443 という特別なポート暗号を使用して通信を行います。そのため、外出先から Web アプリケーション プロキシを経由して接続するようなケースでは、Web アプリケーションプロキシサーバーが TCP 49443 による通信を受信できるようにファイアウォール等の設定を行っておく必要があります。
Windows Server 2016 の ADFS サーバーでは、証明書認証を行うために TCP 49443 を使わないように構成することができるようになりました。これを代替ホスト名バインドと呼びます。証明書認証の代替ホスト名バインドでは、フェデレーションサービス名とは別に証明書認証用に定義された FQDN を用意しておき、その名前で証明書認証の処理を行うように構成します。
このような処理方法を採用することによって、代替ホスト名バインドを利用する場合には、ADFS サーバーの SSL 通信証明書の名前に、フェデレーションサービス名と証明書認証用の代替 FQDN の 2 つの名前が登録された証明書を取得する必要があります。証明書認証用の代替 FQDN には次の名前を使用します。

certauth.<フェデレーションサービス名>

また、既定では証明書認証に TCP 49443 を利用するように構成されているため、これを変更するために次のコマンドレットを実行します。(ADFS サーバーの FQDN にはフェデレーションサービス名ではなく、Active Directory ドメイン名を含む FQDN を指定します。)

Set-AdfsAlternateTlsClientBinding `
-Member <ADFS サーバーの FQDN> -Thumbprint ‘<証明書の拇印>’

証明書による多要素認証を実行する場合、ユーザー証明書をあらかじめデバイスにインストールしておく必要があります。証明書はどの認証局から発行されたものであっても、ADFS サーバーの多要素認証で利用することは可能ですが、利用する認証局の情報は ADFS サーバーの証明書ストア内の NTAuth に事前に登録しておく必要があります。次のコマンドを実行することで登録されます。(root.cer ファイルは認証局のルート証明書です)

certutil -enterprise -addsotre “NTAuth” root.cer

Windows Server の認証局サービスである、Active Directory 証明書サービスでは、エンタープライズ CA を選択することで、NTAuth に自動的に登録されるため、certutil コマンドによる登録は不要です。
エンタープライズ CA を選択した場合、ドメイン参加のクライアント コンピューターにはグループポリシーを通じて、自動的にユーザー証明書を発行するように構成することが可能です。ただし、自動発行するためには証明書サービスに実装されている証明書テンプレートは既定のユーザー証明書テンプレートではなく、Windows Server 2003 以降のバージョンで構成された証明書テンプレートを利用する必要があるため、必ず既定のユーザー証明書テンプレートを複製し、Windows Server 2003 以降のバージョンで構成された証明書テンプレートを作成し、証明書を自動発行するよう、アクセス許可を割り当ててください。
エンタープライズ CA の場合、ドメインに参加していないコンピューターやデバイスに対して証明書を発行することが困難です。iOSやAndroidなどのモバイルデバイスに証明書を発行することをメインに考えているのであれば、Active Directory 証明書サービスのスタンドアロン CA など、エンタープライズ CA以外の認証局の利用を検討してください。
エンタープライズ CA 以外の認証局を利用して証明書を発行する場合、証明書はクライアント認証を用途とする OID = 1.3.6.1.5.5.7.3.2 となる証明書を発行してください。証明書発行要求を作成するときは以下の文字列を作成し、テキストを保存します。

[NewRequest]
Subject=”E=<ユーザーの UPN>,CN=<ユーザー名>,CN=Users,DC=exampleXX,DC=com”
KeyUsage=0xa0
Exportable=FALSE
KeyLength=2048
MachineKeySet=FALSE
SMIME=FALSE
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.2
[Extensions]
2.5.29.17=”{text}”
_continue_ = “upn=<ユーザーの UPN>”

作成したファイルは Certutil コマンドを利用して認証局に提出する発行要求ファイルとして利用できます。発行要求ファイルを作成するコマンドは以下のとおりです。

certutil -new 発行要求テキストファイル名 発行要求ファイル名

証明書発行要求ファイルの作成
証明書発行要求ファイルのフォーマットは使用する認証局によって異なります。本書ではActive Directory 証明書サービスのスタンドアロン CA を利用することを前提としていますが、他の認証局を利用する場合はそれぞれの認証局でのフォーマットに従ってください。

その他、認証局に求められる要件として、証明書に CRL の発行場所情報である CDP (CRL 配布ポイント) の情報が記載されていること、CDP は物理的にアクセスできる場所にあること、証明書認証を開始する前までに CRL が既に公開されていることが前提条件となります。

証明書認証によって、特定の認証局から発行された証明書を保有しているかを確認することでアクセス制御を行いましたが、クレームルールを活用すれば、ユーザーが保有する証明書の内容を検証し、特定の証明書種類を持つユーザー (デバイス) だけをアクセスさせるように制御することができます。その場合、次のルールに従ってクレーム ルールを作成してください。

■受け付け変換規則の作成
発行承認規則でアクセス制御を行うためには受け付け変換規則で使用するクレームを定義する必要があります。利用可能なクレームの一覧は ADFS 管理ツールの [要求記述] からも確認できるように、証明書のサブジェクト、サブジェクトの代替名、拇印などを利用できます。

■発行承認規則の作成
発行承認規則で受け付け変換規則であらかじめ指定したクレーム種類を利用して規則を作成できます。記述方法は一般的な発行承認規則と同じように利用できます。なお、証明書認証はクレームルールの評価よりも先に行うため、証明書認証に失敗したユーザーはクレーム ルールによる評価を行うことはありません。

編集後記

デバイス認証やAzure MFA Serverを利用した多要素認証など、ADFSと共に利用可能な認証要素が少なくなると時代も変化しているんだなと感じます。
私的にとても残念だなと思ったのは、証明書だけでADFSの認証が完了できるという便利さを多くの人に理解してもらえなかった点です。Azure ADで「パスワードレス」という言葉が流行っていますが、ADFSでは4年も前から既に実装されていたんですよね。

皆さんこんにちは。国井です。
ADFSテキスト全文公開チャレンジの17回目はADFSのTips集についてです。
ADFSを利用する上で覚えておくと便利な機能を簡単にまとめてみました。

■ ■ ■

第 6 章では、ADFS サーバーを中心とした運用管理とトラブルシューティング手法について解説します。具体的には、トラブルシューティングに有効なツールの紹介とツールを活用したトラブルシューティング手法について、それぞれ紹介します。

ADFS サーバーでは、ユーザーの円滑な認証と認可をサポートするため、次のような設定が日常の運用管理では発生します。

■サーバー稼働の確認
■サインイン画面のカスタマイズ
■サインインセッションのカスタマイズ
■ユーザーのパスワード変更
■パスワードのロックアウト

これらのトピックについて、次のページから詳しく解説します。

ADFS サーバーや Web アプリケーションプロキシは認証と認可に関わる重要な役割を果たすため、サーバーの稼働確認は Active Directory ドメインコントローラーと同様に行う必要があります。
ADFS サーバーと Web アプリケーション プロキシでは、

http://<フェデレーションサービス名>/adfs/probe

にアクセスし、HTTP プロトコルの応答が返ってくることで、サーバーの稼働状況を確認できます。この稼働状況のチェック方法は、ロードバランサーがパケットの振り分け先として利用する ADFS サーバーを決定する際にも利用できます。
また、別の稼働状況の確認方法として、Azure AD Connect Health を利用する方法があります。Azure AD Connect Health は Azure AD Premium の機能で、あらかじめ ADFS サーバーと Web アプリケーションプロキシにエージェントプログラムをインストールしておくことで、クラウドからサーバーの稼働状況や構成のチェックができます。

企業のアイデンティティ確立を目的として、サインイン画面のカスタマイズを必要とするケースがあります。ADFS サーバーでは Windows Server 2012 R2 より IIS を利用せずに Web サービスを提供しているため、サインイン画面の Web ページも html ファイルとして存在しません。そのため、ADFS サーバーのサインイン画面は、PowerShell のコマンドレットより変更します。
ADFS サーバーのサインイン画面は、「Web テーマ」と呼ばれる設定の集合体から構成されており、現在ある Web テーマ (テーマ名は default) を変更してカスタマイズするか、Web テーマそのものを新しく作成し、カスタマイズすることができます。

■テーマの新規作成
Default テーマをコピーして新しいテーマを作成するときは以下のコマンドレットを実行します。

New-AdfsWebTheme -Name <テーマ名> -SourceName default

■サインイン画面のロゴ変更
サインイン画面のロゴを変更する場合、テーマ名と共に以下のコマンドレットを実行します。ロゴは 260×35 ピクセルで、10KB 以下の画像が推奨されています。

Set-AdfsWebTheme -TargetName <テーマ名> `
-Logo @{path=”<ロゴ画像のパス>”}

■サインイン画面の画像変更
サインイン画面左側にある画像を変更する場合、テーマ名と共に以下のコマンドレットを実行します。画像は 1420×1080 ピクセルで、200KB 以下の画像が推奨されています。

Set-AdfsWebTheme -TargetName <テーマ名> `
-Illustration @{path=”<画像のパス>”}

■サインイン画面の説明文変更
[サインイン] ボタンの下部にある説明文を変更する場合、以下のコマンドレットを実行します。説明文は HTML タグを利用することも可能です。

Set-AdfsGlobalWebContent -SignInPageDescriptionText `
“<p>サインインできない場合は`
<A href=’http://fs1.contoso.com/fyi/’>`
こちら</A> からお問い合わせください</p>”

■サインイン画面の最下部のリンク追加
既定のページでは [2013 Microsoft] と表示されるページ最下部に追加のリンクを入れる場合、以下のコマンドレットを実行します。

Set-AdfsGlobalWebContent -HelpDeskLink `
https://fs1.contoso.com/help/ -HelpDeskLinkText Help

Set-AdfsGlobalWebContent -HomeLink `
https://fs1.contoso.com/home/ -HomeLinkText Home

Set-AdfsGlobalWebContent -PrivacyLink ‘ https://fs1.contoso.com/privacy/ -PrivacyLinkText Privacy

■スタイルシートの適用
サインインページにスタイルシートを適用する場合、以下のコマンドレットを実行します。

Set-AdfsWebTheme –TargetName <テーマ名> –StyleSheet `
@{path=”<CSS ファイルのパス>”}

■ スタイルシートの適用
サインインページに JavaScript を適用する場合、以下のコマンドレットを実行します。

Set-AdfsWebTheme -TargetName custom `
-AdditionalFileResource `
@{Uri=’/adfs/portal/script/onload.js’;path=”<onload.js ファイル`のパス>”}

JavaScript ファイル
既定のサインイン ページでは onload.js という名前の JavaScript ファイルを利用しており、Web テーマをエクスポートすることで、onload.js ファイルは直接編集し、カスタマイズすることができます。例えば、onload.js ファイルを利用して IdPInitiated プロファイル利用時に選択する RP ごとに異なるサインインページを表示するなどのカスタマイズが可能になります。
■Customizing the AD FS sign-in pages per relying party trust
https://blogs.technet.microsoft.com/pie/2015/08/29/customizing-the-ad-fs-sign-in-pages-per-relying-party-trust/

■Web テーマのエクスポート
Web テーマをファイルにエクスポートする場合、以下のコマンドレットを実行します。テーマファイルのパスにはフォルダー名までを指定します。

Export-AdfsWebTheme –Name <テーマ名> `
–DirectoryPath <テーマファイルのパス>

■Web テーマの適用
新しく作成した Web テーマをサインイン画面に適用する場合、以下のコマンドレットを実行します。

Set-AdfsWebConfig -ActiveThemeName <テーマ名>

■エラー メッセージのタイトル
サインイン エラー時に表示するメッセージのタイトル部分を変更する場合、以下のコマンドレットを実行します。

Set-AdfsGlobalWebContent -ErrorPageDescriptionText `
“<エラーメッセージのタイトル>”

■エラー メッセージ
サインイン エラー時に表示するメッセージを変更する場合、以下のコマンドレットを実行します。一般的なエラー、認証エラー、認可エラー、RP 特有の認可エラーとそれぞれ異なるメッセージを表示させることができます。

Set-AdfsGlobalWebContent -ErrorPageGenericErrorMessage `
“<一般的なエラーメッセージ>”

Set-AdfsGlobalWebContent `
-ErrorPageDeviceAuthenticationErrorMessage `
“<認証エラーメッセージ>”

Set-AdfsGlobalWebContent `
-ErrorPageAuthorizationErrorMessage`
“<認可エラーメッセージ>”

Set-AdfsRelyingPartyWebContent -Name <証明書利用者信頼名> ‘
-ErrorPageAuthorizationErrorMessage `
“<RP 特有の認可エラーメッセージ>”

一度のサインインによってアクセスできる時間をカスタマイズすることで、ユーザーの利便性を向上させる効果があります。既定では、一度発行されたトークンはセッション Cookie としてブラウザー内に格納され、ブラウザーを終了するまでの間、または ADFS サーバーのプロパティで定義されている時間 (既定では 480分) 保持されます。この動作をカスタマイズする場合、次の方法を用います。

■ブラウザー画面を閉じずにトークンを破棄したい
ADFS サーバーで提供するSingle Sign Out を利用します。ADFS サーバーの次の URL にアクセスすることで、Single Sign Out を実行し、トークンを破棄します。

https://<フェデレーションサービス名>/adfs/ls/wa=wsignout1.0

■ブラウザー画面を閉じても永続的にトークンを保持したい
ADFS サーバーでは、Keep Me Sign In (KMSI) と呼ばれる設定を有効にすることで、トークンをセッション Cookie としてではなく、永続 Cookie として 24時間保持するように構成することができます。以下のコマンドレットを実行すると、サインイン画面に [サインアウトしない] チェックボックスが表示され、チェックすることで永続 Cookie として保存されます。

Set-AdfsProperties -EnableKmsi:$true

定期的なパスワード変更をグループポリシーで定義している場合、外出先でパスワードの期限を迎えてしまい、サインインできなくなる問題が発生する可能性があります。ADFS サーバーでは、パスワードの変更をADFS サーバーまたは Web アプリケーションプロキシ経由で実行するように構成できます。
パスワード変更を有効にする場合、ADFS サーバーの/adfs/portal/updatepassword/エンドポイントを有効にします。エンドポイントは [プロキシに対して有効にする] を合わせて設定しておくことで、Web アプリケーションプロキシ経由で変更することもできます。
ユーザーが実際にパスワード変更するときは https://<フェデレーションサービス名>/adfs/portal/updatepassword にアクセスし、変更します。
また、Active Directory に保存されているパスワードの有効期限が近付いている場合、ADFS サーバーからメッセージを表示するように、発行変換規則にクレームルールを作成することもできます。

c1:[Type == “http://schemas.microsoft.com/ws/2012/01/passwordexpirationtime”]

=> issue(store = “_PasswordExpiryStore”, types = (“http://schemas.microsoft.com/ws/2012/01/passwordexpirationtime”, “http://schemas.microsoft.com/ws/2012/01/passwordexpirationdays”, “http://schemas.microsoft.com/ws/2012/01/passwordchangeurl”), query = “{0};”, param = c1.Value);

パスワード変更の通知は 14 日前から表示されます。

パスワード入力が一定回数間違えたときに、サインイン自体をできなくするロックアウトの設定は Active Directory とは別に Web アプリケーションプロキシでも実装されています。これは外部から悪意ある第三者によってパスワードロックアウトが勝手に設定されてしまうことを防ぐためにあります。外部からロックアウトが設定されても、Web アプリケーションプロキシ上のロックアウトが設定されるだけで済むため、既存の Active Directory ユーザーとしてのサインインに影響を及ぼすことはありません。

設定は、ADFS サーバーから Set-AdfsProperties コマンドレットを利用します。次のオプションを一緒に実行することで、ロックアウトを設定できます。

■ExtranetLockoutThreshold：ロックアウトされるまでの回数
■ExtranetLockoutEnabled：ロックアウト設定の有効/無効
■ExtranetObservationWindow：ロックアウト期間

例えば、ロックアウト設定を有効にする場合、次のようにコマンドレットを実行します。

Set-AdfsProperties –EnableExtranetLockout $True

ロックアウトされたユーザーによるサインインは ADFS サーバーのセキュリティログ (イベントビューア) からイベント ID 342 で記録されます。ただし、イベント ID 342 のログはパスワードを間違えたときにも記録されるログであるため、エラーメッセージに「ユーザー名またはパスワードが正しくありません」と表示されないログを確認することでロックアウトされているユーザーを確認できます。また、イベント ID 4625 でもサインイン失敗のログは同時に記録されます。

Windows のロックアウトと ADFS のロックアウトの関係
Windows のロックアウトと ADFS のロックアウトを同時に設定している場合、サインインに失敗すると、どちらのロックアウト設定にも「1回失敗」とカウントされます。そのため、Windows のロックアウトで設定した失敗回数が、ADFS のロックアウトで設定した失敗回数よりも少ない場合、Windows のロックアウトが先に適用されてしまい、Windows ユーザーはすべてのサインインができなくなってします。
以上を踏まえ、
Windows のロックアウトでの失敗回数 ＞ ADFS のロックアウトでの失敗回数
となるように必ず設定してください。

ADFS サーバーの [要求プロバイダー信頼] に複数の IdP が登録されていると、トークン発行時に IdP (レルム) を選択する画面 (HRD：ホーム レルム ディスカバリー画面) が表示され、選択を迫られます。一度選択したレルムは Get-AdfsWebConfig コマンドレットの設定によって、30 分間その設定をキャッシュします。しかし、ユーザーにとってはレルム選択という面倒な操作を迫られるため、ADFS サーバーでは HRD のカスタマイズを行い、特定の条件下では自動的にレルムが選択され、HRD 画面が表示されないようにすることができます。具体的には、次の 3 つの方法があります。

■AD ユーザーの認証では自動的にレルムを選択
Active Directory ドメインにサインインしているユーザーが ADFS サーバーにトークンの発行要求を行う場合、Windows 統合認証によって自動的にサインインしているドメインの情報が ADFS サーバーに送信されます。このとき、ADFS サーバーは以下のコマンドレットを実行し、設定しておくことで、ユーザーのドメインに合わせた IdP が自動的に選択されるよう、構成できます。

Set-AdfsProperties –IntranetUseLocalClaimProvider $True

■利用する SP に合わせて自動的にレルムを選択
SAML-P のパッシブプロファイルでは、IdP での認証プロセスの前に SP に接続し、認証を行う IdP を選択します。このとき、利用した SP に基づいて自動的に選択する IdP を決定するよう、SP と IdP の組み合わせを設定しておくことができます。

Set-AdfsRelyingPartyTrust –TargetName <SP 名> `
-ClaimProviderName @(“<IdP 名>”)

■サインインユーザー名で自動的にレルムを選択
ADFS サーバーのフォーム認証画面で認証を行う際、入力したユーザー名のドメイン名部分に基づいてユーザーに合わせた IdP が自動的に選択されるよう、構成することもできます。例えば、adfs.jp ドメインの場合には IdP1 レルムを利用するように、と設定している場合、サインイン画面で、ユーザー名にharaguchi@adfs.jp と入力すれば、自動的に IdP1 レルムで認証が行われるようになります。

Set-AdfsClaimsProviderTrust –TargetName “<IdP 名>” `
–OrganizationalAccountSuffix @(“<ユーザーのドメイン名部分>”)

SharePoint のレルム選択
SharePoint Server で ID プロバイダー認証を設定し、ADFS サーバー経由による認証・認可を設定すると、Active Directory 認証を行うか、ID プロバイダー認証を行うかを選択する画面 (HRD 画面) が表示されます。このときに表示される HRD 画面は ADFS サーバーではなく、SharePoint Server で実装している機能に基づいて表示されるものなので、HRD のカスタマイズは SharePoint Server の設定で行う必要があります。

■Using the WHR Parameter with SharePoint 2010 and SAML Auth
http://blogs.technet.com/b/speschka/archive/2011/09/14/using-the-whr-parameter-with-sharepoint-2010-and-saml-auth.aspx

編集後記

いよいよ最後の章まで来ました。運用というタイトルがついているけど、実際にはサインインページのカスタマイズなどのTips集をお届けしました。
次回は最終回としてADFSのトラブルシューティングについてお伝えします。お楽しみに。

皆さんこんにちは。国井です。
いよいよADFSテキスト全文公開チャレンジも最終回になりました。
最終回はトラブルシューティングについて解説します。

■ ■ ■

ADFS では、設定項目が多岐にわたるため、設定を誤るなどしてトラブルが発生すると、トラブルシューティングが難しくなります。そこで、ここではトラブルシューティングを効率よく行うために利用可能なツールを紹介します。

■イベントログ
ADFS で発生したアクティビティーは Windows イベント ログに記録されます。ADFS関連のイベントログには、ADFS Admin ログ、ADFS Debug ログ、セキュリティ ログがあります。

■パフォーマンスモニター
パフォーマンスモニターでは、ADFS へのアクセス数などをリアルタイムで確認できます。

ADFS サーバーで行われたアクティビティーのうち、サービスの開始・停止やトラブルが発生した特定のアクティビティーについてはADFS Admin ログから、その内容を確認できます。

特に、ADFS の構成が問題で、Web アプリケーションによる ID 連携に失敗する場合、エラーを示す Web ページに 参照番号 (Activity ID) が表示されます。参照番号は、イベントログにも同様の ID が表示されるため、Web アプリケーションにアクセスしたときに発生したトラブルがどのイベントログによって表されているか確認できます。

一方、膨大なイベントログの中から特定の参照番号を持つログを探し出す場合には、フィルターを使用してください。イベントビューアーのフィルター機能では、XPath 形式のクエリーを記述することができるため、以下のようなクエリーを記述することで、特定の 参照番号を持つログを容易に探し出すことができるようになります。

<QueryList>
<Query Id=”0” Path=”AD FS/Admin”>
<Select Path=”AD FS/Admin”>
*[System[Correlation[@ActivityID=”{ActivityID}”]]]
</Select>
</Query>
</QueryList>

ADFS Debug ログは、ADFS に関わるアクティビティーを追跡するために利用できるログです。ADFS Admin ログとは異なり、トラブルの有無に関わりなく記録されるため、有効にすると膨大なログが記録されます。そのため、トラブルシューティングを行うなど、明確な目的があるときだけ利用します。

既定では、Debug ログは無効になっているため、利用する場合には次の方法で有効にします。

■ADFS Admin ログから [分析およびデバッグ ログの表示] を有効にする
Admin ログを右クリックし、[表示] – [分析およびデバッグ ログの表示] をクリックすると、項目が表示されます。

■ADFS debug ログから [ログの有効化] を実行する
Debug ログを右クリックし、[ログの有効化] をクリックするとトレースログが有効になります。Debugログは Admin ログに比べて多くのログを出力するため、トラブルシューティングなどの目的で記録したいときだけ有効にしてください。Debug ログを無効にするときは Debug ログを右クリックし、[ログの無効化] をクリックします。

Debug ログは最大ログサイズが 50MB に設定されており、また 50MB に達しても古いログを上書きしません。50MB 以上のログを記録できるようにするためには、debug ログのプロパティから最大ログサイズを変更します。

ADFS を利用した ID 連携でトラブルが発生した場合、トラブルの原因が ADFS にあれば、ほとんどのケースにおいて Admin ログにトラブルの内容が記録されます。ここでは、Admin ログに記録された内容を中心にトラブルシューティングを行う方法について解説します。

■イベント ID 364 が記録された。
イベント ID 364 はパッシブ プロファイルを利用してクレーム ベース認証を行おうとしたときに、発生したエラーを表します。このエラーが発生するときには、イベント ID 133 が続けて記録されますが、根本的な問題の原因はイベント ID 364 にあります。このエラーが発生した場合、以下のトラブルの可能性があります。

・ADFS サーバーに証明書がインストールされていない
・証明書として、コンピューター用証明書ではなく、ユーザー用証明書がインストールされている
・プライベートキーを含む証明書に対する ADFS サービス アカウントのアクセス許可がない
・証明書が失効していることを確認するための CRL にアクセスできない
・証明書の CN や SAN で示される名前が適切ではない
など

■イベント ID 342 が記録された。(1)
イベント ID 342 はトークンの検証に失敗したことを表します。トークンの検証に失敗する原因として、証明書の正当性の問題が考えられます。特にイベント ID 364 が一緒に生成される場合は証明書関連の問題であることが高いです。その場合には、証明書のプロパティを開き、証明書に記載されている名前 (CN など)に誤りがないか、証明書に記載されている CRL にアクセスできるか、などを確認してください。

■イベント ID 342 が記録された。(2)
イベント ID 342 はトークンの検証に失敗したことを表します。トークンの検証に失敗する原因として、Windows認証の失敗が考えられます。特に、ドメイン名\ユーザー名の形式でユーザー名を入力しなければならないのに、ドメイン名を入力していない、入力すべきドメイン名を間違えているなどを確認してください。

■イベント ID 278 が記録された。
イベント ID 278 は SAML アーティファクト プロファイルをサポートするサーバー構成でないときに記録されます。SAML アーティファクト プロファイルは ADFS サーバーのデータベースに SQL Server を利用していることが前提となるため、組み込みのデータベースで ADFS サーバーをインストールしている場合は必ず出力されます。SAML アーティファクト プロファイルを利用しない限り、問題にはなりませんので、無視してください。

■イベント ID 415 が記録された。
イベント ID 415 は Workplace Join 機能を利用して、ADFS サーバー経由でデバイス登録を行うために必要な構成ではないときに記録されます。ADFS サーバーでデバイス登録を行うためには ADFS サーバーに実装された証明書の SAN に enterpriseregistration～で始まる名前が含まれている必要がありますが、実際に実装されている証明書には含まれていないことが原因です。ただし、ADFS サーバー経由でデバイス登録を行う必要がない場合は問題にはなりませんので、無視してください。

■イベント ID 184 が記録された。
イベント ID 184 は証明書に関するエラーを表します。このエラーが発生するときの特徴は、ブラウザーからアクセスしたときに、ブラウザー画面にX.509 Certificateに関するエラー画面が表示されることと、イベント ID 364 が後続するエラーログとして記録される点です。このエラーが発生するときは、証明書の発行方法に問題があると考えられますので、証明書のインストールを再設定してください。また、認証局がADFS サーバーの信頼されたルート証明機関に登録されていることも同時に確認してください。

■イベント ID 102 が記録された。
イベント ID 102 はサービス起動に関するエラーを表します。原因は様々ですが、実装直後に考えられる原因としては ADFS サーバーに対応するファイアウォールルールが構成されていないことが原因でエンドポイントの有効化に失敗することが考えられます。ADFS サーバーは起動時にファイアウォールルールを構成するので、サービスを再起動してファイアウォールルールが作成されることを確認するとよいでしょう。

■イベント ID 133 が記録された。
イベント ID 133 はトークンにアクセスできないエラーを表します。ただし、実態は証明書に関連するトラブルがほとんどです。このエラーが発生するときには、イベント ID 102 と 364 が続けて記録されますが、根本的な問題の原因はイベント ID 133 にあります。このエラーが発生した場合、以下のトラブルの可能性があります。

・プライベートキーを含む証明書に対する ADFS サービス アカウントのアクセス許可がない
・証明書として、コンピューター用証明書ではなく、ユーザー用証明書がインストールされている
・プライベートキーを含む証明書に対する ADFS サービス アカウントのアクセス許可がない
・証明書として、pfx ファイルではなく、cer ファイルがインポートされた

■イベント ID 325 が記録された。
イベント ID 325 は RP の認可に失敗したことを表すログです。認可に関しては [発行承認規則] で定義されているので、この規則で許可されないクレームをトークン内に持っている場合に認可に失敗します。そのほか、発行承認規則で認可の基準となる情報をクレームで持っていない場合 (emailaddress属性をもとに認可を行うのに、トークンにはemailaddress属性が含まれていないなど) にも同様のエラーとなります。そのため、イベント ID 325 が記録された時には、後続のログにイベント ID 501 が記録されるので、イベント ID 501 のログから発行されたトークンの内容を確認し、発行承認規則で必要とする属性がトークンとして CP で発行されているか確認してください。

■イベント ID 315 が記録された。
イベント ID 315 はトークン証明証明書で使われる証明書チェーンの検証に失敗したことを表します。異なる組織間で ID 連携を展開する場合、RP の組織から CP の組織で展開する認証局へのアクセス (CDP と AIA) が必須になります。CP の組織の認証局がイントラネット内で展開され、外部からのアクセスが許可されていない場合には、Set-ADFSClaimsProviderTrust コマンドレットで、検証を行わないように設定してください。

■イベント ID 218/276/394 が記録された。
イベント ID 218/276/394/422 は Web アプリケーション プロキシが ADFS フェデレーション サーバーとの信頼関係が確認できなかったときに、Web アプリケーションプロキシのイベント ビューア―で記録されます。原因はどのようなイベント ID が記録されるかによって分類することができます。

イベント ID 218 が記録される場合、ADFS サーバーで入れ替えた証明書が Web アプリケーション プロキシに実装されていないことによるトラブルや、ADFS サーバーと Web アプリケーション プロキシの時刻がずれていることが考えられます。特に、時刻がずれている場合には Web アプリケーション プロキシを再構成することも検討してください。

イベント ID 276 が記録される場合、ADFS サーバーで Web アプリケーションプロキシとの信頼が失効したことを表します。この場合には Web アプリケーション プロキシの再構成が必須になります。なお、信頼が失効している場合、Web アプリケーション プロキシ側からはイベント ID 422 で確認できます。

イベント ID 422 が記録される場合、ADFS サーバーと Web アプリケーションプロキシの間で物理的に接続できないことが考えられます。このイベントが表示された場合にはまず物理的な接続が確立されていることや DNS や Hosts ファイルによる名前解決が正しく行えていることを確認してください。ADFS サーバーと Web アプリケーション プロキシの間での同期は 1 分おきに行われるため、最初のエラーログを参照することで、トラブルが始まった、おおよその日時を特定することも可能です。
対処方法としては Install-WebApplicationProxyコマンドレットを実行し、改めて ADFS サーバーと Web アプリケーションプロキシの間で信頼関係を設定してください。

また、以上のトラブルが ADFS 2.x サーバーで発生する場合、イベント ID 394 で確認できます。

■イベント ID 376 が記録された。
イベント ID 376 は 属性ストアとして、Active Directory 以外のものを利用している際、要求規則に記載されている情報に基づいて正しいデータを取得できない際に記録されます。このイベント ID では、属性ストアの SQL 接続文字列の問題、SQL 属性ストアに接続できない、データベースとクエリーの正当性の問題、のいずれかが原因です。イベント ID 376 では、ログ内に詳細なエラー関連情報が記録されるので、イベントログの内容を確認するのは、とても有効な手段です。

■イベント ID 377 が記録された。
イベント ID 377 は 要求規則に記述されたクレーム ルールの内容に問題があるときに記録されます。このイベント ID が記録された時には、クレームルールの内容を再確認してください。

■アプリケーションログ : イベント ID 1309 が記録された。
イベント ID 1309 はASP.NETの処理でエラーが発生したときに記録されるログです。この場合、ASP.NET の処理をつかさどるプロセスである w3wp.exe を強制終了してください。また、ログの詳細メッセージで「例外メッセージ ID3206 SignInResponseメッセージは、現在の Web アプリケーション内でのみリダイレクトされます」と表示される場合には、URL の最後に / (スラッシュ) が抜けていることが原因として考えられますので、クライアントコンピューターのブラウザー画面で、URL を確認してください。

ADFS の処理に関して、その他のイベント ID が記録され、エラーが発生する場合、マイクロソフト TechNet Web サイトを参照してください。

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff641746(v=ws.10)?redirectedfrom=MSDN

ADFS では、パフォーマンスモニターを利用してADFSによるトークン発行のアクティビティーをリアルタイムで確認できます。トークン発行に関わるパフォーマンスを確認する場合や、トラブルシューティングを行うときに役立てることが可能です。

ADFS では、実装するために行わなければならない項目が多いため、設定ミスによりトラブルが発生することがあります。こうしたトラブルが発生したときには、一般的なトラブルシューティングと同じく、トラブルの切り分けを行うことが重要になります。

SAML Tracer ツールは、Firefox のアドオンプログラムで、HTTP のヘッダーをリアルタイムで表示します。ヘッダーの内容を参照しながら通信中に送受信される SAML トークンの内容を確認することで、トラブルシューティングをしやすくし、トラブルの原因を見つけやすくする効果があります。

SAML Tracer ツールはインストールすると、メニューから [SAML Tracer] アイコンをクリックすることで、別ウィンドウが表示され、ウィンドウ内で Firefox 内での通信の様子を確認できます。

また、HTTP ヘッダー内に表示されるフェデレーション プロトコルの内容は [Parameters] タブをクリックして確認できます。

SAML Tracer で HTTP ヘッダーの追跡を行い、トラブルシューティングを行うためには、まず正常な通信で発生するヘッダーについて知る必要があります。ここでは、Office 365へブラウザーからシングルサインオンアクセスする際に発生する、HTTP ヘッダーについて確認します。

① GET /
Office 365 のサイトにアクセスします。このとき、アクセストークンを持たない状態でアクセスしているため、Azure AD サイトにリダイレクトされます。

② GET /login.srf?wa=wsignin1.0&…
Azure AD サイトにリダイレクトされたときに最初にアクセスするページが login.srf ページです。この後、ブラウザー画面では、サインインページが表示されます。

③ GET /common/userrealm/?user=…
サインインページで、ユーザー名を入力すると、そのサインインユーザーがシングルサインオン用ドメインを利用していることを確認し、ADFS サーバーへリダイレクトします。この URL はユーザー名を入力した後に最初にアクセスする URL です。

④ GET /adfs/ls/wia?lc=1041&username=…&wa=wsignin1.0&wtrealm=urn…
ADFS サーバーにアクセスすると、トークン発行のためのやり取りが始まります。この URL ではサインインページで入力したユーザー名 (username=部分) を ADFS サーバーに引き渡して、トークン発行処理を開始しています。なお、ユーザー名がブラウザーでキャッシュされているときなどは、この URL にアクセスしない場合があります。

⑤ POST /login.srf
ADFS サーバーでトークンが発行されると、Azure AD にトークンを持ってアクセスします。そのときに最初にアクセスするページが login.srf ページです。login.srf ページではトークンを Azure AD に引き渡すため、POST メソッドを使ってアクセスしています。

⑥ POST /landing.aspx?target=%2fdefault.aspx&wa=wsignin1.0
Azure AD での認可プロセスが完了すると、Office 365 にアクセスするためのトークンが発行されます。アクセストークンを持って Office365にアクセスする際に利用するページが landing.aspx ページです。

以上のページ以外にも実際の通信では様々なパケットが送受信されます。しかし、以上のおおまかな流れを理解しておくことで、トラブルが発生した際にどこまでの通信ができているかを把握し、次に行うべきアクションをご自身で判断できるようになります。

SAML Tracer アドオンから参照可能な HTTP ヘッダーには、？以降の部分に様々なパラメーターが記述されています。これらのパラメーターはフェデレーションプロトコルで定義されたものを記述しており、プロトコル種類によって記述すべき項目は異なります。ここでは、それぞれのプロトコルで使用する、主なパラメーターについて解説します。

■WS-Federation：wa=
wa= はアクションを表します。例えば、wsignin=1.0 と記述されている場合、これからサインインを行うことを表します。

■WS-Federation：wtrealm=
wtrealm= はレルムを表します。レルムは STS 信頼を結ぶ相手を表しますので、Office365にアクセスしている場合では、レルムとして Azure AD を表す情報 (urn:federation:MicrosoftOnline) が記述されています。

■WS-Federation：wctx=
wctx= は相手の STS に伝える URL などのセッション情報が入ります。

■WS-Federation：wct=
wct= は時刻の情報が入ります。

■SAML：SAMLRequest=
SAMLRequest= には SAML トークンの情報が Base64 形式でエンコードされた形で入ります。エンコードされたデータは SAML Debugger サイトなどを通じてデコードし、参照することができます。

■SAML：RelayState=
RelayState= には相手の STS に伝えるセッション情報が入ります。

■SAML：SigAlg=
SigAlg= には後続のデータで格納される署名データの署名アルゴリズムの情報が入ります。

■SAML：Signature=
Signature= には SAMLRequest のデジタル署名が入ります。

Office 2016 および Office 2013 では ADAL (Active Directory Authentication Library) に対応し、Office アプリケーションからでも多要素認証が利用できるようになりました。しかし、一部のバージョンのOffice 2013 では ADAL から利用する Windows 統合認証に WS-Trust 1.3の
/adfs/services/trust/13/windowstransport エンドポイントを利用します (通常は WS-Trust 2005 のエンドポイントを使用)。このエンドポイントは ADFS サーバー既定の設定で無効になっており、このことが原因で社内から ADAL アプリを利用して認証を行うとエラーになる場合があります。このようなケースでは、/adfs/services/trust/13/windowstransport エンドポイントを有効化し、ADAL アプリからも認証・認可ができるように構成してください。

iPhone や Android などのドメイン参加を行わないデバイスは、Office 365 へのサインインにユーザー名/パスワードを入力する認証を必要とします。しかし、既定では Web アプリケーションプロキシを経由しない認証にはフォーム認証ではなく、Windows 統合認証を利用するため、Windows 統合認証をサポートしないiPhone や Android などのデバイスが社内ネットワークから認証しようとするとエラーになります。

この場合、社内ネットワークからでもフォーム認証が利用できるよう、ADFS 管理ツールから [認証ポリシー] を右クリックし、[グローバル プライマリ認証の編集] をクリックして、[イントラネット] 欄の [フォーム認証] を有効にしてください。

ADFS サーバーでは、Active Directory の認証情報をベースにトークンを発行します。そのため、認証・認可に関わるサーバーが Kerberos の仕様に基づいて動作しなければなりません。中でも注意しなければならない点は Kerberos の時刻に関する仕様です。

Active Directory (Kerberos) では、既定で ドメインコントローラーとコンピューターの間で 5分以上の時刻のズレがあると、Kerberos 認証・認可を行うのにふさわしくない相手と判断し、処理が中止します。ドメイン参加しているコンピューターの場合には Active Directory の機能により、ドメインコントローラーと自動的に時刻を同期しますが、Web アプリケーション プロキシのように、DMZ にサーバーが配置されている場合にはドメイン参加していないことが多いため、時刻のズレが発生する可能性があります。

もし、内部ネットワークからのシングルサインオンは成功するにもかかわらず、外部ネットワークからのシングルサインオンに失敗する場合には、Web アプリケーションプロキシの時刻を確認してください。

ADFS サーバーでは、Active Directory で認証したユーザーの情報を LSA にキャッシュします。具体的には、ユーザーの名前と SID のマッピング情報をキャッシュし、SID に対応する名前を毎回 Active Directory を参照しなくてもよいようにしています。

しかし、Active Directory でユーザーの名前 (sAMAccountName または UPN) が変更しても、キャッシュにはその変更がしばらくの間、反映されません。そのため、名前を変更しても変更前の名前がクレームにセットされてしまいます。このような問題を解決するには、以下の方法で対処します。

■ADFS サービスを再起動する
ADFS サービスを再起動することによって、キャッシュはすべて削除され、ADFS サーバーは新しくユーザーの名前を取得します。

■キャッシュサイズを変更する
キャッシュはレジストリで定義されています。レジストリの設定を直接編集することで、キャッシュしないように設定することが可能です。
レジストリ HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA の
LsaLookupCacheMaxSize (DWORD値) の値を 0 に設定することで、キャッシュされないように定義できます。

編集後記

ついに341ページあったテキストをすべて公開完了しました。
「ADFSを知ってもらいたい」という一心で採算とか度外視でテキストの開発には多くの時間を費やしてきました。
2012年からこのトレーニングを始めて現在はAzure ADのトレーニングに引き継がれるまで、
8年にわたってシングルサインオンの話をし続けたわけですが、
結果的にこういった主張をあちこちで見かけるようになったことは
(自分がSAMLを流行らせたわけでも全くないけど)本当にうれしく思います。

■なぜWebサービスの選定においてSAML/SSOが重要なのか
https://oka-lab.jp/importance-of-saml-sso-in-web-services

ADFSのテキスト自体は減価償却も終わったし、今でも誰かの役に立つならと思い、公開することにしました。このテキスト公開は私にとってADFSからの卒業みたいなもので、卒業していったい何わかるというのかわからないけど、知っていることは全部書いときました。だからADFSの質問はもう私にしないでくださいw

おわり