立即与支持人员聊天
与支持团队交流

Active Roles 7.5.4 - Solutions Guide

Active Roles Solutions Overview ERFM Solution Configuration Transfer Wizard Solution Active Roles SPML Provider Skype for Business Server Solution
Introducing Skype for Business Server User Management Supported Active Directory topologies User Management policy Master Account Management policy Access Templates for Skype for Business Server Deploying the Solution Managing Skype for Business Server Users
Management Pack for SCOM

Configuration settings in sample.config

Support for configuration options enables administrators to set the SPML Provider sample client configuration in order to test the SPML Provider functionality under actual conditions. Administrators can, for example, specify the desired settings for the sample container object (OU) that will be used in sample SPML v.2 operations.

The configuration settings of the SPML Provider sample client can be found in the sample.config file located in the Samples sub-folder of the SPML Provider installation folder.

The sample.config file contains data in the XML format. You can open and edit the configuration file with a common text editor such as Notepad. The default configuration settings in the sample.config file look as follows:

<samples>

<server>localhost</server>

<url>ARServerSPML/spmlprovider.asmx</url>

<sampleContainerName>OU=MyOU,DC=Company,DC=com</sampleContainerName>

</samples>

The following table provides reference information for XML elements used in the sample.config. file.

Table 14: XML elements used in the sample.config. file

Element

Parent element

Description

server

samples

Specifies the name of the computer running SPML Provider.

url

samples

Specifies Web address of SPML Provider. The default address is ARServerSPML/spmlprovider.asmx.

sampleContainerName

samples

Specifies the distinguished name of the container (OU) used in the sample SPML v.2 requests.

Core Operation samples

The following table lists all examples included in the Core Operation samples.

 

Table 15: Core operation samples

Operation

Description

List targets available for provisioning with SPML Provider

This example illustrates how to retrieve the targets available for provisioning with SPML Provider.

To do this, SPML Provider performs the listTargets operation.

The request message includes the following XML elements:

  • The <soap:Envelope> and <soap:Body> SOAP elements enclose the SPML payload.
  • The <listTargetsRequest> element asks SPML Provider to declare the set of targets that SPML Provider exposes for provisioning operations.

The response lists the supported targets, including the schema definitions for each target and the set of capabilities that SPML Provider supports for each target. The contents of the <listTargetsResponse> element conform to the OASIS SPML v2 specification.

Create new user

Create new user (using direct access mode)

These examples illustrate how to create a user account object in two operation modes.

To create a new object, SPML Provider performs the add operation.

The request message includes the following XML elements:

  • The <soap:Envelope> and <soap:Body> SOAP elements enclose the SPML payload.
  • The <addRequest> element asks SPML Provider to create a new object.
  • The <containerID> element specifies the distinguished name of the container in which to create the new object.
  • The <data> element encloses the elements that specify attribute values on the new object. Thus, in accordance with the objectClass attribute value, SPML Provider is requested to create a user account.

The operation response indicates whether the user account is successfully created.

