Tobias Zimmergren has a great post on his blog that explores the User Information List. 

Here is an excerpt:

The User Information List can be accessed (Only if you’re admin) via the browser by navigating to /_catalogs/users/simple.aspx from your site. (Ex: http://zimmergren/_catalogs/users/simple.aspx)

This works for both Windows SharePoint Services 3.0 (WSS 3.0) and Microsoft Office SharePoint Server 2007 (MOSS 2007)

Tobias Zimmergren has a great post on his blog that explores the User Information List. 

Here is an excerpt:

The User Information List can be accessed (Only if you’re admin) via the browser by navigating to /_catalogs/users/simple.aspx from your site. (Ex: http://zimmergren/_catalogs/users/simple.aspx)

This works for both Windows SharePoint Services 3.0 (WSS 3.0) and Microsoft Office SharePoint Server 2007 (MOSS 2007)

The following PowerShell allows you to write to a file a list of all the users in the Site Owners group of all sites in a site collection:

$txt = ""
$siteUrl = Read-Host "enter site url here:"

$rootSite = New-Object Microsoft.SharePoint.SPSite($siteUrl)

foreach($subsite in $rootSite.AllWebs) {
    foreach($siteAdmin in $subsite.SiteAdministrators) {
        #$txt += "$($siteAdmin.ParentWeb.Url);$($siteAdmin.DisplayName);Site Admin`r"
    }
	foreach($group in $subsite.Groups) {
		if ($group.Name.ToLower().Contains("owner")) {
			foreach ($owner in $group.Users) {
				$txt += "$($siteAdmin.ParentWeb.Url);$($owner.Name);Site Owner`r"
			}
		}
	}
    $subsite.Dispose()
}
$rootSite.Dispose()

out-file -filepath owners.csv -inputobject $txt

I got most of it from this question on StackOverflow

Brian Caauwe has a great post summarizing a TechEd 2011 talk about The Ten Immutable Laws of Microsoft SharePoint Security.

The 10 Laws correspond to the 7 layers of security given in the Open Systems Interconnector (OSI) Model:

1. Physical
2. Data Link
3. Network
4. Transport
5. Session
6. Presentation
7. Application

The 10 laws are:

1. “If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore” – Relates to administrator machines and service accounts.  If everyone knows and has unrestricted access to the SharePoint server, through your logged in account or service accounts, your farm has been compromised.  A reminder to all administrators, LOCK your machines whenever you are not physically in front of the machine as you are the first line of defense for this.
2. “If a bad guy can persuade you to run his program on your computer, it’s not your computer anymore” – Everyone has loaded custom SharePoint solutions (.wsp files) to the farm.  The question is though, do you KNOW everything that that solution does?  Before you deploy a solution you should demand proper documentation and verify how it actually works in a  least priveliged environment.  Do NOT deploy unknown customizations directly on production… unless you have your resume ready.
3. “If a bad guy can view your conversation, you have just invited him to tell everyone” – Make sure you know who is sniffing your network and if you extend SharePoint beyond your internal network you need to ensure everything is running over SSL for proper encryption.
4. “If a bad guy can alter the operating system on your computer, it’s not your computer anymore” – This goes to the least privileged accounts and verifying that accounts do NOT have administrator access to the SharePoint or SQL servers.  A key distinction that the farm account DOES require local administrator rights to the SharePoint server at the time of setting up the User Profile Synchronization service, but after that it technically can be removed.
5. “If you allow a bad guy to upload programs to your website or network, it’s not your stuff anymore” – The main part of this conversation was around DDoS attacks, Session hijacking and DNS poisoning, which is more important in public and extranet web sites but should remind you of what people can do on your internal network.
6. “Absolute anonymity isn’t practical, in real life or on the web” – Even if someone claims you are anonymous when hitting a survey, accessing a file or just being on the network, they are flat out wrong.  All traffic goes through the network and can be traced back through packet sniffing, IIS logs or other auditing means.  Do not publish anything to your environments that you can’t live with if the government sees that information.
7. “Weak passwords trump strong security” – If you don’t require strong passwords, or allow individuals to write down passwords and share them around your security is compromised.  You could have your servers in Fort Knox, but if you share your password around that can access it you ARE compromised and cannot ensure people are who they say they are.
8. “A computer is only as secure as the administrator is trustworthy” – If you don’t trust your administrator, they shouldn’t be your administrator.  An admin may not implicitly have full access to everything that you have, but they sure can grant themselves access to that information.
9. “Your infrastructure is as strong as your weakest link” – Much like the weak passwords law, you could have your servers in Fort Knox, but if someone shares the administrator password around you ARE compromised and cannot ensure the safety and health of your environment.
10. “Technology is not a panacea” – Technology, nor SharePoint, is the silver bullet to solve all problems.  It is however a tool to assist users with bridging the gap between business problems and business solutions.  Use technology to make people’s lives easier, not more processed.

You can use the following script to reset the SharePoint Farm passphrase.  You must be logged in as a farm admin and a local admin on the server.

No, unfortunately, you can not retrieve the passphrase.

$passphrase = ConvertTo-SecureString -asPlainText –Force

Set-SPPassPhrase -PassPhrase $passphrase –Confirm

More info for Microsoft

via SharePoint Comic

We were having trouble adding a user to a site collection.  Every time we hit the search button or clicked the check userid button the system would just sit there and spin. I added the following section of the web.config to resolve the issue.

The error that we were getting in the trace logs is similar to below.

Exception Type: System.Web.HttpRequestValidationException  Exception Message: A potentially dangerous Request.Form value was detected from the client (ctl00$PlaceHolderDialogBodySection$ctl04$OriginalEntities="").

via Solien Technology

There are several steps that you need to take in order to enable anonymous access.  Below are the steps taken from Microsoft TechNet.

Enable anonymous access for a zone of a Web application

1. From Administrative Tools, open the SharePoint Central Administration Web site application.

2. On the Central Administration home page, click Application Management.

3. On the Application Management page, in the Application Security section, click Authentication providers.

4. On the Authentication Providers page, make sure the Web application that is listed in the Web Application box (under Site Actions) is the one that you want to configure. If the listed Web application is not the one that you want to configure, click the drop-down arrow to the right of the Web Application drop-down list box and select Change Web Application.

5. In the Select Web Application dialog box, click the Web application that you want to configure.

6. On the Authentication Providers page, click the zone of the Web application on which you want to enable anonymous access. The zones that are configured for the selected Web application are listed on the Authentication Providers page.

7. On the Edit Authentication page, in the Anonymous Access section, select Enable Anonymous Access, and then click Save.

At this point, the Web application zone has been enabled for anonymous access.

Enable anonymous access for individual sites

Now you need to enable anonymous access for individual sites in the site collection.

Enable anonymous access for individual sites

1. Go to the site on which you want to enable anonymous access and click the Site Actions menu.

2. On the Site Actions menu, click Site Settings.

3. On the Site Settings page, in the Users and Permissions section, click Advanced Permissions.

4. On the Permissions page, on the Settings menu, click Anonymous Access. The settings for anonymous access lists three options:

   • Entire Web site   Select this option if you want to enable anonymous access for the entire Web site.

   • Lists and libraries   Select this option if you want to limit anonymous access to only the lists and libraries on your site.

   • Nothing   Select this option if you want to prevent anonymous access from being used on your site.

5. Click OK.

At this point, your site is configured for anonymous access based on the options that you have selected.

Enable anonymous access for individual lists

If you select Lists and libraries, enable anonymous access for individual lists.

Enable anonymous access for individual lists

1. Go to the home page of your Web site and, in the left navigation pane, click View All Site Content.

2. Click the list on which you want to enable anonymous access.

3. On the Settings menu, click List Settings.

4. On the Customize List page, in the Permissions and Management section, click Permissions for this list.

5. On the Permissions page, on the Actions menu, click Edit Permissions. A dialog box is displayed informing you that you are about to create unique permissions for this list. Click OK.

6. On the Settings menu, click Anonymous Access.

7. Select permissions for users who have anonymous access to the list, and then click OK.

At this point, users have anonymous access to the list you have configured. You can control whether users have anonymous access to other lists, the home page, or other pages on this site.