Microsoft Office Tutorials and References
In Depth Information
authentication process of Kerberos, using it to authenticate can be a problem due to time
synchronization. Another consideration is that, in some situations, the Index service used by
the Search service (discussed next) cannot authenticate using Kerberos (on custom ports in
particular) and therefore cannot index sites that require it. That said, Kerberos can be a little
faster and is more secure than NTLM. Further, it can also be used for those service
applications that do pass-through authentication. For more information about Kerberos and how to
configure it, see Chapter 16.
Claims-based authentication Not technically an authentication method, SharePoint
now also supports claims-based authentication. This allows SharePoint to support
standard Security Assertion Markup Language (SAML) tokens, giving it the option to
support non-Windows accounts in a Kerberos ticket kind of way. It also makes it possible to
use security tokens to better protect authentication using forms-based authentication. If
you enable claims-based authentication for a web application, you can still use NTLM or
Kerberos, but claims-based is the option that supports forms-based authentication as well.
The Search service for SharePoint Foundation is basically the same one used for the previous
version (WSS 3.0). The interface has changed a little and is now called SharePoint Foundation Search.
Search basically does two things:
It responds to search queries.
It crawls through site collections and indexes data.
This is why Search has two services, the Search service and the Index service (or content
access service), and their corresponding service accounts. Both services use the search
database; the Index service merges its collected data with it, and the Search service queries it. Only
one Index service can exist on a server farm, but there can be more than one server running
the Search service on a farm. (Each server would share the Index service.) The Index service
requires read access to all content databases of all the web applications that will be searched.
When a web application is being created, you can assign a search server to service its content
database. This is useful if you have more than one server running Search.
The Index service will scan the content databases of the web applications per the schedule
you set up when you enable Search. The changes that it finds are temporarily stored in index
files on the SharePoint server that is running the Index service and then merged with the search
database after a set period of time. Meanwhile, the Search service, when responding to a user
query, will check the index files and the database to be sure that all results are accurate. This is
why there can be only one server running the Index service on a farm, because those files have
to be in one place. When installing SharePoint using either the Complete or Server Farm
Standalone installation, you can use the option to save the index files to a different location. Consider
setting aside a different drive or partition on the server to handle the possible large amount
of files. (If you do specify where the index goes and if you decide to move it later to a different
server, be sure the same path is available for the index files on the new server to avoid issues.)