SharePoint での権限、ユーザー、グループ、およびオブジェクト モデルAuthorization, users, groups, and the object model in SharePoint

SharePointでは、Web サイト、リスト、フォルダー、リスト アイテムへのアクセスは、ロール ベースのメンバーシップ システムによって制御されます。このシステムでは、ユーザーにロールを割り当て、それによって SharePoint オブジェクトへのアクセスを承認します。In SharePoint, access to websites, lists, folders, and list items is controlled through a role-based membership system by which users are assigned to roles that authorize their access to SharePoint objects.

ユーザーにオブジェクトへのアクセス権を与えるには、既にそのオブジェクトへのアクセス許可が与えられているグループにそのユーザーを追加するか、ロールの割り当てオブジェクトを作成して、ユーザーにロールの割り当てを設定し、必要に応じてそのロールの割り当てを基本的なアクセス許可を持つ適切なロール定義にバインドしてから、その割り当てを目的のリスト アイテム、フォルダー、リスト、Web サイトに対するロールの割り当てのコレクションに追加します。ユーザーをロールに割り当てても、そのロールの割り当てをロール定義にバインドしていない場合、ユーザーにはアクセス許可が与えられません。 SharePointでは、次の方法でそのオブジェクトへのアクセスを制御しています。To give a user access to an object, you can add the user to a group that already has permissions to the object, or you can create a role assignment object, set the user for the role assignment, optionally bind the role assignment to the appropriate role definition with base permissions, and then add the assignment to the collection of role assignments for the list item, folder, list, or website. If you do not bind the role assignment to a role definition when assigning a user to a role, the user has no permission. Following are ways that SharePoint provides to control access to its objects:

  • オブジェクトでは、親 Web サイト、リスト、フォルダーと同じアクセス許可を使用することも (親オブジェクトで有効なロールとユーザーの両方とも継承)、固有のアクセス許可を使用することもできます。Objects can use the same permissions as the parent website, list, or folder (inheriting both the roles and users available on the parent object), or they can use unique permissions.

  • 各サイト、リスト、フォルダー、およびアイテムはロールに割り当てられたコレクションを提供するので、オブジェクトへのユーザーのアクセスを詳細に管理できます。Sites, lists, folders, and items each provide role assignment collections, enabling fine management of user access to objects.

  • グループはユーザーで構成されていますが、ロールに割り当てられている場合と、そうでない場合があります。SharePointには、既定で以下の 3 つのグループがあります。Groups consist of users and may or may not be assigned to roles. SharePoint includes the following three groups by default:

    • owners (管理者)owners (administrator)

    • members (投稿者)members (contributor)

    • visitors (閲覧者)visitors (reader)

<span data-ttu-id="78039-114">ユーザー インターフェイスから固有のアクセス許可が設定された Web サイトを作成すると、サイトのプロビジョニングの一環として、これらのグループにユーザーを割り当てることのできるページが表示されます。</span><span class="sxs-lookup"><span data-stu-id="78039-114">When you create a website with unique permissions through the user interface, you are directed to a page where you can assign users to these groups as part of provisioning the site.</span></span>
  • 匿名アクセスを使用すると、ユーザーはリストやアンケートに匿名で投稿したり、ページを匿名で表示したりできます。また、匿名アクセスを有効にしなくても、ドメインのすべてのメンバーが Web サイトにアクセスできるように、"すべての認証されたユーザー" にアクセス権を付与することもできます。Anonymous access allows users to contribute anonymously to lists and surveys, or to view pages anonymously. You can also grant access to "all authenticated users" to allow all members of your domain to access a website without having to enable anonymous access.

  • サイト作成権限 (CreateSSCSiteManageSubwebs) は、ユーザーがトップ レベル Web サイト、サブサイト、またはワークスペースを作成できるかどうかを制御します。Site creation rights (CreateSSCSite and ManageSubwebs) control whether users can create top-level websites, subsites, or workspaces.

