Data Connections in Browser Forms

This post will answer the question "how do I get my data connection to work on the server". Cart, meet horse.

When we started defining the server experience for InfoPath forms, one of the guiding principles we espoused was "design-once." Meaning, provided you stick within the subset of functionality supported on the server, you could design a form once and it would run in InfoPath and in Forms Services. That is basically true for data connections, but there are two special considerations that differ significantly when moving to the server, namely

• Authorization to perform cross-domain connections
• Multi-tier authentication

The cross-domain issue, server edition

Short version:

You can’t make a cross-domain connection from a domain security browser form unless your data connection uses a UDC file. Period.

Long version:

InfoPath has three security modes, which we refer to as restricted (AKA "super-sandbox"), domain, and full-trust. Restricted form templates don’t run on the server. Full-trust form templates are allowed to do whatever and consequently need to be administrator-approved in order to run server-side. Domain trust form templates constitute the vast majority of form templates in the enterprise, and roughly follow the Internet Explorer security model which dictates that by default, the user must approve any attempt to access resources that come from a different domain or Zone. So, if you have a form template running on http://myserver/, and it tries to connect to a web service on http://yourserver/, InfoPath will prompt you before trying the connection.

Works great in InfoPath, but when you run a form in the browser, you may be running server-side business logic. That business logic may want to execute a data query. Because HTTP is a stateless protocol, Forms Services can’t halt execution of a server-side process and return to the browser in order to ask you for permission to continue. Additionally, the user in this case may not be the right person to own the decision about whether the cross-domain connection can take place. So, this decision is placed instead in the hands of the server administrator who owns security around the form template. Depending on whether the form is administrator-approved or just published to a document library by Joe User, this ownership falls on the farm administrator (I call her Julie) or the site collection administrator (henceforth known as Bob).

The technology which allows Julie and Bob to determine whether forms can make cross-domain connections involves a system of checks and balances. Central to this system is a data connection settings file in the Universal Data Connection V2 format, called a UDC file. Bob’s UDC files live in a special type of document library called a Data Connection Library, or DCL. Julie’s UDC files live in the Microsoft Office SharePoint Server configuration database, and are managed via the "Manage Data Connection Files" page in the Application Management section of SharePoint Central Administration (I tend to refer to this as "the store").

The basic premise behind UDC files is that in InfoPath 2007 your data connection settings can live outside of the form template in one of these files, and both InfoPath and Forms Services will retrieve the current connection settings from this file at runtime before making the connection. The UDC file itself is retrieved from a URL relative to the root of the site collection where the form was opened. This enables lots of cool functionality - for example, you can now share settings across multiple forms and change them once when you move your data source.

You can also pre-deploy test and production versions of your data connection settings to your staging and production environments so that you don’t need to update the form template with new data connection settings when you go live.

For the purposes of this discussion the key takeaway is that a domain security form running in the browser will never make a cross-domain data connection unless those connection settings come from a UDC file.

In other words, you can’t make a cross-domain connection from a domain security browser form unless your data connection uses a UDC file. Period.

Why is this more secure? Well, if Bob is a good administrator, he controls access to Data Connection Libraries on his site collection. A DCL requires content approval by default, and while members of the site with Contributor access can write files to the library, nobody but the owner of the file can use the file from InfoPath unless a content approver has approved the file. By default, all members with Designer permissions have the Content Approval right. In short, Bob can set up the site collection such that only people that he designates can approve UDC files. Therefore, forms on Bob’s site collection can only make connections outside the farm unless he approves the connection first.

Julie’s central store is more secure - only users with access to SharePoint Central Administration can modify those files. Furthermore, by default only the server object model can access files in the store. In order to make these files accessible to web clients such as InfoPath, the "web accessible" flag must be set. Otherwise, the files can be used from browser forms only.

Finally, if Julie wants to have complete control over cross-domain connections for the farm, she can turn off the ability for user form templates to make cross-domain connections at all (in fact, these are disabled in a default install). When cross-domain connections are disabled for the farm, even connections that use settings from a UDC file can’t make cross-domain connections.

Solving multi-tier authentication issues

Once your form is allowed to make cross-domain connections, you’ll need to deal with getting access to the data. If your data lives on a different computer than your Forms Services site, this means figuring out an alternative set of credentials for data access. I’ve covered why this is true, and the various options for accomplishing this task, in a series of posts called "Advanced server-side authentication for data connections," but I left out one useful prototyping trick. Consider the following UDC authentication block:

myusername mypassword

The UseExplicit element allows you to specify a username and password in plaintext. When this is present, Forms Services will impersonate the specified user using the supplied credentials. This is a great tool for prototyping - you can see immediately whether your connection can be made given valid credentials before you go to the trouble of setting up Office Single Sign-on. However, I cannot stress enough that this is for prototyping only. Because the UDC file is in clear text and is accessible to anyone with read permission on the library, this puts a windows username and password in clear text on the network, which is bad-bad-bad. You’ve been warned.

Whatever Julie wants, Julie gets

The "Manage data connection files" page (AKA "the store") gives Julie a great deal of power over the use of data connections in administrator-approved form templates. Furthermore, Julie also has a great deal of control over what Bob’s users can do. The following defaults can only be modified on the Configure forms services page:

• User form templates cannot make cross-domain connections (not even with a UDC files)
• User form templates cannot use authentication embedded in a database connection string.
• User form templates cannot use the authentication section of the UDC file
• User form templates can use credentialType BASIC or DIGEST only if the connection is made using SSL.
• User form templates cannot make cross-domain connections (not even with a UDC files)
• User form templates cannot use authentication embedded in a database connection string.
• User form templates cannot use the authentication section of the UDC file
• User form templates can use credentialType BASIC or DIGEST only if the connection is made using SSL.

The following default setting can only be modified on the Configure Web Service Proxy page:

• User form templates cannot use the Web service proxy

DisableLoopback Check

DisableLoopbackCheck & SharePoint: What every admin and developer should know.

What is the issue?
Windows Server 2003 SP1 introduced a loopback security check. This feature is obviously also present in Windows Server 2008. The feature prevents access to a web application using a fully qualified domain name (FQDN) if an attempt to access it takes place from a machine that hosts that application. The end result is a 401.1 Access Denied from the web server and a logon failure in the event log.

Unfortunately 401.1 is not really helpful as this error code means there is a problem with the user credentials. Of course, the HTTP spec doesn’t know about security features in a vendor’s implementation so there can’t be a HTTP error code for such a feature. This can lead to much banging of the head on the desk. It’s one of numerous causes of the 401.1 which are nothing to do with invalid credentials (e.g. attempting to use Kernel Mode Authentication with domain account in IIS7).

What this means is that when you browse a SharePoint Web Application which uses a fully qualified domain name from a WFE in the farm you will get a 401.1. This is very annoying on a development box, or when testing locally, or in other SharePoint specific scenarios (more on those later).

OK, so what’s the big deal here?
Microsoft call this a security feature. Spence calls this a security fix! There are many exploits which attempt to attack via reflection – i.e. pretending to be local as to bypass constraints. This setting should have been in the box since Windows NT4, but it wasn’t. Microsoft have done the right thing and addressed the problem based on customer feedback and exploits. They have fixed a hole and further tightened the attack surface of a Windows server. Good Job. Anyone who cares about host security or platform hygiene knows it makes sense.

But it breaks my SharePoint, dang it!
Yup, it does. But only if you are attempting to access a Web Application from a server hosting it (i.e. locally). You shouldn’t be doing that. Well, you shouldn’t be doing it in production. If you or your company admins are testing locally you have bigger problems that a pesky security fix.

The trouble is there are also scenarios where this fix will break normal operations of SharePoint.

• Search Indexing.
  If you are hosting the WSS Web Application Service on your Indexer for the purposes of having a “Dedicated Crawl Front End” and avoiding a network hop. This is common in small scale “Medium Server Farms”. Because the Indexer is crawling itself, the crawl log will fill up with 401s and your content won’t get indexed.
• Web Application “Warm Ups”.
  If you are running a scheduled task or timer job to hit the Web Application to avoid the start up lag after an application pool recycle, the “warm up” will fail with a 401.
• Custom Code using SharePoint Web Services.
  If you have custom code, either in SharePoint or out with it that leverages SharePoint Web Services (such as using the ExcelService API) these requests will fail with a 401.

Okay, so get to the point what should I do?
Microsoft’s KB Article 896861 details two workarounds. One is to disable the Loopback Check entirely – and this is commonly promoted as the thing to do on all your SharePoint Servers. The second is to add a list of addresses to exclude from the check. Both of these are accomplished by means of a registry key in the LSA hive.

So which one should you use? The answer, of course is, it depends.

If you are working on a development environment or on just a single MOSS box – go for it - disable it completely. You need to debug and test locally and it’s likely you don’t know what addresses you will use ahead of time. I as a matter of course disable the check as part of my sysprep build for all my development and test machines. I never hit the problem because my base image is all sorted as I want it. I recommend you do the same.

However, for production environments, DO NOT DISABLE this feature. You are unpicking a serious security check of the OS. If that environment underwent a security audit by a competent security engineer, it would be flagged. You should add a list of addresses you wish to exclude. This makes your scenario work whilst retaining the security check (which is important if you are handing over the environment to your customer’s admins who may decide to browse the interwebz from the console :)).

It’s not that big of a deal to figure out which addresses you need to exclude, and on what machines you need to apply the change. If you can’t do this quickly, you don’t understand your topology or services.

This change can of course be applied by Group Policy, so should you need to do it on a bunch of boxes (e.g. five WFEs with custom code using SharePoint Web Services) the overhead is avoided. Of course this assumes you are using GPOs to manage your SharePoint Servers (you should be). GPOs are also useful if you need to add additional addresses later on.

Another advantage of using the list, is the change does not require a reboot of the server to take effect, just a restart of the IISAdmin service.

Of course this is a lifecycle issue and like anything else, you should weigh the security risk versus additional complexity on a per implementation basis to make the right call. And more important than this, is you need to document the configuration.

In addition as a consultant or otherwise, if you are hitting 401s that don’t make sense – check this, along with Kernel Mode AuthN and Local Intranet Zone before anything else. Just like everyone else this problem has had me scratching my head for a couple hours. So remember this issue when diagnosing the dreaded 401!

Conclusion
The loopback check is a good thing, not a bad thing, if you care about security and platform hygiene. Do not disable this feature in production. Feel free to disable it in development/test environments. Todd is also planning to spend some time on this subject in his next netcast.

Allowing Partially Trusted Callers

The AllowPartiallyTrustedCallersAttribute (affectionately referred to as APTCA from here on out), is one of the aspects of the security system that most frequently trips people up when they run into it. Lets look at a typical scenario where I might run into an issue with APTCA, and then we'll be able to understand what it is and what it does.

Lets say I'm writing a class library to be used by many applications. Following the standard library design guidelines, I've strongly named my library, and put it in the GAC. So far nobody who's used my library has had any problems. However, someone in my company is building an application that's being run from a network share, and they're reporting a problem using my library. Namely, any method that tries to call into my library isn't running, its just failing with a security exception:

Unhandled Exception: System.Security.SecurityException: Security error.
at Caller.Main()

What's going on here? By default, strongly named, fully trusted assemblies are given an implicit LinkDemand for FullTrust on every public and protected method of every publicly visible class. Essentially, any code that someone outside of your assembly could use as an entry point into your code is protected with this demand.

Why do we do this? One primary reason is to help prevent luring attacks where untrusted code can lure some fully trusted code into doing something dangerous on its behalf. For instance, as an attacker, you look into my library and notice that in one of my methods I do an Assert for FileIOPermission, read its contents, and send them back to the caller. You also notice that this method wasn't carefully audited, and that there's a way for you to control which file is read. Now you can easily lure me into getting the contents of a file that you would not normally have been able to read.

OK, so lets assume that you're a careful developer and are aware of potential security issues. You've audited all your code that performs security critical actions, and you know for sure that you're not susceptible to any luring attacks. How can you remove the link demand so that partially trusted code can make use of the functionality you provide?

That's where APTCA comes into play. APTCA is an attribute that tells the CLR to remove the implicit LinkDemands mentioned above. Once you're sure your code is safe for untrusted callers to work with, apply APTCA to the assembly, and the LinkDemands will go away. One important thing to note is that APTCA is only applicable on the assembly level, so you cannot disable these demands on a method-by-method or even a class-by-class basis; either everything in the assembly is safe for partially trusted code to use, or none of it is.

Well, not exactly. Since APTCA only removes the implicit LinkDemands, 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. A list of types that ship with the .NET Framework, but still fall into that category can be found here.

When would you want to use apply APTCA? Only if the following conditions all apply:

1. Your code has been thoroughly audited for security vulnerabilities (perhaps using the MSDN Security Review Checklist)
2. The code is in compliance with the Secure Coding Guidelines
3. You specifically want partially trusted callers to use the library. There's no sense opening up an attack surface if you only care if fully trusted callers can use your code.

It's interesting to note that not all of the framework assemblies are marked with APTCA. For instance, the v1.1 System..Security.dll is not callable from partially trusted code. A list of assemblies that are callable from partial trust can be found about 2/3 of the way through this article, in the section entitled .NET Framework Assemblies with the AllowPartiallyTrustedCallersAttribute.

One final note about the exception text. On v1.0 and v1.1, the exception pictured above isn't the most helpful in the world when you're trying to diagnose what went wrong. With the work that went into increasing the usefulness of SecurityExceptions in Whidbey, we've also changed the error you get when you're failing a LinkDemand due to APTCA. Instead of "Security error.", you'll now see:

Unhandled Exception: System.Security.SecurityException: That assembly does not allow partially trusted callers.
at Caller.Main()
The action that failed was:
LinkDemand
The assembly or AppDomain that failed was:
Caller, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null
The method that caused the failure was:
Void TestMethod()
The Zone of the assembly that failed was:
MyComputer
The Url of the assembly that failed was:
file:///D:/blog/aptca/Caller.exe

Which is a lot more useful when trying to diagnose the error.

For more information, check out Using Libraries from Partially Trusted Code on MSDN.

Setspn Overview

Setspn Overview

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008

Tool Location

The Setspn command-line tool is included when you install Windows Server 2003 Support Tools from the product CD or from the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=100114). For more information about how to install Windows Support Tools from the product CD, see Install Windows Support Tools (http://go.microsoft.com/fwlink/?LinkId=62270).

Setspn.exe: Manipulate Service Principal Names for Accounts

This command-line tool allows you to read, modify, and delete the Service Principal Names (SPN) directory property for an Active Directory service account. SPNs are used to locate a target principal name for running a service. You can use Setspn to view the current SPNs, reset the account's default SPNs, and add or delete supplemental SPNs.

It is not usually necessary to modify SPNs. They are set up by a computer when it joins a domain and when services are installed on the computer. In some cases, however, this information can become stale. For instance, if the computer name is changed, the SPNs for installed services must be changed to match the new computer name. Also, some services and applications may require manual modification of a service account's SPN information to authenticate correctly.

Corresponding UI

There is no corresponding user interface (UI) for this tool.

Concepts

In Active Directory, the servicePrincipalName (SPN) attribute is a multivalued, nonlinked attribute that is built from the DNS host name. The SPN is used in the process of mutual authentication between the client and the server hosting a particular service. The client finds a computer account based on the SPN of the service to which it is trying to connect.

System Requirements

The following are the system requirements for Setspn:

• Windows XP Professional or Windows Server 2003
  
  

File Required

• Setspn.exe
  
  

Permission Requirements

To perform the tasks that are described in the following sections, you must have membership in Domain Admins, Enterprise Admins, or you must have been delegated the appropriate authority. For information on delegating the permissions to modify SPNs, see Delegating Authority to Modify SPNs.

Using Setspn.exe

When you install the Setspn.exe tool from Windows Server 2003 Support Tools, you should be able to access the tool at a command prompt (cmd.exe).

To start using Setspn.exe

1. Open a command prompt. To open a command prompt, click Start, click Run, type cmd, and then press ENTER.

2. At the command prompt, type setspn, and then press ENTER.

   You should see the setspn command syntax with usage and switches. If you see a message indicating that setspn is not recognized as an internal or external command, use the following steps to change to the Support Tools folder and run the setspn command.

   1. To change to the default Support Tools directory, at the command prompt, type cd "c:\Program Files\Support Tools", and then press ENTER.
      
      
   2. At the command prompt, type setspn, and then press ENTER.
      
      

The following sections describe how to run basic Setspn.exe commands. For additional information about the options for Setspn.exe, see Setspn Syntax, Setspn Remarks, and Setspn Examples.

SPN Format

When you manipulate SPNs with the Setspn tool, the SPN must be entered in the correct format. The format of an SPN is serviceclass/host:port/servicename, in which each item represents a name or value. Unless the service name and port are not standard, you do not have to enter them when you use Setspn. For example, if you have a service with the following characteristics:

• Name: MyService
  
  
• Running on a computer named DCA
  
  
• Uses the TCP or UDP port 8088
  
  
• Service name: MyS
  
  
• Location: in the directory under an organizational unit (OU) named CS, in a domain named cpandl.com
  
  

the SPN looks like the following:

MyService/DCA.cpandl.com:8088/CN=MyS,OU=CS,DC=cpandl,DC=com

The remaining examples in this topic assume that the default port and service name are used for SPNs, which is typical. Unless the service name and port are not standard, you do not have to enter them when you use Setspn. If you need more information about specifying a nonstandard SPN configuration, see Name Formats for Unique SPNs (http://go.microsoft.com/fwlink/?LinkId=102555).

Assume that there is a server named WS2003A that is providing remote desktop (RDP) services over the default port (TCP 3389). This server registers the following two SPNs in its own Active Directory computer object:

TERMSRV/WS2003A

TERMSRV/WS2003A.cpandl.com

Viewing SPNs

To view a list of the SPNs that a computer has registered with Active Directory from a command prompt, use the setspn -l hostname command, where hostname is the actual host name of the computer object that you want to query.

Note
To find the host name for a computer from a command prompt, type hostname, and then press ENTER.

For example, to list the SPNs of a computer named WS2003A, at the command prompt, type setspn -l S2003A, and then press ENTER. A domain controller named WS2003A in Cpandl.com, which is also functioning as a global catalog server and Domain Name System (DNS) server, registers the following SPNs:

Registered ServicePrincipalNames for CN=WS2003A,OU=Domain Controllers,DC=cpandl,DC=com:

ldap/WS2003A.cpandl.com/ForestDnsZones.cpandl.com

ldap/WS2003A.cpandl.com/DomainDnsZones.cpandl.com

NtFrs-88f5d2bd-b646-11d2-a6d3-00c04fc9b232/WS2008A.cpandl.com

DNS/WS2003A.cpandl.com

GC/WS2003A.cpandl.com/cpandl.com

HOST/WS2003A.cpandl.com/CPANDL

HOST/WS2003A

HOST/WS2003A.cpandl.com

HOST/WS2003A.cpandl.com/cpandl.com

E3514235-4B06-11D1-AB04-00C04FC2DCD2/70906edd-c8a5-4b7d-8198-4f970f7b9f52/cpandl.com

ldap/70906edd-c8a5-4b7d-8198-4f970f7b9f52._msdcs.cpandl.com

ldap/WS2003A.cpandl.com/CPANDL

ldap/WS2003A

ldap/WS2003A.cpandl.com

ldap/WS2003A.cpandl.com/cpandl.com

The globally unique identifier (GUID) 70906edd-c8a5-4b7d-8198-4f970f7b9f52 identifies the NTDS Settings object of the domain controller (NTDS-DSA), which is unique for each domain controller. The other two GUIDs, NtFrs-88f5d2bd-b646-11d2-a6d3-00c04fc9b232 and E3514235-4B06-11D1-AB04-00C04FC2DCD2, identify the File Replication Service (NTFRS) and the Directory Replication Service (DRS) remote procedure call (RPC), respectively, and they are standard SPNs for all domain controllers.

Note
If constrained delegation is in use on a Windows Server 2003 computer that requires an SPN modification, some SPNs may not appear. For more information, see article 936628 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=102306).

Resetting SPNs

If the SPNs that you see for your server display what seems to be incorrect names; consider resetting the computer to use the default SPNs. To reset the default SPN values, use the setspn -r hostname command at a command prompt, where hostname is the actual host name of the computer object that you want to update.

For example, to reset the SPNs of a computer named server2, type setspn -r server2, and then press ENTER. You receive confirmation if the reset is successful. To verify that the SPNs are displayed correctly, type setspn -l server2, and then press ENTER.

Note
For information related to troubleshooting SPN issues, see Service Logons Fail Due to Incorrectly Set SPNs (http://go.microsoft.com/fwlink/?LinkId=102554).

Adding SPNs

To add an SPN, use the setspn -a service/namehostname command at a command prompt, where service/name is the SPN that you want to add and hostname is the actual host name of the computer object that you want to update. For example, if there is an Active Directory domain controller with the host name server1.contoso.com that requires an SPN for the Lightweight Directory Access Protocol (LDAP), type setspn -a ldap/server1.contoso.com server1, and then press ENTER to add the SPN.

Removing SPNs

To remove an SPN, use the setspn -d service/namehostname command at a command prompt, where service/name is the SPN that is to be removed and hostname is the actual host name of the computer object that you want to update. For example, if the SPN for the Web service on a computer named Server3.contoso.com is incorrect, you can remove it by typing setspn -d http/server3.contoso.com server3, and then pressing ENTER.

For more information about SPNs, see Service Principal Names (http://go.microsoft.com/fwlink/?LinkId=102556).

More Information:

A Security Principle is created to authorize Kerberos communication. NTLM, the default windows security protocol, does not allow security tokens to be passed from one server to the other.

The SetSPN command line tool is not available on a Windows 2003 Server by default. It is part of Windows Support Tools utility. Windows Support Tools can be installed from the Windows Server 2003 installation CD.

To install the SetSPN Windows Support Tools utility on a Windows 2003 Server:
1. Open Windows Explorer to the folder where you copied the Windows Support Tools package.
2. Run the following file: SUPTOOLS.MSI
SetSPN is built into Windows Server 2008. It is available if you have the Active Directory Domain Services (AD DS) server role installed. To use setspn, you must run the setspn command from an elevated command prompt.

To grant the remote database access privileges to a Domain account using the SetSPN utility:
1. IMPORTANT: Log into Windows using a Domain Administrator account. This level of security
privileges is required to successfully complete the remaining steps.
2. To access SetSPN:
• For Windows Server 2003 - Run Start > Programs > Support Tools > Command Prompt
to open a command prompt.
• For Windows Server 2008 - Click Start, right-click Command Prompt, and then click
Run as administrator.
3. Set a fully qualified domain name, friendly name, and DNS name on the Server machine so that any client can access it:
a. To set the fully qualified domain name, execute the SetSPN command using the
following syntax:
setspn –a http/machinename.domain.com domain\username
IMPORTANT: Be sure to include the Domain Name in the command prompt:
machinename.domain.com. The machinename refers to the machine name.

b. To set the friendly name, execute the setspn command using the following syntax:
setspn –a http/machinename domain\username

c. To set the DNS Name or Alias used to abstract the physical hardware execute the setspn
command using the following syntax: setspn –a http/dns domain\username

4. Verify whether this has been properly set by running the following command:
setspn –l domain\username
The result should list http/machinename.domain.com.

SharePoint 2010 SNEAKPEAKS are here

General Intro:
http://sharepoint.microsoft.com/2010/Sneak_Peek/Pages/Overview-Video.aspx
Developers:
http://sharepoint.microsoft.com/2010/Sneak_Peek/Pages/Developer-Video.aspx
IT Pros:
http://sharepoint.microsoft.com/2010/Sneak_Peek/Pages/IT-Pro-Video.aspx