A BULL's view of LIFE and TECHNOLOGY : Security

NTLM vs KERBEROS - Windows Communication Foundation

ashishme — Sat, 11 Nov 2006 01:23:00 GMT

To understand the windows authentication mechanism better please refer: http://msdn2.microsoft.com/en-us/library/aa480475.....

The Scenario:

A Web Application and WCF web service on Windows XP, where the Web Application uses services provided by WCF layer. Further, the WCF (or coarse grained services) talks to various Web Services (or fine grained web services), massages the data received and pass it to Web Application. The Web Service that WCF connects is hosted on Windows 2003 with NTAuthenticationProviders in IIS metabase set as NTLM.

You can view the IIS metabase using a tool called METAEDIT (download from here). You can also check the NTAuthenticationProviders on the machine by using the following script:

cscript %systemdrive%\inetpub\adminscripts\adsutil.vbs get /w3svc/1/NTAuthenticationProviders

(here "1" is the web site sequence internal to IIS, for XP it will always by "1")

cscript %systemdrive%\inetpub\adminscripts\adsutil.vbs get /w3svc/NTAuthenticationProviders

Now when Web application makes a call to WCF with binding configured as Windows (i.e. basicHttpBinding with bindingConfiguration specifying <security mode="TransportCredentialOnly"> <transport clientCredentialType="Windows"></transport></security>) and WCF calls the fine grained web services with same bindingConfiguration an obvious error would be thrown - that Client authentication header was passed as Negotiate where as the Server authentication header received is NTLM. The solution to the problem is changing the clientCredentialType to Ntlm in the config file of the WCF layer for the binding that is utilized for connecting to fine grained web services.

But now when you run the Web Application again you will encounter the following error - Client authentication header was passed as Ntlm where as the Server authentication header received is NTLM. By looking it seem that client is passing Ntlm and server is expecting NTLM (note the case), but the real reason for this is that NTLM identity is not passed across virtual folders / remote processes when NTLM authentication is used, thus it fails.

The Workaround:

The solutions to this (assuming you don't have control over the third party / fine grained web services) are:

At WCF layer before making a call to fine grained service impersonate your windows identity (you need to specify the password and userName)
In machine.config there is a tag <processModel>(read about processModel here) which let you configure IIS worker process settings. The default setting for this is <processModel autoConfig="true" />, you need to change it to <processModel userName="somedomain\someuser" password="somepassword" />

(can use any one though I would suggest the 2nd approach as there are no code changes)

Reset the IIS and now the Identity is able to flow from the WCF to fine grained web service as you explicitly impersonated the same before calling the service or at worker process level.

The Resolution:

If you have a control over fine grained web services that are hosted on Windows Server 2003, configure the IIS to use Kerberos instead of NTLM, by setting the NTAuthenticationProvider property of IIS metabase to "Negotiate" or "Negotiate,NTLM". The command for the same:

cscript %systemdrive%\inetpub\adminscripts\adsutil.vbs set /w3svc/1/NTAuthenticationProviders "Negotiate,NTLM" (Where the no. 1 depends on the internal sequence used by IIS for different web sites)

As the Kerberos is enabled on Windows Server and following conditions are true for your IIS web site configurations:

• The IIS 6.0 Web site is part of an IIS application pool.

• The application pool is running under a local account or under a domain user account.

• The Web site is configured to use Integrated Windows authentication only.

Now try accessing the fine grained web service (from a web browser) you will receive the error

"HTTP Error 401.1 - Unauthorized: Access is denied due to invalid credentials.",

which is thrown after browser challenges you 3 times for supplying the credntials.

Assuming this is the case with all the conditions mentioned above are true,then when Integrated Windows authentication tries to use Kerberos, Kerberos authentication may not work. To use Kerberos authentication, a service must register its service principal name (SPN) under the account in the Active Directory directory service that the service is running under. By default, Active Directory registers the network basic input/output system (NetBIOS) computer name. Active Directory also permits the Network Service or the Local System account to use Kerberos.

To resolve this behavior when the application pool is running under a domain user account, set up an HTTP SPN with the NetBIOS name and the fully qualified domain name (FQDN) of the domain user account that the application pool is running under.

1. Install the Setspn.exe tool. (for Windows 2000 / Windows 2003)

2. Start a command prompt, and then change to the directory where you installed Setspn.exe.

3. At the command prompt, type the following commands. Press ENTER after each command:

setspn.exe -a http/IIS_computer's_NetBIOS_name DomainName\UserName
setspn.exe -a http/IIS_computer's_FQDN DomainName\UserName

Note

UserName is the user account that the application pool is running under.

This command can only be executed by domain administrators.

After you set the SPN for the HTTP service to the domain user account that the application pool is running under, you can successfully connect to the Web site without being prompted for your user credentials and WCF will also be able to connect to the fine grained web services.

Use of APTCA

ashishme — Fri, 09 Jun 2006 17:27:00 GMT

The .Net Framework provides a number of security features that enables in secure applications, and one of the features is evidence based that works on the top of operating system security. The evidence based security gathers evidences regarding the assembly and determine whether the code has permissions to execute. Any assembly that gets installed in Global Assembly Cache (GAC) is considered by .Net Framework to have Full Trust i.e. the code has unrestricted access to all protected resources and these assemblies can only be called by other Full Trust assemblies. However the partial trust assemblies cannot call the Full Trust assemblies therefore .NET Framework 1.1 introduced an assembly-level custom attribute AllowPartiallyTrustedCallers. The Full Trust assemblies marked with AllowPartiallyTrustedCallersAttribute can be called by partially trusted assemblies and the implicit demand is not called. The improper usage of this attribute can introduce vulnerabilities that can lead to luring attack. The solution presented in this document discusses the proper usage of AllowPartiallyTrustedCallersAttribute.

Trust Levels

In managed world an Assembly can belong to one of the following trust models:

1. Full Trust
Any assembly that has been strong named and installed in GAC is Full Trust Assembly, unless someone has lock down the security policy by changing the grant set of local machine to something less than full trust. This permission set gives code unrestricted access to all protected resources. This can be a very dangerous permission set; it allows full access to your computer's resources such as the file system or network access, potentially operating outside the control of the security system. If you are modifying security policy, be sure to set policy such that only assemblies you fully trust could possibly get this permission set.

2. Partial Trust

Code that does not get full trust will have partial trust. Partial trust code will have to call framework code, and hence an assembly with full trust will be called by an assembly with partial trust.

Why Full Trust is required?

Full Trust is required:

· To call Unmanaged Code

· To create COM objects

· To use OLEdb or ODBC

A partial trust assembly cannot perform the above mentioned operations and most core .Net assemblies don’t have the AllowPartiallyTrustedCallersAttribute(APTCA) applied, hence limiting partial trust assemblies.

The Problem

A class library needs to perform some privileged operations (example: reading contents of some system file) and the assembly needs to be shared among various applications in the organization. To make the assembly be shared among various applications we need to strong name our assembly and host it in GAC. Now this library can only be called by strong named assemblies or assemblies with full trust. To make the assembly accessible by other partially trusted assemblies we need to add APTCA to the assembly.

The Luring Attack

The result of adding APTCA any un-trusted / partially trusted code can call the trusted code. The trusted code then executes the privileged code on the behalf of the un-trusted code. This is known as Luring Attack where an attacker can take advantage of use of APTCA to lure a Fully Trusted assembly to execute un-trusted code on its behalf like calling the privileged operation on the victim machine.

Code Sample: The Luring Attack

// The Trusted Code

using System;

using System.Security;

using System.Security.Permissions;

using System.Reflection;

// This assembly executes with full trust and

// allows partially trusted callers and would reside in GAC

// Applying APTCA to assembly

[assembly:AllowPartiallyTrustedCallers]

namespace TrustedCodeWithImproperAPTCA

{

public class PerformPrivilgedOperations

{

public static void PrivilgedOperations()

{

// Some Call to Privileged Code

}

_______________________________________________________________________________________________

// The Un-trusted / Attacker Code

using System;

using TrustedCodeWithImproperAPTCA;

// If this test is run from the local computer, it gets full trust by

// default. So Remove full trust.

[assembly:System.Security.Permissions.PermissionSetAttribute(

System.Security.Permissions.SecurityAction.RequestRefuse, Name="FullTrust")]

namespace TestSecLibrary

{

class TestApctaMethodRule

{

public static void Main()

{

// Indirectly calls PrivilgedOperations.

PerformPrivilgedOperations.PrivilgedOperations();

}

Solution design

APTCA only removes the implicit Link demands; any demands explicitly placed in your assembly will still be enforced. This means that even once an assembly has been marked with APTCA, it could still have some types in it that are not usable from partial trust by use of Explicit Demands.

Using the above stated fact we can use the APTCA properly with Explicit Demands. Thus we can mark the Full trust assemblies with APTCA and also have explicit demands to prevent the Luring attack. A better design would be not to have APTCA directly applied on the Trusted Code, but introduce a Façade assembly. The Façade assembly / code will have the full trust as the trusted code with APTCA applied to it, and will have explicit demand calls, thus making it non-vulnerable for the luring attack. This allows the Trusted Code to take advantage of Link Demands as well as protection from luring attack with help on explicit demands through Façade.

Code Sample: The proper use of APTCA

// The Trusted Code.

using System;

namespace TrustedCode

{

public class PerformPrivilgedOperations

{

public static void PrivilgedOperations()

{

// Some Call to Privileged Code.

}

_______________________________________________________________________________________________

// The Façade Code (with APTCA applied)

using System;

using System.Security;

using System.Security.Permissions;

using System.Reflection;

using TrustedCodeWithImproperAPTCA;

// Applying APTCA to assembly

[assembly:AllowPartiallyTrustedCallers]

namespace FacadeWithAPTCACallingTrustedCode

{

public class FacadeCallingTrustedCode

{

public static void CallingTrustedCode()

{

// This security check fails if the caller

// does not have full trust.

NamedPermissionSet pset= new NamedPermissionSet("FullTrust");

// This try-catch block shows the caller's permissions.

// Correct code would either not catch the exception,

// or would rethrow it.

try

{

pset.Demand();

}

catch (SecurityException e)

{

Console.WriteLine("Demand for full trust:{0}", e.Message);

}

// Calls PrivilgedOperations()

PerformPrivilgedOperations.PrivilgedOperations();

}

// The Un-trusted / Partial Code

using System;

using FacadeWithAPTCACallingTrustedCode;

// If this test is run from the local computer, it gets full trust by default.

// Remove full trust.

[assembly:System.Security.Permissions.PermissionSetAttribute(

System.Security.Permissions.SecurityAction.RequestRefuse, Name="FullTrust")]

namespace TestSecLibrary

{

class TestApctaMethodRule

{

public static void Main()

{

FacadeCallingTrustedCode.CallingTrustedCode();

}

References

Introduction to Code Access Security - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconintroductiontocodeaccesssecurity.asp

Code Access Security Basics - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconcodeaccesssecuritybasics.asp

Using Libraries from Partially Trusted Code - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconUsingLibrariesFromPartiallyTrustedCode.asp

APTCA methods should only call APTCA methods - http://msdn2.microsoft.com/en-us/library/ms182297.aspx