About the My-Company Sample Domain

Open the My-Company subtree to see the organizational units that My-Company contains. In the sample domain scenario, organizational units are designed as tree objects. Also check the content and structure of the departments that are either lower-level organizational units or user entries. The organizational units are:

Three companies act as suppliers for My-Company:

Three re-seller companies are My-Company’s customers:

Click a user in one of My-Company’s departments. You’ll see two rows of tabs that group different user properties and attributes according to their functions. These tabs and fields represent the default user definition for the My-Company sample domain. This user definition has been designed to provide a comprehensive set of user properties and attributes that you are, with some exceptions, allowed to change or even remove from the user definition if they do not meet your needs.

The default user definition is modeled as a set of object descriptions in XML. The definitions of user properties and attributes that you are not allowed to modify or delete can be found in the Domain Configuration view at My-Company → Object Descriptions → User.xml. If you go to Domain Configuration → My-Company → Customer Extensions → Object Descriptions, you will find two default object description files: UserCommon.xml and User.xml. As delivered with DirX Identity, User.xml is empty and is intended for your use. UserCommon.xml contains the sample set of user properties and attributes that you can modify or delete as necessary. You can also use the object description paradigm to create your own custom user object descriptions. For example, you may want to define several different user types that display different properties and attributes depending on the type of user, such as "internal" user and "contractor". For more information about object descriptions and how to work with them, see the section on "Customizing Objects" in the DirX Identity Customization Guide.

The next sections briefly describe the user properties and attributes provided with the default user definition for the My-Company sample domain and gives some hints on what you can do with them. The context-sensitive help available on each tab (just click Help) provides complete details on each field.

Click the Companies node in the Business Objects tree. You can see subfolders for the My-Company company and its customer companies Mercato Aurum, MultiMarket and TakeAway . Business objects for the sample domain supplier companies (CompuTip, MediaComp and MicroWare) have not been structured into this part of the business objects tree. These company subfolders represent organization business object types.

The My-Company organization is populated with subfolders for its departments (Finances, Sales, and so on). These subfolders represent organizational unit business object types and demonstrate automatic privilege assignment to users via business object inheritance. For example, click on Finances, and then click the References tab. In the Privileges field, you can see that this business object is linked to the Finances Tasks role in the Corporate Role tree. To find this role, click Privileges → Roles → Corporate Roles→ Department Specific. The other department business objects are set up in a similar way: each department business object is linked to one or more roles that are relevant to this department, as follows:

Each My-Company user is linked to a "department" (organizational unit) business object and thus automatically inherits the role that is linked to this object. For example, go to Users → My-Company → Sales and then open Klarmann Bruno. Click the Organization tab. You can see that this user belongs to the organizational unit Sales. If you click the icon to the right of the Organizational Unit field, the Sales business object is displayed. Click the References tab, and you can see that the role Sales Tasks is linked to this business object. Click Close and then click the Assigned Roles tab. You can see Sales Tasks listed as an assigned role, and the Assigned by field indicates that the role has been assigned by a business object (BO).

If you change a user’s organizational unit, DirX Identity automatically unassigns the obsolete privileges and assigns the new ones that are relevant to his new organizational unit. For example, return to the Organization tab for Klarmann Bruno and then click the icon to the right of the Organization field. The Companies business object tree is displayed. Select Marketing to move the user to the Marketing organization, and then click Save. This action automatically removes the Sales Tasks role and assigns the Marketing Tasks role to the user. Conversely, if you change the privileges that are linked to a business object or make changes to the linked privileges themselves, all users linked to the business object will automatically be updated with the new privilege assignments and/or the updated privilege.

Note that changing a user’s organizational unit means changing his link to an OU business object in the Business Objects tree. Moving a user from one department to another in the Users tree has no effect; for example, if you move Klarmann Bruno from the Users → My-Company → Sales - > Sales Europe node to the Users → My-Company → Marketing node, he remains linked to the Sales department until you change this business object link. The sample domain has set up the My-Company User tree to mirror the structure of the Business Object tree, but any kind of Users tree structure is permissible. For example, you may want to create an "administrative area" structure, where users are grouped according to the administrator who is responsible for managing them.

