2008年1月 9日 (水)

MOSS サイトにおけるユーザー管理

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.実験と結果

以上のことを踏まえて以下のような実験をしました。

  1. AD上に "DeleteUser" という名前のアカウントを作成
  2. テスト用のチームサイトを新規に作成し、DeleteUser を追加
  3. AD上から "DeleteUser" を削除し、新規に同じ名前のアカウントを作成
  4. 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テーブル)。この辺は、ユーザー情報がどう管理されているか分かりにくくしているところだと思います。※ユーザーの表示名、アカウント名など一部のプロパティは既定では編集不可となっています。よってインポートによる定期的な更新が不可欠ですね。

***************************************************
大変長くなってしまいましたが、以上がユーザー管理に関する調査結果でした。参考になれば幸いです。

トラックバック

このページのトラックバックURL: http://bb.lekumo.jp/t/trackback/718613/34255791

MOSS サイトにおけるユーザー管理を参照しているブログ:

»改名された組織名を PowerShell で強制変更する (SharePoint MANIACS)
SharePoint のプロファイル同期機能は、AD グループの変更までは同期しません。 厳密に言うと、OU の変更はインポートされます(この辺りの挙動についてはこちらのエントリ参照) しかし
トラックバック送信日: 2009年10月 6日 (火) 17:59

コメント

初コメントですm(_ _)m

ありがとうございます!
ADアカウントを削除してもサイトに残り続けるのが、若干、気持ち悪かったのですが、今、すっきりしましたhappy01
毎回、楽しく購読しておりますので、次回の記事も楽しみにしてます!

taku さん、コメントをありがとうございます! ブログは相手が見えない状態で書くものですから、直接、こうした反応を頂けると素直に嬉しいです。今後とも引き続きよろしくお願いいたします。

いつも拝見しております。
日本語にてこのように詳細に解説をして下さるサイトは
大変ありがたく感じております。

