ControlPoint 8.8.1 - User Guide

Analyzing Users and Permissions

ControlPoint provides the following tools that allow you to examine permissions of SharePoint users throughout your farm:

·Site Permissions shows the permissions of users for selected sites

·Site List Permissions shows user permissions for individual lists and list items within a site.

An additional analysis, Comprehensive Permissions, show permissions for all sites, lists, and optionally list items within a single result set.

NOTE:  In addition to showing user permissions at the individual site level, all Site Permissions analyses include any Web application policy permissions users may have.

You can also:

· find Orphaned Domain Users (that is, users who are no longer listed in the Active Directory but still have permissions in SharePoint).

·analyze Comprehensive User Information about a single user, which in addition to the user's permissions, includes

§workflows created by the user

§documents created by, last modified by, and checked out to the user

§SharePoint alerts that have been created for the user

§open tasks assigned to the user, including workflow tasks

§membership in both SharePoint and Active Directory groups.

·analyze the membership and permissions of SharePoint Groups.

IMPORTANT: Permissions Reporting for Claims-Based Users

If your SharePoint farm includes claims-based authentication, permissions granted through a claim may not be reliably reported because SharePoint only retains permissions information for a claims-based user for a limited time after the user logs in.

Finding Orphaned Domain Users

If you are using Active Directory as the authentication method for your SharePoint environment, the Orphaned Domain Users analysis lists users who currently have permissions in SharePoint but are no longer valid in the Active Directory.  

NOTE:  The results of an Orphaned Domain User analysis are security-trimmed. An orphaned user's individual permissions for sites to which the administrator running the analysis does not have access will not be reflected in results.  If all of the sites in which a SharePoint user has permissions are not accessible to the administrator running the analysis, that user will not be included in analysis results.  Therefore, the analysis will be most complete when run by an administrator with full permissions to the entire farm.

Users Evaluated as Potential Orphans

ControlPoint evaluates users as potential orphans if they are disabled in and/or deleted from Active Directory but are found in:

·a SharePoint permission entry at any level (site, subsite, list, library, folder, or item)

·a site collection's All People list, and/or

·a Site Collection Administrator's list.

ControlPoint does not evaluate names in Web application policies, the Farm Administrator list, or any custom SharePoint list that may contain user names.

Users That Are Not Reported as Orphans

ControlPoint does not report a user as being orphaned if it is considered valid by SharePoint (that is, if a user who is not in the All People list can still be validated by the SharePoint People Picker).  Active Directory entries that are considered valid by SharePoint (and therefore are not reported as orphaned by ControlPoint) include:

·expired accounts, and

·locked accounts (i.e., accounts for which the allowable threshold for failed login attempts has been exceeded).

To generate an Orphaned Domain Users analysis:

1Select the object(s) you want to include in your analysis.

2Choose Users and Security > Orphaned Domain Users.

3Specify the parameters for your analysis.

Note that you have the option of limiting your results only to users who are either disabled in or have been deleted from Active Directory.  If you accept the default option, Show all orphans, both types of users will be included.

4If you want ControlPoint to automatically delete all users returned by the analysis on the home farm, check the Automatically delete users after analysis has run (in home farm only).  Note that, in a multi-farm environment, this action cannot be carried out on a remote farm.

CAUTION: If you check this box, ControlPoint will automatically submit one or more Delete User jobs to the ControlPoint scheduler. The number of jobs submitted depends on the number of users to be deleted, and the number of users processed in a job is determined by the ControlPoint Setting OrphanDeleteBatchSize. The first job will be scheduled to run 30 minutes after the analysis has finished processing. Because this action cannot be undone, you may want to back up user permissions before running the operation. (You also have the option of deleting jobs before they have run via the Schedule Monitor.)

Now you can:

·run the operation immediately (by clicking the [Run Now] button)

OR

·schedule the operation to run at a later time or on a recurring basis.

OR

·save the operation as XML Instructions that can be run at a later time.

When expanded, a list of rights for each orphaned user displays the same information as the User Rights section of the Site Permissions analysis.

Disabled Accounts as Orphans

Users whose accounts have been disabled (or disabled and renamed) in the Active Directory are normally considered orphans by both SharePoint and ControlPoint and are annotated as such in analysis results.  This annotation is intended to help you in evaluating whether or not such users really should be considered orphans in accordance with you organization's policies.

If an account has been both disabled and renamed, the annotation will include the original name, followed by the string DISABLED, RENAMED; and the new name.  (ControlPoint will not consider a renamed account orphaned if it is also active, expired, or locked.)

NOTE:  Although it is not a common practice, it is possible for restricted reads and other permissions to be placed on entries in the Active Directory.  This can affect ControlPoint's ability to detect disabled accounts.  Specifically, if an account has been disabled AND cannot be read by the ControlPoint Service Account, then both SharePoint and ControlPoint will treat that account as valid (not an orphan).

To delete orphaned user permissions from analysis results:

Use the information in the following table to determine the appropriate action to take.

CAUTION:  If you have any doubt as whether a user is truly orphaned, it is recommended that before you delete permissions, you verify his/her existence and status in the Active Directory.

Analyzing Site Permissions

The Site Permissions analysis lets you examine the permissions that one or more users have for selected sites.

To generate a Site Permission analysis:

1Select the object(s) you want to include in your analysis.

2Choose Users and Security > Site Permissions.

3Specify the parameters for your analysis.

Note that, In addition to the "standard" parameters, you have the option to Group by Sites (the default) or Users.

Now you can:

·run the operation immediately (by clicking the [Run Now] button)

OR

·schedule the operation to run at a later time or on a recurring basis.