While the Companies → My-Company "department" organizational unit business objects use only the privileges link, it is also possible to link business objects to other items, such as locations, cost units, categories, and contexts. If you want to create category or context objects, you must create them under the Custom node in the Business Object tree. For more information about business objects, see "Managing Business Objects" in the DirX Identity Provisioning Administration Guide.

Click the Countries node in the Business Objects tree. You can see subfolders for each country in which My-Company, its customers and its suppliers are located: CA (Canada), DE (Germany), ES (Spain), FR (France), GB (England), IT (Italy), US (USA). These subfolders represent country business object types. Each country subfolder in turn contains subfolders for company branch locations - for example, My-Company Paris (FR), My-Company Barcelona (ES), MediaComp Madrid (ES) and so on. These subfolders represent location business object types.

The objects in the Countries folder demonstrate the inheritance of business object data into user attributes and serve as samples for data inheritance. The business object is linked to the user object and masters the business data. If you change the business object linked to the user (because, for example, the user moves to a different branch office), the user data is automatically updated with the information from the currently linked business object. This update is performed immediately during the save operation. Likewise, if you change data at the business object (for example, the branch office street address), the change is propagated to all users linked to this object. This update runs in the background and can take some time to take effect, especially when the number of assigned users is high.

In the sample domain, each user is linked to a location business object and thus automatically inherits the location information in this object. For example, open Countries → DE → My-Company Munich and look at the postal code, street and address information there. Now go to Users → My-Company → Finances and open Abele Marc. Click the Location tab. You can see that this user belongs to My-Company Munich and has the same information in his postal code, street and postal address attributes. If you click the icon to the right of the Location field, the My-Company Munich business object is displayed showing this same information. Now click the icon to the right of the Location field. The Countries business object tree is displayed. Select My-Company Berlin and then click OK. Now you can see that Marc Abele’s postal code, street and postal address information has changed to reflect the My-Company Berlin location.

Note that if you save this change (by clicking Save), an approval workflow is automatically started. This action occurs because there is an attribute access policy for My-Company users that protects against changing locations and organizations without manager approval (you can read more about this policy in "Attribute Policies") and the domain-level flag to enable this type of workflow is set (see the "Request Workflow Parameters" section in "Domain Configuration" for details).

The My-Company sample domain also contains a sample JavaScript routine in its user object description that calculates the user’s country information from the value in his Location field (dxrLocationLink). So when a user’s location changes, his country information is updated automatically, too. To see the elements of this feature, go to Domain Configuration → My-Company → Customer Extensions → Object Descriptions. Click UserCommon.xml, and then scroll or search to the Locality tab definitions. Here you see the property definition for the country field (c). It uses the CountryFromLocation JavaScript, which you can find in Domain Configuration → My-Company → JavaScripts. The country information is stored in the Country proposal list, which you can find at Domain Configuration → My-Company → Customer Extensions → Proposal Lists. For more information on using JavaScripts and proposal lists in object descriptions, see the following sections in the DirX Identity Customization Guide:

Click the Projects node in the Business Objects tree. You can see three subfolders that correspond to the three optimization projects that My-Company runs:

These subfolders represent project business object types.My-Company’s project organization uses these business objects as the source for role parameters in user-project assignment: there is a Project role parameter that references these business objects, and there are Project Member and Project Manager roles that use this role parameter:

The sample domain illustrates how to use business objects to populate role parameter selections; you can also use them to build proposal lists.You can also associate a proposal list with a role parameter to create one list (using business objects or other objects as a source) that you can use for both role parameter selection and drop-down proposal lists.For more information on using business objects, see the section "Managing Business Objects" in the DirX Identity Provisioning Administration Guide.For more information about creating role parameters and proposal lists, see the section "Customizing Parameters" in the DirX Identity Customization Guide.

The Roles subtree is subdivided into a B2B Roles subtree and a Corporate Roles subtree.The B2B Roles subtree contains all roles for customers and suppliers, while the Corporate Roles subtree contains all roles for the My-Company employees and contractors.

