Sdílet prostřednictvím

SharePoint Account Management using SPUserUtil - Part 3 - Auditing Accounts

  • Článek

SharePoint Account Management using SPUserUtil - Part 3 - Auditing Accounts

 

SPUserUtil will mean either WSSUserUtil or SPSUserUtil respectively (WSSUserUtil is used to administer Windows SharePoint Sites on a standalone WSS Farm/Virtual server OR Windows SharePoint sites in the same virtual server of a SharePoint Portal Server 2003 site.) SPSUserUtil is a superset of WSSUserUtil, designed for working on SharePoint Portal Server Areas.

I went back and renamed some of the previous posts I had written about SharePoint Account Management to reflect that these are all really within the realm of SharePoitn Account Management, and each post covers a specific aspect of such.

In fact, the oldest post is now called "Part 0" :)

For a recap (And to unravel any confusion this may have caused :)), here is the series so far.

In this post, I'll show you the many different ways you can use SPUserUtil to audit accounts in your SharePoint environment

Out of Box methods for auditing accounts

The OOB (Out of Box) way to currently audit security principals on your sites and webs is to visit each respective site collection or web and look at their corresponding users list. But nothing (outside of purchasing a third party tool) gives you the ability to quickly audit for users and groups across site collections and webs.

Out of Box methods for auditing accounts

Auditing accounts for a web through the UI

If you just want to view the current account rights on a web, you simply need to access the "Manage Users" page for the web in question. The navigation path to this page (for Windows SharePoint Services) is:

  1. From the home page of the site, click "Site Settings" on the top navigation bar
  2. Click "Manage Users"

If you have removed the navigation bar on your site, or you want to just jump right to the page, you can access it by navigating to the users.aspx layouts page directly in your browser. For example:

    https://server/sites/asite/asubweb/_layouts/1033/user.aspx

This will take you to the "Manage Users" page for the subweb named "asubweb" underneath the top level site "asite" within the managed path "sites" on the "server" in question.

From this page, you can view the account resources on the web. If you have many accounts, you will need to click on the previous and next links on this page to paginate through the list of accounts.

Note: Keep in mind, that the Windows SharePoint Services Capacity Planing Guide states that the The size of the access control list is limited to a few thousand security principals, in other words users and groups in the Web site . The Guideline for optimum performance is 2000. If you need to utilize more than 2000 individual security principals, consider using NT Security Groups, as I have seen many customer experience problems when they exceed these guidelines. SPSiteManager (Also located in the SharePoint Utility Suite) can assist you in detecting and reporting where you have exceeded this capacity planning guideline.

Auditing accounts for a site collection through the UI

If you want to audit accounts that have access from a site collection perspective you simply need to access the "Manage Site Collection Users" page for the site collection in question. The navigation path to this page (for Windows SharePoint Services) is:

  1. From the home page of the site, click "Site Settings" on the top navigation bar
  2. Click "Go to Site Administration"
  3. Click "Go to Top-level Site Administration"
  4. Click "View site collection user information"

If you have removed the navigation bar on your site, or you want to just jump right to the page, you can access it by navigating to the siteusrs.aspx layouts page directly in your browser. For example:

    https://server/sites/asite/_layouts/1033/siteusrs.aspx

This will take you to the "Manage Site Collection Users" page for the site collection whose top level site is "asite" within the managed path "sites" on the "server" in question.

From this page, you can view the account resources at the site collection scope which shows you all users who have at least Guest rights on a web within the site collection. This shows you a concise list of all users whom have hit a web within the site collection. If you have many accounts, you will need to click on the previous and next links on this page to paginate through the list of accounts. 

Cumbersome Problem Number 1

This becomes an administrative headache if you have 100's or 1000's of account resources on your webs or sites, in which case you have to paginate through all these resources on either the users.aspx page or the siteusrs.aspx pages, to "find" an account.

Cumbersome Problem Number 2

If you have 100's or 1000's of site collections, it makes it nearly impossible to find what sites and webs a given account has, or ever had, access to.

SPUserUtil to the rescue.

You can use the analyze operation of SPUserUtil to analyze a Windows SharePoint Services web or SharePoint Portal Server Portal for auditing purposes. This operation will scan your targeted URL and produce two files (the user map and the webs manifest file) which can be used for security audit reviews.

