The steps in the most simplistic form are the following:
1. Create a forms-based\claims Web application to use an LDAP Provider using Central Admin
2. Configure the LDAP Web.Config files for the Central Administrator (web application), Security Token Service (web service), and FBA claims-based (web application).
3. Within User Policy for the newly created FBA\Claims Web Application, Add site collection owner and grant full control.
4. Finally, login to FBA site as site collection owner and grant user permissions to access site
We released a technet article “beta 2” version of how to accomplish this setup using the OfficeServer Ldap Provider. I created this blog in order to fill the gaps and provide some further insight on how to set this up properly. The technet article which covers the first two steps above is located here:
http://technet.microsoft.com/en-us/library/ee806890(office.14).aspx#section2
Note: This has been tested on Beta 2 version. I’ll update the blog when later builds are released to general public if changes are required.
FBA Setup Gotcha’s (three of them)
Gotcha # 1: Steps 3 and 4 are required
I will discuss steps 3 and 4 above in more detail now since they are missing from the article. Once you finish step 1 and 2 from the article, follow step 3 and 4 here:
Step 3 - Within User Policy for the newly created FBA\Claims Web Application, Add site collection owner and grant full control. Steps for this are the following:
1. Launch Central Administrator and select “Manage web applications” under Application Management
2. Select the FBA-Claims based web application and select User Policy from the ribbon
3. Select Add Users, select default zone and hit Next
4. Select the Address book button and add the site owner “Add the account under “User: ”
Note: These are both the same account. You are only required to add the account under “User:” since it’s the one enumerating via the LDAP provider.
5. Grant “Full Control under Permissions and hit Finish button.
Step 4: Login to FBA site as site owner and grant users access to the site.
1. Login to FBA site as site owner
2. Select Site Actions\Site Permissions
3. Select the Group you want
4. Select New, Add users to group and hit the address book
5. Select the ldap account, Add, and hit OK
Gotcha # 2: Web.Config setup
The Technet article walks you through the setup nicely but a couple of things I want to point out. Mainly, misconfigured web.config files. First, treat each web.config file your configuring unique. Not all web.config files are the same. Don't copy output of one and paste it into another one and expect it to work.
Attributes to be aware of when configuring ldap provider in each web.config:
UserContainer - This attribute should look like: userContainer="CN=Users,DC=domain,DC=com"
If UserContainer attribute doesn’t contain a valid DN, you might see the following in the ULS logs during failed logon attempt:
12/29/2009 14:04:54.15 w3wp.exe (0x1118) 0x1374 Office Server Shared Services olgq Exception System.DirectoryServices.DirectoryServicesCOMException (0x80072030): There is no such object on the server. at System.DirectoryServices.SearchResultCollection.ResultsEnumerator.MoveNext() at System.DirectoryServices.DirectorySearcher.FindOne() at Microsoft.Office.Server.Security.LDAP.FindOneObject(DirectoryEntry searchRoot, String filter, SearchScope scope, String[] propertiesToLoad, ResultPropertyCollection& entryProperties) at Microsoft.Office.Server.Security.LdapMembershipProvider.GetUserAttributeBySearchProperty(String searchValue, String searchProperty, String returnAttribute)
groupFilter and userFilter - These two attributes sit under the LdapRoleProvider.
In the technet article, these use different filters within different web.config files.
For example:
Setting these two attributes in the Central Admin web.config looks like:
groupFilter="((ObjectClass=group)"
userFilter="((ObjectClass=person)"
Setting these two attributes within the Claims based FBA Web Application web.config looks like:
groupFilter="(&(ObjectClass=group))"
userFilter="(&(ObjectClass=person))"
It's easy to see the difference in these filters. If your ldap filters are invalid, you will typically get the following exception within the corresponding ULS log during a failed attempt to login via FBA:
12/29/2009 11:52:19.43 w3wp.exe (0x0B04) 0x0F28 Office Server Shared Services olgz High LdapRoleProvider.GetRolesFor() exception: {0}.System.ArgumentException: The (&(((ObjectClass=group))(member=CN=userx,CN=Users,DC=Domain,DC=com)) search filter is invalid. at System.DirectoryServices.SearchResultCollection.ResultsEnumerator.MoveNext() at Microsoft.Office.Server.Security.LdapRoleProvider.GetRolesFor(String userOrGroupDN, DirectoryEntry groupContainer, LdapDistinguishedNameManager ldapDnManager, List`1& userRoles)
Gotcha # 3: Additional step required for Standalone installs
If you run through the above steps with Standalone installs, you need to add one additional step or you will see this in the corresponding ULS log during a failed attempt to login via FBA:
12/29/2009 11:50:02.81 w3wp.exe (0x1868) 0x1AB4 Office Server Shared Services olgq Exception System.DirectoryServices.DirectoryServicesCOMException (0x80072020): An operations error occurred. at System.DirectoryServices.SearchResultCollection.ResultsEnumerator.MoveNext() at System.DirectoryServices.DirectorySearcher.FindOne() at Microsoft.Office.Server.Security.LDAP.FindOneObject(DirectoryEntry searchRoot, String filter, SearchScope scope, String[] propertiesToLoad, ResultPropertyCollection& entryProperties) at Microsoft.Office.Server.Security.LdapMembershipProvider.GetUserAttributeBySearchProperty(String searchValue, String searchProperty, String returnAttribute)
One additional step is required and that is adding a couple of entries to the STS (Security Token Service) web.config file. You will need to add both connectionUserName and connectionPassword.
For example (see Red bold entries below)
<system.web> <membership> <providers> <add name="membership" type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=94de0004b6e3fcc5" server="newyearDC.contoso.com" port="389" useSSL="false" userDNAttribute="distinguishedName" userNameAttribute="sAMAccountName" userContainer="CN=Users,DC=Contoso,DC=com" userObjectClass="person" userFilter="(&(ObjectClass=person))" scope="Subtree" otherRequiredUserAttributes="sn,givenname,cn" connectionUsername="contoso\administrator" connectionPassword="password" /> </providers> </membership> <roleManager enabled="true" > <providers> <add name="rolemanager" type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=94de0004b6e3fcc5" server="newyearDC.contoso.com" port="389" useSSL="false" groupContainer="DC=Contoso,DC=com" groupNameAttribute="cn" groupNameAlternateSearchAttribute="samAccountName" groupMemberAttribute="member" userNameAttribute="sAMAccountName" dnAttribute="distinguishedName" groupFilter="(&(ObjectClass=group))" userFilter="(&(ObjectClass=person))" scope="Subtree" connectionUsername="Contoso\Administrator" connectionPassword="password" /> </providers> </roleManager> </system.web>
Good Luck!
Russ Maxwell, MSFT
I will be moving a good portion of my blogs as well as any new ones over to our new SharePoint Escalation Services Team blog. We think it’s a good idea to get our blogs more consolidated. This also ensures that blog content is mostly coming from Microsoft Support Escalation Engineers and Escalation Engineer’s.
Check out the blog here:
http://blogs.msdn.com/spses
I’ll still be posting my blog content here as well but just wanted to put this on your radar…
Part 1 of this blog will describe ULS and Event log improvements and what you need to know. The new changes simplify troubleshooting and provide the Administrator more flexibility in managing different aspects of ULS logging. I will expand on this topic in Part 2 and will discuss Developer Dashboard. A special shout-out goes to Dan Winter for the knowledge transfer and technical review.
Correlation ID
A deep investment has been made to improve Correlation ID in SharePoint 2010. Events such as page loads and other common events within ULS logs have a corresponding Correlation ID. This ID is grouped with other events based on the same conversation. For example, User A hits a WFE and accesses a site. All the events in the ULS logs that correlate with User A’s login all share the same correlation ID. This makes mining the ULS logs easy in that you can filter based on correlation ID. If the conversation hits multiple servers in the farm, those other servers maintain the exact same correlation ID. A common scenario for this is when a WFE is calling a web service on an application server. It’s also possible to filter on Correlation ID via a SQL profiler trace so you can truly get a farm wide picture of what happened at each level of the conversation. SharePoint error pages also expose a correlation ID along with time stamp of the error so now it’s simple to find the conversation in the servers corresponding ULS logs.
For Example:
Event Throttling
ULS and Event logging now has a richer category based management in that you can set specific subcategories to a unique level of logging while throttling other subcategories that belong to same root category.
For Example, troubleshooting query processor, turn up verbose on query processor component:
In the example above, the root category is bold it flags an administrator when unique logging has been set within a root category. Also, note the different logging levels which can be set on each sub category.
When the issue has been resolved or custom logging levels are no longer required, you can now set logging back to default:
Log File Retention
In SharePoint 2007, the default log file retention policy was to set log files to generate once every 30 minutes with a total of 96 log files at any given time. This equates to 48 hours. ULS logging has been improved by reducing log file size by at least 50 %. This allows a completely new approach to setting log file retention policy. The default setting is now at # of days with the default being 14. A new option exists to restrict trace logs to a fixed disk size. This is unchecked by default.
Once day 15 hits, log files from day 1 are pruned. If restrict trace log setting is enforced to a fixed disk size, then both settings are enforced. The order on which the settings are enforced is dependent upon which condition is hit first.
Number of days to store log files: 14
Restrict trace log disk space usage: 2 GB
SharePoint administrator is chasing a problem and cranks up some verbose logging due to profile provision problem. This causes the total ULS logs size to hit 2 GB on day 3. In this case, the oldest logs are pruned to honor the restrict trace log setting. These settings are configurable via the Set-SPDiagnosticConfig cmdlet.
Note: The highest level you can set the trace log disk space usage is 1 TB.
Event Log Flood Protection
The name says it all. This feature will prevent one event from flooding the event log. This is enabled by default within diagnostics logging:
With this option enabled, if the same event fires 5 times within 2 minutes, we will suppress the event from logging and throw a summary event at the 2 minute mark with a nice description of how many times the event actually fired. This is the default behavior and can be customized using PowerShell via the Set-SPDiagnosticConfig cmdlet.
Note: To qualify has the same event is an event with the same event source and ID. The event severity and/or text doesn’t apply and is not checked.
Manage logging using PowerShell
A more hardcore SharePoint administrator is likely to use PowerShell for all administration including managing ULS logs. The PG has given us a very rich set of command-lets to do things like get\set diagnostic levels and retention policies. It’s possible to mine ULS logs using PowerShell for monitoring or troubleshooting purposes. I’ll discuss each area below and provide some examples.
Retrieve logging levels
The following cmdlet retrieves logging levels:
Get-SPLogLevel – Displays a list of objects or diagnostic levels
The cmdlet pulls all logging levels but what if you wanted to filter this result by area or specific category?
Examples:
To retrieve all logging categories by area “WSS Search Diagnostics”:
Get-SPLogLevel –identity “WSS Search Diagnostics:*” | FL
To retrieve a specific logging category like Query Processor within the WSS Search Diagnostic area:
Get-SpLogLevel –identity “WSS Search Diagnostics:Query Processor” | FL
Set logging levels
The following cmdlet sets logging levels:
Set-SPLogLevel - Sets trace logging and event logging levels to a category
Note: No parameters are set to required but you still need parameters to correctly set logging levels
To set the entire area “WSS Search Diagnostics” to event log level of monitorable and trace level to verbose:
Set-SPLogLevel -TraceSeverity Verbose -EventSeverity Warning –Identity “WSS Search Diagnostics:*”
It’s possible set a specific category within an Area. For Example, setting Query Processor to verbose within WSS Search Diagnostics:
Set-SPLogLevel -TraceSeverity Verbose -EventSeverity Warning –Identity “WSS Search Diagnostics:Query Processor”
Note: Logging levels can be reset back to default level using Clear-SPLoglevel
Creating and Merging Log files
It’s possible to force a new uls log to be created by running new-splogfile. This will end the current log file and start a new one. This is valuable when attempting to reproduce a problem and want to minimize the total size of the log file. Merge-SPLogFile combines trace log entries from all farm computers into a single log file on the local computer. It does this by creating a one-time timer job and executing it to create the merged log. This is extremely valuable if you are tracking an issue and suspect it’s hitting multiple servers in a farm. Since the conversation across multiple servers will contain the exact same correlation ID, the merge-splogfile becomes a powerful cmdlet for troubleshooting.
Some examples of Merge-SPLogFile:
Merge-SPLogFile -Path "C:\Logs\FarmMergedLog.log" -Overwrite
The preceding example merges the last hour of log data from all farm computers with no filtering.
Merge-SPLogFile -Path "C:\Logs\FarmMergedLog.log" -Overwrite -Area Search
The preceding example merges the last hour of log data from the Search area
Additional parameters are available to tune results. For Example, looking for something specific in the ULS message you can filter results using the Message parameter.
Mining ULS Logs via PowerShell
It’s possible to view ULS log entries using the Get-SPLogEvent cmdlet. At beta 2, Running this cmdlet by itself retrieves every event from every ULS log within the directory hosting ULS logs. Some examples of running Get-SPLogEvent:
Example 1: ULS log or logs are moved to a different directory named “newpath”, run the following:
Get-SPLogEvent –Directory “C:\newpath”
Example 2: Retrieve all the events within a certain time period run the following:
Get-SPLogEvent -StartTime "12/04/2007 17:00" -EndTime "12/04/2007 18:00"
Example 3: Retrieve the first 10 events and last 2 events from logs directory:
Get-SPLogEvent | select –first 10 –last 2
Example 4: Retrieve all events with same correlation ID:
Notice the message: “Warning: column “Message” does not fit into the display and was removed.
You can include the message by performing the following:
Note: The more columns you include, the more difficult it is to read the message because it wraps.
Example 5: Retrieve all events based on a specified level.
Get-SPLogEvent | ?{$_.level –eq “critical”}