There are six Customer roles: all customers are classified as Silver Customers.Some are Gold Customers and only a few are Platinum Customers.These classes determine the bonus program.Another set of roles defines the services a customer can subscribe to: Customer Newsletter, Hardware Beta Programs and Software Beta Programs.

Supplier roles include a Standard Class for each supplier and, for suppliers that perform very well, a First Class role.

The Corporate Roles subtree contains another six folders. A collection of all administrative roles makes up the Administration folder. The Department Specific roles folder contains all roles that define tasks for the various organizations in My-Company. The Project Specific roles folder collects all roles necessary for project management. The Physical Access folder contains all roles that pertain to granting access to secured computer rooms in several My-Company branches. The Self-Service folder contains all roles that users can assign themselves via user self-service subscription. All other roles are collected under the General folder. Within this folder is a very complex role - Cost Location Manager - that is part of a specific use case; to read more about this example, see the section "Policies for Hierarchical Role Parameters" in the DirX Identity Provisioning Administration Guide.

The sample domain’s privilege structure demonstrates how to group privileges so that access policies can easily be applied to them. For example, the Roles → Corporate Roles → Self Service folder contains all the roles that users can assign to themselves with Web Center self-service. Now go to Policies → Access Policies → My-Company → Grant Policies and then click on Self Service. This access policy controls which users (in this case, users with the employeeType "Internal") can assign to themselves these roles with self-service. If you click the Resources tab and look at the Resources filter values, you can see that the policy directs DirX Identity to apply this policy to the roles in the Roles → Corporate Roles → Self Service folder. If you subsequently add a new role to this folder, the Self Service access policy is automatically applied to it. If you look at the Resources field, you can see additional physical access roles listed here. As a result, the policy will be applied to these roles explicitly, but any new role added to the physical access folder will not have the policy applied to it. So the sample domain’s privilege structure shows, too, that you can keep privileges segregated from access policies and add them as necessary. You can read more about access policies in "Access Policies".

The sample domain also structures privileges that use role parameters into a separate tree; this is the Project Specific tree underneath Corporate Roles. You can read more about how role parameters are used in the My-Company sample domain in the section "Project Organization".

However, role managers are free to structure their privileges as they like. The My-Company domain is only an example of a privilege structure.

Now click a role, and then click the Assigned Permissions tab to view the attached permissions of the role. In the sample domain, the permissions are almost always symmetrical to the roles, which mean that each permission has exactly one corresponding role, with the following exceptions:

Click a role, and then click the Users tab to see who is assigned to the role.

The Signature Level 3 role provides another example of a role hierarchy. Click this role in the General folder. It contains the Signature Level 2 role as a junior role (click the Assigned Junior Roles tab). This means that an assignment of the Signature Level 3 role includes the automatic assignment of the Signature Level 2 role. You can also see that the Signature Level 2 role is used by a senior role if you click the Senior Roles tab.

The roles in the Physical Access folder are examples of roles that are designed to be assigned manually. The follow-on tutorial "Using Manual Provisioning" demonstrates the use case for these roles. They are also examples of roles that are assigned via provisioning rules; which are described in more detail in the section on "Rules".

In this example, the following roles are set to Requires approval:

Click the Manager role, and then click the Approvals tab. Here you can see that the Manager Nomination workflow has been directly assigned to process the approval of assignments of this role to users. This is an example of direct workflow selection, where the workflow is directly linked to the privilege. The Project Manager role also has a direct assignment to the Manager Nomination approval workflow.

Click the icon to the right of the Assignment field to display the Manager Nomination workflow. Now double-click the Approval by Company Head activity icon and then click the Participants tab. Here you can see that the general manager Olivier Hungs and his secretary Gabriela Morton have been explicitly specified as approvers (only one must approve). This is an example of a static participant definition. For more information about participant calculation, including how to use variable substitution and user attributes to create dynamic approval definitions, see the subsection "Participant Calculation" in the path "Understanding Request Workflows" →"Customizing Request Workflows" → "Using Variable Substitution" in the DirX Identity Application Development Guide.

