Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Join Index Server and Kerberos Error

  Asked By: Daryl    Date: Aug 18    Category: Sharepoint    Views: 1900

I am working on a simple server farm which has one front end and one
back end. Both servers are using Kerberos authentication and it
works fine.

So, when I tried to have another srver to join this server farm as
Index server. What I did include:

1. Create a SPN using -A HTTP/indexserver.FQDN (fully qualified
domain name).
2. On the index server, change the accounts used by the following
services to use the same domain user accounts used by the central
admin hosting server:
Office SharePoint Server Search
Windows SharePoint Services Search
Windows SharePoint Service Timer
3. All three services mentioned above were changed to start either
manually or automatically.

When I opened Centeral Administration site and chosse the index
server to start the Office SharePoint Server Search, I received this
error message:

An unhandled exception occurred in the user interface.Exception
Information: The request failed with HTTP status 401: Unauthorized.

On the front end which is hosting CA and content web application, in
the event viewer, unde Application category there is an exception
like this:

EventType ulsexception12, P1 w3wp.exe, P2 6.0.3790.1830, P3 ........

Under System category, there is an Kerberos errors, the Event ID is 4
and following is the error message:

The kerberos client received a KRB_AP_ERR_MODIFIED error from the
server host/indexserver.domianname.com. The target name used was
HTTP/indexserver.DOMAINNAME.COM. This indicates that the password
used to encrypt the kerberos service ticket is different than that on
the target server. Commonly, this is due to identically named
machine accounts in the target realm (DOMAINNAME.COM), and the client
realm. Please contact your system administrator.

We checked the AD and pretty sure there was no duplicated names
registered with the same server name under HTTP. One of the
difference is:
In the host/indexserver..... , everything showed in lower case.
In HTTP/indexserver ....., the domain name showed in upper case.

Although Windows system does not care about cases, I did find a blog
said he registered with different case and it worked.

My question is: other than change the case, anything else I missed
could cause this problem?



14 Answers Found

Answer #1    Answered By: Aditiya Kapale     Answered On: Aug 18

Would anyone urgently know how to locate the GUID of a SharePoint
contentdb ?

I am trying to perform a database moving using stsadm preparetomove.

Answer #2    Answered By: Cristopher Gould     Answered On: Aug 18

look in your backup logs. they should be there (either in the spbr directory
where you backup, or in Central Admin backup history)

Answer #3    Answered By: Selena Glenn     Answered On: Aug 18

What account did you create  the SPN for? The computer account or the
account that is the identity of the SSP app pool?

I wasn't aware that an http  SPN was needed for a server  that is only
hosting the index  service but if it is, I would assume it would be
for the identity of the SSP app pool. Also, I believe best practice
is to always create 2 SPNs, one fully  qualified and one not because
some services  make the requests with it and some without.

If you haven't come across it already, you might find this article

Answer #4    Answered By: Jonathon Palmer     Answered On: Aug 18

It depends on which server  is selected for crawling. See 'Central
Administration, Services on Server, Office SharePoint Search'

What is selected at the bottom of the page?

Answer #5    Answered By: Aastha Patel     Answered On: Aug 18

In my case, The current one is doing crawling is the one hosting
cnetral admin. I would like to start  the service  on the new index
server and received  the errors.

Answer #6    Answered By: Akshay Gupta     Answered On: Aug 18

I wouldn't think starting the service  should require the SPN, unless you
are using that box for crawling. If so, I assume you will have to register the
SPN for all Web apps.

haven't tried this myself, but will be this Friday on a gov't system. lemme know
what you find?

Answer #7    Answered By: Trinity Scott     Answered On: Aug 18

Here are the SPN I registered:

For the server  which hosting  portal and central admin, I registered
the SPN as:

HTTP/Servername.FQDN domain\userename

HTTP/Portalname.FQDN doamin\username

HTTP/portalname domain\username

These usernames are used in app pools.

For SQL Server

MSSQLSvc/DBservername.FQDN:1433 domain\username

For index  server

HTTP/servername.FQDN domain\username

I thought lots of larger farm  have the index server setup and some of
them may run into this situation. However I have been searching for
cluse for two months and so far no solid ones.

Answer #8    Answered By: Constance Guerrero     Answered On: Aug 18

First, I apologize for this being so long. I don't think I can
explain it adequately any more condensed and I don't currently have
an external blog to post to.

I finally got Kerberos to work for all of the web apps, central
admin, excel services, search, and the BI web parts that display SSAS
and SSRS a couple months ago. I won't lie to you, it was painful.

The structure of our environment is two load balanced Web Front-end
servers hosting  the Portal Web Application, MySite Web Application,
and the SSP Admin Web Application. We also have the query service
running on each of these web front-ends. We then have a separate
server that I am calling an application server  that hosts Central
Admin, Excel Services, and document conversion. There is also a
separate server that just does the indexing. Our SQL Server is a
cluster with multiple named instances. We have a separate server that
hosts SSAS and SSRS. We are running SSRS in sharepoint  Integrated
Mode and are connecting to SSAS through Excel spreadsheets, which get
published to Excel Services.

