The Security Token Service is unavailable

Question

I have to problems left on my dev machine. 1. The Security Token Service is unavailable 2. Get the user profile sync serve started.

I am getting the following error every 5 minutes in my event log after a fresh Sharepoint 2010 Service Pack 2 installation:

Event 8306 (SharePoint Foundation) of severity 'Error' occurred 30 more time(s) and was suppressed in the event log

Looking for similar erros in the event log brought the following line:

Request for security token failed with exception: 
System.ServiceModel.EndpointNotFoundException: Could not connect to 
http://localhost:32843/SecurityTokenServiceApplication/securitytoken.svc/actas. 
TCP error code 10061: No connection could be made because the target machine actively 
refused it 127.0.0.1:32843

I have tried to directly browse to http://localhost:32843/SecurityTokenServiceApplication/securitytoken.svc but Chrome keeps on displaying "the page cannot be displayed"

/EDIT: Changing the url to http://hostname:32843/SecurityTokenxxx..../xxx.svc resulted in a page displayed with the following error:

The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace logs.

After this I followed the solution posted here: http://blogs.technet.com/b/sykhad-msft/archive/2012/02/25/sharepoint-2010-nailing-the-error-quot-the-security-token-service-is-unavailable-quot.aspx which brought no solution.

Please help me on this one. Kind regards.

//EDIT: Some additional information, which might be useful. The root-site in IIS is Sharepoint Web Services, which runs under the application pool SharePoint Web Services Root. If I click on Basic settings and then on "Test settings..." I am getting 2 green checks.

Moving one layer down, to the SecurityTokenServiceApplication: This one is running under the SecurityTokenServiceApplicationPool. Clicking on test settings here results in an error:

Invalid application path

I have checked, that the managed account that runs the SecurityTokenServiceApplicationPool has valid credentials, is member of the Farm-administrator group and is local administrator.

System specification:

• Windows Server 2008 R2
• Sharepoint Server 2010 SP2
• installed as standalone farm
• configured via wizard

EDIT2: Progress Thanks to Ali Sharepoint's hints I was able to make some progress, which as of yet did not bring the solution.

In IIS I can test the settings / connection and both come back with a green tick. The Claims service is started and running. The Token Service itself has a status of Online

Yet the errors described above (Connection refused) still persist and I am not able browse the service.

//Update 22.11.13 I am in the process of comparing the settings of one of our productive environments, one of the dev-machines and the failing dev machine. None of the working environments use a specific account fpr the TokenService. Testing the settings there always results in an error. Also the Claims service is disabled and yet the Service is issing tokens.

Answer 1

this could be faulting at several stages!

first place to look even tho you migh of already is look at the app pool, start or recyle "sharepoint webservices root".

now go under sites and start "SharePoint Web Services" right click, manage and then click start or recycle.

now do an iisreset.

if that doesnt work, you could test this one out!

Moving one layer down, to the SecurityTokenServiceApplication: This one is running under the SecurityTokenServiceApplicationPool. Clicking on test settings here results in an error:

change the accout to a farm admin account that has access to that folder ;)

goto this folder location:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\WebServices\

right click on SecurityToken and select properties, now goto the security tab. what do you see on the list? do you see the user account that your using within the list?

do you see:

 wss_admin_wpg
 administrators

go under advanced settings for securityTokenServiceAppliction and make sure the user account that is used also has access/valid.

if not add them in! once you have done that, when you do the check again with the selected user account who is part of the administrators group should have access and you should see green tick ;)

EDIT

recreated the same issue:

error same as you

changed account to admin account manually

works as you can see for the first

works for the second ;)

EDIT

if all services are running and your still hitting this error than more than likely its todo with the port! make sure its unique and there is no other site using this port number aswell!

also make sure that the service for SecurityTokenServiceApplication, make sure '.net trust level' is set to 'full' trust. todo this click on the service, then under 'asp.net' double click on '.net trust level' and within the drop down select 'full' trust ('full' internal).

next step is to check your security checking on web.config: goto:

%Programfiles%\common files\Microsoft Shared\web server extensions\14\WebServices\SecurityToken

the above is the location of the SecurityTokenServiceApplication web.config that you need to ammend.

