SharePoint 2013 の認証時に使用されるトークンキャッシュについて

  • Article

こんにちは。SharePoint サポートチームの荒川です。

 

以前に投稿された「SharePoint 2013 Active Directory セキュリティ グループを使用した権限設定時の留意点」について、お客様から色々とご質問をいただきましたので、今回の投稿では、この件についてもう少し詳しく解説したいと思います。

 

前回の投稿では、SharePoint 2013 において Active Directory セキュリティ グループを経由してサイトに権限登録されたユーザーがしばらくの間サイトにアクセスできない場合があることについて説明しました。

 

たとえば、以下の状況について考えてみます。

 

1. 以下の 2 つのユーザーアカウントを AD 上に作成します。

 

   contoso\user01

   contoso\user02

 

2. SharePoint サイトに user01 と user02 の権限を付与していない状態で、試しに user01 でサイトにアクセスしてみます。当然、サイトからはアクセス拒否を示すエラーメッセージが返されます。

3. 各ユーザーをそれぞれセキュリティ グループ contoso\group01 に追加します。

4. サイトに group01 のアクセス権限を付与してから、user01 と user02 それぞれでサイトへのアクセスを試みます。

 

この結果どうなるかというと、user01 は引き続きサイトへのログオンに失敗し、user02 だけがサイトへのアクセスに成功します。

何故、このような動作が起きるかについてこれから解説していきます。

 

user01 と user02 の違いは？

user01 と user02 はそれぞれ同じセキュリティ グループ経由でサイトに権限を付与されていますので、設定内容に違いはありません。唯一の違いは、セキュリティ グループに追加する前に、サイトにアクセスしたか、していないかの違いになります。

では、なぜセキュリティ グループに追加する前にサイトにアクセスした user01 では、権限付与後も引き続きサイトにアクセスできなかったのでしょうか。その答えは SharePoint のキャッシュ機能にあります。

 

ログオントークンキャッシュって何？

SharePoint の認証の仕組みでは、認証プロセスと承認プロセスの 2 つの段階があります。

認証プロセスでは、そのユーザーが確かに本人であるということを確認し、承認プロセスではそのユーザーがコンテンツにアクセス権を持っているかどうかの評価をします。クレームベース認証では、認証を受けたユーザーにはログオン トークンが返されて、ユーザーは SharePoint にそのログオン トークン情報を渡すことで、承認プロセスを受ける仕組みになっています。

 

ユーザー数が多い環境では、ログオントークンの生成に負荷がかかる可能性があるため、SharePoint Server 2013 では、パフォーマンスとスケーラビリティの向上のため、新たに追加された機能である分散キャッシュサービス上に、クレームベース認証で使用されるユーザーのログオントークン情報がキャッシュされ、再利用される仕組みになっています。

 

何故問題が発生するのか

今回の問題が発生した原因は、SharePoint が user01 に古いログオン トークン情報を渡してしまったことにあります。

ログオン トークン情報には、ユーザーがどのセキュリティグループに所属しているかといった情報が含まれています。先のケースでは、user01 が最初に group01 に所属していない状態でサイトへのアクセスを 試みてしまったため、このタイミングで SharePoint 側に group01 に所属していない状態での user01 のログオン トークン情報がキャッシュされてしまいました。

 

このキャッシュ情報は所定の有効期限が経過するまでは再利用されてしまうため、user01 は既にキャッシュされた group01 に所属する前のトークン情報を受け取ってしまい、その結果承認プロセスで権限なしと評価されてしまったのです。

 

なお、group01 に所属してから初めてサイトにアクセスした user02 では、このタイミングで新しいログオントークンキャッシュが生成され、この中に group01 の情報が含まれていたため問題は発生しませんでした。

 

対処策は？

この問題の対処方法にはいくつかの方法が考えられます。

 

1. ログオントークンキャッシュのタイムアウト期間を短くする

クレームベース認証における Windows 認証のログオン トークンキャッシュの有効期限は既定では 10 時間に設定されています。

このタイムアウト期間を意図的に短くすることで、AD 側で権限の変更があった際にできるだけ早く、SharePoint に反映することができます。

 

以下のコマンドでは、Windows 認証のログオン トークンキャッシュの有効期限を 3 時間に変更します。

 

$sts = Get-SPSecurityTokenServiceConfig

$sts.WindowsTokenLifetime = "03:00:00"

$sts.LogonTokenCacheExpirationWindow = (New-TimeSpan -minutes 10)

$sts.Update()

 

