|
| ||||||||||||||||||
ユーザグループと組織単位について
ユーザグループについて
ユーザグループを利用すると、管理者は、ユーザのまとまりに対して権限を割り当てたり、レイアウトやデスクトップの表示を設定したりすることができ、ユーザごとに設定作業をしなくても済むようになります。これにより、FirstClassのシステム管理機能が大きく強化され、大規模な変更を簡単に行えるようになっています。
FirstClassサーバをインストールすると、以下の3つのグループ群があらかじめネットワークストア内に作られます（OpenTextソーシャルワークプレイスをインストールしている場合は4つ）。
・標準グループ群（Standard Groups）
・設定グループ群（Configuration Groups）
・部課グループ群（Department Groups）
・ドメイン名グループ群（Domain Name Groups）
この3つのグループ群には、FirstClass環境の設定作業を始めるのに役立つ複数のグループがあらかじめ作られています。初めて［Groups］フォルダを見ると、そのグループの多さに驚かれるかしれませんが、その構成や各ユーザグループの分類方法を理解すれば、設定やカスタマイズが非常に簡単になります。
ユーザグループを利用すると、管理者の作業を効率的に行うことができます。これは、権限の設定やモデルデスクトップの作成、または設定の変更を、ユーザ単位ではなくユーザが所属するグループ単位で行うことができるためです。
標準グループ群（Standard Groups）
FirstClassサーバをインストールすると、標準グループ群に属する複数のユーザグループをサーバが自動的に作成します。FirstClassは、必要に応じて、ユーザをこれらのユーザグループに自動的に追加します。これらのグループの中には、［ユーザ情報］フォームの［ユーザグループ/ディレクトリ］タブで表示されないものもありますが、実際にはユーザは適切なユーザグループに所属しています。標準グループ群のユーザグループ、および各グループに所属するユーザの一覧は、以下の通りです。
 警告標標準グループ群に属するどのユーザグループも、削除や名前の変更をしてはいけません。標準グループ群のユーザグループを削除すると、システムが予期しない動作をしたり、システムが損傷を受けたりする可能性があります。誤ってこれらのユーザグループを1つでも削除してしまった場合は、すぐに全く同じ名前のユーザグループを作成してサーバを再起動してください。