The other roles that require approval do not use direct workflow assignment. Instead, they use rule-based workflow selection and configure the "When Applicable" rules in the My-Company approval workflow definitions so that DirX Identity’s dynamic workflow selection algorithm always selects the 4-Eye Approval workflow to process approvals for these roles. For example, go to the My-Company workflow definitions (Workflows → Workflows → Definitions → My-Company → Approval). Open the 4-Eye Approval workflow and then look at it is When Applicable tab. The Priority parameter is set to a high number so that the selection algorithm will choose it first. If you look at the When Applicable tab of the other workflows - for example, the Manager Nomination workflow - you can see that the priorities are set very low to prevent them from being selected. The 4-Eye Approval workflow works with approval policies to retrieve the manager of the user (the subject) and the owner of the privilege as approvers. Both of these users must approve the assignment.

You can read more about DirX Identity’s assignment workflow selection mechanisms, the 4-Eye Approval workflow, and approval policies in the following places:

The Permissions subtree is subdivided into the same folders as the role subtree. It contains a B2B Permissions subtree and a Corporate Permissions subtree. The B2B Permissions subtree contains all permissions for customers and suppliers, while the Corporate Permissions subtree contains all permissions for the My-Company employees and contractors.

Click a permission, and then click the Assigned Groups tab to view the attached groups. Most of the permissions use groups in a direct relationship, but some permissions use match rules to select some of the attached groups:

Approval for the corporate permissions follows the same configuration as for the corporate roles; see the "Roles" section for more information.

The Groups folder in the Privileges view is a virtual view of the group folders in the target systems in the Target Systems view (see the "Target Systems" section for details).The folder is structured according to target system, and is displayed in the Privileges view to provide a single view of the privileges contained in a domain.

Access policies control self-service and delegated administrative access to DirX Identity’s resources (user and privilege data). An access policy defines a set of access rights to almost any object.

There are two types of access policies: the type that restricts operations on specific objects - for example, "modify user" - and the type that restricts access to specific Web Center menus and menu items. To be able to work on an object, you must have the right to view and use the menu item that relates to managing the object and you must be allowed to manage the object; both of these access policy types must be set up correctly. For example, you can have the right to use the "modify user" menu, but if you are not allowed to manage any users, your rights to the menu are meaningless. Conversely, you can have the right to modify ten users, but if you are not allowed to use the "modify user" menu, you cannot search for these users.

In the Policies view, click the Access Policies node in the tree. You can see three subtrees:

My-Company Approval Policies

The policies in Approval Policies are copies of the DirX Identity default policies for approvals that have been activated for use (the Is active flag is set). These policies are explained in more detail in the "Approval Policies" section in "Request Workflows".

My-Company Create Policies

The Create Policies folder contains one access policy - Managers create roles - which allows all department managers - that is, all users that are members of the allDepartmentManagers group - to create new corporate roles. Open the policy. In the Operations and Object Type part of the General tab, you can see that the create operation is checked and that the object to be created is a role (dxrRole). Click the Subjects tab. The Group of Persons field specifies the group name allDepartmentManagers, which is defined in Target Systems → DirXmetaRole → Groups → Templates. If you go to this location and open the group, and then click the Members tab, you can see the users in the sample domain that are assigned to this group. In Policies → Create Policies, open the policy again, and then click the Resources tab. You can see that it is set up to look for roles in the path Privileges → Roles → Corporate Roles (the notation in the field gives the LDAP directory path to the node in the role tree).

My-Company Grant Policies

The Grant Policies folder supplies the following access policies:

My-Company Menu Policies

The My-Company menu access policies control the selections on the Web Center main menu bar (Self-Service, Delegation, Work List and so on) that are available to different categories of My-Company users. These policies are:

The access rights granted to a particular user are thus an aggregation of the different access policies: for example, a "normal" user has basic rights, a user in the HR department has additional rights, and a manager in the HR department has further rights.

These policies have been activated for the My Company domain (the Enable menu policies flag is checked in Domain Configuration → My-Company → Policies).

My-Company Password Policies

The My-Company password access policies control who can set and read user and target system account passwords. These policies are:

