Archive for September, 2011
A couple weeks ago one of my clients was experiencing constant “Cannot generate SSPI Context” errors in BizTalk. These are Kerberos errors and they are extremely annoying because they happen constantly whenever you are trying to use any database function with BizTalk. These would fill up the event logs on my client’s server and was a huge time waster because they would prevent me from doing just about anything with BizTalk. I would receive these errors when trying to start a host or change almost anything in the BizTalk admin console. I think the source of the problem is that something about the domain membership was different than some of the accounts on the server and this led to Kerberos authentication problems.
As a temporary fix I was able to restart the BizTalk server but the errors eventually came back again. The errors basically paralyze a BizTalk server and they are complicated to diagnose and sometimes you just do not have enough time to do diagnostics – like in a production environment. The fix provided next is similarly a workaround, it does not solve the root problem but at least provides another way to get the server working.
To attempt to resolve the problem, I tried a couple different things such as removing the server from the domain and adding it back in, but none of these things were successful at removing the problem completely. I did also try switching my Enterprise Single Sign On account and master key but this did not conclusively solve the problem. I was looking at the article at http://support.microsoft.com/kb/811889 and tried some of the suggestions but was not getting anywhere. Then I tried disabling TCP/IP for SQL connections and just use named pipes based on using SQL Configuration Manager or the SQL Network Configuration tool. TCP/IP seemed like such a fundamental protocol that I was not optimistic the problem would go away by switching protocols, but it worked for me. Many people also think that named pipes only works on a single server and functions like IPC but this is not exactly right.
My use of this workaround was on BizTalk 2010, W2K8 R2, with SQL 2K8 R2 when SQL is on a separate server than BizTalk.
The KB article above solely mentions this workaround in the context of SQL and Kerberos so I am blogging that this fix is working for me on my BizTalk server too. ‘
A few days ago I was working on finishing up an ADFS implementation and I had customized quite a bit of the built-in ADFS website pages. I needed to use Windows authentication to access a database, and I realized that the ADFS Proxy website app pool by default runs under Network Service. This was troubling because I did not want to grant permissions to Network Service in the database so I needed to modify this account.
I went through the standard stuff to modify the app pool identity and got this error:
Encountered error during federation passive request.
System.IO.FileNotFoundException: Error reading the C:\Program Files\Active Directory Federation Services 2.0\PT directory.
at Microsoft.IdentityServer.PolicyModel.Client.PolicyStoreReadOnlyTransferClient.GetState(String serviceObjectType, String mask, FilterData filter, Int32 clientVersionNumber)
So I opened the path at “C:\Program Files\Active Directory Federation Services 2.0\PT” which is the folder for the stored proxy token and granted full control to my domain account user. The file written to this directory is constantly updated, so the account does need to be able to remove the file. By default the Network Service account has full control, most likely because the ADFS proxy Windows service also runs under Network Service.
Then I just restarted IIS and this worked.