MOSS サイトを管理していて混乱しがちなのがユーザー管理です。特に、MOSS の場合は WSS とは異なり "ユーザープロファイル" を持っていることが混乱を招く最大の要因だと思います。今回は、ユーザー管理に関する私なりの調査内容を記しておきます。※今回は SharePoint が利用する SQL Server データベースの内容についても記述しますが、SharePoint が利用している DB は基本的には参照のみを行い、編集などはしないように注意してください。DBの直接編集はサポートされておらず、SharePoint API を通じて操作することが推奨されています。
1.よくある間違い : ユーザー認証とユーザー プロファイル
セミナーを実施していてよく勘違いされていると感じるのが MOSS のユーザー認証の仕組みです。MOSS はユーザープロファイルを保持できるが故に、ユーザー プロファイルを作成することでユーザー認証ができるようになると考えがちです。しかし、それは間違いです。MOSS そのものがユーザー認証の機能を持っているわけではありません。あくまで、Active Directory (AD) なら ドメインコントローラが認証しますし、スタンドアロンであればローカルのWindows Server 自体がユーザー認証をします。その後、各コンテンツデータベースに格納されているユーザー情報等を使用して、承認(だれにどのようなアクセスが許可されているか) をMOSSがコントロールします。ユーザープロファイルは、"人" にかかわる情報を蓄積している単なるデータベースであり、検索等の目的で利用するもので認証には利用されません。
- MOSS 上でユーザーを作成することはできない
- サイトには、あくまで、ADもしくはローカルサーバー上で作成したユーザーを "追加" しているに過ぎない
- 認証 (Authentication) はADもしくはローカルサーバーが行い、その後 MOSS は承認 (Authorization) を行う
まずはこの点を整理しておくことが肝心です。
2. ユーザー情報の格納場所
ユーザープロファイルが構成されている場合は、ユーザー情報は次の2箇所に格納されます。
- コンテンツ DB : ユーザー情報を格納
- 共有サービス プロバイダのDB : ユーザープロファイルを格納
コンテンツDB は、通常は "WSS_Content" もしくは" WSS_Content_<GUID>" という名前です。また、コンテンツDBは既定では Web アプリケーションごとに1つ作成されますので、3つWebアプリケーションを作成していれば、3つのコンテンツDBが作られているはずです。また共有サービスプロバイダ DB は既定では "SharedServices1_DB" という名前です。
- コンテンツDBとWebアプリケーションの対応付けの確認方法:
[SharePoint 3.0 サーバーの全体管理] - [Webアプリケーション構成の管理]-[コンテンツデータベース]
3. コンテンツDB内のユーザー情報
コンテンツDB 内で最初に確認するべきテーブルが 'dbo.UserInfo' です。主な列は次の通りです。
| 列名 | 説明 |
|---|
| tp_SiteID |
サイトコレクションを識別するID |
| tp_ID |
ユーザーを識別するID |
| tp_GUID |
AD または ローカルアカウントの SID (コピーされる) |
| tp_Deleted |
サイトコレクションから削除されかどうかを示すフラグ |
| tp_Login |
ログイン アカウント |
| tp_Title |
アカウントの表示名 |
| tp_Email |
電子メール アドレス |
サイトにユーザーを追加すると、AD 環境では AD のディレクトリデータベースからユーザー情報の一部が UserInfo テーブルに一方向にコピーされます。テーブルを見ると、ユーザー情報はサイトコレクション単位で管理されていることがわかります。たとえば、"SiteCollectionA" と "SiteCollectionB" の2つのサイトコレクションがある場合に、それぞれのサイトコレクション内の任意のサイトに最初にユーザーを追加したときに、UserInfo には tp_SiteIDが "xxxxxxxx" で tp_ID が "2" のエントリおよびtp_SiteIDが "yyyyyyyyy" で tp_ID が "2" のエントリが追加されます。
4.サイトからのユーザーの削除
すべてのサイトからユーザーを削除しても UserInfo テーブルからエントリは削除されません(ユーザーにひもづくアイテムなどのリンクがどこにも所属しないものとなってしまわないようにするための処置であるようです)。意外とご存じないかも知れませんが、ユーザーの削除には "サイトからの削除" と "サイトコレクションからの削除" の2つがあります。
- サイトからユーザーを削除するには:
各サイトの[サイトの管理]-[権限の設定(詳細)]にアクセスし、直接アカウントにアクセス権限を割り当てている場合はそのまま目的のアカウントを選択する。SharePoint グループに所属しているユーザーの場合はサイドリンクバーに表示されるSharePointグループにアクセスし目的のアカウントを選択する。続いて [操作] -[ユーザー権限の削除] をクリック
- サイトコレクションからユーザーを削除するには:
各サイトの[サイトの管理]-[ユーザーとグループ]にアクセスし、サイドリンクバーに表示される[すべてのユーザー]をクリックする(サイトコレクション内のユーザーを一覧できる)。削除したいユーザーを選択し、[操作] - [サイトコレクションからのユーザーの削除]をクリック
サイトコレクションから削除されたかどうかは tp_Deleted 列が使用されるようです。この値の既定値は 0 です。サイトコレクションから削除されると既定ではこの値に tp_IDの値が代入され(つまり 0 ではなくなる) エントリ自体は残り続けます。サイトコレクション内のどこかのサイトに同じユーザーが再び追加されるとtp_Deleted 列の値が0に戻ります。
5.実験と結果
以上のことを踏まえて以下のような実験をしました。
- AD上に "DeleteUser" という名前のアカウントを作成
- テスト用のチームサイトを新規に作成し、DeleteUser を追加
- AD上から "DeleteUser" を削除し、新規に同じ名前のアカウントを作成
- DeleteUser でチームサイトにアクセス
上記のことを行うと、DeleteUser はWindowsシステムにはログオンできますが、SharePoint サイトには一切アクセスできないようになります。これはSIDの相違が原因です。2.でユーザーを追加したときに、UserInfo テーブルの tp_SystemID 列にアカウントのSID がコピーされます。しかし、このコピーはあくまで一方向のもので、かつ一回限りのものです。3. で新規にアカウントを作成しましたので、当然 SID は変わります。つまりログオン時のSID と UserInfo に登録されている SID が同一ではなくなるため、結果としてアクセス拒否されるようになるようです。このことから、ドメイン移行に伴うアカウント移行を行う場合は注意が必要です。SIDを更新したり、SIDhistory を引き継ぐように構成するには、stsadm.exe が利用できるようです。
stsadm.exe -o migrateuser -oldlogin <ドメイン名\ユーザー名> -newlogin <ドメイン名\ユーザー名> (-ignoresidhistory)
ドメインの移行をしたわけでなく、今回の実験のように単純に削除した同一名のアカウントを再び利用したい場合にも、"-ignoresidhistory" オプションを指定すれば利用できるようになるです。がコマンド実行後、"ユーザープロファイル移行中にエラーが発生しました" というエラーメッセージが表示されます。ただ結果的には、実験環境ではエラーメッセージにも関わらず、同一名アカウントでのアクセスができるようになりましたので tp_SystemIDは更新されているようです。
6. UserInfo と ユーザープロファイル
サイトにユーザーを追加すると UserInfo テーブルにユーザー情報のエントリが作成されることはすでに説明しました。さて、肝心のユーザープロファイルとの兼ね合いについてです。ユーザープロファイルは共有サービス管理で管理され、ADやLDAP, BDC などのデータソースからユーザー情報をSharePoint 側へ一方向に取得できます。ユーザープロファイルは管理画面からスケジューリングすることで、一定のタイミングでデータソースから最新の情報を更新できるようになっています。ユーザープロファイルには、上司や自己紹介、技能などのさまざまなプロパティ情報が格納されます。AD 側のユーザーアカウントのプロパティとマッピングしてやることで、そのままAD上のプロパティ情報を取り込むこともできますし、SharePoint 側で独自のプロパティを用意して利用することもできます。
さて、ここからが本題です。実は、ユーザープロファイルがあると、プロファイルの情報の一部がコンテンツDB側に同期されるようになっています。SharePoint は内部プロセスとしてタイマジョブという処理を行います。このジョブの中に、"プロファイルの同期" というものがあり、既定では1時間置きに実行されています。
- タイマジョブの確認方法:
[SharePoint 3.0 サーバーの全体管理]-[サーバー構成の管理]-[タイマジョブの状態]
ユーザーアカウントの情報以外にも、自己紹介、写真などの情報も同期されるようです。が、これらのユーザー情報は、コンテンツDB内の"dbo.AllUserData" テーブルの方で保持しているようです。
7.よくある混乱 : "ようこそ○○さん"
少し話は変わって、サイトの上部にはサインインしたユーザー名が表示されているかと思います("ようこそ ○○さん" の部分)。たとえば、あるユーザーが結婚したため苗字が変わったのでAD上でアカウントの表示名を変えます。すると当然SharePoint サイトに表示されるユーザー名にもすぐに反映してほしいところですが、そうはいきません。実は、この情報は UserInfo テーブル内の情報(tp_Title列)を参照しています。よって、プロファイルの方の更新を待ってからでしか最新情報が反映されません(プロファイル更新後、最大で1時間は待つ必要がある)。
しかも、この"ようこそ ○○さん" のドロップダウンメニューにある "個人用設定" をクリックした時に、個人用サイトを作成していると個人用サイトにジャンプします(個人用サイトが作成されていない場合は、UserInfoテーブルを参照)。個人用サイトで編集するユーザーのプロファイルは、あくまで 共有サービスプロバイダDBが管理しているユーザープロファイルデータです(SharedServices1_DB内のdbo.UserProfile_Fullテーブル)。この辺は、ユーザー情報がどう管理されているか分かりにくくしているところだと思います。※ユーザーの表示名、アカウント名など一部のプロパティは既定では編集不可となっています。よってインポートによる定期的な更新が不可欠ですね。
***************************************************
大変長くなってしまいましたが、以上がユーザー管理に関する調査結果でした。参考になれば幸いです。