You can adjust the scope of this analysis to a single web, a series of webs, a complete site collection, or multiple site collections on a specified virtual server.

The Webs Manifest (depending on your analysis scope) can give you a holistic view of user security across your SharePoint farm.

Note: SPUserUtil and SPSiteManager are being merged into one all encompassing tool. This will give you the added benefit of taking advantage of the SPSiteManager SDD (Site Distribution Document) as well as the ability to scan multiple virtual servers at once for auditing purposes.

Note: Pay special attention to the new -asuonly and -usermask switches noted below

Auditing accounts for a web using SPUserUtil

By Using the analyze operation in SPUserUtil, it's extremely easy to analyze a single web, or multiple webs and produce a file in XML that can be used with any tool capable of displaying XML to audit user rights.

For example:

    wssuserutil -o analyze -url https://server/sites/asite -r -usermap c:\all-users.xml -webfile c:\allusers-webs.xml

This example starts its analysis at the web/site designated by –url, and scans all subwebs recursively underneath which results in producing two files as noted below:

UserMap file

The UserMap file will contain a distinct list of unique users found within the scope of the analysis operation

Webs Manifest File

This file gives you a complete hierarchical view of the webs and their individual rights on each.

For example:

<?xml version="1.0" standalone="no"?><!DOCTYPE SPUserUtilWebFile><!--This file represents the web information generated and used by SPUserUtil--><webs> <web url="https://myserver/sites/artists" title="Artists Site" description="Cool Artists Web" lcid="1033" template="STS" uniqueperms="True"> <user loginname="MUSIC\edgarf" displayname="Edgar Frose" email="edgarf@tangerinedream.org" notes="" sid="S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxxx-xxxxxx" > <crosssitegroups /> <sitegroups> <group name="Contributor" /> </sitegroups> <listpermissions /> </user> <user loginname="MUSIC\cfranke" displayname="Christopher Franke" email="cfranke@sonicimages.com" notes="" sid="S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxxx-xxxxxx" > <crosssitegroups /> <sitegroups> <group name="Contributor" /> </sitegroups> <listpermissions /> </user> <web url="https://myserver/sites/artists/movies" title="Movies Subweb" description="This site contains information related to movies" lcid="1033" template="STS" uniqueperms="True"> <user loginname="HOLLYWOOD\bwillis" displayname="Bruce Willis" email="bwillis@hollywood.com" notes="" sid="S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxxx-xxxxxx" > <crosssitegroups /> <sitegroups> <group name="Contributor" /> </sitegroups> <listpermissions /> </user> <user loginname="HOLLYWOOD\glucas" displayname="George Lucas" email="glucas@hollywood.com" notes="" sid="S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxxx-xxxxxx" > <crosssitegroups /> <sitegroups> <group name="Contributor" /> </sitegroups> <listpermissions /> </user> </web> </web></webs>

Notice that for each web found within the scan, an individual <user> element is written for each security principal found. Each <user> element will contain a <crosssitegroups> and <sitegroups> container that may contain a list of Cross Site Groups or Site Groups the security principal is in. These individual groups will be noted by a <group> element with each respectively.

Also, for each document library or list where you have explicit permissions set, you'll see a <list> entry within the <listpermissions> container with the title of the list/document library and the permission mask.

The web manifest file only shows the accounts which currently have permissions on sites/webs detected in the scan, but does not have the complete list of users that may exist in the site collection, and thus the usermap will only reflect those users. If you want to see a complete unique list of accounts that have ever hit the site collection (and were not removed from the site collection) use the -asu or -asuonly switch.

The -asu switch causes the usermap to be populated with the complete list of Site Collection users regardless if they currently have permissions on a web or not. When using this switch, we write out all the site collection users, then proceed to do the normal web analysis.

The -asuonly switch performs the same function as the -asu switch, but bypasses the web scanning to create the web manifests file.

If you don't specify a -webfile switch, a webs manifest file is still created for you using the name of the usermap appended with "-webs" in the filename.

Auditing accounts for a site collection using SPUserUtil

In the example in the previous section, asite is the top level site in the site collection, thus the complete site collection was analyzed with the above example. If you wanted to analyze every single site collection on a virtual server, add the -ac switch

For example:

    wssuserutil -o analyze -url https://server/sites/asite -r -usermap c:\all-users.xml -webfile c:\allusers-webs.xml -ac