標準グループ群のグループの［グループ権限］フォームで設定した内容は、システムプロファイルやユーザが所属する他のグループに設定してある内容より優先して適用されます。ただし、ユーザの［ユーザ情報］フォームの権限は、これらのグループに設定した権限より優先して適用させることができます。
例えば、［All Users］の［グループ権限］フォームで「無制限」に設定している［1日あたりの接続時間］を、自動登録のユーザについては30分に制限したい場合は、［Autoregistered Users］グループの［グループ権限］フォームの［制限］タブで30分に設定してください。
ただし、ユーザの［ユーザ情報］フォームで設定した権限が、他のすべての設定より優先して適用されることにご注意ください。
設定グループ群（Configuration Groups）
設定グループ群に所属するグループは、FirstClassシステムの利用方法別に作成されたグループで、部署のような組織での役割別に設定されたグループではありません。設定グループ群にあらかじめ作成されているグループは、以下の通りです。
・［High Disk Usage］グループ
・［Help Desk］グループ
・［Subadmin Users］グループ
・［Suspended］グループ
・［Webmastars］グループ
・タイムゾーン関連のグループ
・［RAD Developers］グループ
・［DS Deleted］グループ
・［DS Admin］グループ
・［Voice users］グループ
・［No Outbound Internet Mai］グループ
・［Administration Resources］グループ
・［Online Help Administration］グループ
・［OnlineHelp End Users］コンテナ用テンプレート
ユーザを設定グループ群のどのグループに所属させるかは、組織内での所属を基準にするわけではありません。設定グループ群のグループの1つに所属したユーザには追加の権限が与えられます。しかし、この権限は、その組織でのユーザの地位を定義するものではありません。例えば、システム部門に5名が所属しており（組織内での所属）、そのうちの2名だけを副管理者に任命する（追加の設定）とします。この5名のユーザは組織的にはシステム部門に分類されますが、うち2名のユーザには、追加業務として副管理者の仕事が与えられているため、追加設定が必要になります。そこで、この2名を［Sub Admin］という設定グループ群のグループに所属させます。
設定用グループ群の各グループは削除や名前の変更を行うことができますが、［Subadmin Users］グループと［Webmasters］グループは削除しないことをお勧めします。その理由は、この2つのグループが、それぞれの役割に必要なツールやセキュリティ機能を利用できるように設定されているためです。FirstClassの管理作業に副管理者を置かない場合、またはFirstClassインターネットサービスを使用してインターネットに接続しない場合でも、［Subadmin Users］グループと［Webmasters］グループは残しておいてください。ただし、この2つのグループにはユーザを所属させないようにしてください。
部課グループ群（Department Groups）
部課グループ群は、ご利用のシステムの登録ユーザを役割別に組織するために使用します。部課グループ群のグループには、組織単位を割り当ててもよいでしょう。
部課グループ群のどのグループも削除や名前の変更ができます。FirstClassでは、（High Capacity Serverライセンスの導入により）ユーザグループを600まで作成できます。
初めてFirstClassをインストールするときに一時的なスクリプトを実行して、あらかじめ設定されている部課グループ群を変更できます。詳細とその方法については、管理者デスクトップにある［Start Here］フォルダを参照してください。
ドメイン名グループ群（Domain Name Groups）
特定のドメイン名（huskyplanes.comなど）に基づいたグループを作成できます。招待を受けたOpenTextソーシャルワークプレイスのユーザがそのドメインに所属している場合、そのユーザは常にそのドメインのグループに自動的に追加され、そのグループのモデルデスクトップや権限などが適用されます。
組織単位（OU）
組織単位（OU）は、ユーザをまとまりとして取り扱ったり、（ユーザ名と会議室で）重複エントリをディレクトリに登録できるようにしたりするために、ユーザグループ以外で利用できる便利な方法です。組織単位は、ご利用のFirstClassシステムに必ず設定する必要があるわけではありません。しかし、特にユーザ数の多い複雑なFirstClassシステムでは、組織とセキュリティの設定を行う際に大変役立ちます。
 注意標準グループ群に属するグループには、組織単位を割り当てないでください。
 FirstClassディレクトリサービスFirstClassディレクトリサービスの使用を考えている場合は、組織の階層の一部であるユーザグループに対して、実際の階層に合うように組織単位を割り当てなければならないことに注意してください。
FirstClassスクリプトを使用してシステムとユーザの設定を行う場合は、SETOUコマンドで組織単位を設定できます。
管理者デスクトップでシステムを設定する場合は、下図のように［グループ権限］フォームで組織単位を設定します。
 組織単位は、システムに登録されているユーザに適した階層の組み合わせを定義するのに使用されますが、組織単位によって階層におけるユーザの役割が決まるわけではありません。したがって、1人のユーザを複数の組織単位に所属させることができます。
