OpenPages, Inc.201 Jones RoadWaltham, MA 02451781.647.3800www.openpages.comSarbanes-Oxley ExpressAdministrators Manual - August 2005 iiCopyright InformationCopyright 2003-2005 OpenPages, Inc. All rights reserved.No part of this book may be reproduced, stored in a retrieval system, or transmitted by any means, electronic, mechanical, photocopying, recording, or otherwise, without written permission from OpenPages.All questions pertaining to duplication or redistribution of this material and/or the software that it describes should be directed to:OpenPages, Inc.201 Jones RoadWaltham, MA 02451781.647.3800Trademark InformationOpenPages, Sarbanes-Oxley Express, and SOX Express are Registered Trademarks of OpenPages Inc.DisclaimerAlthough every precaution has been taken in the preparation of this user manual, OpenPages and the author assume no responsibility for errors or omissions. No liability is assumed for damages resulting from the use of the information contained herein.Release InformationSoftware Version: Sarbanes-Oxley Express 3.1.0Administrators Manual Published: August 2005Manual Version: AM-310.7iiiTable of ContentsChapter 1 IntroductionWhat is the Sarbanes-Oxley Act of 2002? . . . . . . . . . . . . . . . . . . . . . .2Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2What is Section 302?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2What is Section 404?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2Additional Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . .2Additional Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2What is Sarbanes-Oxley Express? . . . . . . . . . . . . . . . . . . . . . . . . . . . .3Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3How Can Sarbanes-Oxley Express Help Me?. . . . . . . . . . . . . . .3What is Internal Controls Documentation?. . . . . . . . . . . . . . . .3Chapter 2 Administering SOX ExpressAdministering Users and Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6About SOX Express Users and Groups. . . . . . . . . . . . . . . . . . .6About User Names and Passwords. . . . . . . . . . . . . . . .6Creating a New SOX Express User. . . . . . . . . . . . . . . . . . . . . .6Modifying an Existing User Account. . . . . . . . . . . . . . . . . . . . .7Disabling a User Account . . . . . . . . . . . . . . . . . . . . . . . . . . . .7Re-enabling a SOX Express User. . . . . . . . . . . . . . . . . . . . . . .7Associating an Existing User with a Group . . . . . . . . . . . . . . . .8Disassociating a User from a Group. . . . . . . . . . . . . . . . . . . . .8Creating a Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8Removing a Sub-Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9Using Application Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10Overview of the SOX Express Application Permissions. . . . . . . .10SOX Express Application Permissions. . . . . . . . . . . . . . . . . . . .10Administration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10Audit Trail. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10Browse Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10Folders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11Project Management . . . . . . . . . . . . . . . . . . . . . . . . . .11View Locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11Other Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11All Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11Administration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11Collaboration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 ivTable of ContentsPublishing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12Setting Up Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13Overview of Implementing ACL Security . . . . . . . . . . . . . . . . . .13About Access Controls . . . . . . . . . . . . . . . . . . . . . . . .13Preparing For Your Security Implementation. . . . . . . . .14The Compliance Object Folder Structure . . . . . . . . . . . . . . . . . .15Using Inheritance with Access Control Lists . . . . . . . . . . . . . . .16About Breaking Inheritance. . . . . . . . . . . . . . . . . . . . .16Creating a New ACL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17Editing an Existing ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18Deleting an Existing ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . .18Using Groups to Establish User Roles. . . . . . . . . . . . . . . . . . . .19The Core SOX Express Groups . . . . . . . . . . . . . . . . .19Example: Using Groups to Establish User Roles. . . . . . .19Using Groups to Limit User Activities. . . . . . . . . . . . . . . . . . . .20Using Nested Groups to Limit User Scope. . . . . . . . . . . . . . . . .23Step One: Breaking Folder Inheritance. . . . . . . . . . . . .23Step Two: Nesting Your User Groups . . . . . . . . . . . . . .23Using Group ACLs to Traverse Business Entities . . . . . . . . . . . .26Setting Up LDAP User Authentication . . . . . . . . . . . . . . . . . . . . . . . . .27Overview of LDAP Authentication . . . . . . . . . . . . . . . . . . . . . .27Supported LDAP Servers. . . . . . . . . . . . . . . . . . . . . . .27Configuring the LDAP Authentication Module . . . . . . . . . . . . . . .27Step One: Adding Existing Users to the LDAP Server . . .27Step Two: Changing the OPSystem Password (optional).28Step Three: Editing the LDAP Configuration File. . . . . . .28Configuring Password Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . .30Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30About the UPEA Command File. . . . . . . . . . . . . . . . . . . . . . . .30Pre-requisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30UPEA Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30Changing the Password Encryption Algorithms . . . . . . . . . . . . .31Changing the 3DES Encryption Key. . . . . . . . . . . . . . . . . . . . .32Working with Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33Viewing Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33Supplied Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34Understanding Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36Accessing the Report Pages and Page Templates. . . . . .36Creating a New Instance of a Report. . . . . . . . . . . . . . . . . . . .37Modifying an Existing Report Template . . . . . . . . . . . . . . . . . . .38Deleting a Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38Creating Interactive Reports. . . . . . . . . . . . . . . . . . . . . . . . . .38Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38Creating an Interactive Report . . . . . . . . . . . . . . . . . . .38Running an Interactive Report. . . . . . . . . . . . . . . . . . .39Limiting the Report Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40About the Report Scoping Wizard . . . . . . . . . . . . . . . . . . . . . .40Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40Configuring the Report Scoping Wizard . . . . . . . . . . . . . . . . . .40Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40Configuring the Scope Wizard . . . . . . . . . . . . . . . . . . .40Using the Report Scoping Wizard . . . . . . . . . . . . . . . . . . . . . . .41Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41Scoping a Report. . . . . . . . . . . . . . . . . . . . . . . . . . . .42Managing Reporting Periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43Overview of Reporting Periods . . . . . . . . . . . . . . . . . . . . . . . .43Creating a New Reporting Period. . . . . . . . . . . . . . . . . . . . . . .43Changing the Reporting Period Naming Convention . . . .43Deleting a Reporting Period . . . . . . . . . . . . . . . . . . . . . . . . . .44Deleting a Reporting Period. . . . . . . . . . . . . . . . . . . . .44Configuring the Deletion Period. . . . . . . . . . . . . . . . . .44Accessing Past Reporting Periods . . . . . . . . . . . . . . . . . . . . . .45How ACLs and Reporting Periods Interact. . . . . . . . . . .45How Reporting Periods and Audit Trails Interact . . . . . . .45Resetting Compliance Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46Overview of Compliance Object Resetting . . . . . . . . . . . . . . . . .46Preparing Your Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46Backing Up Your SOX Express Data . . . . . . . . . . . . . . .46Creating a Reporting Period (optional) . . . . . . . . . . . . .46Creating a Ruleset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47Creating the Ruleset File. . . . . . . . . . . . . . . . . . . . . . .47Sample Ruleset . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47 The Ruleset Tag Library. . . . . . . . . . . . . . . . . . . . . . .48Loading the Ruleset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55Performing the Compliance Object Reset. . . . . . . . . . . . . . . . .55Preparing for the Reset. . . . . . . . . . . . . . . . . . . . . . . .55Configuring the Ruleset Parameters. . . . . . . . . . . . . . .55Using the Compliance Object Reset Page . . . . . . . . . . .56Starting the Compliance Object Reset . . . . . . . . . . . . . .57Viewing the Reset Status . . . . . . . . . . . . . . . . . . . . . .57Viewing the Reset Session Details. . . . . . . . . . . . . . . . . . . . . .57Viewing the Reset Session Log . . . . . . . . . . . . . . . . . . .58After the Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58Starting Jobs from SOX Express Objects. . . . . . . . . . . . . . . . . . . . . . .59Overview of SOX Express Jobs . . . . . . . . . . . . . . . . . . . . . . . .59 Additional Information. . . . . . . . . . . . . . . . . . . . . . . .59Starting a Job from a SOX Express Compliance Object . . . . . . . .59Monitoring Job Progess . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59Chapter 3 Configuring SOX ExpressUsing The Backup Utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61Overview of the Backup Utility . . . . . . . . . . . . . . . . . . . . . . . .61Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61Configuring the Backup/Restore Utility . . . . . . . . . . . . . . . . . . .61Using the Backup Utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . .61Additional Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61Generated Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . .61Usage Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62Using the Restore Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63Overview of the Restore Utility. . . . . . . . . . . . . . . . . . . . . . . .63Using the Restore Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63Additional Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63Generating Object Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64Overview of Name Generation . . . . . . . . . . . . . . . . . . . . . . . .64Modifying the Naming Settings. . . . . . . . . . . . . . . . . . . . . . . .64Configuring the Object Name . . . . . . . . . . . . . . . . . . . . . . . . .65Autogenerating Long Names. . . . . . . . . . . . . . . . . . . .65Naming Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66Managing Signatures and Locks. . . . . . . . . . . . . . . . . . . . . . . . . . . . .67Overview of Signatures and Locks. . . . . . . . . . . . . . . . . . . . . .67Enabling and Disabling Signatures . . . . . . . . . . . . . . . . . . . . . .67Manual Signatures. . . . . . . . . . . . . . . . . . . . . . . . . . .67Automatic Signatures. . . . . . . . . . . . . . . . . . . . . . . . .68Cascading Signatures. . . . . . . . . . . . . . . . . . . . . . . . .69Enabling and Disabling Locks . . . . . . . . . . . . . . . . . . . . . . . . .69The Lock and Unlock Permissions . . . . . . . . . . . . . . . . . . . . . .70Locking Access Privileges. . . . . . . . . . . . . . . . . . . . . . . . . . . .70Enabling Workflows for SOX Express Objects. . . . . . . . . . . . . . . . . . . .71About Enabling SOX Express Workflows. . . . . . . . . . . . . . . . . .71Pre-requisites for Starting SOX Express Jobs. . . . . . . . .71Enabling a Job Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71Configuring Job Behavior. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73Overview of SOX Express Jobs . . . . . . . . . . . . . . . . . . . . . . . .73Enabling Signatures for SOX Express Jobs . . . . . . . . . . . . . . . .73Assigning Job Tasks Based on Object Properties. . . . . . . . . . . .73Planning Ahead . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73Modifying the Job Type Properties . . . . . . . . . . . . . . . .73Modifying the Job Task. . . . . . . . . . . . . . . . . . . . . . . .74Creating the Compliance Object Custom Property . . . . .75Attaching Reports to Workflow Tasks. . . . . . . . . . . . . . . . . . . .75Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75Adding a Report to a Workflow Task. . . . . . . . . . . . . . .75Removing a Report from a Workflow Task. . . . . . . . . . .76Using Interactive Reports with Workflow Tasks . . . . . . .76Enabling Optional Reporting Tools . . . . . . . . . . . . . . . . . . . . . . . . . . .77Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77Differences From the Exporter Tool . . . . . . . . . . . . . . .77Configuring the Reporting Metadata . . . . . . . . . . . . . . . . . . . . .77About the Configuration Tables . . . . . . . . . . . . . . . . . .77About the Reporting Schema Scripts . . . . . . . . . . . . . .79Customizing the Reporting Schema Configuration . . . . .79Supported Macro Keywords. . . . . . . . . . . . . . . . . . . . .80Populating the Reporting Schema . . . . . . . . . . . . . . . . . . . . . .81Checking the Results of the Reporting Schema Refresh . .82Exporting Data to the Reporting Database Instance . . . . . . . . . .83Exporting the Reporting Schema Contents . . . . . . . . . .83Importing the Reporting Schema Contents . . . . . . . . . .84Changing the Database Passwords. . . . . . . . . . . . . . . . . . . . . . . . . . .85Overview of Changing the Database Passwords . . . . . . . . . . . . .85Changing the Oracle Password . . . . . . . . . . . . . . . . . . . . . . . .85Changing the WebLogic Password. . . . . . . . . . . . . . . . . . . . . .86Changing the Password in WebLogic. . . . . . . . . . . . . . .86Changing the Password References in SOX Express . . . .86Changing Your Server IP Address . . . . . . . . . . . . . . . . . . . . . .87Chapter 4 Modifying SOX Express BehaviorCustomizing the Overview Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . .89About Customizing the Overview Pages. . . . . . . . . . . . . . . . . .89Modifying the Overview Page Definitions . . . . . . . . . . . . . . . . .89Enabling/Disabling the Expand All Capability . . . . . . . . . . . . .90Modifying the Overview Node Cache . . . . . . . . . . . . . . . . . . . .91Modifying Compliance Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92Overview of Modifying Compliance Objects. . . . . . . . . . . . . . . .92Example: Adding a New Text Field. . . . . . . . . . . . . . . .92Step One: Identifying the New Field . . . . . . . . . . . . . . . . . . . .92Example: Identifying the New Field . . . . . . . . . . . . . . .93Step Two: Defining the Field Properties. . . . . . . . . . . . . . . . . .93Example: Defining the Field Properties. . . . . . . . . . . . .95Step Three: Attaching the Property Bundle. . . . . . . . . . . . . . . .96Example: Attaching the Property Bundle. . . . . . . . . . . .96Step Four: Displaying the New Field . . . . . . . . . . . . . . . . . . . .97Example: Displaying the New Text Field. . . . . . . . . . . .98Step Five: Activating the New Field. . . . . . . . . . . . . . . . . . . . .99Example: Adding a New Text Area Field. . . . . . . . . . . . . . . . . .99Example: Adding a New Drop-down Selection Field. . . . . . . . . .101Example: Adding a New HTML Field. . . . . . . . . . . . . . . . . . . . .103Hiding an Existing Object Property Field. . . . . . . . . . . . . . . . . .105Modifying Property Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . .106Modifying an Existing Property in configTileDefinitions.xml 106Modifying an Non-Existent Property in configTileDefinitions.xml. . . . . . . . . . . . . . . . . . . .107Modifying the Overview Label . . . . . . . . . . . . . . . . . . .107 Additional Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108Configuring the Compliance Object Tables . . . . . . . . . . . . . . . .108Adding a Column to a Compliance Object Table. . . . . . .108Replacing a Column in a Compliance Object Table. . . . .109Modifying the Label of a Compliance Object Table Column110Hiding a Column in a Compliance Object Table . . . . . . .111Configuring the Compliance Object Listings . . . . . . . . . . . . . . .111Adding a Column to a Compliance Object Listing. . . . . .111Replacing a Column in a Compliance Object Listing . . . .112Modifying the Label of a Compliance Object Listing Column. . . . . . . . . . . . . . . . . . . . . . . . . . .113Hiding a Column in a Compliance Object Listing. . . . . . .114Configuring the User Selector Tool . . . . . . . . . . . . . . . . . . . . . .114Configuring the User Segment Size . . . . . . . . . . . . . . .114Specifying a Group for the User Selector. . . . . . . . . . . .115Configuring the Displayed Fields . . . . . . . . . . . . . . . . .115Redirecting the SOX Express Logout Link. . . . . . . . . . . . . . . . .116Displaying the Sub-Processes Header in the Action Menu . . . . .117Resolving Duplicate Names During Copy Operations . . . . . . . . .117Setting the Default Copy Behavior. . . . . . . . . . . . . . . .117Copy Behavior Options. . . . . . . . . . . . . . . . . . . . . . . .117Using an SSL Connection. . . . . . . . . . . . . . . . . . . . . . . . . . . .118Using Netegrity SiteMinder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119Overview of SiteMinder Integration. . . . . . . . . . . . . . . . . . . . .119Installing and Configuring SiteMinder . . . . . . . . . . . . . . . . . . . .119Configuring SOX Express for SiteMinder Integration . . . . . . . . .119Configuring OpenPages for SiteMinder Integration . . . . . . . . . . .119Appendix A The Notification ManagerOverview of the Notification Manager . . . . . . . . . . . . . . . . . . . .120Why would I use Notifications? . . . . . . . . . . . . . . . . . .120About the Notification Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121Exploring the Notification Reports. . . . . . . . . . . . . . . . . . . . . .121Using the Notification Manager. . . . . . . . . . . . . . . . . . . . . . . .121Requirements for Setting Up a Notification . . . . . . . . . .121Results of Running a Notification Report. . . . . . . . . . . .121Step One: Preparing Your Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122Using the Test Notification Template. . . . . . . . . . . . . . . . . . . .122Using the General SOX Notifications Template . . . . . . . . . . . . .122Step Two: Creating the Notification . . . . . . . . . . . . . . . . . . . . . . . . . .123Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123Creating a Test Notification . . . . . . . . . . . . . . . . . . . . . . . . . .123Understanding the Test Notification Fields. . . . . . . . . . .123Creating a General Notification. . . . . . . . . . . . . . . . . . . . . . . .126Step Three: Triggering the Notification. . . . . . . . . . . . . . . . . . . . . . . .129Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129Running Notification Reports Manually. . . . . . . . . . . . . . . . . . .129Running Notification Reports Automatically . . . . . . . . . . . . . . . .129The Notification Manager Command Line Interface. . . . .129 Scheduling Your Automatic Notification . . . . . . . . . . . .131Chapter B The SOX Express Reporting SchemaOverview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132Compliance Object Tables . . . . . . . . . . . . . . . . . . . . . . . . . . .133Business Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133Accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135Sub-Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139Sub-Processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140Control Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . .142Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147Test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155Action Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161Milestones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162Compliance Object Relationship Tables . . . . . . . . . . . . . . . . . .164Business Entity Relationships . . . . . . . . . . . . . . . . . . . .164Account Relationships. . . . . . . . . . . . . . . . . . . . . . . . .164Sub-Account Relationships . . . . . . . . . . . . . . . . . . . . .165Process Relationships. . . . . . . . . . . . . . . . . . . . . . . . .165Sub-Process Relationships . . . . . . . . . . . . . . . . . . . . . .166Control Objective Relationships. . . . . . . . . . . . . . . . . .166Control Relationships . . . . . . . . . . . . . . . . . . . . . . . . .167Test Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . .167Test Result Relationships . . . . . . . . . . . . . . . . . . . . . .167Issue Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . .167Test Result Relationships . . . . . . . . . . . . . . . . . . . . . .168Action Item Relationships. . . . . . . . . . . . . . . . . . . . . .168Milestone Relationships. . . . . . . . . . . . . . . . . . . . . . . .168Master Relationships Table. . . . . . . . . . . . . . . . . . . . . . . . . . .169Milestone Relationships. . . . . . . . . . . . . . . . . . . . . . . .169Security Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170Effective Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170Folders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171Actors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171Audit Trails. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172Audit Trail. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172Appendix C Integrating with TeamMateWhat is TeamMate?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173How TeamMate and SOX Express Interact . . . . . . . . . . . . . . . .173TeamMate/SOX Express Naming Schemes . . . . . . . . . .174Exporting Data to TeamMate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175How Exporting Data Works. . . . . . . . . . . . . . . . . . . . . . . . . . .175Setting Up The Schema Mapping. . . . . . . . . . . . . . . . . . . . . . .175Running the TeamMate Export Report. . . . . . . . . . . . . . . . . . .175Importing the Data Into TeamMate. . . . . . . . . . . . . . . . . . . . .175Troubleshooting the Export Process. . . . . . . . . . . . . . . . . . . . .176Importing Data From TeamMate . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177How Importing Data Works . . . . . . . . . . . . . . . . . . . . . . . . . .177Exporting the Data From TeamMate . . . . . . . . . . . . . . . . . . . .177Transforming the XML File . . . . . . . . . . . . . . . . . . . . . . . . . . .177Importing the TeamMate Data . . . . . . . . . . . . . . . . . . . . . . . .177Displaying the TeamMate Properties. . . . . . . . . . . . . . .1781IntroductionThis Administration Guide provides information and instructions for maintaining and administrating the Sarbanes-Oxley Express application. Topics covered include user and group administration, database backup and restoration, customizing the applications look and feel, using the data loader capabilities, and much more.What is the Sarbanes-Oxley Act of 2002? 2IntroductionWhat is the Sarbanes-Oxley Act of 2002?OverviewThe Sarbanes-Oxley Act of 2002 (SOA) is a piece of landmark legislation designed to make public companies more transparent in their financial reporting and more proactive in sharing material information with other participants in the financial reporting chain such as auditors, audit committees, analysts, and investors.The SOA is a complex act with many provisions. The two sections most relevant to public corporations are sections 302 and 404. Section 302 pertains to disclosure controls and procedures; Section 404 to internal controls and procedures for financial reporting.What is Section 302?Section 302 of the SOA mandates that CEOs and CFOs personally certify financial statements and filings, as well as affirm that they are responsible for establishing and enforcing disclosure controls and procedures at all levels of their corporation. With each quarterly filing, they must certify that they have evaluated the effectiveness of these controls. In addition, they must disclose to their audit committee all significant deficiencies, material weaknesses, and acts of fraud.Section 302 of the Sarbanes-Oxley Act was put into effect in 2002.What is Section 404?Section 404 of the SOA requires an annual evaluation of internal controls and procedures for financial reporting. Under this scheme, a corporation must document its existing controls that have a bearing on financial reporting, test them for efficacy, and report on gaps and deficiencies.Furthermore, the companys independent auditor must issue a report, to be included in the companys annual report, that attests to managements assertion on the effectiveness of internal controls and procedures and financial reporting.Section 404 of the Sarbanes-Oxley Act will be effective for the fiscal years ending June 15th, 2004.Additional ResponsibilitiesThe SOA also describes other responsibilities. For example, it informs company boards of their responsibilities with respect to the institution of audit committees. It instructs the SEC to create an independent public accounting oversight board with the express mandate to regulate the conduct of audit firms. Furthermore, it lays down guidelines for conduct of attorneys that represent public corporations before the SEC.Additional InformationThis guide only provides a high-level overview of the Sarbanes-Oxley Act of 2002. You can find more in-depth information about the Sarbanes-Oxley Act of 2002 in the Sarbanes-Oxley Resource Center on the OpenPages web site at http://www.openpages.com.What is Sarbanes-Oxley Express? 3IntroductionWhat is Sarbanes-Oxley Express?OverviewSarbanes-Oxley Express (SOX) is an Internal Controls Management System that empowers CEOs, CFOs and financial management officers to document internal controls as set up by the Sarbanes-Oxley Act.SOX allows users to easily see the status of their internal controls documentation project, and provides a secure repository for the storage of their IC documentation.How Can Sarbanes-Oxley Express Help Me?SOX has many features that assist users in documenting their internal controls. Some of the most important are: Collaborative Task ManagementAllows the breakdown of the Internal Controls documentation project into easily achievable milestones and tasks that can be assigned to specific users. Automated Reporting ProcessesGenerates real-time reports on the current status of the IC documentation project that can be sorted and filtered on multiple levels. Internal Controls Documentation RepositoryFlexible, robust documentation repository with versioning and both property and full-text searching capabilities. Signoff CapabilitySupports the attachment of signoff tasks that require a user to append a signature to a compliance object.What is Internal Controls Documentation?A critical facet of implementing an internal controls framework is developing a repository of internal controls. Internal controls may relate to different aspects of running the business, particularly financial reporting, optimal operations, and compliance. For each financial account, a business will have one or more processes that apply to that account. Each process has certain risks associated with it that may result in an unwanted result, such as fraud, mishandling of funds, or simple accounting errors. The Sarbanes-Oxley Act of 2002 requires that these risks be identified, and that controls be put into place to prevent errors from occurring. The existence and performance of these controls must be documented and evaluated by the CEO and CFO of the company, and attested to by an external auditor.2Administering SOX ExpressThis chapter provides information about administering the SOX Express application using the capabilities of the SOX Express user interface, including adding and modifying SOX Express users, setting up folder-level security, report administration, and managing reporting periods. This chapter contains the following sections: Administering Users and Groups on page 6 Using Application Permissions on page 10 Setting Up Security on page 13 Setting Up LDAP User Authentication on page 27 Configuring Password Encryption on page 30 Working with Reports on page 33 Managing Reporting Periods on page 43 Resetting Compliance Objects on page 46 Starting Jobs from SOX Express Objects on page 59Administering Users and Groups 6Administering SOX ExpressAdministering Users and GroupsAbout SOX Express Users and GroupsTo create and administer users and groups for Sarbanes-Oxley Express, you must have access to a SOX Express user account with administrative privileges.In general, there are two different groups of SOX Express users; regular SOX Express users who can view and create compliance objects (such as accounts, processes, risks, etc.), and SOX Express administrators, who can create and modify users and groups, as well as other administrative features of the SOX Express application.This section will explain how to create, modify, and delete SOX Express user accounts and groups using the SOX Express interface.About User Names and PasswordsWhen creating user names, the following rules apply: The maximum length of a user name is 32 characters. The user name cannot contain spaces. The user name can contain alphanumeric characters and any of the following special characters:When creating passwords, the following rule applies: The maximum length of a password is 32 characters. Creating a New SOX Express UserWhen creating a new SOX Express user, you must first select the group to which the user will belong, and then enter information about the user and user account. If you have not created an appropriate group for the new user, add them to the SOXUsers group.If the user will be responsible for adding, editing, or removing reports or access control lists (ACLs), the account should be added to the SOXAdministrators group.To create a new SOX Express user:1. Log into SOX Express with an account that has permissions to add and modify users and groups.2. Click on the Users / Groups link under the Administration heading. The list of SOX Express users and groups is displayed.3. Expand the list of groups and users until the group to which you want to add the new user is displayed. Click the name of the group to display the Group Details page.Allowed Special CharacterDescription@ At sign- Dash! Exclamation point or bang. Period or dot_ UnderscoreAdministering Users and Groups 7Administering SOX Express4. Scroll down to the Users section that lists all of the users who currently belong to the group. Click the Add New... button.5. Enter the necessary information for the new user account. When you are finished, click Create to continue.Note: User names must contain only alphanumeric characters and underscores, and cannot contain spaces. User names and passwords are limited to 32 characters.Modifying an Existing User AccountTo edit a user account:1. Log into SOX Express with an account that has permissions to add and modify users and groups.2. Click on the Users and Groups link under the Administration heading. The list of SOX Express users and groups is displayed. 3. Expand the list until the user account you wish to edit is shown and then click on the user name to display the Details page.4. Click the Edit... button at the top of the User Information section. The Edit User Information page is displayed.Note: You may not change a users user name.5. Edit the necessary information, and click Save to return to the User Details page.Disabling a User AccountUser accounts cannot be deleted in SOX Express. Disabling a user account prevents the user of that account from logging in.To disable a user account:1. Log into SOX Express with an account that has permissions to add and modify users and groups.2. Click on the Users and Groups link under the Administration heading. The list of SOX Express users and groups is displayed. 3. Expand the list until the user account you wish to disable is shown and then click on the user name to display the Details page.4. Click the Disable button at the top of the User Information section. The button text changes to Enable and the value of the Active field changes to False.Re-enabling a SOX Express UserTo enable a disabled user account:1. Log into SOX Express with an account that has permissions to add and modify users and groups.2. Click on the Users and Groups link under the Administration heading. The list of SOX Express users and groups is displayed. 3. Expand the list until the disabled user account you wish to enable is shown and then click on the user name to display the Details page.4. Click the Enable button at the top of the User Information section. The button text changes to Disable and the value of the Active field changes to False.Administering Users and Groups 8Administering SOX ExpressAssociating an Existing User with a GroupTo add a new user to a SOX Express group:1. Log into SOX Express with an account that has permissions to add and modify users and groups.2. Click on the Users and Groups link under the Administration heading. The list of SOX Express users and groups is displayed. 3. Navigate to the group to which you want to add a user.4. Click the group name to display the Details page.5. Click the Associate... button at the top of the Users table. The Select Users page is displayed.6. Expand the user list to find the user you wish to add.7. Select the checkbox next to the user account you wish to add to the group and click the Associate button to add the user to the current group.Disassociating a User from a GroupTo disassociate a user from a group:1. Log into SOX Express with an account that has permissions to add and modify users and groups.2. Click on the Users and Groups link under the Administration heading. The list of SOX Express users and groups is displayed. 3. Expand the list of groups and users and click the name of the desired user group.4. Scroll down to the Users section of the Details page5. Select the checkbox next to the user you wish to remove from the group and click the Disassociate button to remove the user from the group.Creating a GroupUsers with the correct permissions can create groups using the SOX Express User/Group interface. Groups can contain other groups and users, and inherit application permissions from the groups that they belong to.To create a new group:1. Log into SOX Express with an account that has permissions to add and modify users and groups.2. Click on the Users and Groups link under the Administration heading. The list of SOX Express users and groups is displayed.3. Expand the list and click on the name of the group to which the new group will belong. If there is no higher-level group for the new group, click on SOXUsers. The Details page of the group is displayed.4. Scroll down to the Sub-Groups section of the Details page and click Add New...5. Fill in the required information for the new group and click Create. The parent groups Details page is displayed with the new group listed in the Sub-Groups section.Note: Group names must contain only alphanumeric characters and underscores, and cannot contain spaces. Group names are limited to 40 characters.6. Click the name of the new group to view the Details page if you want to add users to the group or modify the group permissions.Administering Users and Groups 9Administering SOX ExpressTip: Finding Users QuicklyIn order to more easily find a specific user without browsing through multiple groups and subgroups, it is recommended that you create an Everyone group (or other suitable name) as a sub-group of the SOXUsers group. This is useful since normally you create SOX Express users in the context of a group, and then add them to multiple groups directly. This means that in order to find an existing user,you need to know a group to which the user belongs. To help this process, follow the suggestions below.As you create your list of SOX Express users, add them directly to the Everyone group as well as the functional groups they will belong to. In this manner, to find a specific user quickly, you can open the Everyone group and select the user directly.If you want to deny a user access to SOX Express by removing him from all SOX groups, you will need to remove him from the Everyone group as well.Note: If you have set up your security access controls for your groups and users, it is important that the Everyone group is not granted access control to your SOX data. Otherwise, the access permissions of the Everyone group may override your security settings. The Everyone group is merely a convenience to help administrators quickly find a specific user and modify their information.Removing a Sub-GroupWhen you remove a sub-group from a SOX Express group and that sub-group does not belong to any other SOX Express group, the sub-group will not appear in the Users/Groups listing. When adding an existing group to another group, the removed group will still be available in the group selector list.Note: If you remove a sub-group from the SOXUsers group, and the members of that group do not belong to any other groups that inherit permissions from the SOXUsers group, they will no longer be able to log in to SOX Express.To remove a sub-group from a group:1. Log into SOX Express with an account that has permissions to add and modify users and groups.2. Click on the Users and Groups link under the Administration heading. The list of SOX Express users and groups is displayed.3. Expand the list and click on the name of the group to which the soon-to-be-deleted group belongs. The Details page of the group is displayed.4. Scroll down to the Sub-Groups section of the Details page, select the checkbox next to the group to be deleted, and click Disassociate. A confirmation dialog is displayed.5. Click OK in the dialog to disassociate the selected group(s)Using Application Permissions 10Administering SOX ExpressUsing Application PermissionsOverview of the SOX Express Application PermissionsSarbanes-Oxley Express (SOX Express) provides a set of application permissions that administrators can use to limit the activities of the various user groups that can access the SOX Express application.This section provides a quick overview of the different SOX Express-specific permissions available to administrative users.All of the permissions can be accessed through the Details page of the various user groups and are grouped under the SOX heading. Selecting the SOX permission checkbox will select all of the SOX permissions. This is only advisable for administrative level users.SOX Express Application PermissionsThe following permissions can be applied to SOX Express user groups:AdministrationThis application permission grants all three permissions in the Administration grouping. If you wish to create an administrative-level group, they will need this permission group. If a user group possesses any of these permissions, they will see the Administration heading in the right-hand Action menu with the appropriate sub-headings.Access Control ListsAllows members of the user group to view, edit, and remove the access control listings for compliance objects through the Access Controls link in the left-hand Action menu. See the Setting Up Security section for more information on Access Control Lists (ACLs).Object ResetAllows members of the user group to reset compliance objects for a new reporting period. For information on governing reset behavior, see the section, Resetting Compliance Objects on page 46.Reporting PeriodsAllows members of the user group to create and delete Reporting Periods through the Reporting Periods link in the left-hand Action menu.Users and GroupsAllows members of the user group to add, modify, and remove users and groups through the Users/Groups link in the left-hand Action menu.Audit TrailThis application permission allows members of the user group to view the Audit Trail information for compliance objects. With this permission enabled, an Audit Trail button can be selected at the top of the compliance objects Details page.Browse FilesAllows groups with this permission to view and navigate the Browse Files heading on the Action menu.Using Application Permissions 11Administering SOX ExpressFoldersThis application permission allows members of the user group to create new folders in the compliance object repository that do not correspond to business entities. This allows users to create their own folder structure.IssuesThe application permission allows members of the user group to view the list of SOX Issues through the Issues link in the left-hand Action menu.Project ManagementThe application permission allows members of the user group to use the Project Management capabilities available through the Project Management link in the left-hand Action menu.View LocksUsers with the View Locks permission can view the existing locks on compliance objects. The View Locks permission does not grant the right to lock or unlock an object - for that you need either the Lock permission or the Unlock permission.Other PermissionsThe following application permissions are not contained under the SOX permission heading, but still have an impact on SOX Express application behavior. Application permissions determine what functional areas and administrative operations a given user or group is able to perform. Typically, end users do not require applicaiton permissions. All PermissionsGrants members of the user group all permissions and access to every functional and administrative area within SOX Express (Web and server). AdministrationGrants members of the user group access to all administrative functions within SOX Express (Web and server).CollaborationThis application permission grants all administrative permissions under the Collaboration grouping that are related to managing tasks and jobs.Manage Job TyesAllows group members to add and modify job types. Job types are templates that can be used to create individual jobs.Start JobsAllows group members to start a job.View All Active JobsAllows group members to view a list of jobs and the Details page related to a selected job.Using Application Permissions 12Administering SOX ExpressFilesThis application permission grants all administrative permissions under the Files grouping that are related to managing files and folders.Add FoldersAllows group members to create and add new folders.Cancel CheckoutAllows group members to cancel the file check out process for associated files that were checked out by others. When a file check out is canceled, the file is checked back into the system without applying any changes and no new version of the file is created.LockAllows group members to sign off on any SOX Express compliance object, regardless of signoff or ACL restrictions.UnlockAllows group members to unlock any SOX Express compliance object.PublishingAdd Folder AssignmentsAllows group members to create a new folder assignment. Folder assignments link to an existing folder in the repository and automatically create a reference in the current channel folder to any files of a particular file type.Add FoldersAllows group members to create and add a new channel folder.Add PagesAllows group members to create and add publishing-specific files that are used to generate published web pages. Pages are based on page templates.Add TemplatesAllows group members to create and add page templates that are used to create Web pages.Assign FilesAllows group members to assign files to specific channel folders.Browse ChannelsAllows group members to browse channels. A channel represent the structure of a published website.Create ChannelsAllows group members to create a new channel for publishing a website.Manage RulesAllows group members to add and modify file rules that specify how file assignments are published within a given channel folder.Setting Up Security 13Administering SOX ExpressSetting Up SecurityOverview of Implementing ACL SecuritySarbanes-Oxley Express allows administrators to grant or deny read, write, delete, and associate permissions to groups or specific users. These permissions are set using an Access Control List, or ACL. An ACL is the list of groups and users who have permissions for the specified folder. You can explicitly set permissions on folders or inherit permissions from a parent folder.This section provides an overview of the procedures involved in setting up security for your internal controls documentation project, as well as the reasoning behind the required group and ACL structures.About Access ControlsAccess Controls can be set to control the ability to read, write, delete, and associate the compliance objects in a folder. Each of these settings can be set individually, allowing fine-level control over user and group access to the contents of a folder. Any folders that contain the SOX Express compliance objects (business entities, accounts, risks, etc.) can be administered through ACLs.Note: SOX Express access controls can only be set at the folder level. Individual objects within a folder cannot have ACLs - they automatically assume the ACL of the folder. If you have permissions for one item in a folder, you have the same permissions for the other compliance objects in that folder. Explaining Access PermissionsThere are four access permissions that users and groups can be given for a folder structure. The permissions are Read, Write, Delete, and Associate. The section below quickly explains the different permissions. Read - the group or user can view the details of the objects contained in the folder and the folder itself, but cannot edit them. Note that if Read access is denied to a group or user, they will not be able to SEE the folder, or any folders under that folder. Write - the group or user can view the details of the objects within a folder and modify them, but cannot delete them. Write access to a folder is required for creating new objects within the folder. Delete - the group or user can delete objects within the folder. Associate - the group or user can create associations between compliance objectsThe settings for the different permissions are: Granted - the user or group has full access to the specified action (Read/Write/Delete/Associate). The user can view, modify, or delete the file or folder, depending on the permission. Inherited - the setting is inherited from the nearest parent folder that contains an explicit setting for the permission. If no parent folder has an explicit permission set, the root folder of the compliance hierarchy sets the permission. Denied - the user or group cannot perform the specified action. If Read permissions are denied, the folder will not be displayed in the hierarchical view or the compliance object view.Read permission is required for Write and Associate access, and Write access is required in order for Delete access to be granted. You can select any combination of permissions, but when you save the ACL, it will be modified to be a valid combination of permissions.Setting Up Security 14Administering SOX ExpressFor example, if you set Read/Write/Delete/Associate to Denied/Granted/Granted/Granted, when you click Ok, the displayed permissions will be Granted/Granted/Granted/Granted because users must have Read permissions in order to have Write, Delete, or Associate permissions. Therefore, the Read permission is automatically changed to Granted.In order to set Read to Denied, Write, Delete, and Associate must also be set to Denied.Using ACLs with Top-Level FoldersWhen setting up your business entity and other compliance object hierarchy, certain folders are already created for you by the SOX Express installation. These folders are created with pre-set ACLs, and should not be modified.Make sure you do not modify the ACLs for the following folders:Default BusinessEntity ICDocumentationAccountsControlObjectivesControlsProcessesRisksSignaturesSubAccountsSubProcessesTest ResultsTests Issue IssueActionItems PlanMilestoneTaskFiles and FormsPreparing For Your Security ImplementationBefore you can implement your security settings for your internal controls documentation project, you should do the following: Set up at least a sample business entity hierarchy for testing purposes Have a map on hand of your business entity hierarchy for easy reference.Note: It can also be helpful to have your user accounts created, although you can implement ACL security without them.Example: Representing the Corporate Structure with Business EntitiesWidgets, Inc. has a main corporate center that centrally controls all of the corporations outlying regions. Each region has a central authority that is responsible for overseeing all of the individual sites located within the region. In addition, each site has a staff responsible for handling the finances and day-to-day operations of their site.When setting up their compliance object hierarchy, the administrators realized that although each site needed to be responsible for documenting their own controls, the set of processes and risks for each site were identical. Therefore, they decided to create a Library of compliance objects all linked to a Library business entity. The Library business entity would serve as the blank template for each sites compliance object hierarchy.First, the administrators created a business entity (CorporateCenter) for the entire corporation. Then, they created an entire set of internal controls under the Library sub-entity. Once the hierarchy was complete, they created a business entity under CorporateCenter for each region, and sub-entities under each region for each regional site. Once the regional site entities were in place, the administrators copied over the entire compliance object hierarchy from the Library Setting Up Security 15Administering SOX Expressentity to each regional site. Now each regional site has its own hierarchy, complete with a unique entity folder structure. Note that in our example, only the Library and the Site business entities have non-entity compliance objects in them. The CorporateCenter and all of the Regional entities are just containers for the Site business entities.The Compliance Object Folder StructureWhen the SOX Express object hierarchy is viewed using the Access Control menu option in SOX Express, the folder structure is slightly different than the hierarchy shown in the Overview screens (Account Overview, Entity Overview, etc.). The folder structure of the object hierarchy looks like the following:Business entities are contained in their own folder, while all of the other compliance object types have their own folder underneath the ICDocumentation folder.Note: ACLs should never be added to folders that were automatically created during the SOX Express installation (e.g. ICDocumentation, BusinessEntity, etc.). Always create ACLs using the SOX Express administrative user interface.When you add a new business entity called Enterprise, a folder with the name of the business entity is created underneath the BusinessEntity folder, as below:When you add a sub-entity named Region to the Enterprise entity, a corresponding folder is created.When you add other compliance objects to a business entity hierarchy, the folder structure of the business entities it belongs to is automatically created under the compliance object type folder. All compliance objects of that type created for that business entity are placed in the same folder.Setting Up Security 16Administering SOX ExpressImportant Note: When you are setting ACLs, it is important to remember to set ACLs for the business entity folders under the ICDocumentation folder structure, as well as the BusinessEntity folder structure. If you do not, when you try to access the compliance objects you will not be able to browse to the objects. You should never set ACLs on the container folders (e.g. ICDocumentation, BusinessEntity).Using Inheritance with Access Control ListsBy default, folders in the SOX Express compliance object folder hierarchy inherit their security ACLs from the folders above them. If a folder does not have an ACL set for a particular group, the application looks back up the folder tree until it finds an ACL for that group and uses it for the current folder. By default, all users can edit any compliance object in the entire project. This setup is extremely useful for smaller projects, where there is a single (or very few) teams all working on the same business entity structure. In the odd case where you have specific users who are denied viewing or editing privileges, you can easily deny them access to a particular folder structure by setting an explicit ACL for the group or user that denies them access.However, this paradigm rapidly becomes unwieldy for large numbers of groups or business entities. If you only want a group to see one particular region or site out of 50, it is much simpler to grant access to the single site than to deny access to the other 49.About Breaking InheritanceUsing the SOX Express user interface, you can break the inheritance property on any folder. When you break inheritance, access is limited to ONLY the groups and users who have an ACL for that business entity. All other groups and users (besides the creator of the object) are automatically set to Denied/Denied/Denied.For large teams and projects who wish to restrict which areas of the IC documentation project can be seen or modified, breaking the inheritance chain is very helpful, since it automatically denies all groups and users access to the particular business entity structure. Only the groups and users specifically included in an ACL have access to the business entity children.Instead of denying a group access to 49 sites, as in the example above, now you only have to grant access to the desired site, and the other 49 are denied by default.Note: Breaking inheritance is not without its drawbacks. Because all groups (except SOXAdministrators and OPAdministrators) are denied access to the business entity, groups that do not have an ACL entry cannot see the business entity or any compliance object underneath the business entity. This is true even if an ACL entry for a specific group is added to a sub-entity. Because the group (or user) is denied Read access at the parent business entity, they cannot browse the tree to view the sub-entity where they have access. The following sections will explain how to circumvent this restriction using nested groups.To break the inheritance on a folder:WARNING: Once you break the inheritance on a folder, the new permissions (or lack thereof) go into effect immediately. Only members of the SOXAdministrators and OPAdminstrators groups will be able to access the object, unless a specific ACL for a user or group is created.1. Log into SOX Express as a user with Administrative privileges.2. Click the Access Control link on the Action Menu and navigate to the business entity folder where you wish to break inheritance (under the Default directory).3. When you have found the desired folder, click the name of the folder to display the Details page.4. Click the Add button and choose the desired group or user from the list.5. Choose the desired permissions for the group or user by highlighting the appropriate entries and click the OK button to add the new ACL to the folder.6. Now that a valid ACL exists for the folder, click the Disable Inheritance button under the Folder heading. The value of the Inherit ACL field is changed to false and the Disable Inheritance button changes to Enable Inheritance.Setting Up Security 17Administering SOX Express7. Click Access Controls in the breadcrumb trail to return to the Access Controls folder list.Remember, no one except the groups (and sub-groups of those groups) listed in the Access Controls table will be able to see the folder or its contents. Note: The SOXAdministrators group and the creator of a folder or object is exempt from ACL restrictions. The creator always has Delete access to files and folders he or she has created, while the SOXAdministrators group has total access to all files and folders. Creating a New ACLYou must have the Access Control Lists application permission to view or edit ACL settings.To set an ACL on a folder:1. Log into SOX Express as a user with the Access Control Lists application permission.2. Click on the Administration | Access Control link in the Action menu. An expandable list of folders is displayed.3. Navigate to the folder whose access control list you want to modify. Click the folder name to display the Details page of the folder.4. Click the Edit... button at the top of the Access Controls table. The Edit Permissions page is displayed.5. Click Add to add a new access control to the list. A dialog box is displayed.6. Choose the desired group or user from the drop-down list.7. Select the desired permissions by highlighting the appropriate choices and clicking OK when finished. The dialog closes, and the new ACL appears in the list area of the folder Details page. Read permission is required for Write and Associate access, and Write access is required in order for Delete access to be granted. You can select any combination of permissions, but when you save the ACL, it will be modified to be a valid combination of permissions.For example, if you set Read/Write/Delete/Associate to Denied/Granted/Granted/Granted, when you click Ok, the displayed permissions will be Granted/Granted/Granted/Granted. Because users must have Read permissions in order to have Delete permissions, the Read permission is changed to Granted.In order to set Read to Denied, Write, Delete, and Associate must also be set to Denied.Note: If you do not set a specific permission, it will be set to Inherited unless a set access permission (such as Delete) forces the blank permission to Granted.For example, if you set a folder ACL for a group to Granted for Read, and leave Write, Delete, and Associate blank, they will be shown in the UI as Granted/Inherited/Inherited/Inherited. However, if you set the permissions to Granted for Delete, and left Read, Write, and Associate blank, the ACL would be displayed as Granted/Granted/Granted/Inherited, since Delete requires Read and Write permissions. 8. Repeat steps 5 to 7 for each ACL you want to set.9. Once you have finished setting the permissions, click the Access Control link in the Action menu to return to the Access Control list.Setting Up Security 18Administering SOX ExpressEditing an Existing ACLTo edit an existing ACL:1. Log into SOX Express as a user with the Manage ACLs application permission.2. Click the Access Control link on the Action Menu to display the list of access controls.3. Click the checkbox next to the folder name and click the Edit button to display the list of existing ACLs.4. Click the checkbox next to the existing ACL you wish to modify and click the Edit button to display the Edit ACL page.5. Select the desired permissions by highlighting the appropriate choices and clicking Save when finished. The dialog closes, and the updated ACL appears in the list area of the Access Control page. Read permission is required for Write and Associate access, and Write access is required in order for Delete access to be granted. You can select any combination of permissions, but when you save the ACL, it will be modified to be a valid combination of permissions.For example, if you set Read/Write/Delete/Associate to Denied/Granted/Granted/Granted, when you click Ok, the displayed permissions will be Granted/Granted/Granted/Granted. Because users must have Read permissions in order to have Delete permissions, the Read permission is changed to Granted.In order to set Read to Denied, Write, Delete, and Associate must also be set to Denied.For example, if you set a folder ACL for a group to Granted for Read, and leave Write and Delete blank, they will be shown in the UI as Granted/Inherited/Inherited. However, if you set the permissions to Granted for Delete, and left Read and Write blank, the ACL would be displayed as Granted/Granted/Granted, since Delete requires Read and Write permissions. Deleting an Existing ACLTo delete an existing ACL:1. Log into SOX Express as a user with the Access Control Lists application permission.2. Click the Access Control link on the Action Menu to display the list of access controls.3. Navigate the folder tree to display the folder containing the ACL you want to change.4. Click the folder name to display the Details page with the list of existing ACLs.5. Click the checkbox next to the existing ACL you wish to remove and click the Delete button to remove the ACL.Note: If you have broken inheritance for a folder, there will be entries for the SOXAdministrators and OPAdministrators groups. These ACLs cannot be edited or deleted.Setting Up Security 19Administering SOX ExpressUsing Groups to Establish User RolesUser groups fulfill three functions - to segregate users into meaningful subsets, to define ACLs to limit both the range of actions that can be performed on a folders contents, and to limit the scope of a users activity to a specific folder or set of folders. In this section, we will examine how groups can be used to separate a set of users into different roles within an organization.The Core SOX Express GroupsSOX Express has two pre-defined user groups already created as part of the initial installation. These groups are: SOXUsers - This group is a container for all users who are part of the SOX Express application. Every SOX Express user will be a part of this group through inheritance. The SOXUsers group has a single sub-group - SOXAdministrators.Note: The SOXUsers group should never be used to set ACLs on any folder. The group exists for administrative purposes only. SOXAdministrators - In order to have administrative-level permissions, users must be part of this group. Administrators can customize reports, create users and groups through the OpenPages user interface, and assign and modify ACLs. They also have access to all folders and objects in the SOX Express hierarchy, regardless of ACLs.Example: Using Groups to Establish User RolesWidgets, Inc. has decided that they will divide their SOX Express users into four main teams, each responsible for a different area of their internal controls documentation project. These four teams are: The Executive Team. These are people who do not document or modify individual compliance objects. As a team, they are only interested in viewing the entire internal controls documentation process as a whole, and quantifying the results. CFOs and high-level corporate users fall into this category. They need read access to almost all folders in order to run reports on the documentation project as a whole. The System Team. This group is responsible for setting up and maintaining the entire hierarchy of SOX Express compliance objects. They are also the only ones allowed to modify anything above the control level. In most companies, the IT department or a sub-set of the central accounting team is responsible for these activities. The Regional Teams. These groups are responsible for developing, maintaining, and overseeing the compliance objects for all of the sites within their regions. The Site Teams. These groups are responsible for documenting the controls for their sites, as well as uploading test results and control documents.The Executive and System teams are both based in the Corporate Center, while the Regional Teams and Site Teams are located in their respective regional and site headquarters.Although you can have user groups that correspond to the entire team, they are not necessary when setting ACLs. However, so-called team groups can be helpful for organizational purposes as well as assigning tasks or other uses. The important groups within each team will divide the teams according to the level of interaction (Reading, Writing, Deleting, Associating) they will be allowed, as well as the scope of the folders they can act on. These groups will be explained in the following sections.Setting Up Security 20Administering SOX ExpressUsing Groups to Limit User ActivitiesGroups are used in folder ACLs to limit what each group of users can do to the compliance objects located in the folder. In general, you will want a group of users who are limited to just viewing the compliance objects, a group who can both view and edit the objects, and another group who can view, edit, associate and delete the objects.In the following sections, we will divide each team into subgroups with different access privileges.The Executive TeamThe Executive team is interested mainly in the overall status of the internal controls documentation project, and gathers most of their information by running reports on the various compliance objects and drilling down into the objects via the report links. As such, they only need read access to objects, but their scope needs to be extremely wide.Some possible sub-groups of the Enterprise team are: FinancialOfficers ExternalAuditors InternalAuditorsIn the case of the Executive Team, the sub-groups are merely organizational in nature. However, by making them sub-groups of the Executive Team group, you gain the flexibility of categorizing the Executive users by roles without adding complexity to your ACL definitions. All of the sub-groups require the same access to the compliance object hierarchy - they only need Read access in order to run reports and view individual objects from those reports. As an organizational grouping, the ExecutiveTeam group will not appear in any ACLs directly - rather, it will be added as a member of many other groups with read-only access.Once you have created your Executive Team sub-groups, add the appropriate users to each sub-group. Users should NOT be added directly to the ExecutiveTeam group - add them to a sub-group instead.Setting Up Security 21Administering SOX ExpressThe System TeamThe System team is responsible for creating, maintaining, and expanding the entire hierarchy of compliance objects and their associations. Of all the teams, they need the widest authority to make changes to the compliance object structure. However, not everyone on the team needs the same permissions. Using sub-groups, we can separate the System team into their separate roles. The sub-groups for the System team are: SystemReviewers - contains all users responsible for reviewing newly created compliance objects and reporting errors in setup or descriptions. They require Read access. SystemWriters - contains all users responsible for creating and modifying new or changed compliance objects, and implementing any changes found by the Reviewers. They require Read, Write, and Associate access to compliance objects. SystemDirectors - contains all users responsible for making modifications to the object hierarchy itself, including removing unnecessary compliance objects. They require Read, Write, Associate, and Delete access.Since the System team is responsible for modifying the entire object hierarchy, as well as reports, projects, etc, they also need to be granted access at the highest level in the entity hierarchy.Once you have finished creating the SystemTeam sub-groups, add the System users to the appropriate System user group, depending on their role.Note: When looking at this group, you might be tempted to add the ExecutiveTeam group to the SystemReviewer group. After all, they both need Read access to everything - why not? One small reason - the Library business entity. As the blank template for any new Regions or Sites that might be created, the SystemReviewers will need access to the Library. The ExecutiveTeam group, however, does not want access to the Library, since they will not want to include the Library objects in any reports they run. Dont forget that the scope of what you can see determines the content of any reports you run. Reports will not include any objects you cannot view.Setting up the System team demonstrates the ability to use sub-groups to refine the permissions and access levels within a specific organization. Setting Up Security 22Administering SOX ExpressThe Regional TeamsEach Regional team (one for each region) is responsible for reviewing and maintaining the compliance objects that are specific to the sites in their region. In function, they are quite similar to the System team, but their influence is limited to all of the sites in their region.The various sub-groups for the Regional teams are actually two levels - first you need an umbrella RegionalTeams group. Under that group, you need to create sub-groups for each region. For example: Region01Reviewers - responsible for reviewing and reporting on all of the sites in Region 01. They require Read access to everything in Region 01. Region01Writers - responsible for making any necessary changes to the compliance objects in any of the sites in Region 01. They require Read, Write, and Associate access to everything in Region 01. Region01Directors - responsible for deleting obsolete compliance objects or defunct sites in Region 01. They require Read, Write, Associate, and Delete access to everything in Region 01.You would create a set of groups for each region in your company (Region02Reviewers, Region02Writers, etc.). Once you have completed creating a set of groups for each region and added all of the users from the Regional Teams who belong directly to each group, it is time to create the groups for each Site.The Site TeamsBelow the Regional level, each Site has its own team of Reviewers, Writers, and Directors. For each site in each region, you would create a set of sub-groups as follows: R01Site01Reviewers - responsible for reviewing and reporting on Site 01 in Region 01. They require Read access to everything in Site 01. R01Site01Writers - responsible for making any necessary changes to the compliance objects in Site 01 in Region 01. They require Read, Write, and Associate access to everything in Site 01. R01Site01Directors - responsible for deleting obsolete compliance objects or defunct sites in Site 01 in Region 01. They require Read, Write, Associate, and Delete access to everything in Site 01.Just like at the Regional level, you would create a set of sub-groups for each site in each Region. Although by this time we are probably creating a lot of groups, each group will only have to be declared in an ACL once at the site level.As you create the Site groups, you can add the users who belong directly to each group. Adding groups to other groups will be handled in the next section.Setting Up Security 23Administering SOX ExpressUsing Nested Groups to Limit User ScopeBy now, you have created dozens and dozens of groups, and you havent actually created any ACLs! Not to worry - this is where all of those groups come in handy. In this section, we will nest our groups inside one another, add ACLs to our regions and sites, and break the inheritance of our business entities to restrict the scope of our users and groups. Lets take the last one first.Step One: Breaking Folder InheritanceThe first step in limiting user access to regions and sites is to break the inheritance of all of our business entity folders - all regions and all sites. Breaking the inheritance sets all of the groups and users without an ACL (except those with the Access Control Lists application permission) on the business entity folder to Denied/Denied/Denied/Denied. They cant view, edit, or delete the folder, create or remove associations, or view any business entity folder underneath it, even if they have an ACL set on a lower-level folder.The Read permission is the most important, for Read allows you to see folders underneath the business entity and navigate down to them. However, with so many Regions and Sites to set up, we dont want to have to keep Denying access to all sorts of groups.To set ACLs and break inheritance in the SOX Express user interface:1. Log into SOX Express as a user with the Access Control Lists application permission.2. Click the Access Control link on the Action Menu and navigate to the business entity folder where you wish to break inheritance (under the Default directory).3. When you have found the desired folder, click the name of the folder to display the Details page.4. Click the Add button in the Access Controls table and choose the desired group or user from the list.5. Choose the desired permissions for the group or user by highlighting the appropriate entries and click the OK button to add the new ACL to the folder.6. Now that a valid ACL exists for the folder, click the Disable Inheritance button under the Folder heading. The value of the Inherit ACL field is changed to false and the Disable Inheritance button changes to Enable Inheritance.7. Click Access Controls in the breadcrumb trail to return to the Access Controls folder list.8. Repeat this procedure for each business entity folder. Note: Do not forget to modify the business entity folders under each compliance object type in the ICDocumentation tree.Step Two: Nesting Your User GroupsNow you have a lot of groups with users assigned to them according to their role. In this step, we will add groups to other groups in order to properly restrict their area of effect.The way groups with users nest seems backwards at first glance - the most general groups (the System and Executive groups) have to be added to the more limited ones (the Regional groups), while the Regional groups have to be added to the most limited ones (the Site groups).If the Region01Writers group belonged to the SystemWriters group, which can read, write, and associate to all regions, they would also be able to read and write to all Regions, which is not the desired behavior. We are trying to limit user scope, not enhance it. So adding smaller groups to larger groups doesnt work out correctly. If you add the larger Regional groups to the smaller Site groups beneath them, you dont increase the smaller groups scope beyond its boundaries, but the Regional groups extend their vision downwards into all of the sites in their own Region. (Remember, since we broke inheritance at each level of the business entity, Regional groups dont automatically get to see the Sites underneath their Region.)Setting Up Security 24Administering SOX ExpressHeres a diagram that shows the way this works:Lets follow one use case shown in the preceding diagram. The SystemWriters group becomes a sub-group to the Region01Writers group (and the Region02Writers group, and so on). Then, the Region01Writers group becomes a sub-group of the R01Site01Writers group (and the R01Site02Writers group, etc.). The sub-groups of Region01Writers also become sub-groups of R01Site01Writers through group inheritance. The effective members list of R01Site01Writers is now:R01Site01Writers

