In Microsoft Provisioning Framework (MPF) authentication, each step in a provisioning request is assigned an identity. MPF and external services, such as the Active Directory directory service, grant procedure execution permissions and access to resources based on permissions defined for the identity.

MPF assigns the identity based on the step's security context, a set of parameters used to secure the interaction between the calling user, MPF, and any external services. This identity can change throughout the processing cycle. Basic authentication and Kerberos delegation are two ways of passing identities into MPF. To simplify security configuration, MPF creates several default user accounts and groups during setup.

Microsoft Provisioning Framework (MPF) uses the security contexts in the following table during request processing.

Table: Security Contexts Used by MPF

Security context	Description
Credentials passed in a request	Credentials are specified in the request's securityContext node. Credentials can take the form of a basic authentication credential (user name, password, and domain), a trustee attribute, or both. Basic authentication credentials can only be passed in requests submitted to MPF by using IProvEngine::SubmitTrustedRequest or IProvQueue::SubmitTrustedRequest. Specifying a trustee attribute grants access to namespaces and procedures based on membership in a discretionary access control list (DACL). For more information, see Authorization During Calls to Namespaces and Procedures in Authorization. When supplying either basic authentication or trusted attribute credentials, MPF delegates authentication responsibility to the calling process.
"Execute as" user credential for the procedure	A basic authentication credential can be defined in the configuration database and assigned to a procedure using the "Execute as" property. This can be convenient whenever all authorized callers share the same permissions for the procedure. For more information, see Basic Authentication in this topic.
Component Object Model (COM) security context of calling user who submits the request	The Microsoft Windows operating system generates and maintains a COM security context for all requests. Whenever the request does not explicitly name a trustee, MPF sets the trustee to the COM identity of the calling user and passes this identity unchanged through the system. In this case, MPF delegates authentication of the trustee to the calling process. For more information, see Kerberos Delegation in this topic.
MPFServiceAcct	All requests automatically inherit the security permissions of MPFServiceAcct, the default service account for provisioning servers. If no other security context is available, MPF uses this context. To simplify security setup, this account can be configured with full security rights to external services.

The security context of a request can change during the processing cycle, especially if the request calls multiple procedures. For example:

• Individual procedures can have different "Execute as" credentials.
• The impersonate and trusted attributes specified in the procedure's execute and queue nodes can determine which security information is passed to other procedures. The impersonate attribute activates or disables impersonation for subsequent calls. The trusted attribute determines whether authentication information in the request's securityContext node is passed to a provider. The provider can then use this information to modify the security context of the call to the external service. For example, the HTTP and SOAP provider does this when initiating an HTTP request with basic authentication.

A request can also have multiple security contexts simultaneously, but the presence of a context does not necessarily mean it will be used. For example, MPFServiceAcct usually runs in the background of all requests, but because its permissions are limited to MPF functions by default, it is not normally used in situations that require (and have) a more robust context.

For basic authentication, Microsoft Provisioning Framework (MPF) authenticates callers using credentials, including a user name, password, and Windows domain name. MPF uses basic authentication in trusted requests and as a means of standardizing access permissions for a procedure.

Trusted requests pass basic authentication credentials in the \securityContext\authentication\basic node. MPF delegates authentication responsibility to the calling process. If the request calls external services, such as the Active Directory directory service, MPF passes the basic credential on to the service, which can then use it to authorize callers. For more information on trusted requests, see Authorization During Request Submittal in Authorization.

When all authorized callers for a namespace procedure are entitled to the same security permissions, it can be convenient to associate these permissions with a credential stored in the configuration database. Credentials are defined in Provisioning Manager by right-clicking Credentials and then selecting the Add Credential option from the contextual menu. Credentials are assigned to procedures using the Execute as property of each procedure.

For example, a request to implement a new Internet Information Services (IIS) server might involve the procedure calls and credentials described in the following table.

Table: Procedure Calls and Credentials

Procedure call	Task	Credential
Active Directory Provider::Create Object	Create a new user account in Active Directory.	None. If no credentials are specified, the security context for the call will be the COM context of the calling user.
File system Provider::CreateDirectory	Create a new directory.	CreateDirectory has administrator credentials specified in the Execute as property.
CoreRMO::Add Resource Group	Create resource groups.	Add Resource Group has administrator credentials specified in the "Execute as" property.

Because CreateDirectory and Add Resource Group have administrative credentials, anyone authorized to call those procedures will have administrative permissions for those two procedures. They will not, however, have administration permissions for other procedures.

A procedure can have only a single set of "Execute as" credentials. Multiple procedures can have separate credentials, or the same credentials can be assigned to multiple procedures. Therefore, the caller's identity can change over time as different procedures are executed.

"Execute as" places the basic authentication credentials into the security context for the procedure. To be used, however, the procedure call must specify the Impersonate attribute for the respective execute or queue node.

Microsoft Provisioning Framework (MPF) can be configured to use Kerberos delegation for authentication in domain deployments. Kerberos delegation is a form of impersonation. Microsoft documentation distinguishes between delegation and impersonation, using the term delegation to refer to impersonation involving multiple computers that communicate over a network. In MPF, delegation refers to the ability of a calling process to execute based on the COM security credentials of the calling user.

MPF can use Kerberos delegation under the following conditions:

• When clients submit requests to provisioning servers.
• When requests call providers that interact with external services such as Active Directory.

To configure MPF to support Kerberos delegation, dynamic cloaking and delegation must be set up on the client during MPF setup, and the MPFServiceAcct must be marked as trusted for delegation in Active Directory. You can do this in one of two ways, depending on the installation mode:

• During installation, select the Impersonation check box (if using the Setup Wizard) or specify the MPF MPF_IMPERSONATE=1 parameter (if installing from the command line).
• After installation, in Provisioning Manager, set the Capabilities property for provisioning engine clients to Dynamic cloaking and set the Impersonation level property to Delegate, and then do the same for queue manager clients.

After impersonation is set up, impersonation for procedure calls is specified in requests using the impersonate attribute of the individual execute and queue nodes. For Kerberos authentication, impersonate must be set to 1 and the request must not contain a \securityContext\authentication\basic node. Otherwise, MPF assumes that the call uses basic authentication rather than Kerberos.