The setPassword operation means that the user can create and change the password, and the readPassword operation means that the user can see the value of the password if it is displayed in Web Center. The readPassword operation is intended for use with passwords of privileged accounts, which are functional accounts like "root" in a UNIX target system or "Administrator" in a Windows target system and are typically assigned to multiple users: When one user is removed from a privileged account, DirX Identity automatically changes the password and then propagates the new password to the target system. The other users who are still assigned to the account must then be able to look up and read the new password. The readPassword operation is intended for this use case when the sample domain configuration parameter Enable privileged accounts is set (see the Privilege Resolution tab at the domain). You can read more about privileged accounts in "Managing Target Systems" → "Managing Target System Accounts" → "Managing Privileged Accounts" in the DirX Identity Provisioning Administration Guide.

My-Company Read and Modify Policies

The access policies in the Read and Modify Policies folder are:

My-Company Report Policies

The My-Company report access policies control who can run reports; they affect the reports that are available to different categories of users in Web Center. These policies are:

My-Company Request Workflow Policies

The My-Company request workflow access policies control the management and use of request workflows in the Workflows → Definitions → My-Company request workflow tree. These policies are:

My-Company View Assignment Policies

View assignment policies allow you to control the visibility of privilege assignments and accounts and so hide sensitive information. To activate this feature, you must set the Enable view policies flag in Domain Configuration → My-Company → Policies. If this flag is enabled, users can see by default all assignments of privileges.

My-Company view assignment access policies control the privilege assignments and accounts that are visible in Web Center to different categories of users in the sample domain. The policies provided here are activated, but the feature must be enabled at the domain level (by checking the Enable view policies flag in Domain Configuration → My-Company → Policies) for the policies to take effect.

The following sample policies exist for the sample domain:

Be aware that using view assignment access policies can result in a user being unable to view any privileges or accounts. When implementing this feature, it is a good idea to create a view assignment access policy that gives an administrator the right to view all assignments and accounts. For more information on policies for viewing assignments, see the DirX Identity Provisioning Administration Guide.

An attribute policy is a type of object policy that is used to track and control changes to specific attributes of specific object types. Click the Attribute Policies node in the Policies tree view. You can see two subtrees: Default and My-Company.

The Default subtree contains the set of sample attribute policies provided with DirX Identity for specific object types like business objects, accounts, groups, and so on. These policies can be applied to any domain.

The My-Company subtree contains one attribute policy: User - Location and Organization - that applies to the sample domain. Click it to display its properties. In the General tab, you can see that the policy is activated and an approval workflow Modify Location and Organization is selected. The purpose of this attribute policy is to prohibit unauthorized changes to a My-Company user’s organization and location values; these values are links to organizational unit and location business objects described in the "Business Objects" section. If you click the Configuration tab, you can see that the policy applies to the user object type (dxrUser is selected) and controls two user attributes (dxroulink and dxrlocationlink). As a result, any time a user’s organizational unit link (dxroulink in the policy’s Configuration tab; the value assigned to a user’s Organizational Unit property in the Users view) or its location link (dxrlocationlink in the policy’s Configuration tab; the value assigned to a user’s Location property in the Users view) is changed, the Modify Location and Organization approval workflow automatically starts to require approval of the change if the attribute modification approval flag is set at the domain level (see the "Request Workflow Parameters" section in "Domain Configuration").

You can add your own attribute policies; for example, you could add an attribute policy that protects a user’s manager attribute against unauthorized change. To set up and enable an attribute policy:

Because the overhead of attribute policy execution can affect your identity system’s performance and introduce a lot of complexity, we recommend that you protect only the most sensitive attributes in your environment from unauthorized changes. For more information on setting up attribute policies, see the subsection "Managing Attribute Policies" in the section "Managing Object Policies" in the DirX Identity Provisioning Administration Guide.

A delete policy is a type of object policy that is used to track and control the deletion of a selected set of object types. The Delete Policies folder contains a default delete policy and a My-Company delete policy. Click the My-Company delete policy. It is identical to the default delete policy, but it has been activated (the Is active flag is checked). This delete policy protects roles and users in the sample domain from being deleted without approval. Click the policy, and then click the Configuration tab. You can see the dxrRole and dxrUser object types are listed in the OD Names column. When a user or role is deleted, this policy ensures that an approval workflow is automatically started for approval of the deletion. For more information on delete policies, see the subsection "Managing Delete Policies" in the section "Managing Object Policies" in the DirX Identity Provisioning Administration Guide.

