Security in Microsoft Provisioning Framework (MPF) is implemented at several levels, including for transactions and databases. You can use Provisioning Manager to customize security by modifying the properties of servers, namespaces, and procedures.
Access to the configuration database is governed by the system configuration and security policies in effect. By default, anonymous users cannot access the database. For domain deployments, domain users have Execute permissions for a subset of stored procedures.
Transaction security in MPF revolves around the authentication and authorization of users who request to execute procedures.
When a calling user submits a request to either clients or to the SOAP Internet Server Application Programming Interface (ISAPI), MPF authenticates the user based on the user's Windows security context. If the request does not already specify a trustee, MPF sets the trustee to the calling user.
When a user submits a request, MPF verifies that the calling user is authorized to call either the IProvEngine or IProvQueue interface, depending on whether the request is to be processed immediately or queued. MPF verifies authorization based on the permissions specified for the user under the Requests Security property of the respective provisioining engines or queue managers. Permissions that you can specicfy for users includes permissions to execute procedures, trusted procedures, and private procedures. MPF implements the permissions as follows:
For more information about the IProvEngine and IProvQueue interfaces, see the Microsoft Provisioning Framework SDK documentation.
You set permissions for MPF by adding users and groups to, or deleting users and groups from, the permissions list for each of the following components:
You configure the security properties of provisioning engines to grant and deny permissions for specific users, groups, and accounts to submit requests and trusted requests. For more information, see Grant permission to submit requests to provisioning engines.
You configure the security properties of queue managers to grant and deny batch submittal permissions for specific users, groups, and accounts to submit requests and trusted requests. For more information, see Administering queue managers
.You configure the security properties of each namespace to grant and deny permissions for specific users, groups, and accounts to implement the namespace. For more information, see Maintaining and updating namespaces and procedures.
You configure the security properties of each procedure to grant and deny permissions for specific users, groups, and accounts to implement the procedure.For more information, see Maintaining and updating namespaces and procedures.
The difference between requests and trusted requests is that only trusted requests are permitted to modify the XML used to implement a request.
Before it executes a request, MPF verifies that the account submitting the request has the required authority to perform the actions specified in the request. MPF uses impersonation and delegation to ensure that incoming requests have the authority to perform the requested action.
Impersonation is the process by which a server makes a request on behalf of a client. The server does this by presenting the client's identity and credentials in place of its own when submitting the call to a provider or namespace in MPF.
The impersonation property setting for clients specifies the level of authority granted to provisioning servers to carry out actions on the client’s behalf. The highest level of trust is required for the server to be able to impersonate the client over the network.
Impersonation over the network is called delegation. For a server to be able to perform delegation, it must be running under an account or identity that is marked as "trusted for delegation" in Active Directory. To enable delegation, the client must not be marked in Active Directory as an account that is sensitive and cannot be delegated.
Using Provisioning Manager, you can specify client impersonation levels for clients of provisioning engines and for clients of queue managers. The levels are as follows:
| Level | Description |
|---|---|
| Default | Distributed Component Object Model (DCOM) chooses the impersonation level by using its normal security blanket negotiation algorithm. |
| Anonymous | The client is anonymous to the server. The server can impersonate the client, but the impersonation token (a local credential) does not contain any information about the client. |
| Identify | The server can obtain the client's identity, and can impersonate the client only for discretionary access control list (DACL) checks. The server cannot access system objects as the client. |
| Impersonate | The server process can impersonate the client's security context while acting on its behalf, with restrictions. The server can access resources on the same computer as the client. If the server is on the same computer as the client, it can access network resources as the client. If the server is on a different computer from the client, it can only access resources that are on the same computer as the server. |
| Delegate | The server process can impersonate the client's security context while acting on its behalf, whether or not on the same computer as the client. During impersonation, the server can make outgoing calls to other servers while acting on behalf of the client, using cloaking. The client's credentials, both those with local and with network validity, can be passed to any number of computers. |
You can implement impersonation for both provisioning engine clients and queue manager clients. You cannot implement impersonation separately for individual clients You can specify the impersonation level for a procedure by modifying the XML of the procedure.
Note
For more information on setting impersonation levels, see Administering clients
Procedures configured for private access can only be called from inside of MPF. Procedures configured for public access can be called from inside or outside of MPF. Private access provides a higher level of security than public access.
By default, namespaces implement public access to facilitate testing, regardless of which type of access they require. For security purposes, change this option to private access for all procedures that do not require public access.
For more information about procedures, see Procedures and Administering namespaces and procedures.
The MPF Audit Log can be a valuable source of information about MPF transactions. Using Provisioning Manager, you can specify auditing methods to address a variety of requirements:
For multiple forests with different provisioning engines, you should not use the same MPFServiceAcct password for all forests. If you do use the same MPFServiceAcct password password, MPF duplicates objects across the forests. This is appropriate only if you are implementing a common provisioning engine for all domains.
For security reasons, we suggest that each password: