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)
and/or a trustee attribute.
Basic authentication credentials can only be passed in requests submitted to MPF via a trusted request or by a caller that has the Execute with Caller's Credentials permission. For more information on trusted requests, see , Provisioning Engines, and Provisioning Queue Manager Service.
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 both situations, 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 privileges for the procedure. For more information, see Basic Authentication.|
|COM security context of calling user that submits the request||Microsoft® Windows® 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 privileges 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 is normally in the background of all requests, but because its privileges are by default limited to MPF functions, it is not normally used in situations that require extended privileges.