When we build enterprise level SOA system on top of windows servers, if the environment is with Active Directory, using windows authentication is probably the most appropriate authentication mechanism which is secure, straight forward to build and easy to maintain. Underneath WCF's windows authentication implementation, two SSP are used: Kerberos and NTLM. You might encounter the same issues like I did, here I want to share some of the experience come from my trouble shooting.

If we use domain user to host a WCF service, and call this service from another machine, very likely we will have this error:

A call to SSPI failed, see inner exception. ---> System.ComponentModel.Win32Exception: The target principal name is incorrect

There are quite a lot articles (1, 2, 3, 4) discussing this issue, basically their solution is to:

1. use setspn.exe to create an SPN for the domain account
2. configure at client side, set spn as client identity

However, the odd thing is actually we can skip step 1, and set a dummy string in step 2, it also works. Why? I am not the first one who has this question, these 2 posts (1, 2) has the exact same question against this. So, I decided to dig deeper and find the root cause.

Analysis

From the result of the workaround, we can 'feel' that the key point is which protocol is used in authentication, NTLM or Kerberos, they make the difference. This KB tells us how WCF choose the protocol, as below (left column is client / top row is server):

In our case, we are using domain user and domain machine (network service cross machine), they should all use Kerberos as 1st choice.

How do we know which protocol is finally picked? There are two ways:

1. Look at the Security Event Log, you can filter like I do:
   
   View the 'Logon' event, it can tell us Kerberos or NTLM:
   
   
2. Disable NTLM at client side and call service.
   We can configure this at code level:
   

      1: channelFactory = new ChannelFactory<TChannel>(binding);

      2: channelFactory.Credentials.Windows.AllowNtlm = allowNTLM;

   Or in config file:

      1: <behaviors>

      2:       <endpointBehaviors>

      3:         <behavior name="WcfTestBehavior">

      4:           <clientCredentials>

      5:             <windows allowNtlm="false" />

      6:           </clientCredentials>

      7:         </behavior>

      8:       </endpointBehaviors>

      9:     </behaviors>

     10:   </system.serviceModel>

   If NTLM is picked and we disable that, we will get this exception:
   System.ServiceModel.Security.SecurityNegotiationException:The remote server did not satisfy the mutual authentication requirement.

Now we are ready to do the experiment to see the logic inside WCF.

As I said before, this "A call to SSPI failed" exception only occurs when service is run under domain account, and client is from another machine. So If we put the client to the same machine of the server side, it can succeed, that's because it is using NTLM. This behavior is expected from the information in the protocol choosing strategy table.

If we set the dummy string as the SPN in client side, we can see it actually use the NTLM to authenticate. Why it cannot fallback to NTLM if we don't specify the spn?

I tried to dig out the reason via reflector, however unfortunately I failed to get 100% correct answer because I found myself not able to understand the fancy WCF design, too many factories, base classes, reflections, etc, just dizzy

Per my experiment, my assumption is: if identity is not specified on client side, it would automatically create identity using the hostname in the Uri, suppose we are calling net.tcp://remotemachine1:port/MyService, the WCF client will use the machine name as spn, that is: EndpointIdentity.CreateSpnIdentity("remotemachine1") to call service.
The tricky logic is: if the SPN specified in client is valid, WCF would use this to do Kerberos auth. If SPN is not a correct one, it would pick NTLM. That's why it is working if we specify any dummy string as SPN, it is actually fallback to NTLM because the SPN is invalid.
This is not cool and correct to me, because the logic is not like Negotiate, described in this document:

Your application should not access the NTLM security package directly; instead, it should use the Negotiate security package. Negotiate allows your application to take advantage of more advanced security protocols if they are supported by the systems involved in the authentication. Currently, the Negotiate security package selects between Kerberos and NTLM. Negotiate selects Kerberos unless it cannot be used by one of the systems involved in the authentication.

The WCF's fallback logic is crappy, waste thousands of poor .net developer huge amount of time to investigate the failure and workaround. If it can use this logic: "try Kerberos, if fail, try NTLM", I bet very few people would even see this ugly SSPI exception.