Note that in direct access mode, to provision a user account, you should complete the following steps:

  • Issue a request to create a new user account (see above).
  • Issue a request to set the user password (see “Set user password” in “Password capability samples,” later in this document).
  • Issue a request to enable the user account (see “Resume user account” in "Suspend capability samples,” later in this document).

Create new user (approval aware)

This example illustrates how to create a user account if this operation is subject to approval by designated approvers. For more information about approval activities and workflows, refer to Active Roles Help and Active Roles SDK.

If the creation of user is subject to approval, to perform the operation, your SPML request must contain the AllowApproval built-in control. For information about how to use controls in SPML requests, see Support for Active Roles controls earlier in this document.

To create a new object, SPML Provider performs the add operation.

The request message includes the following XML elements:

  • The <soap:Envelope> and <soap:Body> SOAP elements enclose the SPML payload.
  • The <addRequest> element asks SPML Provider to create a new object.
  • The <controls> element includes the child element <control> that sets the AllowApproval control to the Confirm value.
  • The <controlsForOutput> element includes the child element <control>, which specifies that the OperationStatus control will be returned with the SPML response.
  • The <containerID> element specifies the distinguished name of the container in which to create the new object.
  • The <data> element encloses the elements that specify attribute values on the new object. Thus, in accordance with the objectClass attribute value, SPML Provider is requested to create a user account.

The operation response contains the OperationStatus control value that indicates the creation operation status. For example, if the user creation operation is subject to approval, the OperationStatus control returns the Pending value. In this case, the operation is waiting for approval by designated approvers. For more information about possible values of the OperationStatus control, see Active Roles SDK.

Create a user whose logon name is not in compliance with Active Roles policies

This example illustrates an attempt to create a new user account whose logon name does not conform to the Active Roles policies.

Because the user logon name does not conform to the Active Roles policies, the creation operation fails and the operation response includes an error message returned by Active Roles. For example, an attempt to set the sAMAccountName attribute to a string of more than 20 characters causes the user creation operation to fail, with the response containing a message that provides some details on the error condition.

Create new group

This example illustrates how to create the group object SPMLGroup in the mycompany.com domain.

To create a new object, SPML Provider performs the add operation.

The request message includes the following XML elements:

  • The <soap:Envelope> and <soap:Body> SOAP elements enclose the SPML payload.
  • The <addRequest> element asks SPML Provider to create a new object.
  • The <psoID> element specifies the distinguished name of the object to be created.
  • The <data> element encloses the elements that specify attribute values on the new object. Thus, in accordance with the objectClass attribute value, SPML Provider is requested to create a group object.

Modify user attributes

This example illustrates how to modify the description attribute of the John Smith user object in the mycompany.com domain.

To modify the object attribute, SPML Provider performs the modify operation.

The request message includes the following XML elements:

  • The <soap:Envelope> and <soap:Body> SOAP elements enclose the SPML payload.
  • The <modifyRequest> element asks SPML Provider to make changes to a specified object.
  • The <psoID> element specifies the distinguished name of the user account to be modified.
  • The <modification> element specifies the type of change as replace, causing the new values to replace the existing attribute values.
  • The <data> element encloses the elements that specify the new attribute values.

Modify Shared mailbox user permissions

Modify or replace the edsaUserMailboxSecurityDescriptorSddl attribute of the Shared mailbox object.

To modify the object attribute, SPML Provider performs the modify operation.

The request message includes the following XML elements:

  • The <soap:Envelope> and <soap:Body> SOAP elements enclose the SPML payload.
  • The <modifyRequest> element asks SPML Provider to make changes to a specified object.
  • The <psoID> element specifies the distinguished name of the user account to be modified.
  • The <modification> element specifies the type of change as replace, causing the new values to replace the existing attribute values.
  • The <data> element encloses the elements that specify the new attribute values, in SDDL format along with the SID of the user specified.

For example, see Sample request to modify Shared mailbox user permissions.

Add user to group

This example illustrates how to add the John Smith user account to the SPMLGroup group object in the mycompany.com domain.

To do this, SPML Provider preforms the modify operation.

  • The request message includes the following XML elements:
  • The <soap:Envelope> and <soap:Body> SOAP elements enclose the SPML payload.
  • The <modifyRequest> element asks SPML Provider to make changes to a specified object.
  • The <psoID> element specifies the distinguished name of the group object to be modified.
  • The <modification> element specifies the type of change as add, causing the new values to be appended to the existing attribute values.
  • The <data> element encloses the elements that specify the distinguished name of the user account to be appended to the existing values of the member attribute.

Look up user attributes

This example illustrates how to get the XML representation of the John Smith userin the mycompany.com domain.

To get the XML representation of an object, SPML Provider performs the lookup operation.

The request message includes the following XML elements:

  • The <soap:Envelope> and <soap:Body> SOAP elements enclose the SPML payload.
  • The <lookupRequest> element asks SPML Provider to return the XML document that represents a specified object.
  • The <psoID> element specifies the distinguished name of the object.

The response contains the object identifier, the XML representation of the object and its attributes, and information about SPML Provider capabilities that are supported on the object (the capability-specific data that is associated with the object).

Delete user

This example illustrates how to delete the John Smith user account.

To do this, SPML Provider performs the delete operation.

The request message includes the following XML elements:

  • The <soap:Envelope> and <soap:Body> SOAP elements enclose the SPML payload.
  • The <deleteRequest> element asks SPML Provider to delete a specified object.
  • The <psoID> element specifies the distinguished name of the user account to delete.

Delete group

This example illustrates how to delete the SPMLGroup group object in the mycompany.com domain.

To do this, SPML Provider performs the delete operation.

The request message includes the following XML elements:

  • The <soap:Envelope> and <soap:Body> SOAP elements enclose the SPML payload.
  • The <deleteRequest> element asks SPML Provider to delete a specified object.
  • The <psoID> element specifies the distinguished name of the group object to delete.

Sample request to modify Shared mailbox user permissions

Sample request to modify Shared mailbox user permissions

This section provides a sample request that illustrate how to use Active Roles controls in your SPML requests to modify Shared mailbox user permissions.

Sample request to modify Shared mailbox user permissions

<?xml version="1.0"?>

<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Body>

<spml:modifyRequest xmlns:spml="urn:oasis:names:tc:SPML:2:0">

<spml:psoID ID="CN=shmb1,OU=NOV_OU,DC=ars,DC=cork,DC=lab,DC=local"/>

<spml:modification>

<modification name="edsaUserMailboxSecurityDescriptorSddl" operation="replace" xmlns="urn:oasis:names:tc:DSML:2:0:core">

<value>O:PSG:PSD:AI(A;CI;RC;;;S-1-5-21-2064067869-2662360268-1970296196-3772)(A;CI;RC;;;S-1-5-21-2064067869-2662360268-1970296196-3773)

</value>

</modification>

</spml:modification>

</spml:modifyRequest>

</soap:Body>

</soap:Envelope>

 

Capability samples

The following tables list all examples included in the Capability samples, grouped by Capability.

Search Capability samples
Table 16: Search Capability samples

Operation

Description

Perform one-level search

This example illustrates how to obtain a list of the child objects (direct descendants) of the Active Directory container object. In proxy mode, you can use this example to list the domains that are registered with Active Roles (managed domains).

To do this, SPML Provider performs the search operation.

The request message includes the following XML elements:

  • The <soap:Envelope> and <soap:Body> SOAP elements enclose the SPML payload.
  • The <searchRequest> element asks SPML Provider to perform a search and return the identifiers of the objects found.
  • The <query> element determines that SPML Provider is to perform a one-level search (that is, to search only direct descendants of the object specified by <basePsoID>).
  • The <basePsoID> element specifies the distinguished name of the container object to search.

The response contains the identifiers (distinguished names) of the objects residing in the container object specified by the <basePsoID> element.

Perform subtree search

This example illustrates how to obtain a list of objects that reside below the Active Directory object in the directory tree. You can use this example to list the objects that reside in a given domain.

To do this, SPML Provider performs the search operation.

The request message includes the following XML elements:

  • The <soap:Envelope> and <soap:Body> SOAP elements enclose the SPML payload.
  • The <searchRequest> element asks SPML Provider to perform a search and return the identifiers of the objects found.
  • The <query> element determines that SPML Provider is to perform a subtree search (that is, to search any direct or indirect descendant of the object specified by <basePsoID>).
  • The <basePsoID> element specifies the distinguished name of the container object to search. For instance, this could be the distinguished name of a domain that is registered with Active Roles (managed domain).

The response contains the identifiers (distinguished names) of the objects that reside in the directory tree below the container object specified by the <basePsoID> element.

Perform base search

This example illustrates how to obtain an XML representation of the specific object.

To do this, SPML Provider performs the search operation.

The request message includes the following XML elements:

  • The <soap:Envelope> and <soap:Body> SOAP elements enclose the SPML payload.
  • The <searchRequest> element asks SPML Provider to perform a search and return the XML representation of the object found.
  • The <query> element determines that SPML Provider is to perform a base search (that is, to search only the object identified by <basePsoID>).
  • The <basePsoID> element specifies the distinguished name of the object to search. For instance, this could be the distinguished name of a user account.

The response contains the identifier of the object and the XML representation of the object (as defined in the schema of the target).

Iterate search results

This example illustrates how to obtain the next set of objects from the result set that SPML Provider selected for a search operation.

In this case, SPML Provider performs the iterate operation.

The request message includes the following XML elements:

  • The <soap:Envelope> and <soap:Body> SOAP elements enclose the SPML payload.
  • The <iterateRequest> element asks SPML Provider to return additional objects that matched a previous search request but that the Provider has not yet returned to the client.
  • The <iterator> element supplies the iterator ID found either in the original search response or in a subsequent iterate response.

Stop iterating search results

This example illustrates how to tell SPML Provider that the client has no further need for the search results that a specific iterator represents.

In this case, SPML Provider performs the closeIterator operation.

The request message includes the following XML elements:

  • The <soap:Envelope> and <soap:Body> SOAP elements enclose the SPML payload.
  • The <closeIteratorRequest> element tells SPML Provider that the client no longer intends to iterate search results.
  • The <iterator> element specifies the ID of the iterator to close. This could be the iterator ID found in the original search response or in a subsequent iterate response.

Find inactive users

This example illustrates how to get a list of inactive (disabled or deprovisioned) user accounts found within a specified container.

To do this, SPML Provider performs the search operation.

The request message includes the following XML elements:

  • The <soap:Envelope> and <soap:Body> SOAP elements enclose the SPML payload.
  • The <searchRequest> element asks SPML Provider to perform a search and return the identifiers of the objects found.
  • The <query> element determines SPML Provider is to perform a subtree search.
  • The <basePsoID> element specifies the distinguished name of the container object to search. For instance, this could be the distinguished name of a certain organizational unit.
  • The <filter> element encloses the elements that direct SPML Provider to search for inactive user accounts. Thus, the <equalityMatch> elements are configured so as to limit the search to user accounts; the <isActive> element combined with the <not> element causes SPML Provider to select the user accounts that are inactive.
  • The response contains the identifiers (distinguished names) of the inactive user accounts that exist in the directory tree below the container object specified by the <basePsoID> element.

Perform complex search

This example illustrates how to have SPML Provider find all objects that meet certain search criteria and return the values of certain attributes of the objects found.

In this case, SPML Provider performs the search operation.

The request message includes the following XML elements:

  • The <soap:Envelope> and <soap:Body> SOAP elements enclose the SPML payload.
  • The <searchRequest> element asks SPML Provider to perform a search and return the identifiers and attribute values of the objects found.
  • The <query> element determines the scope of the search.
  • The <basePsoID> element specifies the distinguished name of the container object to search. For instance, this could be the distinguished name of a certain organizational unit.
  • The <filter> element encloses the elements that specify the search criteria.
  • The <attributes> element specifies the object attributes to be included in the response.

The response contains the identifiers (distinguished names) of the objects found and, for each object, the values of the attributes specified by the <attributes> element in the search request.

Find only security groups

This example illustrates how to obtain a list of security groups found in a specified container.

In this case, SPML Provider performs the search operation.

The request message includes the following XML elements:

  • The <soap:Envelope> and <soap:Body> SOAP elements enclose the SPML payload.
  • The <searchRequest> element asks SPML Provider to perform a search and return the identifiers of the objects found.
  • The <query> element determines that SPML Provider is to perform a subtree search.
  • The <basePsoID> element specifies the distinguished name of the container object to search. For instance, this could be the distinguished name of a certain organizational unit.
  • The <filter> element encloses the elements that direct SPML Provider to search for security groups. Thus, the <equalityMatch> elements are configured so as to limit the search to group objects; the <extensibleMatch> element specifies a matching rule that is equivalent to the LDAP filter (groupType:1.2.840.113556.1.4.803:=2147483648) where 2147483648 is the decimal equivalent of the ADS_GROUP_TYPE_SECURITY_ENABLED flag (0x80000000).

The response contains the identifiers (distinguished names) of the security groups that exist in the directory tree below the container object specified by the <basePsoID> element.

Password Capability samples
Table 17: Password capability samples

Operation

Description

Set user password

This example illustrates how to set a new password for the specific user account.

To set a new password, SPML Provider performs the setPassword operation.

The request message includes the following XML elements:

  • The <soap:Envelope> and <soap:Body> SOAP elements enclose the SPML payload.
  • The <setPasswordRequest> element asks SPML Provider to change to a specified value the password that is associated with a certain user account.
  • The <psoID> element specifies the distinguished name of the user account.
  • The <password> element specifies the new password to assign to the user account.

Expire user password

This example illustrates how to force a given user to change the password at next logon.

To do this, SPML Provider performs the expirePassword operation.

The request message includes the following XML elements:

  • The <soap:Envelope> and <soap:Body> SOAP elements enclose the SPML payload.
  • The <expirePasswordRequest> element asks SPML Provider to mark expired the current password that is associated with a certain user account. The remainingLogins attribute is set to 1 so as to disallow grace logons once the expirePassword operation is completed, forcing the user to change the password at next logon.
  • The <psoID> element specifies the distinguished name of the user account.
Suspend Capability samples
Table 18: Suspend capability samples

Operation

Description

Suspend user account

This example illustrates how to either disable or deprovision a specified user account, depending on the SPML Provider configuration (see the description of the <suspendAction> element in the “Configuring SPML Provider” section earlier in this document).

To do this, SPML Provider performs the suspend operation.

The request message includes the following XML elements:

  • The <soap:Envelope> and <soap:Body> SOAP elements enclose the SPML payload.
  • The <suspendRequest> element asks SPML Provider to perform the suspend action on a certain user account (either disable or deprovision, depending on the configuration of SPML Provider).
  • The <psoID> element specifies the distinguished name of the user account to suspend.

Resume user account

This example illustrates how to enable a disabled user account. This operation requires that the suspend action be set to disable in the SPML Provider configuration file (see the description of the <suspendAction> element in the “Configuring SPML Provider” section earlier in this document).

In this case, SPML Provider performs the resume operation in order to enable a disabled user account.

The request message includes the following XML elements:

  • The <soap:Envelope> and <soap:Body> SOAP elements enclose the SPML payload.
  • The <resumeRequest> element asks SPML Provider to re-enable a user account that has been disabled.
  • The <psoID> element specifies the distinguished name of the user account to re-enable.

Check whether user is active

This example illustrates how to determine whether a specified user account is active, that is, has not been suspended. A user account is considered to be suspended if the suspend action was performed on that account. The suspend action can be either disable or deprovision, depending on the SPML Provider configuration (see the description of the <suspendAction> element in the “Configuring SPML Provider” section earlier in this document).

The request message includes the following XML elements:

  • The <soap:Envelope> and <soap:Body> SOAP elements enclose the SPML payload.
  • The <activeRequest> element asks SPML Provider to check whether the suspend action has been performed on a given user account (either disable or deprovision, depending on the SPML Provider configuration).
  • The <psoID> element specifies the distinguished name of the user account to check.

The <activeResponse> element in the response message has the active attribute that indicates whether the specified user account is suspended. If the user account is suspended, the active attribute is set to false. Otherwise, the active attribute is set to true.

相关文档

The document was helpful.

选择评级

I easily found the information I needed.

选择评级