ユーザにとって最も固有な組織単位を、そのユーザの第一組織単位といいます。例えば、あるユーザが経理部に所属する管理職の社員であり、「社員」「管理者」および「経理部」のいずれもこの企業の組織単位として設定されているとします。このユーザにとって最も固有な組織単位は、部署を表すグループです。したがって、「経理部」がこのユーザの第一組織単位となります。
この第一組織単位を、ピラミッド構造のように、さらに大きな組織単位に所属させることができます（ただし、必須ではありません）。組織単位は、組織での地位ではなく、組織での役割ごとにユーザをグループ化するものです。
注意ユーザの権限が、ある組織単位から別の組織単位に引き継がれることはありません。したがって、管理者は、［ユーザ情報］フォーム上でユーザの所属するユーザグループを正しい順番で登録する必要があります。
注意システムを構成するのに組織単位を利用する場合は、すべてのユーザを少なくとも1つの組織単位に所属させないと、権限設定が意図した通りに適用されなくなります。
企業での組織単位（OU）の作成例
ある企業で、社内の組織に以下のようなグループがあるとします。
・［社員］グループ
・［経営管理課］グループ
・［システム課］グループ
・［経理課］グループ
・［顧客］グループ
［経営管理課］、［システム課］、［経理課］は会社の個別の部署であり、各ユーザはどれか1つの部署に所属します。したがって、この3つのグループは、組織単位を［レベル6 課］に設定します。
［顧客］グループに所属するユーザも、この会社のシステムを利用し、社員とコミュニケーションを取ることから、［顧客］グループも部署と同じレベルと考えることができます。したがって、［顧客］グループの組織単位も［レベル6 課］に設定します。
［社員］グループもこの会社のグループの1つであるため、組織単位を割り当てる必要があります。［社員］グループには、この会社のほぼ全員が所属し、他の組織単位に所属するメンバーも含まれます（［顧客］グループのユーザは社員ではないため、部署に相当するすべてのグループのユーザが含まれるわけではありません。ただしし、［顧客］グループはシステム上では部署と同列に扱われます）。したがって、このグループの組織単位は［レベル4 会社］に設定します。
学校での組織単位（OU）の作成例
ある学校には、次のようなグループがあります。
・［社員］グループ
・［事務課］グループ
・［学校経営者］グループ
・［システム課］グループ
・［学生］グループ
・［教員］グループ
［事務課］［学校経営者］［システム課］および［教員］は、学校の組織構成では個別の部門であり、システムに登録されている各ユーザはどれか1つの部門に所属します。したがって、この3つのグループは、組織単位を［レベル6 課］に設定します。
［従業員］グループもこの学校のグループの1つであるため、組織単位を割り当てる必要があります。［従業員］グループには、この学校のほぼ全員が所属し、他の組織単位に所属するメンバーも含まれます（学生と保護者は従業員ではないため、部門に相当するすべてのグループのユーザが含まれるわけではありません）。したがって、このグループの組織単位は［レベル4 学校］に設定します。
組織単位のディレクトリ一覧表示
［グループ権限］フォームで、ディレクトリに表示する情報を選ぶことができます。［第一組織単位］を選択すると、ユーザの第一組織単位だけが表示されます。また、［すべての組織単位］を選択すると、ユーザが所属するすべての組織単位が表示されます。
 上図の例では、「従業員 志村」は特定の部署に所属していないため、第一組織単位は［従業員］となっています。「経営管理課 志村」と「システム課 志村」は2人とも社員であり、［従業員］組織単位のメンバーですが、一覧に表示されているのはそれぞれに割り当てられた第一組織単位だけです。
ユーザが2つの第一組織単位に所属している場合は、そのユーザの［ユーザ情報］フォームにある［このユーザが所属するグループ］フィールドで、先頭に近い位置に登録されているグループが表示されます。下図の例では、「システム課 志村」は、経営管理課にも所属しているため、［経営管理課］組織単位のメンバーでもあります。
 しかし、FirstClassディレクトリでは、「システム課 志村」のグループには「システム課」が表示され、「経営管理課」は表示されません。
 会議室への組織単位の登録
管理者が管理者デスクトップで作成した会議室とコンテナ用テンプレートは、組織単位に所属させることができません。しかし、FirstClassスクリプトのSETOUコマンド.を使うと、会議室やコンテナ用テンプレートに組織単位を設定できます。
ユーザが所有するオブジェクトには、そのユーザの第一組織単位の権限設定が適用されます。したがって、会議室やカレンダーを共有する権限をユーザに与えると、ユーザが作成した会議室やカレンダーにはすべて、そのユーザの第一組織単位の権限設定が適用されます。
組織単位とディレクトリの重複エントリ
組織単位を利用すると、名前が重複するエントリをディレクトリに登録できます。［グループ権限］フォームで［OU内部で、同じグループ名の使用を禁止する］を選択すると、それぞれ異なる組織単位に所属している2名のユーザを、全く同じ名前でディレクトリに登録できるようになります。例えば、経営管理課に須田礼子というユーザがいても、経理課に須田礼子という別のユーザを登録できます。ディレクトリで須田礼子を検索すると、下図のように表示されます。
 ただし、重複した名前を持つ複数のユーザを同じ組織単位に所属させることはできません。もし経理部の須田礼子が管理部に異動したら、ディレクトリに登録される名前を変更する必要があります。
注意重複したユーザIDを使用することはできません。
FirstClassデザイナーによる組織単位レベルの編集
組織単位の名前を編集したり、ご利用の組織に合うようにレベルを追加したりしたい場合には、FirstClassデザイナーを使用してください。FirstClassデザイナーでフォームを編集するための基本的な情報については、FirstClassデザイナーのヘルプかオンラインヘルプを参照してください。
FirstClassサーバは、組織単位を数値としてしか認識しません。FirstClassデザイナーで［グループ権限］フォームを開いて組織単位のドロップダウンリストのフィールド属性を見れば、各レベルの横に数値が割り当てられていることがわかります。ここで、番号の横にある名前や数値を編集できます。また、このリストに選択肢を追加することも可能です。編集した情報のうち、FirstClassサーバが認識できるのは数値だけです。有効な数値は0から800までです。
複数システム共存環境の構築
組織単位の機能を利用して複数のシステムが共存できる環境を構築すると、この機能が持つ柔軟性がよくおわかりいただけます。ここで説明するのは、1つのFirstClassサーバ上で独立した2つ以上のシステムを運営するための設定方法です。複数のシステムは互いに完全な独立性を保ち、あるシステムのユーザがディレクトリで別のシステムのユーザを閲覧することは絶対にできないようにします。
企業における複数システム共存環境の構築
ある企業が子会社を設立したとします。その子会社は、親会社のシステムを使用することになっていますが、経営は完全に独立して行います。したがって、両社は、互いの情報を共有したり、コミュニケーションを行ったり、ディレクトリ一覧を閲覧したりできないようにしたいと考えています。両社はFirstClassシステムを共同で使用しながら、お互いに完全な独立性を維持する予定です。FirstClassの管理者は、組織単位とディレクトリの閲覧制限機能を利用し、以下の手順に従って独立した複数のシステムを設定できます。
1 ［Groups］フォルダ内で必要な変更を行います。
・標準グループ群、設定グループ群、ディレクトリ閲覧制限グループ群に属するグループは、どれも変更しないでください。これらのグループに対して設定を加えたり変更したりすると、システムに登録されている該当ユーザすべてに適用されてしまいます。
・部課グループ群に、［親会社 ユーザ］という名の新しいグループを作成します。このグループは、親会社の全ユーザを登録する主グループになります。
・［親会社 会議室］というコンテナ用テンプレートと［親会社 カレンダー］というカレンダーグループを作成します。これらのグループは、親会社の使用するすべての会議室とカレンダーをそれぞれ登録する主グループになります。
・部課グループ群にあるすべてのユーザグループ、コンテナ用テンプレート、およびカレンダーグループの名前を、親会社用に変更します。例えば、［Employee］グループは［親会社 社員］に、［Finance］は［親会社 経理課］のような名前に変更します。親会社が利用するグループをすべて［Groups］フォルダ内の片側に寄せて、システムの規模が大きくなってもグループ作成が簡単に行えるようにするとよいでしょう。
この段階では、［Groups］フォルダは下図のようになります。
 2 親会社の各グループに組織単位を設定します。
