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:
- 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
Create a group in Active Directory with a name such as Customer Service Reps, without configuring it with any specific permissions.
Create a set of procedures within MPS that call the Managed Active Directory namespace.
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.
Use the MPS Provisioning Manager to set security on the procedure to allow only the Customer Service Reps group to execute that procedure.
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.