Microsoft Provisioning Framework (MPF) uses the following security contexts during request processing.
|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. 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.|
|COM security context of calling user who submits the request||The 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.|
|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:
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.