ユーザーは、ロールが割り当てられたグループを介して間接的に、またはロールの割り当てによって直接的に SharePoint オブジェクトのメンバーになります。また、グループまたはロールに追加された Microsoft Windows NT ドメイン グループのメンバーも、ユーザーになれます。ロール定義は、それぞれのユーザーまたはグループをユーザーを Microsoft.SharePoint.SPBasePermissions 列挙の値に対応した 1 つの権限または権限セットに関連付けます。各ユーザーまたはグループは、それぞれ固有のメンバー ID を持ちます。addrole.aspx ファイルと editrole.aspx ファイルの機能を使用する方法以外にも、オブジェクト モデルを使用して、ロールの割り当てと定義を作成したり変更したりできます。ユーザー インターフェイスで表示されるこれらのページとは異なり、オブジェクト モデルでは、権限の依存関係は適用されないので、権限を自由に組み合わせてロール定義を作成できます。ただし、オブジェクト モデルを使用してロール定義やアクセス許可をカスタマイズするときは注意が必要です。ロール定義に対する計画が不十分な場合や、権限の割り当てが不適切な場合、ユーザーの利便性が損なわれる可能性があります。SharePointの権限について詳しくは、「 SPBasePermissions 」を参照してください。Users become members of a SharePoint object indirectly through a group that has a role assignment, or directly through a role assignment. Users also can be members of a Microsoft Windows NT Domain Group that is added to a group or to a role. A role definition associates a user or group with a single right or set of rights corresponding to values of the Microsoft.SharePoint.SPBasePermissions enumeration. Each user or group has a unique member ID .You can use the object model to create or modify role assignments and definitions differently than the way you can through the functionality of the addrole.aspx file and the editrole.aspx file. Unlike these pages, which are presented in the user interface, the object model does not enforce rights dependency, so you can create a role definition with an arbitrary combination of rights. But, plan carefully when using the object model to customize role definitions and permissions, because a poorly planned role definition and inappropriately assigned rights can lead to a bad user experience.For more information about SharePoint rights, see SPBasePermissions .

セキュリティ ポリシーSecurity policy

セキュリティ ポリシーは、Web アプリケーション (仮想サーバー) 内のすべてのサイト コレクションで一貫したセキュリティを適用する手段です。ポリシーを使用すると、ロール (つまり、権限のコレクション) を個々の SharePoint ユーザーと、Windows 認証やプラグ可能な認証システムを使用しているドメイン グループ (SharePoint グループを除く) に割り当てることができます。ポリシー エントリごとに、Web アプリケーションのユーザーまたはグループの権限が指定されます。A security policy provides a way to enforce uniform security throughout all site collections within a web application (virtual server). Through policy, you can assign a role, or collection of rights, to individual SharePoint users, and to domain groups using Windows authentication or pluggable authentication systems, but not to SharePoint groups. Each policy entry specifies rights for a user or group in the web application.

ポリシーは、論理 Web アプリケーション レベルまたはゾーン レベルで設定されます。たとえば、2 つの Web アプリケーションのコンテンツが同じでも、 http://Serverhttp://Server.extranet.microsoft.com ではそれぞれ異なるポリシーがユーザーに適用されます。Policy is set at the logical web application level or at the zone level. A user can have, for example, different policies on http://Server and http://Server.extranet.microsoft.com, even if the two web applications have the same content.

権限は、ポリシーによって付与したり、取り消したりできます。権限を付与すると、オブジェクトのローカル権限とは関係なく、Web アプリケーション内のセキュリティで保護されたすべてのオブジェクトに対する権限がユーザーまたはグループに与えられます。権限の取り消しは権限の付与よりも優先度が高くなります。権限を取り消すと、Web アプリケーション内のセキュリティで保護されたすべてのオブジェクトに対するユーザーまたはグループの権限がブロックされます。あるユーザーの権限をすべて取り消すと、特定のコンテンツに対する明示的なアクセス許可がそのユーザーに付与されている場合でも、すべてのコンテンツにアクセスできなくなります。ポリシーは、サイト レベルのアクセス許可を無効にします。Rights can be granted or denied through policy. Granting a right gives that right to the user or group on all secured objects within the web application, regardless of local permissions on the object. Denying a right is given a higher priority than granting the right, actively blocking that right for the user or group on all secured objects within the web application. Denying all for a user prevents that user from accessing any content, even if the user has explicit permissions on specific content: policy overrides site-level permissions.