OR

·save the operation as XML Instructions that can be run at a later time.

Site Permissions analysis results contain the following sections:

·Web Application Policies

·User Rights

·Active Directory group members (if you chose to Include AD Group Members table.)

Web Application Policies Section

Depending on how you chose to group results, the top level of the Web Application Policies section lists either the Web application(s) or the users within the scope of your analysis.  If grouped by sites, a plus sign (+) in any of the permission columns at the Web application level indicates that at least one user has that permission.  If grouped by user, the plus sign indicates that the user has that permission for at least one Web application.

The policy permissions within individual Web applications/for individual users (depending on how results are grouped) or for users within the Web application (including any that are zone-specific) displays.  A plus sign (+) displays in the applicable column(s), which may include:

·the following policy-level site collection permissions (which indicates that one of the specified policy permission levels has enabled the site collection permissions):

§Administrator

§Auditor

§System settings (for accounts that operates as a system account)

NOTE:  Administrator and Auditor are site collection level permissions that a policy level can have.  They are set for the Web application via the SharePoint Manage Permission Policy Levels > Edit Permission Policy Level page.

·the four built-in SharePoint policy permission levels:

§Full Control

§Full Read

§Deny Write

§Deny All

NOTE: If a user has a custom policy permission level, it is recorded in the Other column.

Note that the account in which the Web application's application pool runs is listed with the zone identified as (System Account).

User Rights Section

Depending on how you chose to group results, the top level of the User Rights section lists the Web application(s) or users within the scope of your analysis.  

NOTE:  If Anonymous Access has been enabled for the Web application, it will be indicated in parentheses following the Web application name.

For each Web application, a list of sites within the Web application displays.

When expanded, a list of users and/or Active Directory groups with permissions for the site collection or site displays, along with the following information:

·the login name of the SharePoint User

NOTE:  If Anonymous Access has been enabled for the site, <Anonymous Access> appears as the first user name

·the user's permission level(s), as indicated by a plus sign (+) in the applicable column(s), which may include:

§the site collection's Admin group

§the five default SharePoint permission levels:

§Full Control

§Design

§Contribute

§Read

§Limited.

NOTE:  If a user has a template-specific or custom permission level, it is recorded in the Other column.  If Anonymous Access has been enabled for the site, the level of access (Entire Website, Lists and Libraries, or None) is recorded in the Other column.

By default, the report lists:

·users with direct permissions

·users with membership through SharePoint groups, and

·Active Directory groups that either have direct permissions or have been placed into SharePoint groups.

The Display Name/Group column shows the display name of each user whose permissions are direct or through membership in a SharePoint group.  This name is taken from the Preferred Name field of the SharePoint User Profile, which is typically populated with the Active Directory Display Name.  If a display name does not exist for the user, the user's login name will display in brackets < >.  

If you chose to Include Users with AD Group Membership, users who have permissions through Active Directory groups are listed as separate line items, with name of the Active Directory group displayed in the Display Name/Group column.

If you chose to group by Sites, you can click the AD hyperlink to the left of an AD group in the User Rights section to view Active Directory group members.

If you chose to Include AD Group Members table, an Active Directory members section, which lists each Active Directory group with permissions and all of its members, displays at the end of analysis results.

Analyzing Site Lists Permissions

The Site Lists Permissions analysis lets you examine user permissions for individual lists within a selected site.

NOTE:  List permissions are also included as part of the Comprehensive Permissions analysis.  You can also view permissions for items within a selected list by running a Permissions by List Item analysis.

To generate a Site Lists Permissions analysis:

1Select the site whose list permissions you want to analyze.

NOTE:  You can only analyze list permissions for one site at a time.  If you multi-select, only the site on which you right-clicked will apply.

2Choose Users and Security > Site Lists Permissions.  Use the information in the following table to determine the appropriate action to take.

3Specify the parameters for your analysis.

Now you can:

·run the operation immediately (by clicking the [Run Now] button)

OR

·schedule the operation to run at a later time or on a recurring basis.

OR

·save the operation as XML Instructions that can be run at a later time.

The top level of the Site Lists Permissions analysis shows all of the lists used on the site, along with the following information:

·the Security type (Inherited or Unique)

·the number of Items in the list

·the number of Items with Unique Permissions.

NOTE:  If you chose to Show unique permissions only, results will include any list that contains items with unique permissions (even if the list itself has inherited permissions).

When expanded, the following information displays for each list:

·each User or Active Directory group with permissions to the List item(s)

·if applicable, the SharePoint Group via which the user has permissions (users who have direct access are appropriately identified)

·the number of Accessible Items for that user, and

·the user's permission level(s).  A plus sign (+) displays in the applicable column(s), which may include any of the five default SharePoint permission levels:

§Full Control

§Design

§Contribute

§Read

§Limited.

NOTE:  If a user has a template-specific or custom permission level, it is recorded in the Other column.

By default, the report lists:

·users with direct permissions

·users placed into SharePoint groups, and

·Active Directory groups that either have direct permissions or have been placed into SharePoint groups.

The Display Name/Group column shows the display name of each user whose permissions are direct or through membership in a SharePoint group.  This name is taken from the Preferred Name field of the SharePoint User Profile, which is typically populated with the Active Directory Display Name.  If a display name does not exist for the user, the user's login name will display in brackets < >.  

If you chose to Expand Active Directory Groups:

·users who have permissions through Active Directory groups are listed as separate line items, with name of the Active Directory group displayed in the Display Name/Group column.

AND

·an Active Directory members section, which lists each Active Directory group with permissions and all of its members, displays at the end of analysis results.