The Application Administrative User

The Application Administrative User has a normal Windows Operating System user account from either the local or network domain. It is required to have direct or indirect membership of the local “Administrators” group, or its equivalent.

The Application Administrative User account must be a domain account if any of the following conditions are true:

The application would be accessed by any end-user via a domain user account. The processes running as the Application Administrative User needs to verify the membership of users in various COM+ Roles. This cannot be done for domain users unless the Application Administrative User is also the domain user.
The database is on a different machine to the applications.
The applications are deployed remotely.

If the Application Administrative User account is a domain account, then it must not have a roaming profile.

In addition, if applications are to be deployed remotely, the Application Administrator User’s account must be marked as “Account trusted for delegation” in the domains active directory. This applies only to Windows 2010 and later, domains. The change might not be immediately visible as it can take some time to propagate throughout the machines within the domain. This is applicable for all the supported operating systems. Therefore, the deployment server running as the Application Administrative User impersonates the user that invokes the deployment to access the resources on the developer machine. This requires the invoking user to be given the administrator privileges in the runtime server and the Application Administrative User to be given the “Account trusted for delegation” privilege.

Note: In Windows Server 2010 and later version domains, to provide delegation privileges to the Application Administrator User account and mark it as “Account trusted for delegation”, you should assign Service Principal Name (SPN) to the Application Administrator User account in the active directory.For example, to assign an SPN name 'https/AppAdminUser' to AppAdminUser account, run the following setspn command on domain controller:setspn -a https/AppAdminUser AppAdminUserwhere, the first parameter, https/AppAdminuser, is an SPN name and the second parameter, AppAdminUser, is an account name. You can also prefix a domain name with the account name, for example,

setspn -a https/AppAdminUser MyDomain\AppAdminUser

The RuntimeServiceImpersonationLevel registry key provides an alternate method of deployment. With this registry key, you can choose to deploy a system with or without the Application Administrative user having delegation privileges. The RuntimeServiceImpersonationLevel is of the type String and is stored in the runtime machine under the following registry key:

\HKEY_LOCAL_MACHINE
 \SOFTWARE
  \Unisys
   \AB Suite
    \7.0
     \SM Runtime

where

"RuntimeServiceImpersonationLevel"= string:"Anonymous/Delegate"

Note: The registry setting must be reapplied after each IC upgrade.

The RuntimeServiceImpersonationLevel registry key can be assigned the following values that represent various impersonation levels:

Anonymous (Security Anonymous) – When you assign the Anonymous value, the deployment process is initiated by using the Application Administrative User account instead of the user that invokes the deployment process. This avoids the Application Administrative User to be given the “Account trusted for delegation” privilege. Additionally, the user that invokes the deployment does not need to be given the administrator privileges in the runtime server. However, the invoking user must be part of the “Security Administrators” COM+ role under security helper and the “Deployers” COM+ role under deployment server.
Delegate (Security Delegate) – When you assign the Delegate value, the deployment process is initiated by the user that invokes the deployment process. By default, the impersonation level is set to the Delegate value.

Warning
Since runtime cannot identify or authenticate the user, who deploys a system, any anonymous user can deploy a system. The anonymous user who invokes the deployment need not be given the administrator privileges in the runtime server. However, the invoking user must be part of the “Security Administrators” COM+ role under security helper and the “Deployers” COM+ role under deployment server. Additionally, the administrators cannot trace the users who have tried to deploy and access the runtime server resources.
By default, the setting is Delegate.

Refer to the Agile Business Suite Developer User Guide for more information on deploying with reduced impersonation levels.

Client and server(s) taking part in remote deployment, as well as the client user, and Application Administrative User, must all be part of this domain.

The following processes run under the Application Administrative User identity:

The process housing the Database Configuration application.
The process housing the Database Reorganization application.
The process housing the Runtime Manager.
The process housing the System Administration application.
The process housing the Security Helper application.
The process housing the Deployment Server.

Application Administrative User Account Required Rights and Privileges

The account should not be granted any privileges beyond those specified below.

On all machines:

“Log on as a batch job” required as some batch processes assumes the Application Administrative User's identity.

On the machine hosting the applications:

“Replace a process level token” required to run deployment packages and make external calls.
“Act as part of the operating system” required to verify all domain user credentials. This privilege is also needed for deployment operations using the non-console Remote Desktop Connections on both operating systems.

On the machine hosting the databases when the databases are on a different machine to the applications:

“Access this computer from the network” required to be able to connect to the database remotely.
With Windows 10, Windows Server 2016, Windows Server 2019, and later Operating Systems, it is only the Administrator version of those users, not the Standard User version that are members of the Administrators Group. Therefore, no Standard User accounts are added by default into the Users Role. In earlier versions of Windows, the user was automatically in the Users Role via its membership of the Administrators Group. Non-administrative users still had to be added manually to the Users Role. In Windows 10, Windows Server 2016, Windows Server 2019, and higher Operating Systems, this rule still applies, but now everyone is a non- administrative user by default.