To make it clear, I drew a diagram to illustrate the logic (I don't guarantee 100% of correctness):

Solutions

Now we know the fact that we are actually using NTLM to workaround the issue in the most cases.

If you don't care Kerberos and NTLM,  you can use String.Empty or null to create SPN identity at client side, you always go to NTLM.

What if we want to stick to Kerberos, what should we do?

We got original exception "A call to SSPI failed" because the remote service account (domain account) has no access to the machine SPN key, but if we use "Network service" or "Local system" to run the server side, they have the access so the Kerberos auth can be done.

The arbitrary SPN's syntax is <ServiceClass>/<ServiceName>, the machine SPN = HOST/MACHINENAME, we can use setspn.exe –L machinename$ to see the set of SPNs that machine account has.

So, can we create a SPN for the service account, using the HOST/MACHINENAME, so that client side would need no change?

setspn.exe –U –A HOST/SERVERNAME DOMAIN\SERVICEACCOUNT

Unfortunately the answer is NO. By doing this command, it would cause duplicate SPN record, and Kerberos would always fail.

To check duplicate SPNs, use setspn.exe –X

We have to use a different name to create the SPN for the user, for example: MySystem/Service1.

setspn.exe –U –A MySystem/Service1 DOMAIN\SERVICEACCOUNT

Then we come back to client side, set the identity:

1. in config file, set inside the endpoint node:
   

      1: <endpoint name="winservicenettcp"

      2:                 binding="netTcpBinding"

      3:                 bindingConfiguration="netTcp"

      4:                 address="net.tcp://myserver:12345/WcfPerfTest"

      5:                 contract="Contract.IPerfTest"

      6:                 behaviorConfiguration="WcfTestBehavior">

      7:         <identity>

      8:           <servicePrincipalName value="MySystem/Service1"/>          

      9:         </identity>

     10:       </endpoint>

2. Or in code level, set in EndpointAdress:
   

      1: new EndpointAddress(new Uri(ServiceUrl), EndpointIdentity.CreateSpnIdentity("MySystem/Service1"));

If we didn't create SPN successfully, it could still pass because it can fallback to NTLM, so we can disable NTLM at client side.

Another solution is use UPN, in config it is userPrincipalName and in code it is EndpointIdentity.CreateUpnIdentity. Just use the service account's upn (mydomain\accountname) as input, and it can also succeed.

Another useful tool in debugging Kerberos is klist.exe. It can show use the current cached KerbTicket in the system, make sure you run klist.exe purge after we change something, or the cached ticket would give us some bogus result.

Conclusion

Because of the weird design of WCF windows authentication, it is very challenging to write a generic client wrapper because you cannot tell how to set identity (not set, use correct spn, use correct upn or use dummy spn) just from the Uri. Personally I would say the behavior is a bug, if it is by design, it must be a very bad design If it can change to "Kerberos first, if fail, try NTLM", that would be fantastic, although seems not very possible ^_^

public class AA{
 }

public class AA{ }

1. Leverage database server feature, such as SQLServer backup/restore, which is database level.
2. Backup/Restore in table level, store it in file.

Neither of them is perfect:

I am lucky that our new system adopts the foreign key free sql design, so solution 2 looks a good choice for us.

Here is a very simple class to do the back/restore job:

To enumerate table names:

   1: public List<string> GetTableNames()

   2: {

   3:     List<string> result = new List<string>();

   4:     string tableName = string.Empty;

   5:     string sql = "SELECT name AS table_name, * FROM sys.tables WHERE Type = 'U'";

   6:     using (SqlConnection conn = new SqlConnection(ConnectionString))

   7:     using (DataTable table = new DataTable())

   8:     using (SqlDataAdapter adapter = new SqlDataAdapter(sql, conn))

   9:     {

  10:         adapter.Fill(table);

  11:         foreach (DataRow row in table.Rows)

  12:         {

  13:             result.Add(Convert.ToString(row["table_name"]));

  14:         }

  15:     }

  16:     result.Sort();

  17:     return result;

  18: }

To backup tables to DataSet/String:

   1: /// <summary>

   2: /// Pass null as includedTables if you want to backup all.

   3: ///     Actual tables = includedTables - excludedTables

   4: /// </summary>

   5: public DataSet BackupDatabase(List<string> includedTables = null, List<string> excludedTables = null)

   6: {

   7:     includedTables = includedTables ?? GetTableNames();

   8:     if (excludedTables != null)

   9:     {

  10:         includedTables = includedTables.Except(excludedTables, StringComparer.OrdinalIgnoreCase).ToList();

  11:     }

  12:  

  13:     DataSet result = new DataSet();

  14:     using (SqlConnection conn = new SqlConnection(ConnectionString))

  15:     {

  16:         includedTables.ForEach(t =>

  17:             {

  18:                 string sql = "select * from " + t;

  19:                 using (SqlDataAdapter adapter = new SqlDataAdapter(sql, conn))

  20:                 {

  21:                     adapter.Fill(result, t);

  22:                 }

  23:             });

  24:     }

  25:     return result;

  26: }

  27:  

  28: public string BackupDatabaseToString(List<string> includedTables = null, List<string> excludedTables = null)

  29: {

  30:     using (var dataSet = BackupDatabase(includedTables, excludedTables))

  31:     using (MemoryStream ms = new MemoryStream())

  32:     {

  33:         dataSet.WriteXml(ms, XmlWriteMode.WriteSchema);

  34:         return Encoding.UTF8.GetString(ms.ToArray());

  35:     }

  36: }

To restore table from DataSet:

   1: public void RestoreDatabase(DataSet newDataSet)

   2: {

   3:     using (TransactionScope scope = new TransactionScope())

   4:     using (SqlConnection conn = new SqlConnection(ConnectionString))

   5:     using (DataSet currentDataSet = new DataSet())

   6:     {

   7:         conn.Open();

   8:         foreach (DataTable newTable in newDataSet.Tables)

   9:         {

  10:             string tableName = newTable.TableName;

  11:             SqlCommand deleteAllCmd = new SqlCommand("delete from " + tableName, conn);

  12:             deleteAllCmd.ExecuteNonQuery();

  13:             // reseed the indetity columns

  14:             SqlCommand reseedCmd = new SqlCommand(String.Format("DBCC CHECKIDENT ('{0}', RESEED, -1)", tableName), conn);

  15:             try

  16:             {

  17:                 reseedCmd.ExecuteNonQuery();

  18:             }

  19:             catch { } // ignore the error from table without identity columns

  20:  

  21:             using (SqlDataAdapter adapter = new SqlDataAdapter("select * from " + tableName, conn))

  22:             {

  23:                 adapter.Fill(currentDataSet, tableName);

  24:                 foreach (DataRow newRow in newTable.Rows)

  25:                 {

  26:                     currentDataSet.Tables[tableName].Rows.Add(newRow.ItemArray);

  27:                 }

  28:                 Console.WriteLine("restoring table '{0}' with {1} rows", tableName, newTable.Rows.Count);

  29:                 SqlCommandBuilder dummyCmd = new SqlCommandBuilder(adapter); // this would generate insertCommand inside adapter

  30:                 adapter.Update(currentDataSet, tableName);

  31:             }

  32:         }

  33:         scope.Complete();

  34:     }

  35: }

You can use this in your c# automated test case, or powershell.

Basically, to deploy an Mvc 3 web app is amazingly easy: we just need to install AspNetMVC3Setup.exe on the web server, then use MsDeploy, or just copy the binary and content to the destination folder, that’s it.

However sometimes you want to make the automation of the deployment even easier and cleaner, or, you might not be able to install the MVC3 base package on your environment. No worry, it is not that difficult.

Prerequisite

• Windows Server 2008/R2 with IIS 7.
• .Net 4.0 runtime is installed on the server.

.Net 4.0 is needed, since the Mvc 3 binaries are built from it, I haven’t tested whether it is possible to grab the code and build from .net 3.5.
And I didn’t test IIS 6.

To Deploy:

Use the MsDeploy, then publish from visual studio, it would create the web application for you automatically.

Or, just manually create the web application, then copy the folder structure to your server. Here I use the default template of Mvc3 as an example, you need to include the *.cshtml (I use Razor), *.js, css, web.config and asax file.

We are almost done, usually Mvc base assembies are in .net 4 GAC, we need to take these files to your Bin folder:

• Microsoft.Web.Infrastructure.dll
• System.Web.Helpers.dll
• System.Web.Mvc.dll
• System.Web.Razor.dll
• System.Web.WebPages.Administration.dll
• System.Web.WebPages.Deployment.dll
• System.Web.WebPages.dll
• System.Web.WebPages.Razor.dll

You can get them from C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET Web Pages\v1.0\Assemblies and C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET MVC 3\Assemblies , from the box you installed MVC3, most likely it is your develop machine.

The reason why I stroke out the System.Web.WebPage.Administratration.dll is if you copy that file, you need to also copy the NuGet.Core.dll, but if none of them are available, the site can also work.

For other IIS settings like authentication, SSL and logging, etc, you can use appcmd.exe to do the automation, it is located in %windir%\System32\inetsrv