・［親会社 ユーザ］グループの組織単位を［レベル4 会社］に設定します。
・親会社の他のグループの組織単位は、［レベル5 部］［レベル6 課］［レベル6 グループ］または［レベル7 チーム］から適切なものを設定します。
3 重複しないドメイン名を設定します。
この設定を行うと、親会社は子会社とは異なるドメイン名を持つことになります。親会社の［グループ権限］フォームの［サービス］タブで、［メールアドレスのドメイン］フィールドに親会社のドメイン名を登録します。このグループのメンバーが利用するメールエイリアスはすべて、このドメイン名がデフォルトになります。
ただし、教育センターや他の学校が独自のドメイン名を持っていない場合は、ここにドメイン名を入力しないでください。
注意ユーザが複数の組織単位に所属していて、そのうち2つ以上の組織単位がドメイン名を持っている場合は、そのユーザの第一組織単位のドメイン名が使用されます。
ドメイン名が複数ある場合は、［複数サイトと複数言語の設定］フォーム上で、必ずすべてのドメイン名を登録してください。
4 ディレクトリの閲覧制限を設定します。
［親会社 ユーザ］［親会社 会議室］および［親会社 カレンダー］の各グループにはディレクトリの閲覧制限を設定しないでください。
親会社の他のすべてのグループに対して、［グループ権限］フォームの［ディレクトリ］タブで、［ディレクトリでの閲覧を許可するグループ］に［親会社 ユーザ］［親会社 会議室］［親会社 カレンダー］を入力して、ディレクトリの閲覧制限を設定してください。
注意必要であればさらにディレクトリの閲覧制限を設定できますが、設定するグループはこれら3つのグループより上に登録してください。
以下の点に注意してください。
親会社のシステムに所属するユーザはすべて、［親会社 ユーザ］グループのメンバーにしてください。［ユーザ情報］フォームの［ユーザグループ/ディレクトリ］タブで、［Regular Users］グループまたは［Remote Users］グループのすぐ下に［親会社 ユーザ］グループを登録してください。
親会社のシステムで利用する会議室（および、後で親会社のシステムに登録する会議室）はすべて、［親会社 会議室］コンテナ用テンプレートのメンバーにしてください。
親会社のシステムで利用するカレンダー（および、後で親会社のシステムに登録するカレンダー）はすべて、［親会社 カレンダー］カレンダーグループのメンバーにしてください。
このようにすると、ユーザが新しい会議室を作成したときにユーザの組織単位の設定がその会議室に適用されるため、そのユーザのディレクトリ閲覧制限の設定が自動的に適用されます。
5 子会社の部課グループ群のグループを、親会社の場合と同じ要領で作成します。
注意すべてのユーザ、コンテナ用テンプレート、カレンダーグループ、会議室、およびカレンダーで、名前の先頭に「子会社」と付けて、子会社専用であることがわかるようにしてください。
子会社のユーザが所属する組織単位は、親会社と同じく［レベル4 会社］に設定してください。
子会社の他のすべてのグループには、その組織に該当する組織単位を設定してください。
子会社のユーザはすべて［子会社 ユーザ］グループに、子会社の会議室はすべて［子会社 会議室］コンテナ用テンプレートに、子会社のカレンダーはすべて［子会社 カレンダー］グループに所属させてください。
親会社と子会社のシステムが共存できる環境が完成すると、［Groups］フォルダは下図のようになります。
 ［親会社 ユーザ］のメンバーとして登録されたどのユーザも、［子会社 ユーザ］に所属するユーザを見ることはできません。また、親会社の会議室とカレンダーは、どれも子会社のユーザから見ることができません。その逆も同様です。このようにディレクトリを分割すると、サーバの管理作業を除いて、完全に独立した2つのシステムとして動作させることができます。すべての作業を全ユーザ一括ではなく、会社単位（または、グループ、ユーザ単位）で行うことができるため、複数システムが共存した環境となります。
学校における複数システム共存環境の構築
この学区では、教育センターと学校Aと他の学校のシステムを1つのFirstClassサーバで運営しながら、それぞれの独立性を保ちたいと考えています。つまり、各学校と教育センターは、互いの情報を共有したり、コミュニケーションを行ったり、ディレクトリ一覧を閲覧したりできないようにしたいと考えています。各学校と教育センターはFirstClassシステムを共同で使用しながら、お互いに完全な独立性を維持する予定です。FirstClassの管理者は、組織単位とディレクトリの閲覧制限機能を利用し、以下の手順に従って独立した複数のシステムを設定できます。
1 ［Groups］フォルダ内で必要な変更を行います。
・標準グループ群、設定グループ群、ディレクトリ閲覧制限グループ群に属するグループは、どれも変更しないでください。これらのグループに対して設定を加えたり変更したりすると、システムに登録されている該当ユーザすべてに適用されてしまいます。
・ディレクトリ閲覧制限グループ群で、［School］グループの名前を［学校A］グループに変更します。このグループは、学校Aの全ユーザを登録する主グループになります。
・［学校A 会議室］というコンテナ用テンプレートと［学校A カレンダー］というカレンダーグループを作成します。これらのグループは、学校Aの使用するすべての会議室とカレンダーをそれぞれ登録する主グループになります。
・部課グループ群にあるすべてのユーザグループ、コンテナ用テンプレート、およびカレンダーグループの名前を、学校A用に変更します。例えば、［Faculty］グループは［学校A 教職員］、［Students］グループは［学校A 学生］のような名前に変更します。
・学校Aが利用するグループをすべて［Groups］フォルダ内の片側に寄せて、システムの規模が大きくなってもグループ作成が簡単に行えるようにするとよいでしょう。
この段階では、［Groups］フォルダは下図のようになります。
 2 学校Aの各グループに組織単位を設定します。