goto this line:

      <security authenticationMode="SspiNegotiatedOverTransport" allowInsecureTransport="true" defaultAlgorithmSuite="Basic256Sha256" messageSecurityVersion="WSSecurity11WSTrust13WSSecureConversation13WSSecurityPolicy12" />

and change it to this:

      <security authenticationMode="IssuedToken" allowInsecureTransport="true" defaultAlgorithmSuite="Basic256Sha256" messageSecurityVersion="WSSecurity11WSTrust13WSSecureConversation13WSSecurityPolicy12" />

iv changed the above from SspiNegotiatedOverTransport to IssuedToken, more can be found here on the subject of types of authentication for wcf:

http://msdn.microsoft.com/en-us/library/aa751836(v=vs.110).aspx

you can also follow this kb article:

http://support.microsoft.com/kb/2493524

EDIT

after reading through the error reported on central admin i could safely assume ;) that its a configuration issue! Have you added any wcf hotfixes??? you would need to. also you need to check on the securityTokenServiceApplicationPool by going to advanced settings! make sure that its targeting framework .net 2.0 and that enable 32 bit application is set to false, you could check against one of your working servers!

If the server is running Windows Server 2008 SP2 then ensure that the hotfix at http://support.microsoft.com/kb/971831 is installed.

If the server is running Windows Server 2008 R2 then the hotfix at http://support.microsoft.com/kb/976462 is installed.

Answer 2

Disable loopback check or specify allowed host names. The two methods are described here.

Answer 3

This problem indicates that the secure token service application is not functioning correctly. Following could be the possible causes of this problem (see http://support.microsoft.com/kb/2493524):

1. A required WCF hotfix has not been installed on the SharePoint server
2. Authentication for the SecureTokenServiceApplication is not configured properly in IIS.
3. The web.config file of the SecureTokenServiceApplication contains invalid data
4. The SecureTokenServiceApplication is not provisioned properly.

Depending on the cause of the problem, here are the possible resolutions:

1. Missing WCF Hotfix: If the server is running Windows Server 2008 SP2, please ensure that the hotfix mentioned at http://support.microsoft.com/kb/971831 is installed. If the server is running Windows Server 2008 R2, the hotfix mentioned at http://support.microsoft.com/kb/976462 must be installed.
2. Incorrect Authentication Settings: Please ensure that the authentication settings for the SecureTokenServiceApplication are correctly configured by completing the following steps: a) Open IIS Manager b) Expand “Sites” c) Expand “SharePoint Web Services” d) Select “SecurityTokenServiceApplication” e) From the “Features” pane, double click on “Authentication” under “IIS” f) Right click “Forms Authentication” and select “Disable” g) The authentication settings page should only have Windows and Anonymous access enable for the security token service to issue tokens properly (and for claims authentication to work properly)
3. Incorrect data in the configuration file: Please review the web.config file of the secure token service application and compare it to a web.config file from a "working" secure token service application.

4. SecureTokenServiceApplication not provisioned: Use the following power shell commands to provision the secure token service application

   $sts = Get-SPServiceApplication | ?{$_ -match "Security"} $sts.Status

Answer 4

I had the same issue on a server with two IP addresses. I modified the hosts file to point "localhost" to the first IP address (which the STS was bound to), and that solved the problem. I am not a windows systems expert, so I don't know if that is a bad idea for other reasons.

Answer 5

I had the same issue it turned out to be a duff username and password for the identity. I recreated the identity and it then worked.

Answer 6

for me, the it turned out WWW Publishing Service wasn't started.

Answer 7

In my case, I simply re-ran the prerequisite (WcfDataServices) exe explicitly, and it's fixed the issue (so far)

Answer 8

One problem that I didn't see mentioned in any existing answers is that every machine in the farm should have any "custom claims provider" assembly DLLs installed in the GAC.

You can find out if a DLL is missing by adding <serviceDebug includeExceptionDetailInFaults="True" httpHelpPageEnabled="True"/> to the STS web.config under <behavior name="SecurityTokenServiceBehavior">, requesting a token, then checking the logs for a "could not load file or assembly" error. If a DLL is missing on one box, install it there and reset IIS.

ref: this MSDN page about the error, this blog post about troubleshooting