Tag: Security

Workaround for Kerberos SSPI Context Errors in BizTalk

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. ‘

Thanks,

2

The importance of IT knowledge for a BizTalk Developer

The past few days I have been working at a client that is ultra-secure and have been tasked with installing BizTalk with insane security. I have worked in environments in the past that religiously use the DISA gold disks (http://iase.disa.mil/stigs/SRR/index.html) had to follow the NSA security review documents. Another similar suite of security checkers is the Microsoft Baseline Security (MBSA) tool. The MBSA tool basically enables an IT administrator to lock down a system so tight that Microsoft server products are unable to run. In security alerts released by Microsoft, MBSA provides a way for administrators to harden a system through group policy settings, IPSec policy, among many other configuration settings. The security alert articles (like http://www.microsoft.com/technet/security/bulletin/MS05-051.mspx) even mention that modification of settings in this way will break certain Microsoft server products like BizTalk, SQL Server, MSMQ, etc. So I realized it was really important for people to know that if they are in an ultra-secure environment and are being asked to setup a Microsoft server product, you should defintely start with a baseline that was not already infinitely locked down and then slowly harden it while testing. Otherwise you will wind up going down a million rabbit holes trying to get connectivity working and may never make much progress.
 
In other words, make sure you have a test and development strategy that corresponds to a security baselining strategy. If you do not have more than one quality environment (your production version is your test version), then you will probably get stuck debugging security issues. Otherwise, be sure that baselines are created or established after doing functional testing rather than before. Some people will argue that its better to do it right the first time. I generally agree with this, but if you are in an ultra-secure environment where it is hard to know if a product will work at all due to the security, you will be better off knowing it will work first and then hardening the application over time.
 
Here is a list of some of the things I have had to do just to get BizTalk to install and partially configure:
 
Install network COM+, network DTC, Configure group policy to enable COM+, DTC to run on multiple servers, Configure DTC settings so that Remote Clients and Network DTC access exists, configure COM+ NTFS permissions at %windir%registration (see http://support.microsoft.com/kb/909444 for an example of ultra security – configuring the security beyond even Microsoft’s recommendations).
0

SharePoint Security Permissions Matrix

It looks like an MSDN article that is really useful is located under the SPPermissionGroup64 Enumeration rather than a more descriptive title. This article gives all of the possible user access levels in SharePoint and then describes which individual rights are covered by the levels. These individual rights are used when deploying features for attributes in the feature definition files like "Rights". Here is the link to this vary important SharePoint security chart: http://msdn2.microsoft.com/en-us/library/microsoft.sharepoint.sppermissiongroup64.aspx?topic=306117.
0

Blog at WordPress.com.

Up ↑