・［学校A］グループの組織単位を［レベル4 学校］に設定します。
・学校Aの他のグループの組織単位は、［レベル5 学年］［レベル6 組］［レベル6 グループ］または［レベル7 チーム］から適切なものを設定します。
3 重複しないドメイン名を設定します。
この設定を行うと、学校Aは教育センターと学区内の他のすべての学校とは異なるドメイン名を持つことになります。学校Aの［グループ権限］フォームの［サービス］タブで、［メールアドレスのドメイン］フィールドに学校Aのドメイン名を登録します。このグループのメンバーが利用するメールエイリアスはすべて、このドメイン名がデフォルトになります。
ただし、教育センターや他の学校が独自のドメイン名を持っていない場合は、ここにドメイン名を入力しないでください。
注意ユーザが複数の組織単位に所属していて、そのうち2つ以上の組織単位がドメイン名を持っている場合は、そのユーザの第一組織単位のドメイン名が使用されます。
ドメイン名が複数ある場合は、［複数サイトと複数言語の設定］フォーム上で、必ずすべてのドメイン名を登録してください。
4 ディレクトリの閲覧制限を設定します。
［学校A］［学校A 会議室］および［学校A カレンダー］の各グループにはディレクトリの閲覧制限を設定しないでください。
学校Aの他のすべてのグループに対して、［グループ権限］フォームの［ディレクトリ］タブで、［ディレクトリでの閲覧を許可するグループ］に［学校A］［親学校A 会議室］および［学校A カレンダー］を入力して、ディレクトリ閲覧制限を設定してください。
注意必要であればさらにディレクトリの閲覧制限を設定できますが、設定するグループはこれら3つのグループより上に登録してください。
以下の点に注意してください。
学校Aのシステムに所属するユーザはすべて、［学校A］グループのメンバーにしてください。［ユーザ情報］フォームの［ユーザグループ/ディレクトリ］タブで、［Regular Users］グループまたは［Remote Users］グループのすぐ下に［親会社 ユーザ］グループを登録してください。
学校Aのシステムで利用する会議室と、後で学校Aのシステムに登録する会議室はすべて、［学校A 会議室］会議室グループのメンバーにしてください。
学校Aのシステムで利用するカレンダーと、後で学校Aのシステムに登録するカレンダーはすべて、［学校A カレンダー］カレンダーグループのメンバーにしてください。
このようにすると、ユーザが新しい会議室を作成したときにユーザの組織単位の設定がその会議室に適用されるため、そのユーザのディレクトリ閲覧制限の設定が自動的に適用されます。
5 教育センターの部課グループ群のグループを、学校Aで行った作業と同じ要領で作成します。
注意すべてのユーザ、コンテナ用テンプレート、カレンダーグループ、会議室、およびカレンダーで、名前の先頭に「教育センター」と付けて、教育センター専用であることがわかるようにしてください。
［学校A］ではなく、［教育センター］のような名前をグループに付けてください。このグループの組織単位を［レベル3：地方］にしてください。
教育センターの他のすべてのグループには、その組織に該当する組織単位を設定してください。
教育センターのユーザはすべて［教育センター］グループに、教育センターの会議室はすべて［教育センター 会議室］に、教育センターのカレンダーはすべて［教育センター カレンダー］グループに所属させてください。
教育センターと学校Aのシステムが共存できる環境が完成すると、［Groups］フォルダは下図のようになります。
 ［学校A］のメンバーとして登録されたどのユーザも、［教育センター］に所属するユーザを見ることはできません。また、学校Aの会議室とカレンダーは、どれも教育センターのユーザから見ることができません。その逆も同様です。このようにディレクトリを分割すると、サーバの管理作業を除いて、完全に独立した2つのシステムとして動作させることができます。すべての作業を、全ユーザに一括ではなく、学校単位（または地域、グループ、ユーザ単位）で行うことができるため、完全な複数システム共存環境となります。
教育センターと学校A、その他の学校との間で何らかの共同作業を行いたい場合は、作成した複数の独立したシステム間にまたがって利用できるような会議室やユーザグループを作成できます。
詳細情報
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||