Office Server Web Service Authorization
Office Server Web Service Authorization
I recently encountered a mystery. I was testing a newly written utility that called the object model method Content.ContentSources to get a list of the search content sources. The utility functioned perfectly on my single server virtual development farm. When it came time to deploy to a medium farm, the utility was installed on the Central Administration server, which was separate from the Index server. The utility stopped working! (This is why you should always test in a multiple server environment). Now I had to figure out what was causing the failure.
The root cause was Office Server Web Service security. When the utility ran on a single server, SharePoint automatically made direct object model calls (known as short-circuiting web service calls, to optimize performance), so the SearchAdmin.asmx web service was not called. When the utility ran on a separate server, SharePoint under-the-covers converted the object model call to a web service call to the Index server.
Problem 1: SSL Failure
The first problem was quickly discovered in the Application Event Log. There was an SSL failure reported. The Office Server Web Service by default uses SSL to secure intra-farm communications. A search of KB articles found KB962928 (http://support.microsoft.com/?id=962928). This article matched my scenario. The .NET Framework 3.5 SP1 had just been installed on the farm. This installation can corrupt the SSL certificate used by the Office Server Web Service. You can refer to the KB article for details. In summary the fix is to run SelfSSL.exe found in the IIS 6.0 Resource Kit. This must be done on all servers in the farm.
To run SelfSSL.exe you need to know the Office Server Web Service identifier, which you can find in the IIS Manager MMC. It is 1720207907, as seen in the following picture.
Run the command as explained in the KB article on every farm server, using the correct Identifier value. A sample command session follows:
C:\Program Files\IIS Resources\SelfSSL>net stop osearch
The Office SharePoint Server Search service is stopping.
The Office SharePoint Server Search service was stopped successfully.
C:\Program Files\IIS Resources\SelfSSL>selfssl /s:1720207907 /v:1000
Microsoft (R) SelfSSL Version 1.0
Copyright (C) 2003 Microsoft Corporation. All rights reserved.
Do you want to replace the SSL settings for site 1720207907 (Y/N)?y
The self signed certificate was successfully assigned to site 1720207907.
C:\Program Files\IIS Resources\SelfSSL>
Problem 2: Connection Refused
Unfortunately, the next attempt at testing the utility also failed. This time the Application Event Log on the Index server had an entry 1314, from ASP.NET. The web service call was not even getting to SharePoint. It was being refused by the ASP.NET handler in IIS. (I highly recommend reading Inside SharePoint Enterprise Project Management with SharePoint. This article goes into great detail on how SharePoint web service authentication/authorization works.)
There is a wealth of information in the event description. Notice the message says “URL authorization failed”. We can also see the requested URL was “/SharedServices1/Search/SearchAdmin.asmx”, and the requesting user identity was “LITWAREINC\Administrator”.
But wait, the requesting user was a farm administrator. How could a farm administrator be denied access to a SharePoint URL? This sounds like a web.config issue, not a SharePoint issue.
Event code: 4007
Event message: URL authorization failed for the request.
Event time: 4/11/2009 4:28:24 PM
Event time (UTC): 4/11/2009 9:28:24 PM
Event ID: 418e2b58d47e4e0e81c213f24f64d642
Event sequence: 2
Event occurrence: 1
Event detail code: 0
Application information:
Application domain: /LM/W3SVC/1720207907/root/SharedServices1-1-128839589029265968
Trust level: Full
Application Virtual Path: /SharedServices1
Application Path: C:\Program Files\Microsoft Office Servers\12.0\WebServices\Shared\
Machine name: MOSS
Process information:
Process ID: 4448
Process name: w3wp.exe
Account name: LITWAREINC\sspservice
Request information:
Request URL: https://moss:56738/SharedServices1/Search/SearchAdmin.asmx
Request path: /SharedServices1/Search/SearchAdmin.asmx
User host address: 192.168.150.2
User: LITWAREINC\Administrator
Is authenticated: True
Authentication Type: Negotiate
Thread account name: LITWAREINC\sspservice
The web.config file on the Index server is listed below. Unimportant sections have been removed for brevity. The key lines are the authorizations.
The first authorization, for the root level, looks fine. WSS_ADMIN_WPG membership includes all farm administrators including the requesting account “LITWAREINC\Administrator”, so this is not the problem.
The second authorization for the specific location “SharedServices1” looks more interesting. This authorization only lists 2 accounts and no groups. Neither account is “LITWAREINC\Administrator”, which is why ASP.NET denied access to the web service call.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
. . .
</configSections>
<system.web>
<authorization>
<allow roles=".\WSS_ADMIN_WPG" />
<deny users="*" />
</authorization>
<webServices>
. . .
</webServices>
</system.web>
<location path="SharedServices1" inheritInChildApplications="true">
<microsoft.office.server>
. . .
</microsoft.office.server>
<system.web>
<authorization>
<allow users="litwareinc\SPAppPool,litwareinc\SPFarmAdmin" />
</authorization>
</system.web>
</location>
</configuration>
So now the question is where do these account names come from? A little digging through documentation and blogs revealed the answer. These are the application pool accounts for SharePoint web application sites. Everytime you create a new application pool through Central Administration when creating or extending a web application, the application pool identity is added to this list. In this farm there are 2 application pool identities, SPAppPool (for non-administrative application pools) and SPFarmAdmin (for Central Admin and SSP application pools). It is important to notice that since litwareinc\administrator is not used as an application pool identity, this account does not appear in the authorized users list.
Now that we know what the problem is, how do we get litwareinc\administrator into the authorized list? We cannot directly edit web.config. Other than supportability questions, SharePoint automatically rewrites this list every minute. Even it we manually changed web.config, SharePoint would remove our change.
Since the utility had to run as litwareinc\administrator, the only way to make this happen was to create a dummy web application through Central Administration, specifying to created a new application pool with the identity litwareinc\administrator. Since we are not really using this application pool, we can stop the dummy web application and the application pool to minimize the performance impact. After this, SharePoint added litwareinc\administrator to the web.config authorized list.
The utility now works perfectly from any server in the farm. The takeaway of this story is if you are writing code that has to call the Office Server Web Service, impersonate a SharePoint application pool account when making the web service call, realizing some object model method calls are converted under-the-covers to web service calls depending upon which server in the farm your code is running on.
