In Microsoft Provisioning System (MPS) security, each procedure called by a provisioning request can run under the context of one of the following security identities:

  • COM security identity - The Microsoft Windows operating system generates and maintains a COM security context that applies to all requests. Whenever an XML-based request does not explicitly specify the security context, MPS relies on Kerberos delegation authentication to provide the COM security identity of the calling user or application.
  • Basic authentication credentials - These are the basic authentication credentials that you specify in the security context node of an XML request. They include each of user name, password, and domain; or trustee attribute, or all of these. Basic authentication credentials can only be passed in requests submitted to MPS when one of the following methods of the Provisioning Engine interface is called:
    • IProvEngine::SubmitTrustedRequest
    • IProvQueue::SubmitTrustedRequest
  • Stored credentials - A stored credential is a pre-existing valid credential that is stored in the Configuration database in encrypted format (rather than clear text). By using the Provisioning Manager, you can define a stored authentication credential in the Configuration database and then assign the Execute As property to a procedure, to configure it to use the credential you defined.
  • MPFServiceAcct - All requests automatically inherit the security permissions of the MPFServiceAcct, which is the default service account for provisioning services. If no other security context is available, MPS uses this context. It is possible to configure your system so that procedures run using the MPFServiceAcct. However, because this configuration is not secure, we do not recommend this configuration.

To implement procedure level security in MPS, you can use the Provisioning Manager Microsoft Management Console (MMC) snap-in provided with MPS to set security on a given procedure to define who can or cannot run it. One example of how you might do this is by combining the security setting on a given procedure with the Execute As setting on the procedure. This configuration enables you to provide a user with the ability to perform specific actions without actually giving them the rights to perform those actions at the application level.

For example, suppose you have or plan to create an Active Directory group such as Customer Service Representatives (CSR) and you want to allow users in this group to create new user accounts and reset passwords. However, you do not want them to have the rights to perform these actions directly in Active Directory. In addition, you want to ensure that all these actions are accomplished through the provisioning system so they can be performed by a predefined Named Procedure stored within MPS and logged in the Audit database as well. To implement this configuration, you can use the following steps.

Procedure SPV.6: To implement procedure-level security

  1. Create a group in Active Directory with a name such as Customer Service Reps, without configuring it with any specific permissions.

  2. Create a set of procedures within MPS that call the Managed Active Directory namespace.

  3. Create a new super user in Active Directory with a name such as CSR Provisioning User and give that user the specific permissions configuration within Active Directory to perform the required actions.

  4. Use the MPS Provisioning Manager to set security on the procedure to allow only the Customer Service Reps group to execute that procedure.

  5. Set the Execute As property on the procedure to use the CSR Provisioning User.

At this point, you have a set of procedures that can only be executed by members in the group Customer Service Reps. When a member of this group calls the procedure, it then executes under the super user account, which is the only account with actual rights to perform the tasks in Active Directory. If you have any users who are not members of the group and they attempt to call these procedures, MPS does not permit the procedures to execute.

As indicated in Best Practices for Service Provisioning, we recommend regularly changing the password for MPS accounts. This also applies to the Execute As user, which is the CSR Provisioning User in the example above. Therefore, be sure to configure your password security policy to include monitoring for periodic password changes on all MPS accounts and changing passwords for these accounts regularly. However, in this example, you should also configure Active Directory such that the password for the Execute As user never expires. Otherwise, it is possible that your domain policy will cause the password to expire after 30 days, thus rendering the Execute As user inoperable and preventing execution of associated procedures.