Datasheet
SharePoint Search 
|
  23
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 applica-
tions 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 stan-
dard Security Assertion Markup Language (SAML) tokens, giving it the option to sup-
port 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.
SharePoint Search
The Search service for SharePoint Foundation is basically the same one used for the previous ver-
sion (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.
•u
It crawls through site collections and indexes data.•u
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 data-
base; 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 Stand-
alone 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.)
626382c01.indd 23 1/27/11 10:47:24 AM