An event policy is a type of object policy that is used to track the creation of and changes to a selected set of object types. The Event Policies folder contains a default event policy and a My-Company event policy. Click the My-Company event policy. It is identical to the default event policy, but it has been activated (the Is active flag is checked). In this event policy, organizations, organizational units, users, and accounts in the sample domain have been flagged for event monitoring (context objects are also included in the policy for completeness, but are not activated for event monitoring). If you click the Configuration tab and look at the OD Name column, you can see the object description names. As a result, a change to any object with one of these selected types or a creation of a new object of one of these types triggers an event-based workflow that stores information about the creation or change event for compliance purposes (in this list, you can see that the context object type dxrContext is set to false; which deactivates it from being monitored).

Note that because a single event policy allows you to specify all the object types you want to track for events, you only need to have one event policy for a domain. For more information on event policies, see the subsection "Managing Event Policies" in the section "Managing Object Policies" in the DirX Identity Provisioning Administration Guide.

The Password Policies folder keeps all the password policies that pertain to My-Company. The following password policies exist:

Note that all of these password policies have the maximum number of characters set to 8. This setting is necessary for a centralized password scenario to accommodate target systems that cannot handle longer passwords (for example, a target system running UNIX).

Rules use operations. The Operations folder in the Policies view contains the set of standard operations supplied with DirX Identity. The My-Company rules use these standard operations (there are no special operations defined for the sample domain). You can read more about operations in the section "Managing Consistency Rules" in the DirX Identity Provisioning Administration Guide.

DirX Identity supports the following rule types:

In the Policies view, open the Rules folder. The Default folder contains the default set of consistency and validation rules supplied with DirX Identity that are applicable to any domain to satisfy a variety of different use cases. The My-Company folder contains additional rules that apply only to the sample domain. In this folder, you can see two subtrees: Consistency and Role based scenario. The next sections describe the rules in these subtrees in more detail. To read more about rules and how to use them, see "Managing Rules" in the DirX Identity Provisioning Administration Guide.

My-Company Consistency Rules

The My-Company sample domain provides the following additional consistency rules:

My-Company Role-Based Scenario Rules

If we look at Role based scenario, we can see that it consists of a set of B2B and a set of corporate provisioning rules. Some examples are:

Open the SoD Policies folder.It shows segregation of duty policies.(Some people use the term "separation of duty" instead.) The Default folder shows policies that can be relevant for any customer domain, while the My-Company folder shows the policies that are only relevant for the sample domain.

Open the My-Company folder.Here you can see the SoD policies that can be used for the sample domain.For example, the SoD policy Contractor <> Manager specifies that My-Company contractors cannot be managers; that is, a user with the Contractor privilege cannot also have the Manager privilege.Should someone assign a conflicting privilege to a user, DirX Identity runs an SoD mitigation workflow that automatically notifies specific users (called "participants") about the SoD violation; these users may override the violation if necessary; DirX Identity will not assign the privilege unless the violation is specifically overridden.In the case of the Contractor <> Manager conflict, two company heads - Olivier Hungs and Gabriela Morton - are notified of the violation.One of these users must approve or reject the privilege assignment.Violations to a policy are stored below the policy in this subtree and in the user entry (see the SoD Exceptions tab).For a demonstration of the SoD process, see the follow-on tutorial "Applying SoD Policies".

To use the sample SoD policies, you will need to activate them individually (check each policy’s Is active flag) and then check the Segregation of Duty (SoD) checks flag at the domain.You can read more about SoD policies and how to create them in the section "Managing SoD Policies" in the DirX Identity Provisioning Administration Guide.

The Status Reports tree is designed to provide a single (virtual) point of view for distributed status reports.Open the folder.You can see two folders: Default and Customer Specific.