Even though the above example still specifies a direct site collection in the -url, by specifying the -ac (All Collections) switch we simply connect to the virtual server for the URL, and analyze every Site Collection found for the virtual server.

In this case, the usermap will contain a distinct list of users detected in the scan by distinct across the entire virtual server for all site collections.

The Webs Manifest file will also have a top level <web> element for each site collection found within the <webs> container.

Auditing a single account across the farm using SPUserUtil

In this example, we'll use the -usermask switch to filter the analysis down to a single account, or find accounts using a given mask

For example to scan an entire virtual server to determine where a specific user has rights:

    wssuserutil -o analyze -url https://server -r -usermap c:\all-users.xml -webfile c:\allusers-webs.xml -ac -usermask "TAILSPINTOYS\krichie"

This will produce a webs manifest file, but only the account TAILSPINTOYS\krichie will be reported on.

If I wanted to filter for accounts only matching a portion of the login name, say perhaps all users from the WINGTIPTOYS domain

  wssuserutil -o analyze -url https://server -r -usermap c:\all-users.xml -webfile c:\allusers-webs.xml -ac -usermask "*WINGTIPTOYS*"

This will produce a webs manifest file, but only report on accounts which have WINGTIPTOYS within the login name

You would repeat this process for each virtual server in your farm to get a complete list of account right locations through your farm.

Note: Once the merge of functionality of SPUserUtil and SPSiteManager is complete, the resulting output will not include the nested webs when filtering on specific account masks as it does now. The way SPUserUtil works in it's current iteration, you could have many <web> elements and nested <web> elements in the resulting file for your entire farm, even though the account only exists on one web.

I hope you see the benefit in the auditing capabilities of SPUserUtil. Our goal is to improve this experience in the next release of this tool set. If you have any questions or comments, please let me know!

 - Keith

For more information in regards to the Schema of the Various SharePoint Tables, see the Databases section in the SharePoint Products and Technologies SDK at:
https://msdn.microsoft.com/library/default.asp?url=/library/en-us/spptsdk/html/SPPTWSSDatabases_SV01072208.asp

For more information in regards to Managing Users and Cross Site Groups in SharePoint
https://office.microsoft.com/en-us/assistance/HA011608091033.aspx

SPUserUtil is contained in the The SharePoint Utility Suite at:
https://www.microsoft.com/sharepoint/downloads/components/detail.asp?a1=724

For More information on the Windows SharePoint Services MigrateUserAccount() API:
https://msdn.microsoft.com/library/default.asp?url=/library/en-us/spptsdk/html/tsamSPGlobalAdminMigrateUserAccount_SV01234066.asp

For More information on the SharePoint Portal Server MigrateAccount() API:
https://msdn.microsoft.com/library/default.asp?url=/library/en-us/spptsdk/html/mPortalAccountMigManagerMigrateAccount2_SV01187841.asp

For more information on Windows SharePoint Services and SharePoint Portal Server 2003:
https://www.microsoft.com/sharepoint

Comments

  • Anonymous
    June 19, 2006
    SPSiteManager Postings
    Throughout this week, I hope to get some SPSiteManager postings complete matching...
  • Anonymous
    June 26, 2006
    Keith Richie has been putting together a series of articles that describes the awesome tool that goes...
  • Anonymous
    July 20, 2006
    I can't stress how many times Keith Richie's SharePoint Suite has helped me in solving customer requests.&amp;nbsp;...
  • Anonymous
    August 03, 2006
    SharePoint Account Management using SPUserUtil - Part 4 - Replaying Permissions and Moving Webs
    Originally...
  • Anonymous
    August 04, 2006
    SharePoint Account Management using SPUserUtil - Part 5 - Handling NT Login Name ChangesOriginally Posted...
  • Anonymous
    August 07, 2006
    SharePoint Account Management using SPUserUtil - Part 6 - Synchronizing Display Names and Email Addresses...
  • Anonymous
    August 07, 2006
    SharePoint Account Management using SPUserUtil - Part 6 - Synchronizing Display Names and Email Addresses...
  • Anonymous
    July 09, 2008
    The comment has been removed
  • Anonymous
    May 29, 2009
    PingBack from http://paidsurveyshub.info/story.php?title=keith-richie-sharepoint-account-management-using-spuserutil-part-3