SharePoint 2010 のアカウント ID 変更ツール SPMigrateUsers

原文の記事の投稿日: 2012 年 6 月 3 日 (日曜日)

SharePoint を運用しているとアカウント ID の変更が必要になることがあります。SAML クレームはそのよい例です。私は、自分が扱ってきた事例の影響もあってか、ユーザーの ID クレームには電子メール アドレスを使うことにしています。こうするのは、a) ほとんどの人々は電子メール アドレスを持っている、b) 電子メール アドレスはほとんどのユーザーに理解される、という 2 つの理由によります。しかし、電子メール アドレスは人々により変更されるという理由で、それを使うことに躊躇することもよくあります。電子メール アドレスを変更すると、当然、すべてのアクセス許可は失効するわけです。正直なところ、私は変更がそれほど頻繁に起こるとは考えていません。もしそうなら、電子メール アドレスなど端から使わないでしょう。ただし、ときどきは変更されるので、SharePoint を電子メール アドレスで保護しているとき、どのような処置が必要になるかを考えてみましょう。

この問題を扱うときの要点は、IMigrateUserCallback インターフェイスに関する以前のブログ投稿 (https://blogs.msdn.com/b/sharepoint_jp/archive/2011/03/07/windows-saml.aspx) で説明しています。先の投稿記事では、IMigrateUserCallback インターフェイスで ID を移行するときの手順と、Windows クレーム ID を SAML クレーム ID に変換する例を示しましたが、変更すべき資格情報を入力するだけで必要な変更が自動的に行われる簡単な Windows アプリケーションがあればよいと考え、それを作成することにしました。こうした変更は本来、各自の状況に即して作られた簡単なツールで行うべきことなのですが、本稿に添付したソース コードを基に、もっと独創的なツールを開発してもよいでしょう。たとえば、ファイルやデータベースからユーザーの一覧を読み込んで、自分自身で照合するといったこともできます。

このツールにもよいところがあります。それは多くのシナリオに対応できることです。電子メール アドレスを別のアドレスに変換できるのはもちろん、グループ名を別のグループ名に変換することもできます。後者は Ops 関係者が教えてくれたもう 1 つのケースで、実際、グループの名前を変更しても SID は変化しないので、グループ名 (たとえば、SAML のロール クレーム) に SID を使うのは自然なことなのでしょう。とは言え、a) これがそれほど頻繁に起こるとは思えない、b) 多くの人々はとりあえずグループの SID 名を入力し、それから SharePoint グループに追加するのがよいと考えている (このやり方を当然と思うのは問題なのですが)、c) SID はローカルな Active Directory の外部では何の意味も持たない、ということもまた事実なので、Azure、Google、Yahoo、Facebook などのクラウド ベースのサービスに移行すると、現在使っている SID はたちまち、まるで役に立たなくなります。

このツールのよい点はまだあります。それは変更の範囲を特定の種類のプロバイダーに限定しなくてよいことです。Windows グループを SAML ロール クレームに変更することもできれば、SAML ID クレームを FBA メンバーシップ ユーザーに変更することもできます。FBA ロールを AD グループに変更することもできます。要するに、さまざまなプロバイダーの間で、“ユーザー”と“グループ”の組み合わせをひととおりり試し、今までのところどちらからどちらへの変換もうまくできているということです。

このツールの使い方は簡単です。次にそれを示します。

起動すると、最初に Web アプリケーションの一覧が読み込まれます。Web アプリケーションごとに、その下の 2 つのコンボ ボックスに当該 Web アプリケーションで使われているプロバイダーの一覧が設定されます。複数の SAML プロバイダーまたは複数の FBA プロバイダーがある場合、各プロバイダーはドロップ ダウン リストに表示されます。ここでの操作は移行元と移行先のプロバイダーを選択するだけです。[クレーム値] (Claim Value) セクションでは、移行前と移行後の値を入力します。それぞれの [テキスト値] (Plain Text Value) 編集フィールドに値を入力し、ID クレームのボタン (左側) かグループ クレームのボタン (右側) をクリックします。詳細は、ここに表示される説明を読めばわかります。また、各ボタンの表示ラベルは、使用している ID プロバイダーに応じて、より適切な内容を反映するように変化します。

たとえば、SAML 認証だけを使用しているとき、電子メール アドレス「steve@contoso.com」を「stevep@contoso.com」に移行することを考えます。この場合、Web アプリケーションを選択すると、各ドロップ ダウン リストでは既定で SAML 認証プロバイダーが選択された状態になります。次に、[移行前の値] (Before Values) セクションで、[テキスト値] (Plain Text Value) 編集フィールドに「steve@contoso.com」と入力し、[ID クレーム] (ID Claim) ボタンをクリックします。これで、適切にエンコードされたクレーム値が [エンコードされた値] (Encoded Value) 編集フィールドに設定されます。次に、[移行後の値] (After Values) セクションの [テキスト値] (Plain Text Value) 編集フィールドに「stevep@contoso.com」と入力します。再び [ID クレーム] (ID Claim) ボタンをクリックすると、適切な値が [エンコードされた値] (Encoded Value) 編集フィールドに設定されます (注意: 上図で [移行後の値] (After Values) セクションのボタンの表示ラベルが「ID クレーム (ID Claim)」ではなく「ユーザー (User)」になっているのは、SAML クレームから Windows クレームに移行しようとしているからです)。すべての値を設定した後、[移行] (Migrate) ボタンをクリックすると、必要な処理が実行され、移行完了を知らせるメッセージ ボックスが表示されます。

さまざまな Web アプリケーションと数種類の認証についてこれをテストしたところ、いくつか問題点が見つかったので、読者が同じ問題に遭遇したときのために一応まとめておきます。第一に、ある特定の Web アプリケーションのユーザーを移行しようとしたところ、「Access Denied (アクセスが拒否されました)」というエラー メッセージが返されましたが、問題の原因を突き止めることはできませんでした。筆者のファーム内の他の 4 つないし 5 つの Web アプリケーションでは問題が生じなかったので、その Web アプリケーションにどこか不具合があるとは言えても、それが何であるか確実なことは言えません。

第二に、移行が正常に完了したと通知されたのに移行後のユーザーでログインできないことがありました。問題を詳しく調べたところ、移行元のアカウントが IMigrateUserCallback 関数でプッシュされていないことが判明しました (つまり、ツールのコーディング上の問題というよりも、SharePoint の問題です)。この問題に遭遇した場合は、添付のソース コードと Visual Studio を使い、デバッガーをステップ実行して移行元のアカウントが本当に呼び出されているか確認することをお勧めします。残念ながら、筆者の場合には、ある 1 つの FBA メンバーシップ ユーザーがこの問題に見舞われました。

最後に、注意点を 1 つ。アカウントをある値から別の値に移行し、新しいユーザーでログインしたとき、ページの右上隅のウェルカム コントロールに以前のアカウント名などが表示されても慌てないでください。この移行関数ではアカウント名しか変更されません。その後、ユーザー プロファイルを更新することがあって、その際に他のユーザー情報が少しでも変更されれば、プロファイル システムとの次回の同期時に正しい情報がすべてのサイト コレクションにプッシュされるはずです。

以上、このツールが読者の役に立てば幸いです。上で述べたように、完全なソース コードが添付してあるので、自由にテストしてみてください。必要なら読者のシナリオに応じて変更するとよいでしょう。

これはローカライズされたブログ投稿です。原文の記事は、「The SPMigrateUsers Tool for Changing Account Identities in SharePoint 2010」をご覧ください。