This page describes the default accounts under which guest application components run on the Platform, how those accounts can be managed, and how you can run applications under pre-specified service accounts (e.g. for .NET components, creating Domain Groups and limiting access rights for all group members). Platform Operators have the ability to manage all accounts (Platform and guest application) and can choose to allow Developers to manage accounts specific to their applications.
At Platform installation, guest application components will run as the following:
Most enterprises will not run the Platform and guest applications using the default account settings for good reason. By creating specified accounts you can allow computer/domain user account credentials with restricted access or with disk quotas to launch application components, enterprises can add further access controls and abide by the principle of least privilege.
Both Platform Operators and Developers can specify service accounts for guest applications. Operators can manage the user account credentials for all application components (Platform Core or guest application) on the Applications page of System Operations Center (SOC) or they can change the credentials for different types of application components to run under single accounts in the Platform Registry (not recommended for a Platform running many applications with different access rights).
Operators can also delegate control directly to Developers to set credentials for their application components for only the applications they are allowed to manage. Platform Operators can configure how much Developers can specify, they can override Developer configuration, or they can disable Developer control completely. Platform Operators can also specify the accounts available for Developers to use for Java and Linux component types.
A Developer’s ability to specify credentials for their application components is enabled by the Platform Registry Setting ComponentCredentialSpecification, which is set to Allowed by default. When enabled, Developers can set specific credentials for their application components if they chose, but they do not have to. If a Developer doesn’t set credentials for an application, the Platform will use the default credentials specified in the Platform Registry for that component type.
To require Developers to set credentials for each application, set ComponentCredentialSpecification to Required. The Platform will require Developers to set credentials for their application components before the application can be moved to the next stage in its Lifecycle.
To disable Developer’s ability to set application credentials, set ComponentCredentialSpecification Forbidden. The defaults specified in the Platform Registry will be used and Developers will not be able to set component credentials for an application.
Platform Operators can always view and update user account credential settings for specific guest application components through the SOC Applications page. If credential settings are updated for a component on that page, the Platform will launch any subsequently-deployed instances of the component under the new credentials you specified. Any previously-deployed instances will continue to run under the credentials they were launched with unless they are stopped and then re-started, in which case they will be deployed under the new credentials you set.
Changes made to component credential settings through the SOC will apply only to the application version while it remains in its current stage, and will not persist, for instance, if the version is promoted from the Sandbox to Published stage.
Note: If the ComponentCredentialSpecification registry setting is changed to Forbidden after Developers have previously been allowed or required to specify component credentials, Developers will no longer be able to update those settings. The settings they had previously entered will remain in place unless updated through the SOC Applications page, and any subsequently-deployed component instances will still run under the Developer-specified credentials (unless updated through the SOC).
When Developers are allowed or required to specify an account under which Java Web Application or Linux Service components will run, the user accounts available is limited to a list of accounts specified by the Platform Operator. Accounts that Developers are permitted to use (along with optional corresponding Tokens) must be specified on the Configuration>Security page of the SOC. Developers can then use the account name and corresponding Token in order to deploy components under that account.
By default, the Platform runs Windows Services applications under Virtual Accounts, a Windows Server feature that enhances isolation and manageability of network applications. See Microsoft’s documentation for more on Virtual Accounts.
To run WCF Services, you will have to make sure NT SERVICE\ALL SERVICES have the “Log on as a Service” permission. For each instance of these component type, a new Virtual Account will be created to manage the instance.
If you upgraded to 7.1.0 or later from a version before 7.1.0, the Platform will continue to use the Apprenda System Account to run guest application WCF and Windows Services components after the upgrade. To use Virtual Accounts after the upgrade, Platform Operators must edit the following Platform Registry Settings to have blank values (do not remove the settings) and redeploy or restart all WCF and Windows Services application workloads.
Note that if an application component has a defined Active Directory user assigned by a Developer, the Platform will use that user instead of a Virtual Account.
When a developer specifies a user account for a .NET service or .NET UI component, by default the Platform will load the user profile in order to validate the credentials. This process requires that the account has Allow log on locally rights.
In order to accommodate security protocols that do not allow specified accounts to have Allow log on locally permissions, the Platform ships with a Load User Profile Custom Property that can be used to disable this check for .NET UI components (and run an alternative validation on the credentials).
By default the Load User Profile property is both visible to and editable by Developers. As needed the Platform Operator may edit the Custom Property in order to hide the Custom Property from Developers and set a default value.
When the Load User Profile Custom Property is set to a value of No, Developers can successfully specify credentials for .NET UI components when the user account does not have Allow log on locally rights. Developers can specify the value in one of two ways:
In the Developer Portal, the Custom Property can be set for the .NET UI component through the Deployment section of the Configure Components tab for the application version.
It should be noted that Developers must set the value of the Custom Property to No and then save before the credentials can be successfully specified and saved in the Security section of the Configure Components tab.
Developers may also specify the Custom Property value through a Deployment Manifest included with their Application Archive. Developers should specific the Load User Profile Custom Property and the user credentials at the component level for the .NET UI component (through the “presentation” attribute”) in the Deployment Manifest.
<?xml version="1.0" encoding="utf-8"?> <appManifest xmlns="http://schemas.apprenda.com/DeploymentManifest" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://schemas.apprenda.com/DeploymentManifest http://apprenda.com/schemas/platform/9.0/DeploymentManifest.xsd" > <presentation pipelineMode="Integrated" strategy="CommingledRootApp" domain="myDomain" userAccount="myUserName" password="myPassword" instanceCount="1" scalingType="Manual"> <customProperties> <customProperty name="LoadUserProfile"> <values> <propertyValue value="No" /> </values> </customProperty> </customProperties> </presentation> </appManifest>