ポリシー ロールでは、ユーザーおよびグループはセキュリティ識別子 (SID) とログインまたはユーザー名の両方によって識別されます。In policy roles, the users and groups are identified by both their security identifier (SID) and their login or user name. ポリシー ロールの適用は、Web サイト、リスト、フォルダー、またはドキュメントのアクセス許可の管理に似ています。ユーザーまたはグループを追加し、1 つまたは複数の役割の定義を割り当てます。Applying a policy role is similar to managing permissions for a website, list, folder, or document: you add users or groups and assign them to one or more role definitions. 各 Web アプリケーションには独自のポリシー ロールがあります。Each web application has its own policy roles. ポリシー ロールとアクセス許可の管理のもう 1 つの違いは、全体管理者が Web アプリケーション全体でユーザーの権限を拒否することができる点です。Another difference between policy roles and managing permissions is that central administrators can deny a right to a user throughout a web application.

注意

サーバーの全体管理のポリシー ロールは、サイト コレクションのロール定義と異なります。Central administration policy roles differ from the role definitions for a site collection.

ユーザー、グループ、およびプリンシパルUsers, groups, and principals

個々のユーザー ( SPUser ) が SharePoint オブジェクトにアクセスするには、個別のロールの割り当てを通じて直接アクセス権を取得するか、ロールの割り当てが設定されたドメイン グループまたは SharePoint グループ ( SPGroup ) を通じて間接的にアクセス権を取得します。直接的なロール割り当てでは、ユーザーがプリンシパル ( SPPrincipal ) になります。一方、ドメイン グループまたは SharePoint グループのロールの割り当てでは、ドメイン グループまたは SharePoint グループがプリンシパルになります。An individual user ( SPUser ) gains access to a SharePoint object directly through an individual role assignment, or indirectly through membership in either a domain group or a SharePoint group ( SPGroup ) that has a role assignment. In a direct role assignment, the user is the principal ( SPPrincipal ). In a domain group or SharePoint group role assignment, the domain group or SharePoint group is the principal.

SharePoint Server では、Windows ユーザー (例: DOMAIN\ User_Alias) と (プラグ可能な認証による) 外部ユーザーの両方がサポートされています。ユーザーの ID の保守は、ID 管理システム (Active Directory ディレクトリ サービスなど) によって行われます。ユーザー プロファイル (ユーザーの表示名、電子メール アドレス、その他の情報など) のスコープはサイト コレクション レベルです。表示名を変更すると、サイト コレクション全体に変更が適用されます。SharePoint Server supports Windows users (for example, DOMAIN\ User_Alias) and external users (through pluggable authentication). The user identity is maintained by the identity management system (for example, the Active Directory directory service). The user profile (which includes the user's display name, email address, and other information) is scoped to the site-collection level. Changing a display name affects the entire site collection.

グループは、SharePoint Server でセキュリティの管理に使用されるユーザー コレクションです。ユーザー ベースの管理は、シンプルなサイトでは容易ですが、個別にセキュリティ保護されるリソースの数が増すにつれ複雑になります。たとえば、1 つ目のリストには " Contribute" ロール、2 つ目のリストには " Read" ロール、3 つ目のリストには " Design" ロールが 1 人のユーザーに割り当てられている場合もあります。このモデルはスケールアップに支障をきたします。仮にユーザー数が 50,000 人もいるとすると、個別にセキュリティ保護されるオブジェクトごとのアクセス制御リスト (ACL) に 50,000 個ものアクセス制御エントリ (ACE) が連なることになります。A group is a collection of users through which SharePoint Server manages security. User-based management is straightforward for simple sites, but becomes more complex as the number of uniquely secured resources grows. For example, a user may have the Contribute role for list 1, the Read role for list 2, and the Design role for list 3. This model does not scale well if there are, for example, 50,000 users—which would result in access control lists (ACLs) being 50,000 access control entries (ACEs) long on every uniquely secured object.

グループを使用することで、ユーザー ベースのアクセス権の管理に立ちはだかる管理の複雑さと拡張性の問題が解消されます。グループ ベースの管理は、より抽象的で概念化しにくくなりますが、個別にセキュリティ保護されるオブジェクトを多数抱える複雑なサイトでは、管理を容易にすることができます (たとえば、システム内のさまざまなオブジェクトで適切なロールが既に与えられているグループにユーザーを追加するときなど)。保存の必要なグループの ACE 数は大幅に少なくなるので、グループに対するアクセス権チェックは拡張性に優れています。Groups provide an answer to the manageability and scale problems of user-based permissions management. Group-based management may be more abstract or more difficult to conceptualize, but it enables easier management of complex sites with many uniquely secured objects. For example, when adding a user to a group that has already been granted the appropriate role on various objects in the system. The permissions checking for groups scales better because far fewer group ACEs need to be stored.

SharePoint Server では、ドメイン グループと SharePoint グループの 2 種類のグループがサポートされています。ドメイン グループは、SharePoint Server の管理対象外に留まります。つまり、ユーザーは SharePoint Server を使用して、ドメイン グループのメンバーシップの定義、参照、変更を行うことはできません。SharePoint グループのスコープは、サイト コレクション レベルに限定され、サイト コレクション内でしか使用できません。ドメイン グループは、Active Directory ディレクトリ サービスのスコープ内であれば任意の場所で使用できます。SharePoint Server supports two kinds of groups: domain groups and SharePoint groups. Domain groups remain outside SharePoint Server control; users cannot use SharePoint Server to define, browse, or modify domain group membership. SharePoint groups are scoped to the site-collection level, and they can be used only within the site collection. Domain groups can be used anywhere within the scope of the Active Directory directory service.

プリンシパルは、セキュリティ管理に使用されるユーザーまたはグループです。1 つのサイトにユーザーを追加すると、ユーザーがプリンシパルになり、そのサイトにグループを追加するとグループがプリンシパルになります。SharePoint Server でセキュリティをスケールアップするにあたり、スコープ内のプリンシパルを妥当な数に保つことが重要となります。グループを使用すると、少数のプリンシパルで膨大な数のユーザーにアクセス権を与えることができます。A principal is a user or group that is used to control security. If you add a user to a site, the user is the principal, but if you add a group to the site, the group is the principal. The key to scaling security in SharePoint Server is to keep the number of principals per scope reasonable. By using groups, a smaller number of principals can be used to grant access to a much larger number of users.

オブジェクト関係の概観 ? スコープ、ユーザー、グループ、ロールHigh-level view of object relations—scopes, users, groups, and roles

図 1 は、SharePoint Server セキュリティ管理システムの概観を論理データベース図で示したものです。各ボックスはシステム内のセキュリティ オブジェクトを表し、線はオブジェクト間の関係を表します。また、 1N の表記は関係の種類を表します。この図は、どのように権限データがユーザー トークンと ACL に構造化されているかを示しています。Figure 1 shows a high-level view of the SharePoint Server security management system in a logical database diagram. Each box represents a security object in the system. The lines represent relationships between the objects. The 1 and N notation represents the type of relationship. The figure shows how permissions data is structured into a user token and an ACL.

図 1. 承認オブジェクトの関係Figure 1. Authorization object relations

承認オブジェクトの関係

スコープは、個別にセキュリティ保護される 1 つのオブジェクトまたは複数のオブジェクト セットで示されます。サイト、リスト、フォルダー、アイテムの各レベルをスコープに指定できます。A scope represents a uniquely secured object or set of objects. You can scope to site, list, folder or item level.

ユーザーとグループは、多対多の関係 (N - N) にあります。各ユーザー ( SPUser ) は複数のグループのメンバーに属することができ、各グループ ( SPGroup ) には複数のユーザーを含めることができます。Users and groups have a many-to-many relationship (N to N). Each user ( SPUser ) can be a member of multiple groups, and each group ( SPGroup ) can contain multiple users.

権限とロールの定義も、多対多の関係 (N - N) にあります。各権限 ( SPBasePermissions ) は、複数のロール定義に属することができます。たとえば、" Insert List Items" 権限は " Contributor"、" Designer"、" Administrator" の各ロール定義に属します。また、各ロール定義 ( SPRoleDefinition ) にも、複数の権限を含めることができます。たとえば、" Contributor" には、リスト アイテムを挿入する権限、更新する権限、削除する権限が含まれます。Rights and role definitions also have a many-to-many relationship (N to N). Each right ( SPBasePermissions ) can be part of multiple role definitions. For example, the Insert List Items right is included in the Contributor, Designer, and Administrator role definitions. Each role definition ( SPRoleDefinition ) can also contain multiple rights. For example, Contributor includes the rights for inserting, updating, and deleting list items.

ロール定義とロールの割り当て ( SPRoleAssignment ) は、一対多の関係 (1 - N) にあります。各ロール定義は、複数のロールの割り当ての中で使用されます。リスト 1 の閲覧者とリスト 2 の閲覧者が異なる場合もありますが、そのロールの割り当ては " Reader" という 1 つのロール定義を共有できます。Role definitions and role assignments ( SPRoleAssignment ) have a one-to-many relationship (1 to N). Each role definition is used in multiple role assignments. The readers on list 1 and the readers on list 2 may be different, but their role assignments can share a single role definition: Reader.

ユーザーまたはグループとロールの割り当ては、多対多の関係 (N - N) にあります。各ユーザーまたはグループは、任意のオブジェクトに対して複数のロールの割り当てのメンバーに属することができます。たとえば、1 人のユーザーが同じオブジェクトに対して " Designer" ロールと " Administrator" ロールを併せ持つことができます。Users or groups and role assignments have a many-to-many relationship (N to N). Each user or group can be a member of multiple role assignments on a given object. For example, a user may have both the Designer role and the Administrator role on the same object.

スコープとロールの割り当ては、一対多の関係 (1 - N) にあります。各スコープにはロールの割り当てが複数ありますが、各ロールの割り当てにはスコープが 1 つしかありません。たとえば、あるユーザーがイベント リストの閲覧者になっており、別のユーザーがイベント リストの投稿者となっているとしても、どちらのロールの割り当てもお知らせリストには適用されません。2 つのリストで同じロールの割り当てを共有するには、それぞれの権限を親コンテナーから継承する以外に方法はありません。この場合、セキュリティのスコープは 2 つのリストではなく親コンテナーとなります。Scopes and role assignments have a one-to-many relationship (1 to N). Each scope has multiple role assignments, but each role assignment has only one scope. For example, one user may be a reader on the Events list, and another user may be a contributor on the Events list, but neither of these role assignments applies to the Announcements list. The only way for two lists to share the same role assignment is by inheriting their permissions from the parent container, in which case the security scope is the container, not the two lists.

ユーザー トークンとアクセス制御リストUser tokens and access control lists

SharePoint Server では、権限チェックを速やかに行うため、そのセキュリティ モデル内にユーザー トークンと ACL が実装されています。ユーザー トークンによって、ユーザーに適用される認証プロセスが識別されます。Windows ユーザーは、ユーザー固有の文字列 (SID) と、そのユーザーが属するすべての Windows ドメイン グループのリストで構成される複雑なトークン (例: DOMAIN\Department 15688) を使用します。Windows 認証が設定されていないユーザーは、ユーザー名に固有の文字列からなる非常にシンプルなトークンを使用する場合もあれば、Windows 認証で表されるようなグループ/ロールのメンバーシップが組み込まれた複雑なトークンを使用する場合もあります。各ユーザーが属する SharePoint グループのメンバーシップはユーザー トークンを使って表されるため、SharePoint Server では、ユーザー トークンを読み取ることにより、現在のユーザーが属するすべてのグループが識別されます。To make checking permissions faster, SharePoint Server implements user tokens and ACLs in its security model. The user token identifies the authentication process applied to a user. A Windows user has a complex token: a unique string for the user (SID) and a list of all the Windows domain groups for the user (for example, DOMAIN\Department 15688). A user who does not have Windows authentication may have a very simple token with a unique string for the user name, or a complex token with group/role membership just as expressed in Windows authentication. SharePoint group membership for each user is expressed through a user token so that, by reading the user token, SharePoint Server identifies all groups for the current user.

ACL は、特定のオブジェクトに対するユーザーとグループの権限を指定するバイナリ オブジェクトです。ACL は複数の ACE で構成され、各セキュリティ プリンシパル (ユーザーまたはグループ) が ACL 内で 1 つの ACE となります。権限、ロール定義、ロールの割り当てはスコープごとに ACL に構造化されているため、SharePoint Server では、指定された対象範囲内でユーザーまたはグループごとに許可されているアクションを識別できます。An ACL is a binary object that determines the rights that users and groups have on a given object. An ACL consists of multiple ACEs, each security principal (user or group) being one ACE in the ACL. Rights, role definitions, and role assignments are structured into an ACL for each scope, so that SharePoint Server knows what each user or group is allowed to do within the given scope.

オブジェクト モデルの変更: 廃止されたセキュリティ オブジェクト (前方互換性あり)Object model changes: obsolete but backward-compatible security objects

SharePointのオブジェクト スコープでは、同じ基本的な権限の管理操作を共有します。SharePointでは、ロール定義によって権限が管理されます。これにより、リスト、フォルダー、アイテムの各レベルで一貫した操作が可能になります。以下のセキュリティ オブジェクトは Windows SharePoint Services 2.0 で使用されていたもので、廃止となりますが、前方互換性を持たせるために引き続き機能します。In SharePoint, all object scopes share the same basic permissions management experience. SharePoint manages permissions through role definitions, which enable a consistent experience at the list, folder, and item level. The following security objects used in Windows SharePoint Services 2.0 are obsolete, but continue to function for backward-compatibility:

ユーザーをロールに割り当てるには、 Microsoft.SharePoint.SPRoleAssignment クラスと Microsoft.SharePoint.SPRoleAssignmentCollection クラスのメンバーを使用します。 SPRights に代わる SPBasePermisssions 列挙には、追加の権限が含まれます。また、 SPBasePermisssions 列挙には、 SPRights の以前の権限と同じ定数値にマッピングされる従来の権限も含まれます。SharePoint グループの概念は、クロスサイト グループを表す既存の SPGroup オブジェクトと SPGroupCollection オブジェクトに対応付けられます。To assign users to roles, use members of the Microsoft.SharePoint.SPRoleAssignment class and the Microsoft.SharePoint.SPRoleAssignmentCollection class. The SPBasePermisssions enumeration, which replaced SPRights , includes additional permissions. The SPBasePermisssions enumeration also includes legacy permissions that map to the same constant values as previous permissions in SPRights . The SharePoint group concept maps to the existing SPGroup object and SPGroupCollection object, which represent cross-site groups.

ポリシー ロール: URL ゾーンのセキュリティ ポリシーを作成または変更するPolicy roles: create or modify security policies for URL zones

URL ゾーンのセキュリティ ポリシーを作成または変更するには、以下のクラスとそのメンバーを使用します。To create or modify security policies for URL zones, use the following classes and their members:

共有リソースに対応するためのゲスト ロール (制限付きアクセス)Guest roles (Limited Access) to accommodate shared resources

ゲスト ロールの概念は、プラットフォームの共有リソースに対応するというものです。たとえば、リスト ビューのページをレンダリングするには、Web サイトのテーマやナビゲーション構造を使用する必要があります。この概念への対応は、フォルダー レベルとリスト レベルの権限にまで広がっています。The concept of a guest role is to accommodate the shared resources in the platform. For example, the theme and navigation structure of the website must be used to render the page for a list view. This concept is extended to include folder-level permissions and list-level permissions.

従来のオブジェクト モデルとの意味的互換性を保つために、SharePoint オブジェクト モデルはこれまでと同様に " Guest" ロールと呼ばれますが、ユーザー インターフェイスでは [ 制限付きアクセス] と表示されます。The SharePoint object model continues to call this the Guest role for semantic compatibility with the previous object model, although in the user interface the role is now called Limited Access.

フォルダとアイテムの権限が及ぶ範囲Folder and item extensions

フォルダーに対する権限がユーザーに与えられると、そのフォルダーの親リストとそのリストの親 Web サイト (そのフォルダーの上から最上位の先祖である Web サイトまでの、個別にセキュリティ保護されたすべてのスコープ) に対する " Guest" ロールも一緒に与えられます。これは、リスト アイテムにも当てはまります。アイテムに対する権限がユーザーに与えられると、すべての親フォルダー、リスト、最上位の先祖である Web サイトにまでさかのぼった Web サイトに対する " Guest" ロールも一緒に与えられます。When a user is granted permissions on a folder, they are also granted the Guest role on the parent list of that folder and on the parent website of that list—on every uniquely secured scope above the folder, all the way to the first unique ancestor website. This is also true for list items: granting a user permissions on an item also grants that user the Guest role on all parent folders, lists, and websites up to the first unique ancestor website.

1 つのスコープまたはすべてのスコープからユーザーを削除するRemoving users from a scope or from all scopes

あるスコープからユーザーを削除すると、現在のスコープより下にある個別にセキュリティ保護されたすべてのスコープからもそのユーザーが削除されます。たとえば、ある Web サイトからユーザーを削除すると、そのサイト内で個別にセキュリティ保護されたリストからもそのユーザーが削除されます。Removing a user from a scope also removes that user from all uniquely secured scopes beneath the current scope. For example, removing a user from a website also removes that user from uniquely secured lists in the site.

すべてのスコープからユーザーを削除する唯一の方法は、サイト コレクションからそのユーザーを削除することです。そうすることにより、サイト コレクション内ですべてのスコープのすべてのロールからそのユーザーが削除されます。The only way to remove a user from all scopes is to delete that user from the site collection, which removes the user from all roles in all scopes within the site collection.

関連項目See also