Forms Server & Credential Delegation
This will be my first quick post to this blog and hopefully people will find this of use.
With the increase of people wanting to leverage forms server to render InfoPath forms in the users web browser I am often seeing people hitting the problem of forms server not passing credentials to the K2 Server.
So following is a quick explanation of what the problem is and summary’s of solutions available to work around the problem.
The Problem
There is an issue in forms server which prevents the delegation of credentials using Kerberos when a hop is involved. This means that when Forms Server connects to the K2 [blackpearl] web services the identity of “NT Authority\Anonymous” is passed which causes a “401” error to be returned.
Server A being the K2 [blackpearl] hosting the K2 [blackpearl] Host Server, K2 [blackpearl] Workspace and Web services
Server B MOSS 2007 (Forms Server)
The Solutions
Allow Anonymous
This is the first obvious option although is HIGHLY unadvisable due to the obvious security reasons.
Embed Credentials in the UDCX files
The second option is to embed your credentials in the UDCX files, the problem here is that these details are stored in clear text and the identity being passed to the K2 server is always the same which raises security concerns and overhead in process design.
Protocol Transition
My preferred workaround is to move the K2 [blackpearl] Web Services on the same Server as MOSS 2007 and enable Kerberos protocol transition on the account under which the K2 [blackpearl] Web Services run. This enables forms server to authenticate with the web services using NTLM and as there is no hop involved the users identity is passed, the K2 [blackpearl] Web Services then proceed to undertake Kerberos authentication on behalf of the user and pass the users credentials to the K2 [blackpearl] server.
When using Kerberos protocol transition we need to factor in the security implication that the web services are able to impersonate any user which is not marked as sensitive. At first this sounds a lot worse than it is but consider the following points;
- Use of protocol transition requires that constrained delegation be configured, so in this scenario an attacker can only impersonate to the K2 server.
- Protocol transition does not use and store passwords!
- In this example we do not set the K2 web services account the right to act as part of the operating system!
- In this scenario an initial authentication via NTLM has to occur to ascertain the users identity, you can’t just pass a string with the user you want to impersonate
- To exploit the protocol transition in this example an attacker would need to compromise the server and inject code which they would then need to execute
- You can remove all unwanted web services and expose only the InfoPath web service
- Control access to the web service by utilizing a firewall
Unfortunately Kerberos Protocol Transition is only available when the domain which the service account belongs to has functionality level running in Windows 2003 Native Mode.
Single Server
Your domain is running at Windows 2000 Mixed Mode as you have Windows 2000 domain controllers. This means that the use of Kerberos Protocol Transition is not an option, but all other options are not viable for security reasons. To work around the problem you can install all the K2 [blackpearl] components on the MOSS server as a standalone installation. Performance must be taken into account, a level of scalability can be provided by having multiple servers running as a farm.
Mark Green