UserInfoテーブルに関してふとした疑問があるのですが、
私も動作確認を色々やってみましたが、UserInfoのレコード
そのものが削除されることは無いのでしょうか。
(動作から行くと削除済みフラグONとなるだけのような、、、

こういった場合、あるユーザー向けに作成したコンテンツを
別のユーザーさんに画像等を差し替えて売りたい!なんて
場合に、当初のユーザー会社のプロファイルとかが残存している・・・
なんて事になってしまうような気が致します。
それって個人情報保護上大変危険な気がするのですが、、、
そもそも上記のようなコンテンツの再利用自体認められていないのでしょうか。

ご意見いただけますと幸いです。
今後も随時拝読させていただきます!

onsatuさん
いつも閲覧いただいているようで、ありがとうございます!

念のためいろいろと調べてみたのですが、UserInfo のレコードそのものが削除されることはないようです。たとえば AllUserData など見てみるとユーザーにひもづいた形でアイテムなどの情報が格納されています。となると誰かが退職した場合に、その方が残していったアイテムがあるわけでして、これは会社の資産となりうる情報ですからこちらは削除するわけにはいきません。で、ユーザー情報の方だけ削除してしまうと拠り所をもたないアイテムとなってしまい都合が悪い、ということだと思います。そう考えれば、これは仕様でしょう。

さて、気にされているコンテンツの再利用のことですが、通常はサイトテンプレートもしくはサイト定義の形で提供することになるのではないかと思います。そうすれば、ユーザー情報は含まれません。マイクロソフトさんの方でも、カスタムで作成してある「サイト管理テンプレート」というものを提供されています。詳細はURLをご参照ください。http://www.microsoft.com/japan/technet/windowsserver/sharepoint/wssapps/templates/default.mspx
こういった方法がよいと思われますが、いかがでしょうか。

お返事ありがとうございます!

削除されることはないのですね、、、
となると

・既存ユーザー向けWSS_Content系をバックアップ
・新規ユーザー向けMOSSを構成
・Webアプリ作成
・コンテンツデータベースをバックアップから復元したものに入れ替え
・SSP作成
・完成catface

というお手軽(手抜き?coldsweats01)構成を目指した
私の目論見はダメダメですね、、、
それぞれコアとなるテンプレートを移行する方法で
がんばっていきます!

わざわざ調査頂いた上に資料までご提示頂きまして
誠にありがとうございましたcrying

今後とも参考にさせて頂きますので
これからも頑張ってください!

はじめまして。Kunitakaさんのブログからこちらに導かれ、勉強させていただいておりますmomochiroです。

ちょうど偶然、SPS2003でですが、この仕組みをはじめて知ったときの驚きを自分のブログに書いたところです。

弊社では、、この仕組みのところに何らかの問題があるのか・・改姓した人の表示名が自動的に新姓にならない、つまりユーザー情報にプロファイルからちゃんとデータコピーがされないようなんですが、、。orz
手でちまちまと直しております。
何か代表的な問題とか考えられるものはありますでしょうか?


なお、こちらの講師もつとめられていらっしゃるのでしょうか?ぜひぜひ開催を!
https://www.crie-illuminate.jp/training/courselist01.aspx

momochiroさん
はじめまして。お返事が遅くなりましてすみません。SPS2003ではユーザープロファイルとUserInfo間での同期はされていなかったと思います。それが、MOSS 2007 になり、同期の仕組みができてこれまでの問題が改修されたという認識です。MOSS 2007は SPS 2003 と比較してかなり詳細な部分が変わっていますが、そのひとつですね。
(参考)http://www.andrewconnell.com/blog/archive/2005/08/18/1912.aspx

またご指摘のコースは「Microsoft Office SharePoint Server 2007 ベーススキル トレーニング」でしょうか? このコースは私が現場ではきっと必要とされるはず! と思い最近開発したものでして、一部定期開催日程が決定されていませんが、近々スケジュールを公開する予定です。このコースを含め一般集客となるコースで自分が登壇する予定のものは、こちらのブログでも公開しようかと思っております。もし、ご都合がつくようでしたら、ぜひ、ご参加くださいませ。
引き続きよろしくお願いいたしますconfident

山崎さん

お返事アリガトウゴザイマス。
>SPS2003ではユーザープロファイルとUserInfo間での同期はされていなかったと思います

そうなんですか。。MSのエンジニアが勘違いしたのでしょうか。。

トレーニングはご指摘のコースです!crie-illuminateさんに開催日をお問い合わせしましたところ4月にでもとおっしゃっていただけました。上司にも承諾もらいましたし、開催される暁には絶対に参加させていただきます!

お疲れ様です。Sunmoretecの富です。

InfoPathでの表示ユーザ絞込み方法で困っています。

InfoPathのプルダウンメニューにADのユーザ表示名を出力するようにしています。
元データは個々で紹介されている「userinfo」テーブル(データ接続)です。
ただ、ユーザ数が多く、プルダウンメニュに表示するユーザをADで登録したグループで絞りたいのですが、このテーブルにある「tp_DomainGroup」項目がすべて「false」となっていて取得できないようです。

何とか、ADユーザをAD登録グループで絞り込んでInfoPathのプルダウンメニューに表示することは出来ないでしょうか?

利用しているのは SharePoint Service 3 です。

富さん

ご無沙汰しております。コメントをありがとうございます。ADユーザーをADグループで絞り込んで表示したいということですが、この場合はuserInfoテーブルではなくて、ADからLDAPなどを使って情報を取得するようなWebサービスを構築するのが妥当ではないかと思います。

そもそも InfoPath はあまり多い情報を取得してしまうと、パフォーマンス低下を招く可能性が高いので、できる限り必要な情報だけを抽出して取得することも重要ですから、そうした Web サービスは可能であれば用意したいところです。

なお、Web サービスを作成する際に、AD上のグループやグループ内のメンバシップの列挙方法については C# ベースの資料であれば、次のMSDNサイトに情報がありますので、参考になりそうです。

http://msdn.microsoft.com/ja-jp/library/ms180909(VS.80).aspx
http://msdn.microsoft.com/ja-jp/library/ms180906(VS.80).aspx

現在、InfoPathプルダウンメニューにADユーザ情報を出力できるようになりました。

LogParserでCSV出力したADユーザ情報をSharePointのリストへ読込ませて、
InfoPathのデータ接続(SharePointライブラリ、リスト)で結びつけてInfoPath内で利用しています。

また、最初に「部署」を入力してもらうことで「申請者」の表示データを絞り込んでいます。
これで、何とか実用というところまできました。

ただ、この方法だとActiveDirectoryのADユーザが追加/削除された場合、
SharePointで管理しているリストの手作業での更新が必要です。

InfoPathの他のデー接続で何とか、ADとSharePointの登録情報の自動連携を検討しましたが、

・XMLデータ接続 
 InfoPathを最初に開いたときは「部署」は取れるのですが「申請者」がうまく取れないようで断念しました

・DBデータ接続
 SharePointのDBへ接続してデータを取ろうと思いましたが、ユーザ所属グループがとれず断念しました

私が作成している感じではSharePointリストしか持続的にInfoPathでデータを利用できないような気がしています。

後は、ActiveDirectoryのADユーザ情報 ~ SharePointリスト との間で自動同期させられないものか、
検討中です。そして SharePointリスト ~ InfoPath(リスト、データ接続)へ。

今回のワークフロー&InfoPathフォームによる申請フォームは本番運用できそうですが、
やはりこの点が運用としては2重登録になり問題です。

 ActiveDirectoryのADユーザ情報 ~ SharePointリスト ~ InfoPath(リスト、データ接続)

「ActiveDirectoryのADユーザ情報 ~ SharePointリスト」間の自動更新について
お知恵を拝借できれば助かります。

このフォームの後も、社内では沢山のフォーム化(InfoPath+SharePointワークフロー)されるのを
待っている業務があるので何とかここを越ええたいと思っています。

理想としては、事務業務の半自動化/浮いた時間による社員のスキルアップ実現です。・・・(上司用)
(本当の目標は、残業時間40時間越えが続く職場環境の改善です)・・・(本音)

・・・SharePointが職場環境の救世主ソフトになってもらいたいものです。

富さん、すみません、ずっとお返事ができませんでした。AD連携の部分はInfoPathにはぜひ欲しい機能なのですが、標準では提供されていないので、いろいろと工夫が必要ですが、おそらくメンテナンスなど考えると一番効率がよいのはWebサービスで連携できるようにすることです。

ちなみに、昨日(2009/2/2)に投稿した記事に書きました書籍のサンプルコードに比較的単純なAD連携可能なWebサービスのサンプルが含まれます。まだ、弊社の側でダウンロードサイトを準備しているところなのですのでダウンロードできるようになったら、こちらのブログでも告知しますので、参考にしていただけるかと思います。

また、AD連携およびデータベース連携を比較的容易に行えるようにするWebサービス作成ツールがあります。Qdabra,Incという会社がInfoPath連携ソリューションをいろいろと出しているのですが、その会社の一製品です。ちなみに、このツールは前職のクリエ・イルミネートで販売などを扱っていますので、詳細はそちらにお問い合わせいただくとよいと思います。

★参考★ http://thesource.ofallevil.com/japan/office/2007/oba/partner/crie.mspx#ECC

はじめましてhappy01

私、MOSS駆け出し中のwolfwoodと申します。

4月から弊社内でトレーニング用のMOSSをAD環境で構築しています。

当初から
【ADに追加したドメインユーザーをSharePointサイトに追加してもアクセスできない。】
という問題がありました。

原因が全く分からず、今回質問させて頂いております。

1.ADに新規ユーザーを追加
2.ユーザープロファイルのインポート
3.トップレベルサイトにユーザーを追加

という手順で処理しても、追加したユーザーでサイトにアクセスすることができません。

Windowsにはログインできるので、コンテンツDBの問題かなとも思うのですが。。。

ただ、不思議なことに、一瞬だけアクセスすることができる方法があります。

1.サーバーのドメインを再設定(マイコンピューターのプロパティで変更)
2.再起動

を行うと、ドメインユーザーでアクセス出来る時があります。

何が原因だったのか分からず腑に落ちないまま、そのユーザーで作業をしていると、いつの間にかアクセス不能となります。。。crying

これは【タイマージョブによる同期】の影響なのでしょうか。

このような状態なのですが、どの辺りに問題がありそうなのか推測することは出来ますでしょうか?

無茶な質問すみません orz

wolfwoodさん、コメントをありがとうございます。お返事がなかなかできず申し訳ありませんでした。コメントをいただいてから、しばらく経っておりますが、現状はいかがでしょうか。ご質問いただいたところからは、ちょっと詳細状況がわかりませんが、ユーザー認証にユーザープロファイルは関係していませんので、切り分けて問題解決に臨んだ方が良いですね。また、トップレベルサイトに追加しただけでは、全サイトにアクセスできるとは限りません。まずは、認証周りで確認すべきはIIS側の認証がNTLMなのかKerberosのいずれで構成されているかを確認することです。Kerberosだと追加設定が必要な場合がありますので。また、SharePointのセキュリティ管理(アクセス権管理)の考え方が混乱されているようですので、一度整理されるとよいと思いますよ。

お返事ありがとうございましたhappy01

状況は、残念ながら全く変わっておりませんcrying

IIS認証は、【SharePointの全体管理】から確認したところ、【NTLM】でした。

【Kerberos】の場合は、SharePointアプリケーションプールIDを固有ユーザーで設定した場合、そのユーザーをサービスプリンシパル名に登録するという処理が必要なようですが、
【NTLM】の場合は、特に設定は必要ないのでしょうか?

とりあえず、
Active Directoryに関しても全く知識がないので、
そこから勉強してみようと思います

ありがとうございましたhappy01

wolfwoodさん、その後も状況は変わらずですか。。。お役に立てずすみません。

ですが、そもそもSharePointのユーザー管理はそんなに難しい設定ではないので、SharePointだけでないところにも原因があるような気もしますし、SharePoint自体の調子が悪いのかも、、なんて色々と憶測してしまいます。どちらにせよ、これ以上は貴社の環境依存の問題がありそうなので、がんばって調査してみてください(そんなことしか、いえずすみません)。

-追伸-
ちなみに、IISがNTLMの場合はWindows認証基盤が整っていれば、SPN登録などは不要で基本的にはすぐ使えるはずです。

もしご存知であれば教えてください。

サイトコレクションのアクセス権限として
ADのセキュリティグループを登録した環境にて
メンテナンス(部署名変更)のため
DCのセキュリティグループの名前変更を行うという処理を行う場合、
サイトコレクション内からユーザの削除を実施し
再度、登録するという方法しかないでしょうか?

「migrateuser」のコマンドを試しましたが、
グループアカウントのため処理出来ませんといった
応答がありました。

Onoさん、
SharePoint Server 2007の場合は、ユーザープロファイルによる一元管理の考え方がWindowsグループにも適用されてしまい、いったん登録されたらユーザーアカウントと同様に直接編集はできくなってしまいますね。

厳密に言えば、AD側のグループ名を変更した場合は、いったん削除せずに、再度サイトコレクションにアカウントを追加すればログオン アカウント名(ex. EXAMPLE\TestGroup)は更新されます。このままでも、Windowsグループに所属するユーザーはアクセス可能です。ただし、表示名は変更されませんので、そのままでは運用上望ましくありません。そこで、表示名まで更新するには、御指摘通り一度削除してから再登録するというのがマニュアル操作では一般的ではないかと思います。

なお、表示名の変更は、つまるところサイトコレクションで管理されているUserInfoテーブルを変更すればよいのですが、データベースの直接変更はサポートされていないため、SharePoint オブジェクトモデル経由で変更することが推奨されます。もし、データベースを直接変更する場合は自己責任のもとで実施します。

SharePointオブジェクトモデルを操作する場合のソースコードを、参考までに記載しておきますね。
***********
using (SPWeb web = new SPSite("目的のSharePointサイトのURL").OpenWeb())
{
SPUser winGroup = web.AllUsers['ログイン名'];
winGroup.Name = "変更したい表示名";
winGroup.Update(); };
***********
※SPUserオブジェクトはWindowsユーザーおよびグループを表します。

適切なご回答ありがとうございますcatface
PowerShellにて、下記のように変更を試してみたところ上手くいきました。

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$SPSite = New-Object Microsoft.SharePoint.SPSite("http://moss")
$OpenWeb = $SPSite.OpenWeb("/")
$spUser = $OpenWeb.SiteUsers["demo\testgroup-4"]
$spUser.Name = "NEW USER DISPLAY NAME"
$spUser.Update()

運用としては、グループアカウントの名前変更を行った後、
上記スクリプトを元にしたアカウント名+名前を
変更する物を用意し対応したいと存じます。

はじめまして。大変参考になりました。

フォームベース認証を構成してSSPへプロファイルをインポートしたいと思っているのですが、どうにもうまくいきません。

やったこと>
下記を参考にしてフォームベース認証のSSP管理サイトを構成しました。
http://technet.microsoft.com/ja-jp/library/cc262201.aspx
この例ではLDAPサーバーを使っていますが、認証プロバイダにはAspNetSqlMemberShipProviderを利用しています。そうするとインポート接続を作ることができませんでした。ビジネスデータカタログにすればOK?と思ったんですがStandardエディションでは使えないようです。「ユーザープロファイルの追加」で一人ずつ追加していくことはできるのですが、メールなどの情報がマッピングできませんし…
いい方法をご存じないでしょうか?

ka2さん、はじめまして。コメントをありがとうございます。

フォーム認証を利用してらっしやるんですね。この場合プロファイルインポートを行うにはカスタム ツールを作成するか、CodePlexサイトのオープンソースツールの一つである「MOSS 2007 Profile Import Tool 」を使うかのいずれかになりますね。

参考となる情報は、下記MSDNサイトの方が充実しています。http://msdn.microsoft.com/ja-jp/library/bb977430.aspx

以下は抜粋です。
「プロファイル インポートは、ユーザーの情報を SharePoint プロファイル システムにインポートする MOSS 2007 の機能です。このプロファイル情報は個人用サイト エリアに表示されます。ユーザーはこの情報を表示して、組織内の他のユーザーに関して公開されている情報 (各自の技能や興味、組織の階層、配布リストのメンバシップなど) を参照することができます。プロファイルは、Windows ベース ディレクトリのユーザーか、LDAP (Lightweight Directory Access Protocol) ベースのディレクトリから作成できます。プロファイルの属性は、ビジネス データ カタログを介して、他の基幹業務 (LOB) システムから追加することもできます。

フォーム認証を使用する場合、ユーザーやユーザーの属性をプロファイル システムにインポートできるツールは用意されていません。フォーム認証ユーザーのデータをインポートするには、ユーザー、属性、およびロール情報 (オプション) を列挙し、その情報を基に SharePoint 製品とテクノロジでプロファイル データを作成または更新できるカスタム アプリケーションが必要です。(以下、略)」

ちなみにMOSS 2007 Profile Import Toolは、まだ利用したことがないので、逆に感想などいただけると助かりますhappy01

ありがとうございます!

このツール、実はダウンロードだけしていたんですが、英語だったので「うーんよくわからん」という状況でこちらのページを拝見しました。ユーザー管理についてだいぶ理解できた(ような気がします)ので、試してみますね。ご報告はだいぶ後になるかもしれませんが…

お世話になります。紹介いただいたツールでユーザープロファイルのインポートができましたので、簡単にレポートしておきます。

■概要
設定ファイルに登録したメンバシッププロバイダとプロファイルプロバイダの内容をローカルサーバー上SSPのユーザープロファイルにインポートするツールです。
コマンドラインでの実行とWindowsフォームアプリとしての実行が可能です。(/runオプションをつけるとコマンド実行になります)

ダウンロードした内容はVS2005のソリューション形式になっています。
(VS2008だと変換ウィザードが実行されますが、エラーなく変換できます)
プロジェクトは以下の四つで、C#でコーディングされています。
・CustomProviders
・CustomTasks
・SampleProviders
・Driver

本体はDriverプロジェクトで、ビルドするとProfileImporter.exeになります。
MOSSがセットアップされていないマシンでは参照エラーが出るので、MOSSをセットアップしたサーバーにVS2005なりVS2008なりをインストールして使う必要があります。
エラーの出る参照は以下の二つです。
・Microsoft.Office.Server
・Microsoft.SharePoint
MOSSがセットアップされていないマシンでも上記dllをコピーして参照すればビルド可能ですが、実行するとサイトがないのでエラーになります。

■前提条件
MOSSがフォームベース認証で構成されていること。検証環境ではメンバシッププロバイダにSystem.Web.Security.SqlMembershipProvider、プロファイルプロバイダにSystem.Web.Profile.SqlProfileProviderを利用しています。また、二つのプロバイダは同一接続文字列を利用して、ローカルのSQLExpressのデータベースに接続しています。

■使い方
Driverプロジェクト内のApp.Configに必要な設定をして実行すれば設定したメンバシッププロバイダとプロファイルプロバイダの内容がローカルサーバー上のSSPのユーザープロファイルにインポートされます。インポート先を指定する必要はありません。(App.ConfigはビルドするとProfileImporter.exe.configになります)
フォームとして実行する場合、4つの実行用ボタンとサイト指定テキストボックスが表示されます。コマンド実行した場合は右上の「Import All Providers」ボタンを押した場合と同じコードが実行されます。上の段がアプリにインポート、下の段がSSPにインポートという切り分けになっているようですが、左下のボタンはコードがコメントになっていたり、右下のボタンは右上と同じだったり、左上の「Import Default Providers」ボタンはエラーになったりしました。プロバイダを1つだけ登録して右上ImportAllが確実なようです。左のエリアには実行結果が表示されます。

■App.Configの設定
1~5の設定を行います。もともとサンプルの設定が記述されているので、該当する箇所を書き直します。

1.Configuration Handler登録
検証環境ではここは特になにもしなくても動作しました。

2.SQL接続文字列の登録
メンバシッププロバイダとプロファイルプロバイダのデータベース接続文字列を登録します。検証環境では同一DBなのでひとつだけ設定しました。MOSSのWeb.Configにも設定してあるはずですので、それを持ってくればOKです。

3.メンバシッププロバイダの登録
MOSSのWeb.Configで利用している設定をそのまま持ってくればOKです。

4.プロファイルプロバイダの登録
propertiesの内容は変更していません。providersは以下のようにしています。
※<>は全角で投稿しました。

<providers>
<remove name="AspNetSqlProfileProvider" />
<add name="AspNetSqlProfileProvider" connectionStringName="WSS_MEMBERDB" applicationName="WSS_MEMBER" type="System.Web.Profile.SqlProfileProvider" />
</providers>

5.インポートプロバイダの登録
このツール独自の設定です。インポート元となるメンバシッププロバイダとプロファイルプロバイダの組に適当な名前をつけます。
指定するのはname、membershipProvider、profileProvider属性で、nameを適当につけます。

■感想
英語のドキュメントで「プロバイダ」が何度も出てくるので???となっていました。このあたりの仕組みはわかればとても便利ですね。前々回の投稿で触れた、SSP管理サイトのフォーム認証用拡張は不要な気がします。ありがとうございました。sun

ka2さん、早速の詳細なご報告をありがとうございました! 私自身とても参考になりました。こうした情報交換をさせていただけると非常に助かります。また、私も時間のある時に、試してみたいと思います!happy01