Open the Default folder.This folder contains the central report definitions that you can also find in Domain Configuration → Reports.Now open Target System Specific.This folder is organized into target system-specific subfolders; each one contains the relevant Report folder for the target system, which contains the reports that are valid for this type of target system.For example, the folder Default → Target System Specific → Boston Workstation → Reports can be found under Domain Configuration → Target Systems → Boston Workstation → Reports.It contains the valid reports for the Boston Workstation target system type.

The reports in the Default folder and its subfolders are defaults that you can use, but do not modify them here because your changes will be overwritten with DirX Identity upgrades.

Now open the Customer Specific folder. This folder refers to Domain Configuration → Customer Extensions → Reports and is the location at which you can set up your own reports. To create reports for your domain, examine the status reports in the Default folder, copy the ones that apply to your environment into a separate domain-specific folder that you create in the Customer Specific subtree, and then change them to your requirements. For information on how to customize the default status reports, see the subsection "Customizing Status Reports" in "Customizing Auditing" in the DirX Identity Customization Guide. There are no sample domain-specific reports, but there are a lot of default reports that you can use.

Under the Customer Specific subtree, you can see a Target System Instances folder. If you open it, you can see a list of target system-specific folders that correspond to the sample target system types provided with the sample domain (see the "Target Systems" section for more information). You can use these subfolders to create reports for a specific target system in your domain: copy a default report for a target system type to the corresponding target system instance folder in your domain-specific part of the tree, and then modify it to your requirements. Your report is then also visible under the corresponding folders in Target Systems → target system instance → Configuration → Reports. Try creating some reports in the Auditing → Status Reports view and then check to see if they’re visible in the other views.

Note the Target Systems subfolder that also appears in the Customer Specific subtree. This subfolder is not operational and will be removed in a future DirX Identity release.

Now open Audit Trail and then open Audit Policies.Here you can see three different subtrees:

The procedure for using the default audit policies in your own domain is the same as for using default status reports and the other default DirX Identity objects: determine which default audit policies apply, copy them from the Default folder into your own domain-specific folder with the name of your domain, and then customize the copies to your requirements.Segregating your customizations from the Default folder allows you to preserve them across DirX Identity upgrades and provides a simple structure for synchronizing your customizations into your production system with the DirX Identity transport mechanism after you’ve tested them sufficiently.For information on how to set up audit trail and customize audit policies, see the subsection "Managing the Audit Trail" in the "Managing Auditing" section of the DirX Identity Provisioning Administration Guide.For information on the DirX Identity transport mechanism, see the subsection "Transporting Data" in the section "Using DirX Identity Utilities" in the DirX Identity User Interface Guide.

The General tab supplies information about the domain, such as the name by which it is known throughout the Provisioning system, a description of its function, its type (for example, "test domain" or "production domain"), and information about the server for the Connectivity configuration domain that corresponds to the domain.The Include domain into topic flag is a DirX Identity version compatibility flag that is always set .for any domain.

The Policies tab provides the following parameters:

The Timing tab provides domain-wide controls that relate to time limits. The My-Company domain uses the standard settings of a new domain for these parameters. For more information about the fields displayed in this tab, see the online help and read the section "User and Account Life-Cycle" in the chapter "Managing Provisioning → Managing States" in the DirX Identity Provisioning Administration Guide.

The Permission Parameters tab shows the user attributes to be used in security policies or permission match rules in the My-Company sample domain. The "Getting Started" exercise "Using Permission and Role Parameters" " in the section "Adding a New User" demonstrates how the sample domain uses permission parameters for automatic privilege assignment. For detailed information about permission parameters, see the path "Managing the Privilege Structure" → "Managing Privilege Resolution" → "Handing Permission Parameters" in the DirX Identity Provisioning Administration Guide.

The Privilege Resolution tab provides parameters that relate to privilege assignment and resolution. The My-Company domain does not use any of these parameters. For information about the fields displayed in this tab, see the online help and the following documentation links:

The Request Workflow tab provides parameters for controlling DirX Identity request workflows. For information about the fields displayed in this tab, see the online help. The My-Company sample domain uses these parameters are follows:

The Compliance tab provides domain-wide controls that relate to compliance measures.For information about the fields displayed in this tab, see the online help.The My-Company sample domain uses these parameters as follows: