Machine Logon Options

For the Run As feature to function correctly at run time, the requirement still exists for the creation and availability of a valid token that is passed by the K2 Server when a user’s credentials are passed from one server to another.

In the following scenario, the K2 Server Service account passes the credentials of the specified user and attempts to impersonate the specified user when accessing a SQL Server to retrieve data. If the K2 Service account is in possession of a valid token then the SQL Server will allow the credentials to pass and the K2 Server will have successfully gained access.

System Implementation

The Run As functionality makes use of the Windows LogonUser framework for the K2 Server to create a token for the user. The simplest way to implement this is to enable "Log On Local" rights, this is however not secure and not best practice either. Incidentally the LogonUser class is used by Kerberos and other windows users and services when an attempt is made to logon to a system or the local machine and access the machine’s resources.

For further information on the Windows Logon framework see the following link : http://msdn.microsoft.com/en-us/library/aa378184(VS.85).aspx

For an authenticated logon, where credentials are passed a valid token must be created first. The user token is then passed to the machine for example the SQL Server.

There are a number of methods that could be used to 1) Create the token 2) pass the credential containing to token to the designated machine. The machine then ‘interrogates’ the validity of the token and verifies that the credentials being passed are valid. The table below lists the various options that are available, however the method used by the Run As feature must 1) enable access to the machine without a local logon required and 2) no credentials must be cached which means that the presence of logon would only be valid for a single transaction or session and then the logon is closed.


1 - Recommended *	LOGON32_LOGON_BATCH	This logon type is intended for batch servers where Server Events would be executed on behalf of a user or using a User account other than the K2 Service account without any user interaction	No user credentials are cached on the local machine
2 - Insecure	LOGON32_LOGON_NETWORK_CLEARTEXT	This logon type preserves the user credentials as part of the authentication package. However as the name suggests the credentials are exposed as CLEARTEXT and this method is therefore insecure.
3- Provides Insufficient functionality	LOGON32_LOGON_NETWORK	Enables a plain text password to be authenticated
	LOGON32_LOGON_NETWORK_NEW_CREDENTIALS	Enables the current token to be cloned
	LOGON32_LOGON_UNLOCK	Enables the user account that is specified to logon and interactively make use of the local machine
4 - Requires other	LOGON32_LOGON_INTERACTIVE	This logon is for servers and users that will use the local machine interactively as if being logged on by a terminal server i.e. service or server is not run on behalf of the specified user by instead by the specified user.
4 - Requires other	LOGON32_LOGON_SERVICE	Indicates a service type logon
^{* This method is the method that has been implemented and supported by the RUN AS functionality. The rest of the methods described in this table are there for information purposes only and are not recommended owing to the prospective security risks they create.}

LOGON32 Implementation

The LOGON_32 implementation must be secure and that reduces the number of available options significantly. Of interest is LOGON32_LOGON_NETWORK, which will generate a valid token but since the token is of a poor quality it is not secure. It is still valid and the Logon framework will process this and enable a valid session. LOGON32_LOGON_NETWORK_CLEARTEXT will do the same as LOGON32_LOGON_NETWORK; i.e. provide a valid authenticated package however since the user name is exposed it is not advised.

If an attempt is made to pass a token generated using the LOGON32_LOGON method to another server, the likely result is that the token will be rejected i.e. there will not be valid authentication of the user.

Finally, the method implemented is LOGON32_LOGON_BATCH. This method enables the K2 Server Service account to impersonate the user and pass the user credentials to the designated machine when a logon attempt is performed. The token will be authenticated as valid and provided that the impersonated user has the appropriate user permissions to access the SQL Server then the process will continue as per normal.