...Region01Writers (SystemWriters)In the above example, SystemWriters is in parenthesis, because it isnt explicitly added to the group - its included as a sub-group of the RegionalXXWriters groups. The same goes for the ExecutiveTeam group; it is added to each of the RegionXXReviewers groups. Executives only need Read access, so we dont need to add them to any other ACL classification.Note: If you are using the Library paradigm, you do not want to add the ExecutiveTeam group to the Library group. You dont want empty Library data included into the executive level reports.Now lets explore how we can use our nested groups to set our ACLs. Step Three: Setting Folder Access Control ListsNow that we have user groups with different permission needs for each site, we can start creating our ACLs. For each Site, we create an ACL for each R##Site## group and give them the necessary permissions. For example, in R01Site01, the ACLs for the business entity folder would look like this: Setting Up Security 25Administering SOX ExpressWe dont need to specify the Region01Reviewers, Writers, or Directors - they are already included as members of the R01Site01 groups! In general, you only need to specify ACLs for different access control levels (Read, Write, Delete, Associate) for business entity folders that contain non-business entity compliance objects. For example, in our hierarchy, Regions only contain the sub-entity Sites - there are no accounts, processes, etc. directly associated with a Region. Therefore, we dont have to create ACLs for Region01Reviewers and the other ACL-specific groups at the Region level. In our current example, heres the ACL list for Region01:Heres are some general guidelines for whether or not to create an ACL for a user group on a business entity: If the business entity has accounts or processes associated with it, you need to create an ACL for each entity-specific group (such as R01Site1Writers, etc.) with the correct privileges. When you create ACLs for a business entity, you must replicate the ACL for each business entity folder underneath the ICDocumentation folder structure. For example, you must create the same ACL list for the ICDocumentation/Accounts/Region01/R01Site01 folder that you created for the BusinessEntities/Region01/R01Site01 folder, and so on through each sub-folder structure under ICDocumentation (Accounts, Processes, Risks, Controls, etc.). Note: If no folder with the correct name exists, either there is no compliance object of that type currently in the business entitys hierarchy, or a parent folders ACLs do not include a group that contains the current user, preventing you from seeing the folder. If a business entity only has sub-entities associated with it, you should not create individual ACLs for the business entitys Reviewer, Writer, and Director groups. We will deal with this in the next section, Only one step remains - weve created the ACLs for our business entities, but when you log in, you can only see the first level of your business entities! We now need to establish read permissions in the business entities above our Site user groups, so that we can browse down to the Site level and view our compliance objects.Setting Up Security 26Administering SOX ExpressUsing Group ACLs to Traverse Business EntitiesEven though we have successfully created a nested series of groups that successfully limits the scope of our site users, we seem to have gone a little too far - we cant browse through the business entities to get to our site! We need to create a group that will allow site users to browse through the entities, without granting anything but Read. To allow Read access to lower-level user groups:1. Log into SOX Express as a user with Administrative privileges.2. Click the Users / Groups link in the Action menu to display a list of the available groups and users.3. Create a new group at the Region level (actually, at any level above the lowest, if you have more than two levels). Call the new group Region01Browsers, because thats what its purpose will be - to allow users from the entities below it to browse down to their site.4. Create a similar group for each business entity above the lowest level (Site, in our example).5. Click the Access Controls link in the Action menu and navigate into your business entity folder structure (under \Default\BusinessEntities).6. Create an ACL on Region01 and grant Region01Browsers Read access. Repeat this with Region02Browsers in the Region02 business entity folders, and so on in any other Regions youve created.In order to not make the Browsers groups unwieldy, well need to roll-up each sites users into a single group that can be added to the Region01Browsers group. 7. Add the R01Site01Directors and R01Site01Writers group to the R01Site01Reviewers group.8. Add the R01Site01Reviewers group to the Region01Browsers group. This has the effect of adding all of the R01Site01 groups to the Browsers group, even though you only added one.9. Repeat the process for the rest of the business entities.10. If you have more than one level above your lowest level, you will need to link the Browsers groups together, creating a chain to the highest level of business entity.For example, if we had top-level business entities called Country01, etc., we would create a group called Country01Browsers, and add the Region01Browsers group to it. However, if Region02 was not a child of Country01, you would not add Region02Browsers to the Country01Browsers group.11. Once the groups have been added, log out and log back in with a Site level user and test that the ACLs are working correctly.Setting Up LDAP User Authentication 27Administering SOX ExpressSetting Up LDAP User AuthenticationOverview of LDAP AuthenticationSOX Express supports the use of an LDAP authentication server to control user access. This section details the configuration steps required to integrate SOX Express with an LDAP data source.Only one login module can be active at the same time. The underlying Openpages platform supports a single namespace, so all users must be authenticated through the same data source. Multiple authentication modules cannot be used at the same time.Any users that are created or imported into SOX Express must also be present in the LDAP authentication server. It is the responsibility of the person managing the SOX Express users to maintain the correlation between the SOX Express user list and the external LDAP data source. If a user is disabled on the SOX Express server, they must be manually disabled on the LDAP Directory server.Note: If an LDAP Directory Server is being used for user authentication, the Change Password button will be disabled in the SOX Express user interface. When an LDAP server is used, passwords are not maintained in SOX Express. The password must be changed directly in the LDAP server.Supported LDAP ServersSOX Express has been certified for use with the following LDAP servers: Microsoft Active Directory Sun One Directory Server (formerly known as iPlanet Directory Server)Configuring the LDAP Authentication ModuleTo successfully use an LDAP Directory Server with SOX Express, you must configure the LDAP Authentication Module to recognize the presence of the LDAP server. This is accomplished by completing the following steps: Adding the necessary users to the LDAP server Changing the OPSystem password (optional) Modifying the LDAP configuration fileThe following sections will detail the steps required to configure SOX Express to work with an external LDAP authentication source.Step One: Adding Existing Users to the LDAP ServerPlease refer to your LDAP Directory Server documentation for the steps required to add SOX Express users to the LDAP server.All users that will need access to the SOX Express or OpenPages platforms must be added to the LDAP authentication server. In addition, the following users will need to be added to the LDAP server: OPSystem OPAdministrator (only if you are using this account) SOXAdministrator (only if you are using this account)Note: If you specify a password for the OPSystem account that is different from the one installed by the product, you will need to complete Step Two to change the OPSystem account password system-wide.Setting Up LDAP User Authentication 28Administering SOX ExpressStep Two: Changing the OPSystem Password (optional)If the OPSystem password on the LDAP server does not match the one installed by SOX Express, you will need to change the OPSystem password using the provided tool.To change the OPSystem password:1. Start all services.2. Run the following batch file:/aurora/bin/chng-sys-pswd.bat is the home directory for your WebLogic installation. By default, this location is c:\bea\weblogic81.You will be prompted for the old OPSystem password and then the new password.3. Open and edit the \bin\twf.ini file. is the Workflow directory of your SOX Express installation. By default, this location is c:\OP_Workflow.4. Find the line that contains the TWFServerPassword property and change the value to the new OPSystem password.5. Save your changes and exit.6. Restart all services in order to enable the new password.Step Three: Editing the LDAP Configuration FileFinally, you must modify the authentication configuration file to enable the LDAP Directory Server you are using.The aurora_auth.config file contains three authentication modules: Openpages - the default internal user directory OpenpagesIP - the LDAP configuration for the Sun One Directory Server OpenpagesAD - the LDAP configuration for the Microsoft Active Directory ServerThe only module that Openpages pays attention to is the module named Openpages. Therefore, in this step we will modify the configuration file to change the name of the correct LDAP authentication server module to Openpages, and then change the settings to reflect the settings of your LDAP server.To modify the configuration file:1. Stop all OpenPages, SOX, and i-Flow services.2. Open and edit the \aurora\conf\aurora_auth.config file in a text editor.3. Find the module named Openpages and change the name to OpenpagesDefault (without the quotes).4. Depending on the LDAP server you intend to use, modify either the OpenpagesIP or OpenpagesAD module name to Openpages (again without the quotes).If you are using a Microsoft Active Directory server, change the OpenpagesAD module. If you are using a Sun One Directory Server, change the OpenpagesIP module.5. Specify the correct values for the following properties in the appropriate module: provider.url - Change the value to the hostname and port number for the LDAP authentication server. base.dn - The top level of the LDAP directory tree structure (Domain Name) on the LDAP server. If the users to be authenticated are located in multiple locations within your Active Directory structure, you will need to list all of the locations explicitly by using the distinguished names of the locations, each separated by a semi-colon.Setting Up LDAP User Authentication 29Administering SOX ExpressFor example: base.dn="DC=LDAPTesting,DC=local;CN=Users,DC=LDAPTesting,DC=local;OU=Auditors,OU=External Auditors,OU=Staff,DC=LDAPTesting,DC=local" user.attr.id - the attribute name of the user identifier (for example, uid, cn, etc.) Additional custom parameters can be added by preceding them with the prefix ctx.env. (without the quotes).For example, when using the Sun One Directory Server:OpenpagesIP{ com.openpages.aurora.service.security.namespace.LDAPLoginModule required debug=falseprovider.url="ldap://192.168.0.169:30429"security.authentication="simple"base.dn="DC=LDAPTesting,DC=local;OU=People,DC=LDAPTesting,DC=local"user.attr.id="uid"ctx.env.your.param="paramvalue";};An example when using the Microsoft Active Directory server:OpenpagesAD{ com.openpages.aurora.service.security.namespace.LDAPLoginModulerequired debug=falseprovider.url="ldap://192.168.0.165:389"security.authentication="simple"security.search.user.dn="CN=Paul Smith,CN=Users,DC=LDAPTesting, DC=local"security.search.user.credentials="openpages"base.dn="CN=Users,DC=LDAPTesting,DC=local"user.attr.id="sAMAccountName";};6. When you are finished editing the file, save your changes and exit.7. Restar