There were several gotchas along the way but here are some of the
1. SSAS uses the instance name for the SPN request  whereas SQL
Service uses the port number of the instance.
2. IE (or probably more appropriately .NET) doesn't append the port
number when making an SPN request so all of the HTTP SPNs needed to
be created without the port number or they wouldn't work.
3. The HTTP SPNs not using port numbers caused another issue which I
didn't find documented anywhere. The best practice that is documented
everywhere details out some 15 different service accounts  that should
be used when setting up a MOSS environment. One of these is what is
often called the Farm Account that is supplied when you first run the
configuration wizard. This account becomes the identity of the
Central Admin App Pool. Another is the SSP service  account that is
requested when setting up a SSP. This account becomes the identity of
the SSP Web Service App Pool that MOSS search, Excel Services, etc.
uses. Typically, neither of these websites use host headers. The SSP
WS App Pool uses ports 56737 and 56738. Central Admin uses whatever
port you tell it to use when you are configuring it. So, if the HTTP
SPNs did use port numbers your SPNs would be, for
example, "HTTP/CentralAdminServer:1234 domain\FarmAccount"
and "HTTP/ExcelServicesServer:56737 domain\SSPServiceAccount" but,
since they don't, they
become "HTTP/CentralAdminServer" "HTTP/ExcelServicesServer". Now if
Central Admin and Excel services  (or any of the other SSP services)
run on the same server you have a problem because this is forcing you
to register the same SPN for 2 different accounts, which isn't
allowed. Neither SPN will work in this case. So, what I found I had
to do was use the same account for the Farm Account that Central
Admin uses and for the SSP Service Account. This allowed me to use
one SPN that covered both Central Admin and Excel Services, since I'm
hosting them on the same server currently.

These are the steps that I took. If you aren't worried about Excel
Services, SSAS, and SSRS then several of these won't be necessary.

- MSSQLSvc/SQLServerName:port domain\SQLServiceAccount
- MSSQLSvc/SQLServerFQDN:port domain\SQLServiceAccount

- MSOLAPSvc.3/SSASServerName:InstanceName domain\SSASServiceAccount
- MSOLAPSvc.3/SSASServerFQDN:InstanceName domain\SSASServiceAccount

- HTTP/CentralAdminServerName domain\FarmAccount
- HTTP/CentralAdminServerFQDN domain\FarmAccount

- HTTP/PortalName domain\PortalAppPoolAccount
- HTTP/PortalFQDN domain\PortalAppPoolAccount

- HTTP/MySiteName domain\MySiteAppPoolAccount
- HTTP/MySiteFQDN domain\MySiteAppPoolAccount

- HTTP/SSPSiteName domain\SSPSiteAppPoolAccount
- HTTP/SSPSiteFQDN domain\SSPSiteAppPoolAccount

Granted the following service/computer accounts the "Trust this
user/computer for delegation to any service(Kerberos)" Delegation
right within AD:
- PortalAppPoolAccount
- MySiteAppPoolAccount
- SSPAppPoolAccount
- FarmAccount
- WebFrontEndServer1
- WebFrontEndServer2
- AppServer1
* Once you have proven that everything is working, going back in and
defining exactly what services each should have the right to delegate
to would probably be wise.

Answer #9    Answered By: Chandrabhan Konwar     Answered On: Aug 18

I am really appreciated that you spent time to write this. One quick

If I have the same web application hosting  content, mysite and SSP,
then I only need to register the SPN for content since the rest of
them are the same, correct?

Answer #10    Answered By: Tina Owens     Answered On: Aug 18

I'm sure right now you are just trying to get this to work but, I
would strongly suggest that you look into breaking these out into
separate web apps when it is implemented in your production
environment. There are many reasons that this is advisable but I
won't get into that now.

However, with how your current environment is configured, it sounds
like you would probably need SPNs for your multi-purpose web app,
Central Admin, and SQL Service. I'm assuming you aren't attempting
Excel Services, SSRS, or SSAS right now.

- HTTP/PortalName domain\PortalAppPoolAccount
- HTTP/PortalFQDN domain\PortalAppPoolAccount

- HTTP/CentralAdminServerName domain\FarmAccount
- HTTP/CentralAdminServerFQDN domain\FarmAccount

- MSSQLSvc/SQLServerName:port domain\SQLServiceAccount
- MSSQLSvc/SQLServerFQDN:port domain\SQLServiceAccount

Where is the MOSS query service  running (a.k.a. What server
is "serving search  queries")? I didn't run into any issues with this
in my implementation so I am assuming you are fine  if it is running
on the server  that is hosting  the multi-purpose web app. If it is
another server though, it seems plausible that you might need SPNs
for it also because the MOSS search web parts may be communicating
with the query service using web services.

- HTTP/QueryServiceServerName domain\SSPAppPoolIdentity
- HTTP/QueryServiceServerFQDN domain\SSPAppPoolIdentity

Answer #11    Answered By: Tiana Whitaker     Answered On: Aug 18

I think I missed the central
admin FQDN and SQL server  FQDN SPN. Also I will create  HTTP Index
server FQDN name to join  the new one.

The crawling will split out to the new server but the query will stay
with where the central admin is.

Answer #12    Answered By: Alice Chandler     Answered On: Aug 18

The account I used to create  the SPN for the index  server is the same
account of SSP App Pool.

I will create another one with HTTP but server  name only. However, if
I do not create SPN for this server, how to make the Kerberos works?
I tried it before and it could not pass the creditenal to the
database. Perhaps I missed anything?

Answer #13    Answered By: Lynette Sawyer     Answered On: Aug 18

does the 401 happen every time the new server  is used or
only from time to time?

Answer #14    Answered By: Shelton Dickson     Answered On: Aug 18

The 401 error  only happened when I tried to start  search services  in
Central Admin and define the new server  to start it.

Didn't find what you were looking for? Find more on Join Index Server and Kerberos Error Or get search suggestion and latest updates.