Policies Element
Author: Collin VanDyck
<policies>
The policies element contains individual policy elements that are one of the following:
- user-policy
- ad-security-group-policy
<user-policy>
This is the most common type of policy. It is not implementation specific, and only requires a LDAP-compliant directory. It queries a container, iterating over that container’s child objects, determining which objects are user objects to be imported into the CMS.
container-identifier is the DN of the container which contains the users to be queried as a part of this policy. Note that typically this will be an Organizational Unit (OU).
The object-attribute-filter allows the integrator to specify which objects inside of the container for the policy are actual user objects. For each object-attribute-filter specified, each child of the container must have the attribute and value match for that child to be considered a user.
These are the names of the attributes for each user that contain the username, email, and full name of the user, respectively.
If the user, once brought into Cascade Server, should as a part of the log in process authenticate against the LDAP server.
<enable-new-users>yes</enable-new-users>
Should each user migrated from the LDAP installation be enabled by default? If one is not authenticating against the LDAP server, this should be no to allow for the manual setting of that user’s password from the web based administration tool.
The system-groups element specifies for each user migrated in to what groups that user should belong. Note that the attribute remove-from-other-groups=”yes” will instruct the migration tool to remove the user from any groups not included as children of this element.
Each group element should have a name element that specifies the name of the group. If one wishes to auto-create groups that do not already belong in the system, then the create-if-does-not-exist should be specified for that group. The create-if-does-not-exist should contain at least one or more role elements, which will be used to assign role(s) to the newly created group.
The system-roles element specifies for each user migrated in to what roles that user should belong. Note that the attribute remove-from-other-roles=”yes” will instruct the migration tool to remove the user from any roles not included as children of this element. At least one role should be specified.
</user-policy>
Additional User Policy Option
Each LDAP-created user, at migration time, needs some key pieces of information:
- email address
- full name
- username
- fully qualified distinguished name (FQDN)
The FQDN will usually look something like:
CN=FirstName LastName,OU=Employees,DN=company,DN=com
The user-policy configuration element supports the following sub-element in the event distinguishedName is not present or does not represent the FQDN for that user:
If the user-dn element is not specified, the user-policy will default to the standard method of using the distinguishedName attribute to gather the FQDN for that particular user. If it is specified, then it will attempt to read the value of attribute-name when migrating the user. The value of the attribute is basis of the new FQDN for this user.
If the use-name-value-pair is true, then the FQDN will look something like:
fullName=FirstName LastName
If the prepend-to-container-identifier element is true, then the FQDN will look something like:
fullName=FirstName LastName,OU=Employees,DN=company,DN=com
For most cases, use-name-value-pair and prepend-to-container-identifier should both be set to "true" if the custom user-dn rules are specified.
Wildcard filtering capability for LDAP User Policies
To enable a user policy to select user objects located inside a base container on an LDAP installation:
Typically this is done by specifying multiple <object-attribute-filter> elements:
For the base container for this user-policy, these two object attribute filters have this effect:
Select all objects under the base container that have the attribute value pairs:
objectclass=person
and
department=Marketing
This method is meant for less complex LDAP installations. For those requiring more complex queries and wildcard filtering, in place of object-attribute-filter elements, one may specify a single <freeform-filter> element:
<freeform-filter>(&(objectclass=person)(department=Mark*))</freeform-filter>
This would match all objects under the base container that have the attribute objectclass=person and any department that starts with Mark (Marketing, Marker Production, etc).
Note: You may not have both a freeform-filter and any object-attribute-filter element
Note: The '&' symbol that is used to denote a logical “AND” should be escaped as “&”; because of the XML nature of the configuration file.
<ad-security-group-policy>
This is only applicable for Active Directory installs. It queries a Security Group object in the system, and from that Security Group’s attributes determines the DNs of the members of that Security Group. Each of those users, then, are queried and brought into the CMS.
The security-group-id is the DN of the Security Group object within the Active Directory install.
<group-member-attribute-id>member</group-member-attribute-id>
The security group identified by the security-group-id will be queried to get a list of its members. This is done by getting a list of all of the attributes of that Security Group that have a specific name. This name is specified by the group-member-attribute-id.
Getting this set of values from the Security Group results in a collection of user DNs. These DNs are then queried in a similar fashion to that of the user-policy. To that effect, the options below are handled in a similar manner to that of the user-policy.