LogonTokenCacheExpirationWindow では、実際にトークンが有効期限切れになるまでの猶予期間を指定します。既定値は 10 分です。たとえば、上記の例では、WindowsTokenLifetime は 3 時間に設定されていますが、現在サイトにアクセスしているユーザーに対しては、有効期限の 10 分前になった段階で、トークンキャッシュの再作成を行うために認証要求を行います。これにより、コンテンツを利用しているユーザーが利用中に突然利用できなくなることを防いでいます。LogonTokenCacheExpirationWindow の値は、特別な要件がない限りは、既定の 10 分を指定していただき、WindowsTokenLifetime の値は 10 分より短い値にしないことをお勧めします。

 

また、WindowsTokenLifetime を極端に短くすると、頻繁に再認証を求められることになり、サーバー側の負担が大きくなりますので、ここには既定の 10 時間の範囲内で、できる限り長めの時間をとっていただくことをお勧めします。

 

なお、本設定は今後新しく発行されるログオン トークンキャッシュに対して有効になるもので、既にログオン トークン キャッシュが生成されており、アクセス拒否を受けているユーザーに即座に反映させるには、後述の 2 の方法でログオン トークン キャッシュを一旦リセットする必要がありますのでご注意ください。

 

2. ログオン トークン キャッシュをリセットする

AD 上での権限変更が計画的なもので、ログオン トークン キャッシュの有効期限を待たずに速やかに反映させたい場合には、ログオン トークン キャッシュをリセットすることが有効です。

具体的な方法については、以前の記事「SharePoint 2013 Active Directory セキュリティ グループを使用した権限設定時の留意点」をご参照ください。

 

備考: stsadm -o setproperty -pn token-timeout で設定するトークン タイム アウトについて

今回の投稿で解説した WindowsTokenLifetime の設定とは別に、stsadm -o setproperty -pn token-timeout で設定するトークン タイム アウトというものがあります。

これは、SharePoint 2013 以前のバージョン (SPS2010、MOSS2007) から存在した設定で、Microsoft.SharePoint.SPUserオブジェクトから取得される、ユーザーのユーザー トークン (SPUserToken) 情報のタイムアウト値であり、今回の投稿で取り上げているユーザー認証後に生成されるセキュリティ トークンとは別のものです。SPUserToken の情報は、主に、ワークフローの遅延アクティビティーやタイマージョブによる操作など、ユーザーがサイトにアクセスしていない時に、実行ユーザー アカウントを偽装する際や、対象のユーザーの権限を評価する際に使用されます。

 

通常、サイトにユーザーがアクセスする際には、HTTP 要求スレッド内に含まれるユーザートークンの情報でユーザーの権限を直接評価できますが、ワークフローの遅延アクティビティーやタイマージョブによる操作では、ユーザーの認証情報が現在の実行スレッド (HTTP 要求スレッドではない) から取得できません。そのため、別途ユーザーのトークン情報及び、トークンの有効期限に関する情報をデータベース上に適時キャッシュして利用しています。これらの情報は、コンテンツ データベースの UserInfo テーブルの tp_ExternalToken カラムおよび、tp_ExternalTokenLastUpdated カラムに格納されます。

 

SharePoint の主な標準機能では、権限の設定ページにおける「権限の確認」機能や、タイマーサービスによる、ユーザーのアクセス権に基づく通知メールの送付処理などに SPUserToken の情報が使用されています。

したがって、セキュリティ グループの変更が生じた際に、権限の設定ページにおける「権限の確認」機能が正しく機能しなかったり、権限に基づく通知メールが送付されないなどの問題が生じた場合は、今回の投稿で取り上げた WindowsTokenLifetime の例と同様に、古い SPUserToken の情報が利用されている可能性を疑うとよいでしょう。

SPUserToken の情報は既定では 1440 分 (24 時間) に設定されており、以下のコマンドにより変更が可能です。

 

例) stsadm -o setproperty -propertyname token-timeout -propertyvalue 720

 

なお、通常、SPUserToken の有効期限が切れていた場合、タイマーサービスやワーカープロセスの機能により、自動的に新しいトークンの生成が試みられます。また、サイトにユーザーがアクセスした場合は、1 時間ごとに最新のトークン情報が更新されますので、ユーザーがーサイトに長時間ログインしていないケース且つ権限の変更後、24 時間以内に問題が起きることが殆どです。ごく稀に、アカウント ドメインとリソース ドメインが分かれている環境において、サービス アカウントにアカウント ドメインへの参照権限がないため、トークンの更新に失敗するケースが報告されていますので、マルチ ドメイン環境ではサービス アカウントの権限に対する注意が必要です。

 

(参考資料)

偽装

https://msdn.microsoft.com/ja-jp/library/aa543158(v=office.12).aspx

 

Token-timeout: Stsadm property (Windows SharePoint Services)

https://technet.microsoft.com/en-us/library/cc287917(v=office.12).aspx