Livelink Users and Groups Explained With Best Practices (Ver 1 - Feb 2008)

Product: Livelink ECM Enterprise Server Version: 9.5.x, 9.6.0, 9.7.
.x Task/Topic: Features & Functionality Audience: Administrators Platform: All Document ID: 700036 Updated: February 29, 2008
Best Practices
Livelink Users and Groups

Colin T. Sim, Senior SDK Support Specialist (Certified Livelink SDK Developer & System Administrator)
Best Practices
Document Title
Contents
Abstract .................................................................................................................. 1 Overview ................................................................................................................. 1 Application .............................................................................................................. 1 Background ............................................................................................................ 2 The Basics ...................................................................................................................4 User and Group Settings from the Admin Pages ................................................... 5 Configure Department Selection (drop-down list or department dialog) ........................................................................................................ 5 Configure Domain ............................................................................................ 7 Configure Group Settings (Prevent Recursive Groups) .................................. 7 Configure Password Settings........................................................................... 7 Configure User Name Display ......................................................................... 8 User Tab Permissions ...................................................................................... 9 User and Group Settings from the Opentext.ini file .............................................. 13 Explanation of the Opentext.ini settings ............................................................... 14 User Setting Section ...................................................................................... 14 License Key Section ...................................................................................... 14 Lang Section .................................................................................................. 14 General Section ............................................................................................. 15 Key Tables that Affect Storage and Maintaining of LES Users and Groups ......... 15 Main User and Group Tables ......................................................................... 15 Related Tables ............................................................................................... 15 Directory Services, LDAP and Other Considerations ........................................... 15 Understanding User Licensing ................................................................................ 17 What Does this Mean? ......................................................................................... 18 Configure Server Parameters Page ............................................................... 18 Using Up Available Licenses ................................................................................ 19 Distinguishing Active, Disabled and Deleted User Accounts .............................. 21 How Customers Secure New License Keys ........................................................... 22 General User and Group Best Practices and Considerations.............................. 26 General Naming Conventions ........................................................................ 26 User Login names .......................................................................................... 26 User Account Passwords ............................................................................... 26 Managing User Accounts ......................................................................................... 28 Disabling and Enabling Accounts .................................................................. 28 Rename User Account (Change Login) or Change Password ...................... 28 Deleting User Accounts .................................................................................. 29 What is stored within the user profile? ........................................................... 29 Groups........................................................................................................................31 Group Nesting .............................................................................................. 32
Champion Toolkit Document
www.opentext.com
Best Practices
Document Title
Best Practices and Group Nesting ................................................................. 32 Recursive Groups ................................................................................................. 32 Group Strategy and Design Principles ................................................................. 33 Group Naming Conventions and Best Practices ........................................... 33 Useful List of Group Name Abbreviations ...................................................... 34 Group Naming Conventions for Usability ............................................................. 34 Acronyms (also refer to the previous abbreviation table): ............................. 35 Number Scheme ............................................................................................ 36 Group and User Types ................................................................................... 36 Creating a Group .................................................................................................. 38 Are More Groups Better? ............................................................................... 40 Group Notification ................................................................................................. 40 Deleting a Group .................................................................................................. 41 User Rights or Privileges ...................................................................................... 43 Assigning Rights (Privileges) to a User Account............................................ 43 System administration rights .......................................................................... 44 Assigning Rights (Privileges) to Users or Groups ................................................ 45 Group Management and the Responsibility for Creating and Managing Groups ................................................................................................................. 47 Who Specifically Can Create, Edit and Delete Users and Groups? ..................... 50 Group Leaders ............................................................................................... 51 Best practice considerations for assigning User and Group privileges: ................................................................................................ 52 1. Why the 1000 user/group per group limit as found in the Opentext.ini file? ................................................................................................ 53 2. How can an organization establish a company-wide group if there is a limit? ................................................................................................................. 53 Directory Services .................................................................................................... 54 Back to the Basics -- Modeling ................................................................................ 56 Turn Public Access On or Off for Livelink Users .................................................. 58 Consequences of Disabling a Users Public Access ............................................ 59 No Single Way ............................................................................................... 62 User Group Modeling Methodology ............................................................... 62 Data Gathering ..................................................................................................... 63 Key Questions in information gathering ......................................................... 63 Analysis .......................................................................................................... 64 Design ............................................................................................................ 64 Implementation .............................................................................................. 64 Impact of User and Groups on Deployment of Access Rights to Livelink Documents ..................................................................................................... 64 Mature Systems ........................................................................................................ 68 Taking a Survey of Current System and Where Things are Right Now .............. 70 User and Group Verification ................................................................................. 70 Deal with Group Recursivity ................................................................................. 72
www.opentext.com
Best Practices
Document Title
Completely Lost: Must Output List of Users and Groups? ............................ 72 Glossary .....................................................................................................................73 Appendix A: Database Activity during Creation and Deletion of a Livelink Group .................................................................................................... 75 Appendix B: Example of LAPI Code for Outputting Livelink Users and Groups ................................................................................................................. 77 Appendix C: Summary of User and Group Best Practices ................................... 79 User Login names .......................................................................................... 79 User Account Passwords ............................................................................... 79 Group Nesting ................................................................................................ 79 Group Names ................................................................................................. 80 Group and User Types ................................................................................... 80 Creating a Group ........................................................................................... 80 Assigning User and Group privileges: ........................................................... 80 Group Modeling ............................................................................................. 81 [Department:] setting in the User Profile: ....................................................... 82 Credits ........................................................................................................................ 83 General Reference where no specific pages have been cited ............................. 83
www.opentext.com
Best Practices
Document Title
Abstract
Best Practices document dealing with Livelink 9.5.x, 9.6.0 and 9.7.x concerning Users and Groups, how they work and a series of suggested design and maintenance Best Practices.
Overview
This document was written in an effort to enhance product information that may not be covered in documentation to date and to expand on information that is presently provided either in Livelink Training Courses or Customer Support materials.
Application
The following document was written to provide additional information and best practice recommendations in the following topical areas of Livelink Users and Groups: Users and Groups from the Admin Pages Users and Groups from the Opentext.ini File Key Tables that Affect Storage and Maintenance of Users and Groups Understanding User Licensing Distinguishing Active, Disabled and Deleted User Accounts How Customers Secure New License Keys General User and Group Best Practices and Considerations Managing User Accounts Groups Recursive Groups Group Strategy and Design Principals Group Naming Conventions for Usability Creating a Group Group Notification Deleting a Group User Rights or Privileges and Assigning Rights to Users or Groups Group Management and the Responsibility for Creating and Managing Groups Who Specifically Can Create, Edit and Delete Users and Groups? Why 1000 Users/Groups per Group Limit? Directory Services
www.opentext.com
Best Practices
Document Title
Back to the Basics Modeling Turn Public Access On or Off for Livelink Users Consequences of Disabling a Users Public Access User Group Modeling Methodology Data Gathering Impact of User and Groups on Deployment of Access Rights to Livelink Documents
Background
In order to implement, maintain and support a Livelink System, Administrators require a level of competency that is both technical and practical with respect to understanding how LES (Livelink Enterprise Server) Users and Groups work and operate. To achieve this level of competency, it is necessary to present both technical and practical information concerning Livelink Users and Groups. Recognizing that some readers may only be interested in the Users and Group best practices from a purely Business Management perspective, these Best Practices have been appropriately summarized within an appendix of this document, targeted specifically for the Business Management audience. The remainder of the document contains the necessary technical information in addition to the strategic placement of User and Group best practices. This document is further targeted towards two separate audiences or groups, each with their own unique issues and requirements. There are a common set of considerations, including best practices, which need to be addressed by everyone, regardless if the LES system is a new installation or one which is mature and has been operating for years. The first group includes those involved with the installation and configuration of a new Livelink system who are not dealing with any previous legacy ECM system. This group needs to consider how to structure their user and group community in a manner that will provide for sustainable growth over time and that can be managed or maintained with reasonable resources and overhead. An understanding of how Livelink operates with users and groups will be important to successfully applying many of the concepts and best practices presented in this document. The second group includes those who already have one or more Livelink installations that could be considered as being mature. A mature LES system was originally installed some time ago and has enjoyed considerable growth, perhaps during various stages in its lifecycle. This group needs to review how their user and group community has been implementing and consider how it is affecting the overall usability and performance of their Livelink System. Over time, the Corporation with a mature LES system may have experienced growth spurts or may have merged or assimilated other companies into itself. Perhaps some of this assimilation may not have been adequately planned or been less than perfect creating subsequent difficulty in maintaining the users and groups within the system. During the examination and reassessment of the user and group structure of a mature LES
www.opentext.com
Best Practices
Document Title
system, a review of best practices is also in order and implementation of any needed changes to the existing structure based on the presented best practices in this document. There is also additional troubleshooting and remedial actions that can be undertaken to keep the LES system in good working order. Readers unfamiliar with Livelink and its administration are encouraged to attend the appropriate training courses (http://www.opentext.com/training/ ) if they have not already done so. In situations where Customers may be upgrading from versions of LES that are considered Past Maintenance (side bar note and URL link to Knowledge Center regarding maintenance lifecycles) they may wish to consider attending updated training classes to understand many of the new features and changes that have been implemented in recent LES versions that have been released. An alternative to instructor lead training may be to replay recorded Webinars that touch on some of the new features and changes to the LES product which are available from Communities at the following URL: http://communities.opentext.com/communities/llisapi.dll?func=ll&objId=5906659&objA ction=browse&sort=name&viewType=1 For illustrative purposes, this document will use LES 9.7.1 as the example system when referring to functionality and illustrated screenshots. The establishing of LES Users and Groups is of equal importance to establishing correct permissions and access rights to documents and other materials stored in Livelink. If the User and Group implementation is ineffective, users who implement and manage the granting of permissions or access rights within the LES system will be challenging. A solid understanding of how LES will be used within the Corporation is also of considerable importance. This understanding will prove to be beneficial in the designing and testing of users and group structures.
www.opentext.com
Best Practices
Document Title
The Basics
When LES is first installed the system and its key components can be illustrated as follows:
Figure 1
Of course, in larger scaled or enterprise systems, there may be a need to cluster or have multiple server installations to service a larger population. For discussion purposes, use of a Tri-server or distributed configuration will be used where the Livelink and Web Server is located on one computer system while the External File Store and Relational Database are on their own respective computer systems. The Admin server, responsible for searching and indexing, would also be on another computer system.
NOTE: The Knowledge Center contains a page which deals with the concept of Past Maintenance or where a software package has a period of its existence where it is actively supported, enhanced, fixed / patched etc. https://knowledge.opentext.com/knowledge/llisapi.dll/fetch/2001/7 44073/2598689/3692538/customview%2Ehtml?func=ll&objId=369 2538 Generally speaking, Open Text maintains active support for a product for a period of 18 months following the month in which a version was released. The page details what Maintenance resources are available during the Current Maintenance and the Past Maintenance portions of the softwares lifecycle.
During the installation, Livelink will automatically create an Admin User account and a Default Group. There are several best practices or guidelines to remember: Admin User account cannot be disabled Admin User account cannot be renamed There is only one Admin user account Every user must belong to at least one group Do not attempt to remove the Admin User from the Default Group immediately following LES installation (more on this later)
For those interested in a comparison of rights and capabilities the Admin User account they are published in a separate document available at the following URL:
www.opentext.com
Best Practices
Document Title
https://knowledge.opentext.com/knowledge/llisapi.dll?func=ll&objId=9808343&objActi on=properties&nexturl=%2Fknowledge%2Fllisapi%2Edll%3Ffunc%3Dll%26objid%3D 6849437%26objAction%3Dbrowse%26sort%3Dname
User and Group Settings from the Admin Pages

Livelink User and Group Administration links are available from the Admin Pages:
Figure 2
Configure Department Selection (drop-down list or department dialog)

Beginning with LES 9.7.1, there is an option to select the kind of interface that is available when selecting groups within a user profile. By default it uses the preexisting drop-down list box interface (see illustration on next page) From the Administration Pages, it is possible to change the Department Selection interface from the drop-down to a Dialog interface, This option is recommended where a LES system has a large number of groups (see illustration on next page). When selected, the Department Dialogue interface has a Select button that provides a dialogue to enter some or all of the desired Group names to perform a query, returning all Groups that meet the name query are returned. Displayed groups from the Department Dialogue or form the drop-down list are permission based. If the user who is editing the User Profile is not the Admin User, does not have User Administration Privilege or did not create the particular groups, it will not appear on the list or interface. Conversely, if the user who is editing the User Profile, is logged in as the Admin User or as someone who has the User Administrator Privilege, then no restrictions will apply, and all LES system groups should display on the list (more details on this later). The classic drop-down interface for selecting a group. Please note that the Default Group should appear regardless of who is logged into the Livelink system.
www.opentext.com
Best Practices
Document Title
Figure 3
The Admin Page option for changing from the classis drop-down list style to a Department Dialog:
Figure 4
This is the Department Dialog as opposed to the classic drop-down list which is very useful once an organization has a considerable number of groups that cannot be readily accommodated by the drop-down list interface.
Figure 5
www.opentext.com
Best Practices
Document Title
Configure Domain
This option allows you to activate and provide administrative support for Livelink Domains. A discussion of this particular topic is outside of the scope of this document.
Configure Group Settings (Prevent Recursive Groups)

A number of Livelink functions and reporting options routinely query the tables responsible for storing user and group information including the KUAF and KUAFChildren tables. Handling of this look-up information is treated differently depending on the database server being used; MS SQL Server or Oracle. The existence of recursive groups forces Livelink to reference user/group information in a manner that is less efficient that translates into a performance hit against the system. For complete details, refer to the Note posted on the Knowledge Center at the following URL: https://knowledge.opentext.com/knowledge/llisapi.dll?func=ll&objId=9727109&objActi on=properties&nexturl=%2Fknowledge%2Fllisapi%2Edll%3Ffunc%3Dll%26objid%3D 6849437%26objAction%3Dbrowse%26sort%3Dname If you are using LES 9.6.0 or later, there is a setting available from the Admin Pages that will aid in the prevention of recursive groups being created. This setting will not remediate any pre-existing recursivity that might already exist within a system. Those systems that are likely to be afflicted with recursivity will be the ones running against Oracle or SQL Server 2005 databases. To remedy any pre-existing recursive groups, readers should consult the note posted to the KC. To prevent future recursively, enable the Prevent Recursive Groups check box.
Figure 6
Configure Password Settings

From the Configure Password Setting page, the LES Admin User has the ability to specify a number of password-hardening measures including: Minimum Number of Characters Passwords Must Contain Digits Password Cannot Begin with a Digit Password Cannot End with a Digit
www.opentext.com
Best Practices
Document Title
Changed Passwords Must be Different Change Password at First Login Password Expiration Days to Prevent Password Use Days Required Between Password Changes
The Livelink administrative page controlling the password setting may have the features or settings illustrated below:
Figure 7
Configure User Name Display

The Configure Name Display page provides the opportunity to specify the general display format for the users name. When activated, the users full first name and last name (etc) will be appended to their login ID.
www.opentext.com
Best Practices
Document Title
Figure 8
User Tab Permissions

The User Tab Permissions page provides the LES Admin User with the ability to specify whether: Users are/are not allowed to change their General Profile information Users are/are not allowed to change their Personal Profile information
Figure 9
www.opentext.com
Best Practices
Document Title
Specific users (or groups) can change the General Profile information of ANYONE within the system. Specific users (or groups) can change the Personal Profile information of ANYONE within the system.
Figure 10
This User Tab Permission information is stored to the UserTabRights table. By default, users with the System Administration Rights privilege also receive full Edit Anyone privileges. The entry below referring to Right ID 2643 corresponds to the student1 login account.
Figure 11
However, all of the names of users and groups appearing on the Access List are NOT taken entirely from the UserTabRights table. Anyone with the necessary User Administrator Rights or above will also appear on the Access List.
www.opentext.com
10
Best Practices
Document Title
Figure 12
NOTE: If and organization, for security reasons, was to disable the ability for a user to edit the information on their Personal Tab using the provided User Tab Permissions interface, it may result in an inability for the user(s) to change their Livelink passwords 1 . This issue presently affects all Livelink versions beginning with 9.5.0 though to 9.7.1. The change involves un-checking the Personal Tab and the General Tab for Allow Edit of Self. An error message stating Access is Denied will result when the user attempts to change their password.
Check the Knowledge Center for monthly patches and/or individually issued patches for a fix to this issue once it becomes available.
Here is a SQL statement that can be executed, perhaps as a Live Report to generate a list of those user accounts with User Administrator Rights or higher in the LES system: select k.ID, k.name, k.firstname, k.lastname, k.userprivileges from kuaf k where k.userprivileges in (2079, 2111, 2175, 2431) order by k.userprivileges
Bancroft, Chris. Referencing Bug LPAD-12694 and ITSM ticket 353499. Internal Customer Support
Communication (email). Feb 2008.
www.opentext.com
11
Best Practices
Document Title
The following table represents a synoptic view of these bit-masked KUAF.userprivileges binary and digital values used in the SQL statement above:
Privilege Login Enabled Have a record User Administration Create/Modify Users Create/Modify Group System Administration Public Access Bit(s) 0 1, 2, 3 4 5 6 8 11 000000001111 100001111111 100000101111 100001101111 100010111111 100000001111 15 2175 2095 2159 2431 2063 Binary Value Decimal Value
Attending the Livelink Advanced LiveReports and Schema Course (www.opentext.com/training) provides the necessary background in understanding of bit-masking permissions and privileges. And here are the corresponding results. Please note that the KUAF.userprivileges is based on bit-masked values as previously noted.
Figure 13
Additionally, the e-link and Admin User accounts have full rights (16777215), thus we are able to construct the corresponding seven (7) individuals in the list. The lack of the function button for these 6 users (excluding student1) is due to the fact that their User Administration rights cannot be revoked from this interface.
www.opentext.com
12
Best Practices
Document Title
User and Group Settings from the Opentext.ini file

Here is an abridged series of settings from an opentext.ini file that governs a variety of user and group setting. [general] MaxUsersToListPerPage=30 MaxListingOnGroupExpn=100 MaxUsersInGroup=1000
[Lang_en_US] UserNameDisplayFormat=1
[UserSetting] RowColorOptions=#FFFFFF,#EEEEEE,#FFFFCC,#CCFFFF,#CCFFCC,#DDDDF F ColumnHeaderColorOptions=#CCCCCC,#A0B8C8,#83D8A4,#CCCC99 Row1Color=#FFFFFF Row2Color=#EEEEEE ColumnHeaderColor=#CCCCCC UserNameAppendID=1
[LicenseKeyInfo] CompanyName=Open Text - Customer Support ExpireDate=? NumUsers=500 LicenseKey=*******************************
www.opentext.com
13
Best Practices
Document Title
Explanation of the Opentext.ini settings

User Setting Section
The user setting section of the opentext.ini file contains information corresponding to the interface that can be seen by users on their Tools Settings Color page. The row and column color options are specified by the hexadecimal colors in this section of the ini file.
Figure 14
The appending of a user name, as previously discussed in the last section, is controlled in this section. The Append to Display Name setting is enabled when the ini value is (1) and disabled when the value is (0). More help on these ini sections are available from the LES installation files, for example: \support\adminhelp\_en_us\webadmin\ot_ini-usersetting.html
License Key Section

A discussion of the license key and licensing will follow in the next section.
Lang Section
The UserNameDisplayFormat setting defines the format which LES displays a users name, for example infields such as Created by, Owned by, and User. Although the default value is 1 (Log-in ID), other valid values include: 2 = FirstName LastName, 3 = FirstName MiddleInitial LastName, 4 = LastName, FirstName, 5 = LastName, FirstName MiddleInitial, 6 = LastName FirstName.
www.opentext.com
14
Best Practices
Document Title
General Section
MaxUsersToListPerPage=30 The maximum number of users to display per page on a user search result list. MaxListingOnGroupExpn=100 This setting specified the maximum number of users to display when opening the members of a group. If you search for groups and then click a group to display its members, maximum number of members displayed on the page is defined by the value of the MaxListingOnGroupExpn parameter. MaxUsersInGroup=1000 This setting specifies the maximum number our users per group. This will be explained in greater detail later on in the document.
Key Tables that Affect Storage and Maintaining of LES Users and Groups
Main User and Group Tables
KUAF KUAFChildren KUAFPrefs KUAFProxy KUAFRightsList
Related Tables
AgentSchedule NotifyInterests2 OldPasswords UserTabRights
Directory Services, LDAP and Other Considerations

Topics and issues dealing with Directory Services and LDAP are outside of the scope of this document. Each user or group that exists in Livelink has a unique identifier corresponding to the KUAF.ID information. This could be roughly equated to a unique identifier, like a SID You cannot xml import or export users and groups. Since users and groups are not llnodes, the current XML Import and Exporting capabilities cannot be used to export and import users from one LES system to another.
www.opentext.com
15
Best Practices
Document Title
To maintain user and group IDs (i.e., the unique identifier corresponding to the KUAF.ID), the database in which they exist must be either upgraded or imported in its entirety. Developers could use LAPI (or Web Services) to create users and groups programmatically. Creating users and/or groups programmatically using LAPI or Web Services is beyond the scope of this document
NOTE: A document containing useful LES XML Export and Import information is has been published to the Knowledge Center and is available at the following URL: https://knowledge.opentext.com/knowledge/llisapi.dll?func=ll&objI d=13621570&objAction=properties&nexturl=%2Fknowledge%2Flli sapi%2Edll%3Ffunc%3Dll%26objid%3D13621345%26objAction% 3Dbrowse%26sort%3Dname
www.opentext.com
16
Best Practices
Document Title
Understanding User Licensing

To better understand current LES licensing, a review of licensing concepts is in order. For full details, consult the respective EULA or End User Licensing Agreement. Conceptually, licensing can be illustrated in the following pair of diagrams:
Per Server Licensing Per Seat Licensing
Per server licensing was typified by the presence of Primary and Secondary Livelink Servers. This kind of licensing was implemented years ago around the time that LES 9.0.0 was released. Secondary Servers were used to augment indexing and search provided by the Primary Server. Licensing was usually on a per-server basis. The number or users logging into the system did not matter and there was no License Key
Per seat licensing was typified by the presence of any possible number of Livelink Servers. This arrangement provides for scalability and redundancy in the case of fail-over. Licensing is on the basis of named user accounts. A license key is issued to each Livelink Customer based on a maximum of named accounts in their system.
The Livelink End User License Agreement or EULA 2 defines the nature and scope of end user licensing while using a number of terms or concepts are common to the software industry including: Client Named User(s) means an individual employee of the Licensee which: a) uses a unique login name/password combination assigned to such individual by the
Dobbie, Stacey. ELUA Text and Terminology Used to Explain Livelink Licensing. Internal Customer Support Communication (email). 29 Jan 2008.
www.opentext.com
17
Best Practices
Document Title
Licensee to access and/or use Client Module(s), and b) is authorized by a Client Named User License to access and/or use a Client Module; Client Named User License means an OTC license purchased by Licensee hereunder authorizing: (a) Licensee to install a specific Client Module on one Desktop; and (b) one Client Named User to access and use all available functions within such Client Module on such Desktop Named User means an individual employee of the Licensee which: a) uses a unique login name/password combination assigned to such individual by the Licensee to access and/or use the Server Application Software or Vista Plus Server Software (as the case may be), and b) is authorized by a Named User License to access and/or use the Server Application Software or Vista Plus Server Software (as the case may be) Named User License means an OTC license purchased by Licensee hereunder authorizing one Named User to: (a) access and/or use Server Application Software; (b) have a Personal Workspace; (c) create, modify, and/or delete Object(s); and (d) participate in any Workflow.
What Does this Mean?

It means a single Licensee (use of the term Company will be used interchangeably here for the sake of readability) will have a license key issued to them composed of a Company Name, a possible expiration date, a specified number of users and an encrypted string. During the installation or updating of a Livelink server, this key information is entered in the GUI interface and incorporated into the corresponding Livelinks opentext.ini file. In distributed, load balanced or clustered systems, the same key information must be entered into each server and/or its corresponding opentext.ini file.
Configure Server Parameters Page

The provided license key is entered in the GUI interface on the Configure Server Parameters page
Figure 15
Here is the corresponding information from the Opentext.ini file: [LicenseKeyInfo] CompanyName=ODG - A GreenSquare Company
www.opentext.com
18
Best Practices
Document Title
ExpireDate=D/2008/8/8:0:0:0 NumUsers=1000
LicenseKey=MTAwMEQvMjAwOC84Lzg6MDowOjA5Ljcu In this context, Outdoor Gear - A Green Square Company can have 1000 named users licensed for read and write access to the above Livelink 971 system.
The concept of concurrency (http://en.wikipedia.org/wiki/Concurrent_user) does not really apply. Unless security settings have been implemented to prevent the same named user from logging into Livelink multiple times. https://knowledge.opentext.com/knowledge/llisapi.dll?func=ll&objId=12782424&objAc tion=properties&nexturl=%2Fknowledge%2Fllisapi%2Edll%3Ffunc%3Dll%26objid%3 D13586326%26objAction%3Dbrowse%26sort%3Dname While it is possible for multiple users to share a single login account, there is no practical business application of doing this. Some modules or client applications can also be licensed in the same way as the Livelink server. Here is an example of the Web Reports and its Web Reports Licensing page:
Figure 16
Using Up Available Licenses

Which users within our company (that have Livelink named accounts) use up licenses?
www.opentext.com
19
Best Practices
Document Title
Admin user is going to take up one (1) license. If elink is in use, another (1) license will be used up. Each and every named user in the system who has an account that is NOT deleted, counts towards the total. If a user account has been disabled, it too counts towards the total usage. To free up the license, the user account must be deleted. When the system reaches its user limit, based on the licensing key, an error message will result the next time someone attempts to create an additional user account above the specified limit:
Figure 17
When a license key similarly expires, Livelink functionality (excluding creating new user accounts) will continue to operate normally without any impact to its usability.
www.opentext.com
20
Best Practices
Document Title
Distinguishing Active, Disabled and Deleted User Accounts

Livelink Administrators can use Live Reports to generate a count or tally of user accounts that are presently defined in their system. To list or identify all named user accounts in the system: select k.id, k.ownerid, k.name, k.groupid, k.mailaddress from kuaf k where k.type = 0 order by id To tally all named user accounts in the system: select count(*) from kuaf k where k.type = 0 Similarly, to generate a count or tally of user accounts that are presently deleted in their system. To list or identify all users whos user accounts have been deleted: select k.id, k.ownerid, k.name, k.groupid, k.mailaddress from kuaf k where k.deleted = 1 and k.type = 0 order by id To tally all named user accounts that have been deleted in the system: select count(*) from kuaf k where k.deleted = 1 and k.type = 0 To list or identify all users whos user accounts have been disabled: select userprivileges, * from kuaf where deleted in (0,1 )and floor(k.userprivileges / Power (2, 0)) %2 = 0 To tally all named user accounts that have been disabled in the system: select count(*) from kuaf k where deleted floor(k.userprivileges / Power (2, 0)) %2 = 0 in (0,1 )and
In the above statement, administrators can change this SQL so the statement reads deleted in (0) for accounts where user has not been deleted or deleted in (1) to identify where user accounts have been deleted. A document detailing technical aspects and considerations of deleting Livelink users is published to the Knowledge Center at the following URL: https://knowledge.opentext.com/knowledge/llisapi.dll?func=ll&objId=12981313&objAc tion=properties&nexturl=%2Fknowledge%2Fllisapi%2Edll%3Ffunc%3Dll%26objid%3 D6849437%26objAction%3Dbrowse%26sort%3Dname
www.opentext.com
21
Best Practices
Document Title
How Customers Secure New License Keys

Each time a new major version of Livelink is installed, (such as when performing an upgrade), a new license key needs to be secured. Generally speaking, updating to service pack levels of Livelink does not require the re-issuing of a license key. The following diagram illustrates many of the various LES versions.
Figure 18
Other situations may arise, such as increasing the number of named users in a system, thus requiring the issuing of a new license key. For Customers and Affinity Partners who require a new licensing key to be issued, they can log into the Knowledge Center and make the form-based key request. Users making the license key request need to complete one request for EACH Livelink Version and if they have multiple systems with different licensing quantities, for EACH Livelink system. The following series of screen shots shows how to navigate the through the Knowledge Center to the page where the form-based license key request can be made.
www.opentext.com
22
Best Practices
Document Title
Login to the Knowledge Center (http://knowledge.opentext.com) : Select the Downloads link:
Figure 19
Select the Livelink ECM Enterprise Server -> Enterprise Server link:
Figure 20
www.opentext.com
23
Best Practices
Document Title
From this page, select the appropriate Livelink Server version
Figure 21
Clicking on the Expand/Collapse button opposite the specific LES Server Version will result in a page where the user can then click on the key icon to open a formbased page to request a new key.
Figure 22
www.opentext.com
24
Best Practices
Document Title
Click on the key icon to open the License Key Request Form
Figure 22
Once the request has been processed, an automated email will be sent to the applicant. If the applicant does not get an email within 24 hours, they should ensure that their supplied email address is not blocked for filtered in a way that would prevent reception of the email. If, after further investigation, they still do not have the needed key, they should open a support ticket with support@opentext.com .
www.opentext.com
25
Best Practices
Document Title
General User and Group Best Practices and Considerations

General Naming Conventions
An Application Note has been previously published concerning naming conventions. Although the document does not specifically address naming conventions for users and groups, it could be reviewed to familiarize Administrators as to some of the characters that are or are not supported within Livelink in general. https://knowledge.opentext.com/knowledge/llisapi.dll?func=ll&objId=13698124&objAc tion=properties&nexturl=%2Fknowledge%2Fllisapi%2Edll%3Ffunc%3Dll%26objid%3 D6849437%26objAction%3Dbrowse%26sort%3Dname
User Login names 3

User login names should conform to the following series of best practices (additional naming restrictions may need to be imposed based on the operating system) Provide unique login name (<= 64 characters prior to LES 971; 255 characters 971 or later) Provide Domain name if required O/S limitations or restrictions; for example Windows 2000 only recognizes first 20 characters Active Directory only supports 64 characters Avoid invalid character, when using various operating systems like Windows "/\{}:;|=,+*?<> Login name may be case sensitive; for LES, it will depends on database installation
Additionally, email address should not contain special characters like spaces and brackets as some email systems cannot deal with them.
User Account Passwords 4

Passwords should be difficult to guess for added security Strong password including numbers and added characters (see previous section on LES password hardening)
Spealman, Jill. MCSE Training Kit: Microsoft 2000 Active Directory Services (MCSE Study Guide for Exam 70-217). Microsoft Press. Redmond, Washington. 2000. 691 pages. Cited pages 184-261.
4
Spealman, Jill. MCSE Training Kit: Microsoft 2000 Active Directory Services (MCSE Study Guide for Exam 70-217). Microsoft Press. Redmond, Washington. 2000. 691 pages. Cited pages 184-261.
www.opentext.com
26
Best Practices
Document Title
Upper case, lower case, numbers, non-alphanumeric characters must not contain username
www.opentext.com
27
Best Practices
Document Title
Managing User Accounts

Disabling and Enabling Accounts
For users with the appropriate privileges, they will have the rights to disable or reenable user accounts within a Livelink system. It is possible, with the use of additional modules, such as Directory Services, to have names synchronized and/or authenticated. It is possible, under the correct conditions, for a user account to be disabled when synchronization has failed. A discussion of Directory Services is out of the scope of the information being provided in this document. To disable or re-enable a user account a user would navigate to the Users and Groups (user.listuser), click the Edit link to the extreme right side opposite the desired users name and proceed to check or uncheck the Log-in Enabled Checkbox and then click Update Button. To enable the account repeat the process, leaving the Login-Enabled check box enabled.
Figure 23
Rename User Account (Change Login) or Change Password

To change the login name or password of a user account a user would navigate to the Users and Groups (user.listuser), click the Edit link to the extreme right side opposite the desired users name and enter a new login name and then click Update Button. To change the password, it would be a matter of selecting the Change Password Checkbox and then entering and confirming the new password and then clicking the Update button.
Figure 24
If the end user themselves wished to change their password, they can do so by selecting | Tools | Settings | Password | and entering the old password followed by the new password and confirming the new password and clicking the Update button.
www.opentext.com
28
Best Practices
Document Title
Figure 25
Deleting User Accounts

To delete a user account a user would navigate to the Users and Groups (user.listuser), click the Edit link to the extreme right side opposite the desired users name and proceed to click the Delete User button. Before LES user accounts are deleted in a system, readers are advised to review a separate Application Note on the subject of deleting Livelink users, which can be found at the following URL: https://knowledge.opentext.com/knowledge/llisapi.dll?func=ll&objId=12981313&objAc tion=properties&nexturl=%2Fknowledge%2Fllisapi%2Edll%3Ffunc%3Dll%26objid%3 D6849437%26objAction%3Dbrowse%26sort%3Dname Figure 26
Once a user account has be deleted, the only means of un-doing the deletion and restoring the account and its related database information is by performing a complete database restore.
What is stored within the user profile?

For those readers who are not familiar with the Livelink schema, they should consider attending the 9x-209 Advanced Schema and LiveReports training class. Official Schema Documentation: Livelink ECM Enterprise Server SDK System Schema Reference (LLESCOR090701-ARE-EN-1), which is the official Schema guide describing the database tables and columns in Livelink ECM Enterprise Server 9.7.1, can be obtained by contacting your Account Representative. User preferences are stored in the KUAFPrefs table.
www.opentext.com
29
Best Practices
Document Title
Figure 27
www.opentext.com
30
Best Practices
Document Title
Groups
A group, by definition, is a collection of users and/or other groups. Groups can be assigned system privileges but they cannot be assigned permissions. Diagrammatically, a group can look like this:
Figure 28
One role or purpose of these groups is to provide a means to simplify access control and user rights within the content management system. Other uses for groups include: administer privileges access control assign work, workflow steps and tasks set up notification
www.opentext.com
31
Best Practices
Document Title
Group Nesting 5
Adding groups to other groups or nesting creates a consolidated group which can simplify administration. Nesting can also reduce the number of times permissions need to be added or checked. Create a hierarchy of groups based on the business needs of members.
Best Practices and Group Nesting

A balance needs to be established between the need to nest groups and the impact that excessive nesting could cause on the system. Consider the following guidelines when planning out group nesting: Minimize levels of nesting. Minimum nesting will reduce added maintenance of the users and groups and will improve performance. There also needs to be a good understanding how the groups will be utilized within the LES system System performance. System performance will be impacted relative to the effective (or ineffective) nesting of groups. Proper nesting may also reduce network traffic (i.e., repeated database queries and checking for access rights) and simplify administration Keep it simple to aid in future troubleshooting. The more levels and complexity of group nesting that is employed, the more difficult or complex the tracking of rights and permissions will become Document the nesting structure. There should be documentation on your LES group structure and membership. Tracking or documenting the users and groups can help in reducing clutter and eliminate or reduce un-needed duplication in groups. The documentation may also assist in preventing or avoiding group recursivity
Recursive Groups
A number of Livelink functions and reporting options routinely query the tables responsible for storing user and group information including the KUAF and KUAFChildren tables. Handling this look-up information is treated differently depending on the database server being used; MS SQL Server or Oracle. The existence of recursive groups forces Livelink to reference user/group information in a manner that is less efficient that translates into a performance hit against the system.
Spealman, Jill. MCSE Training Kit: Microsoft 2000 Active Directory Services (MCSE Study Guide for Exam 70-217). Microsoft Press. Redmond, Washington. 2000. 691 pages. Cited pages 184-261 Finnel, Lynn. MCSE Training Kit: Microsoft Windows 2000 Server. MCSE Study Guide for Exam 70-215. Microsoft Press. Redmond, Wahington. 2000.1033 pages.
6
www.opentext.com
32
Best Practices
Document Title
The following document discusses the concept of a Recursive Group in greater detail and provides recommendations how to eliminate recursive groups is published and is available from the following URL: https://knowledge.opentext.com/knowledge/llisapi.dll?func=ll&objId=9727109&objActi on=properties&nexturl=%2Fknowledge%2Fllisapi%2Edll%3Ffunc%3Dll%26objid%3D 6849437%26objAction%3Dbrowse%26sort%3Dname
Group Strategy and Design Principles

One central theme of Enterprise Content Management is to ensure that people have access to information and materials that are needed / required for them to perform their day-to-day business. This implies they need access to some information but not access to all of it. A combination of permissions, users and groups provides the means to manage Enterprise content. Those Administrators and system designers who are new to Livelink will find that implementation of groups in particular are distinctly different from other implementations they may be familiar elsewhere for example Windows such as security groups; distribution groups and group scope.
Group Naming Conventions and Best Practices

Standard conventions are an important factor in delivering a positive Livelink experience for users. Conventions provide a consistent method and best practice for creating Livelink groups and items such as folders, documents, and URLs. The following list of generalized best practices in establishing group names and is a good starting point: Names should be easily recognized groups and administrators or knowledge managers do not have to guess at their meaning Similar groups should have similar names
A balance between brevity and readability must be achieved when establishing group names. If the group names are to be portable or serve multi-system or platform use, the lowest common denominator will determine what the names have to conform to. A good example of this is 64 character-support with Microsoft Active Directory (4). In pre- LES 9.7.1 systems the limit was also 48 characters; however, beginning with LES 9.7.1, a maximum of 255 characters can be used in establishing both login names and group names. A compromise may need to be found between a clear and verbose naming convention (that can make effective use of the 255 characters in LES 971) or using a series of abbreviations where there are length restrictions (prior to LES 971).
www.opentext.com
33
Best Practices
Document Title
Useful List of Group Name Abbreviations

Prior to LES 9.7.1, Livelink group names have length restriction of 48 characters. When group abbreviations are needed, a standardized convention for creating abbreviations and using them will be important. The following table provides a series of useful group name abbreviations:
Full Group Name Project Program Community Committee Folder Legacy Workspace Manager Consumer Contributor Coordinator Abbreviation PRJ PRGM COM CMTE FLD LGC WM CONS CNTR CORD
Group Naming Conventions for Usability

A Naming Convention for the Groups that comprise the Group Hierarchy is a very important consideration for ongoing administration, usability, and extendibility. A good Naming Convention provides the following benefits: Provides a hierarchically sorted list of groups when using Livelink Helps users understand which groups belong to other groups Makes assigning permissions to knowledge assets powerfully simple Makes assigning users to their respective base group straightforward Creates a common naming structure for use when synchronizing users & groups to an external directory source with the Livelink Directory Services Module Aids in LiveReports used to analyze users and groups Significantly reduces the level of effort required to maintain the Livelink Community Model Avoid characters that could cause problems
There is a pair of opposite approaches to building up a group name.
www.opentext.com
34
Best Practices
Document Title
The first approach (illustrated in the diagram below, on the left) starts with the largest group or companywide group and works from the general to the specific as the group structure is established or created. In this case the organizational-charted based order is Open Text -> Services -> Global Customer Support -> North America > Livelink -> SDK-Builder can be abridged to a name that occupies fewer than 40 characters: OT-Services-GlobalCS-NA-Livelink-SDK. This approach is the most common implementation and follows many of the aforementioned recommendations in establishing the group name. In some Companies or organizations, their need to organize users could be on a functional or geographic basis (illustrated in the diagram below, on the right) where the most important aspect of the group (i.e., their role as a developer) is placed first. In this case the role-based Developer is in a group structure typified by the following: Developer -> Search -> Core -> Livelink -> Waterloo -> Open Text. Again, the name can be abridged to something that is under 40 characters but is still quite readable: Dev-Search-Core-LL-Waterloo-OTC.
Figure 29
Regardless of the technique, the vital key to a good naming convention is a Group Name Prefix. Enforcement of the standards or conventions should be firmly implemented within the LES community 7 .
Acronyms (also refer to the previous abbreviation table):

Top Level (Universe) Community Group Division, Role or Relational Group Level 1 child Group Level 2 Child Group Base Group Group Livelink Universe Livelink Community ABC Internal Users S:Sales S-NA: Sales North America S-NA-SW: Sales North America Software S-NA NA-SW SW-IN: Sales North America Software
Open Text PS. "Knowledge Management Community Modeling Design and Best Practices" 28 Feb 2002.
www.opentext.com
35
Best Practices
Document Title
Number Scheme
The number scheme works on principals similar to that of accounting where people have A/P, A/R and other accounts based on a numbering system. The numbering system could also be derived from a financial system (using cost centers) or a Human Resource system. The Number Scheme is not recommended, but if this technique is chosen, take care to use the appropriate number of digits to handle the number of possible levels at the specific organization. In our case above, we used 5 digits, which would facilitate up to 4 levels below the Division, Role, or Relational Group level and assumes no more than 10 child Groups below any level.
Top Level (Universe) Community Group Division, Role or Relational Group Level 1 child Group Level 2 Child Group Base Group Group Livelink Universe Livelink Community ABC Internal Users 10000:Sales 11000: Sales North America 11100: Sales North America Software 11110: Sales North America Software
Its important to note that including the Prefix, a Group name can have up to 48 characters prior to LES 9.7.1. Beginning with LES 9.7.1 groups can support up to 255 characters, but keep in mind if these group conventions are to be portable across multiple operating systems and applications, the lowest common denominator (i.e., 48 characters) will be what must be adhered to.
Group and User Types 8

In the previous examples, use of an Organization-based group was cited. Livelink supports more than just Org-chart based groups to allow a community to manage its enterprise content. Not every group can fit into an org chart Regardless of your user and group formulation, keep duplication to a minimum and streamline where possible Create a company everyone group and do not use LES Public Access (the everyone group is usually named after the company or organizations (i.e., Open Text)
Zimmerman, Maureen Williams. Microsoft Windows 2000 Professional Resource Kit. Microsoft Press. 2000. Redmond, Washington. 1767 pages.
www.opentext.com
36
Best Practices
Document Title
Consider the following chart where there is a different aspect of the grouping being considered ranging from: Org Chart Functional Role Similar Needs Geographic Regions Skill-Knowledge Level
Org Chart Finance IT Sales Support Marketing Org Chart Type of work being performed Functional Role Support Administrative Executive Technical Similar Needs Manage users and groups Manage executing WFs Create Categories Task-based work Org Regions North America United Kingdom Europe Asia Pacific Rim Geography or location Knowledge Based skill based Skill Level Basic Skill Advanced Skill
In order to meet the demands of the organization, it may be necessary to have a synthesis or synergy of these different styles or models of groups to provide cross functionality. This concept is often referred as hyperlinked groups or cross-functional groups. Livelink can certainly assist in supporting these multi-disciplined group structures If the organization presently has computer systems making use of users and groups, perhaps a starting point is to map current group implementation to your LES design taking advantage to optimize, change or re-design where necessary.
www.opentext.com
37
Best Practices
Document Title
The same concept of creating and maintaining crossfunctional groups can be illustrated diagrammatically (below) where some users within a Technical Group ( O ) may have a Support Role ( F ) and be located in North America ( R ) = ( * ). The same concept could be extended to situations where users in the Finance Department may have an Administrative Role yet have an advanced skill level and are consequently responsible for creating and managing Workflow instances that apply to day-to-day business processes.
Figure 30
Creating a Group
Using the previously discussed best practices, a Livelink group can be established to assist with the administering of privileges (?func=admin.adminfactories), access control or permissions, notifications or assigning work including workflow steps or assignments. Best Practices of when to create a Livelink group may include: Organizing users into Can-See and Can-Reserve functional groups to be used in applying permissions Assigning Workflow steps to a group rather than hard-coding an individual user making the WF Map easy to update when users change jobs Remember to strike a balance between the business needs of having additional groups and the overhead that will be created in having to maintain them If these groups are to be portable between systems, use the lowest common characteristics (i.e., 48 characters)
www.opentext.com
38
Best Practices
Document Title
Figure 31
Figure 32
Figure 33
NOTE: This is used for background information on a topic When a group is added to the Livelink system, several tables can be affected (see Appendix A), including: KUAF KUAFChildren KUAFPrefs NotifyInterests0 NotifyMessages AgentSchedule
www.opentext.com
39
Best Practices
Document Title
Are More Groups Better?

Designers will ask, How many groups should we have in our system? Unfortunately, there is no optimum number or one answer that will fit all customer situations. The consideration here is to balance the need to have more groups against any performance impact or overhead they will cause. Remember that group membership is loaded at login time and there should be no difficulty in loading or using several thousand groups as long as the membership list for the group is short. In some situations, where users are members of 300 groups, it would not be uncommon for the LES login to take 2 minutes. 9
Group Notification
In situations where Knowledge Managers, Power Users or even Administrators may prefer to 'push' out notification on Livelink items and events, rather than relying on end users to setup personal notifications, functionality referred to as Group Notification exists within the Livelink software. The typical business application for this would be to establish required notifications at a department level. The existing Group Notification functionality can be best summarized as a means by which new users can inherit default notification settings. The Modify Settings page allows general interests to be defined in addition to the format and time increments for the three reports. These settings are copied to new users whose department is set to this group. Please note that the implementation of this Group Notification is constrained by the following behavior: Group-level notification settings will only serve as the defaults for new users added to the department after the report settings have been added. They will not affect existing members of the department 10 Editing a user (changing the users department, adding the user to other groups, etc.) has no effect upon the users notification settings Once a user begins to set up their own notification, these settings no longer have any effect 11
Obbard, Geoff, Is More Better? Internal Communication (email). Feb 2008.
10
Open Text Learning Services. Open Text Training Session 97-101. Enterprise Server Knowledge Fundamentals. Release 1.2. 15 Oct 2007.
Open Text Learning Services. Open Text Training Session 97-201. Enterprise Server System Administration. Release 1.1. 15 Oct 2007.
11
www.opentext.com
40
Best Practices
Document Title
NOTE: This is used for background information on a topic Customers have previously requested the ability to establish group notifications for existing Livelink Users. A feature enhancement request has been logged under (LPAD 12330) to provide the ability to set group notifications for users that already exist in the system as opposed to the current implementation in which only new Livelink users can inherit group notification settings. 12
A published Knowledge Base Article (KBA Article 3499529) 13 addresses the question of How do you notify a group of people when a particular event occurs? which can be found at the following URL: https://knowledge.opentext.com/knowledge/llisapi.dll?func=ll&objId=3499529&objActi on=ArticleView&viewType=1
NOTE: This is used for critical information (showstoppers). STOP and READ THIS FIRST is what is implied. Without this information the system may be compromised or data lost Customers using LES 9.5.x should be aware of an issue that was addressed in LES 9.6.x in which modify notification settings for a group actually displays the notification settings of the user who has logged in (instead of the group settings). This issue was logged under LPAD-10157 and formerly 1995660. Customers should upgrade to the latest version of LES to address this issue.
Deleting a Group
When a group is no longer needed it can be deleted right? Not exactly. There are a number of considerations that have to be taken into account before the group is deleted.
Open Text Learning Services. Open Text Training Session 97-201. Enterprise Server System Administration. Release 1.1. 15 Oct 2007.
13
12
Open Text PS. KM Livelink Configuration. 6 Feb 2002.
www.opentext.com
41
Best Practices
Document Title
It is easy enough to delete the group from the provided interface during which, a confirmation dialog will be presented:
Figure 34
Once a group has been deleted, there is no undo functionality that will allow the restoration of the group to the system. In fact, the group deletion causes a systemic change to multiple database tables in the Livelink schema, possibly including: KUAF NotifyInterests0 KUAFChildren NotifyMessages KUAFPrefs AgentSchedule
To answer the question of What is impacted when a group is deleted? can be addressed by detailing where groups are used throughout Livelink, which includes: Groups can be used in the assigning of workflow steps Groups can be used in the assigning of tasks Groups can be used to establish group notifications Groups can be used to establish Item Creation Privileges Groups can be used to establish Group Leadership Groups can be used to establish Access Control (ACL lists) Groups are used for nesting of other groups and users Groups are used to organize users including establishing of a base or departmental group
Thus, the system should be queried to make sure that there would not be any undue consequences of deleting the group. It is evident from the logs generated during the deletion of a group, Livelink performs cleanup or remediation of much of the relational information including the Notifications and Agents, Leadership, Child-group associations and to Item Creation privileges etc. Workflow and task assignments would not be affected. update KUAF set GroupID=:A0 where GroupID=:A0 | 1 | | |
delete from KUAFChildren where ID=:A0 and ChildID in <snip> update KUAF set LeaderID=:A0 where LeaderID=:A0 | 1 | delete from NotifyMessages where UserID=:A0 | 1 | delete from KUAFChildren where ID=:A0 | 1 | | | | | | | | |
delete from KUAFChildren where ChildID=:A0 | 1 |
www.opentext.com
42
Best Practices
Document Title
delete from NotifyInterests0 where UserID=:A0 | 1 |
insert into AgentSchedule ( UserID,AgentID,Enabled,<snip> delete from AgentSchedule where UserID=:A0 | 1 | | | | |
insert into DAuditMore values ( :A0, :A0, :A0 ) | 13 |
delete from NotifyInterests0 where UserID=:A0 and NodeID=:A0 | 1 | | |
User Rights or Privileges

By default, a privilege is a system wide right or entitlement; login or the ability to create or edit certain kinds of objects. A privilege should not be confused with permissions. A permission specifies the level of access a user (or group) has to a specific object
Assigning Rights (Privileges) to a User Account

The following rights or privileges are assigned to individual named LES accounts:
Log-in enabled Public Access enabled Can Create / Modify users Can Create / Modify groups User administration rights System administration rights
Figure 35
Log-in enabled The user has the ability to login to Livelink.
www.opentext.com
43
Best Practices
Document Title
Public Access enabled The user is part of the Public Access group. Everyone in Livelink who has an account, is automatically part of the Public Access group that appears on the Access Control List (ACL). Can Create / Modify users The users can create new users and modify existing users that they previously created (or own). Can Create / Modify groups The users can create new groups and modify existing groups that they previously created (or own). User administration rights The user can create new groups and modify existing groups regardless of who originally created them or owns them. The user will also be able to delete any existing user account or group.
System administration rights

User accounts granted System Admin privilege can Can navigate to anyone's Personal Workspace Have full permissions on all Livelink items View the entire audit trail for all items from the Query Audit Log page User accounts granted System Admin privilege cannot Change the admin user password Edit and Delete Groups, unless also granted the User Administrator privilege Access to system workflow instances
The aforementioned privileges are stored in the KUAF.userprivileges table. To identify those users with the User Administration Rights, the following SQL statement run against a MS SQL database would yield the corresponding users: SELECT name, userprivileges FROM KUAF WHERE Type = 0 and Floor( userprivileges / Power( 2, 4 ) ) % 2 = 1
www.opentext.com
44
Best Practices
Document Title
Assigning Rights (Privileges) to Users or Groups

The assigning of system rights to create or manage LES content is established from the Admin Pages using the Administer Object and Usage Privileges link on the System Administration Tab.
Figure 36
www.opentext.com
45
Best Practices
Document Title
Default rights to create the core-objects include: Category, Category Folder, Live Reports, Appearance and Global Appearances and XML DTDs are all restricted so that only the LES Admin user can create or edit these objects.
www.opentext.com
46
Best Practices
Document Title
Group Management and the Responsibility for Creating and Managing Groups
Using well-planned groups is the easiest way to manage access permissions for Livelink items. With groups, designated Knowledge Mangers or designates can add and remove members from the group as necessary. Using group management can and does enhance the folder owners ability to control and maintain the integrity of the information being accessed. Group management is particularly useful with staff folders that need to be secured from the general public. Groups can be assigned varying levels of privileges depending on the security level of the item. What are the differences rights of the Admin User and a user who has been granted System Administration Privileges? The following published document provides the background and details comparing these pair of LES users: https://knowledge.opentext.com/knowledge/llisapi.dll?func=ll&objId=9808343&objActi on=properties&nexturl=%2Fknowledge%2Fllisapi%2Edll%3Ffunc%3Dll%26objid%3D 6849437%26objAction%3Dbrowse%26sort%3Dname An Admin User account is automatically created when the Livelink software / system are installed and this account is assigned a base or departmental group of Default Group. This Admin User account has full access and full privileges to the Livelink system including the ability to: Create other users and groups Define the access control or permissions for the Enterprise Workspace Configure various system settings Assign the System Administration privilege to other people Restore deleted documents using the Undelete Module (core) Item Creation Privilege for XML DTDs, Live Reports (default)
Things that only the Admin User can do View status and contents of all workflows in the system Automatically has User Administration rights, other users must be given this privilege. Manage system, for example installing modules or change the database
If you click a link on a page that requires you to work with the systems data, you will be prompted to enter the Admin Users password for these pages before being allowed to proceed further.
www.opentext.com
47
Best Practices
Document Title
It should be noted that someone with System Administration Privilege CANNOT administer the LES user and group community, unless they have been granted additional rights. The concept and implementation of User Profile Privileges has been previously discussed, however, the discussion did not cover the subject of why a LES Administrator would grant those respective privileges to a user. A discussion of these User Privileges as they apply to the Responsibility for Creating and Managing Groups will now be undertaken. The hierarchy of privileges that can be assigned to a user can be expressed diagrammatically (shown on the left in the next figure) corresponding to the LES GUI interface (shown on the right on the same figure). The order of privilege is decreasing as one move down to the base of the pyramid while the privileges are increasing moving down through the series of check boxes.
Figure 37
Each company has their own business processes it needs to follow when it comes to adding users to their system. One example of this is a Company that performs background and security checks of its potential employees. It is officers within their security department who create the user account and adds the new hire to a departmental group (that was previously established). Once the new hire reports to their new manager (or designate), this
www.opentext.com
48
Best Practices
Document Title
manager has the appropriate system rights (privileges or settings) that permits them to add the new hire to additional groups and / or grant other system privileges as needed for the new hire to perform their daily work. This process can be illustrated diagrammatically:
Figure 38
In other Companies much of the user and group administration is performed by their Information Technology (IT) department. Regardless, considerations need to be made within each organization as to who will or will not be able to manage the users and groups within a Livelink System.
www.opentext.com
49
Best Practices
Document Title
Who Specifically Can Create, Edit and Delete Users and Groups?
Those users and user accounts which can create, edit/modify and delete users and groups are tabulated below:
User Account Create User Yes Modify User Only if Own No Delete User Only if Own No Create Group No Modify Group No Delete Group No
Create / Modify User
Create / Modify Group User Administrator System Administrator Admin User Group Leader User Tab Right
No
Yes
Only if Own Yes No Yes Yes No
Only if Own Yes No Yes Yes No
Yes No Yes No No
Yes No Yes Yes Yes
Yes No Yes Yes Yes
Yes No Yes No No
When a user with the Create/Modify User/Group rights creates either a user or a group, their ownership is recorded within the KUAF table. The following illustrates that user # 2324 created a pair of user accounts and one group. If # 2324 leaves the company, then another user with greater rights is needed to update or modify the records.
Figure 39
www.opentext.com
50
Best Practices
Document Title
Referring back to the pyramid diagram of user profile rights, only a User Administrator or the Admin User would be able to subsequently manage the above users and groups. A Group Leader is one other setting that would also allow the continued management of these accounts. Group Leader will be discussed next.
Group Leaders
In cases where you need to grant the ability to manage a group to users who do not have the ability to create / modify Livelink groups, you can utilize Group Leader functionality in Livelink. The Group Leader has the ability to ADD and REMOVE group members as deemed appropriate. A Group Leader configured with groups of two or more people is recommended for managing each group. This can eliminate problems caused by absences, transfers, and terminations. Workspace Managers should advise each person requesting a group of the use and benefits of using leader groups for groups. The Group Leader should assign another member of the owner/leader group to complete tasks whenever the Group Leader is unavailable and must designate a new Group Leader before leaving the group or organization. The corresponding information is stored to the KUAF.Children table.
Figure 40
Regardless of who is adding a user to a LES system, a series of data entries are made to the LES server and its associated database, including: New (unique) user ID bound to the new user account (KUAF.ID) User is assigned a primary group or Department with their user profile. The user profile also permits the storage of additional biographical information or metadata including
www.opentext.com
51
Best Practices
Document Title
General Tab password, first name, last name, middle initial, [job] title, email address, phone, fax, office location, time zone 14 (**) and lastly privileges Personal Tab photo (must be stored in Livelink), Gender, Birthday, Alternate Email, home address, phone, fax, cellular, pager, home page, Favorite Links, Interests
As a user is added to additional groups, the user can see what groups they have been added to using | Personal | My Groups |:
Figure 41
Best practice considerations for assigning User and Group privileges:

In security situations, the Security Department may be exclusively responsible for administering users and groups If Knowledge Mangers are responsible for administering knowledge and thus content within a Livelink System, there will be no need to grant these Knowledge Managers any user or group management rights If Knowledge Mangers share equal responsibility for administering both knowledge or content as well as users and groups, the level of rights to administer users and groups must be established If granting the User Administrator privilege is required to meet various business needs or goals, these users will have system wide rights to manipulate and manage the entire user and group population of the Livelink system. This level of authority may not wish to be casually granted If a user with the Create/Modify User or the Create/Modify Group privilege creates a group they will be able to make subsequent modifications; a similar user who did not create or own the account Use of the Group Leader functionality is a great choice when a company wants to provide decentralized user administration or where they do not wish to grant system wide rights to administer the users and groups. When Group Leaders are
14
time zone is for information purposes only; it is cosmetic and has no functional role, particularly when it comes to Time Zone Offset.
www.opentext.com
52
Best Practices
Document Title
used, at least 2 users should be part of the sub-group and made Group Leaders to prevent creating weak links in their management of the users and groups
1.
Why the 1000 user/group per group limit as found in the Opentext.ini file?
In a word performance. When Livelink checks for permissions (i.e., user rights), it must expand all of the groups and also take the union set of the permissions that a specific user may have and then grant the set of permissions which is most enabling. If a group was to contain more than 1000 entries, the systems performance would begin to degrade. As the number of users in group continued to grow away from that 1000 limit, the performance would continue to degrade. The best practice is to keep the design of groups within the recommended 1000 user/group limit.
2.
How can an organization establish a company-wide group if there is a limit?

This can be easily addressed. Although a single group should not have more than 1000 entries, there is nothing preventing us from adding 1000 sub-groups within the group. A single company-wide group consisting of 1000 sub-groups where each of the sub-groups contained 1000 users, this arrangement could accommodate 1000 x 1000 or 1,000,000 users.
www.opentext.com
53
Best Practices
Document Title
Directory Services
Although this document does not discuss the subject of Directory Services, there are some things to remember about Authentication. It is imperative that organizations understand the impact of implementing Livelink Directory Services without first establishing a reliable community model. Many external directory (users & groups) sources do not facilitate nested groups (groups that are subgroups of other groups). Simple groups of users are fine for creating distribution lists for email and access control groups for certain applications, but these groups will simply not suffice for the granular permission needs of corporate knowledge assets stored in Livelink. The proper way to implement Livelink Directory Services therefore, is as follows: 1. Design the nested group of the community model for use in Livelink portion (users will be created/assigned in the external directory source) 2. Create and nest groups (set parent/child group relationship) in Livelink as recommended in this document 3. Create a list of all groups created in step 2 above that will contain at least 1 or more Livelink users. Do not list Livelink parent groups that only contain other groups 4. Create these groups (from step 3), using identical group names, in the external directory source 5. Create and/or assign users to their appropriate base group (created in step 4) in the external directory source 6. Synchronize Livelink to the new or updated external directory source (assumes Livelink Directory Services has been installed) This method will ensure that both users, and the groups that each of these users belong to, can be administered centrally in the external directory source. Livelink Directory Services synchronization will then mirror the external directory by importing these users into the identically named and hierarchically nested Livelink group. If a user moves to a different base group or leaves the company, simply make the change in the external directory source and it will be automatically updated in Livelink during the next scheduled synchronization. Please keep the following issues in mind when using this approach: Remember to properly nest groups in Livelink that were created by a recently imported (synchronized), newly created group in the external directory source i.e. not created first in Livelink Failure to create the appropriately nested group with an identical name in Livelink prior to synchronization of newly created groups in the external directory source, youll have to manually add (nest) these groups into their appropriate parent group in Livelink once they have been imported The best approach is to always repeat steps 2 through 6 above every time there is a need to add new groups
www.opentext.com
54
Best Practices
Document Title
NOTE: If an organization is planning to make use of Directory Services and a corresponding LDAP or Active Directory source, it is important to remember to definitely take the time to map the groups for synchronization so all synched users go directly into a the correct group(s) and that other best practices (like 1000 users/groups per group) are also observed.
www.opentext.com
55
Best Practices
Document Title
Back to the Basics -- Modeling

LES is flexible and robust enough to allow the implementation of a single user and group model not unlike that encountered with active directory or better yet, designers can select elements or characteristics from various modules and integrate them into their own unique blend to meet the challenges of managing the life cycle of Enterprise content and making corporate or organization information easier to manage! In previous sections of this document, the concept of different group modeling was introduced: Org Chart Functional Role Similar Needs Geographic Regions Skill-Knowledge Level
Although there is an illustrated example of a Mixed Taxonomy published in the System Administration course (97-201, Figure 13.1), another possible representation of the same concept is diagrammed below 15 . The idea is that in addition to classical groups, additional functional or role-based groups can be established to assist with the managing of Enterprise content within a Livelink system over the life cycle of the various documents contained within it.
Figure 42
15
Open Text PS. KM Livelink Configuration. 6 Feb 2002.
www.opentext.com
56
Best Practices
Document Title
Begin the modeling process by looking at Group Hierarchy (perhaps beginning with Org Chart principals) and then mapping or determining what function each group will serve, and then mapping the relationship between them. A Livelink Group can be defined as either a container for other Livelink Groups or a container for Livelink Users. All Livelink Groups will therefore fall into one of the following categories: Container Group a Livelink Group that is the parent of (contains) one or more other (child) Groups. Base Group Existing only at the lowest level of a particular path in the Group Hierarchy, Base Groups are the only Groups that serve as containers for Livelink Users. Livelink Enterprise Group a top-level Container Group that is the (eventual) parent of all other Groups. This Group plays an important role in Permissions Modeling to displace the use of the Livelink [Public] access feature. Communities Container Groups used to segregate the Internal, External, and Role-based Group hierarchies. A Community in this context is a cross-functional group that may contain users or other groups from different Company Departments and areas. Division Groups Container Groups for lower level child Groups that represent an organizational business unit or department. As previously discussed, establishing and following a naming convention for the groups is an important consideration for ongoing administration, usability, and extendibility. A good naming convention provides the following benefits: Provides a hierarchically sorted list of groups when using Livelink Helps users understand which groups belong to other groups Makes assigning permissions to knowledge assets powerfully simple Makes assigning users to their respective base group straightforward Creates a common naming structure for use when synchronizing users & groups to an external directory source with the Livelink Directory Services Module Aids in LiveReports used to analyze users and groups Significantly reduces the level of effort required to maintain the Community Model
External (User Groups) The external users will only have permission to access projects or containers that there is need for collaboration or knowledge sharing. Role (Functional Role) Groups Container Groups for lower level child Role Groups or for Livelink Users who perform specific system-related roles or belong to a cross-functional team privy to information not managed by a Livelink Project. For example there may be a set of people who are responsible for administering and managing Workflow instances. Geographic Region Groups Groups may be arranged based on geographic regions. For example North America, EMEA (Europe + Middle East + Africa).
www.opentext.com
57
Best Practices
Document Title
Skill Knowledge Groups Groups may be arranged based on a similar skill level or need to access certain content. For example technical article reviewers may be the only other users who need to access and interact with technical draft documents besides the original authors and editors. The following is a list of best practice recommendations for community and information modeling in Livelink (from e-methods): The group hierarchies defined under Internal Users should be as granular as possible. This will make assigning permissions much simpler and more precise. Add <Company Name> users into the lowest-level group to which they actually report or belong to within an organization The ACL for an object should be as short as possible. Ideally this should be no larger than 5-6 ACLs (remember that ACLs are loaded into memory) In most cases apply the correct set of ACL at the upper folder level of a subject area and make sub items inherit this ACL. Apply the least permissions at the top of the content hierarchy and apply more specific permissions near the bottom of this hierarchy Do not assign individual users to the ACL of an object. Always assign groups even if it there is only one user in the group If a user falls into the Default Group they will only have access to the Default User folder and will need to follow instructions in the folder to be granted access to the <Company Name> Livelink instance Do not grant permissions to Public Access anywhere in the folder hierarchy
Turn Public Access On or Off for Livelink Users

A best practice recommendation on the previous page stated that Public Access (with respect to Access Control Lists) should be turned off. While this remains a best practice, there is a consequence to this choice when it is implemented. Leaving Public Access enabled on the various Access Control Lists means that Livelink has an easier time determining when a user has access to documents and folders, so there would be a corresponding performance gain within the Livelink system. The choice of enabling or disabling Public Access on the various Access Control Lists in Livelink is usually determined based on security concerns within the organization. This is an example of the Public Access entry appearing on a typical Access Control List:
www.opentext.com
58
Best Practices
Document Title
Figure 43
The Public Access described above should not be confused with another pair of similarly named terms. A similar term also called Public Access appears on the Project Participants Tab which makes the Project accessible to all Livelink users who have the Public Access privilege.
Figure 44
The Public Access privilege is specified on the user profile page as illustrated below:
Figure 45
Consequences of Disabling a Users Public Access

If a Livelink user, who is responsible for administering the user community, was to disable the Public Access to a users profile, the user would usually not be able to login to the Enterprise Workspace and the system would generate an error message.
www.opentext.com
59
Best Practices
Document Title
Figure 46
A user who has Public Access will be able to login to the Enterprise Workspace and additionally be able to perform searches against the available search indices or slices.
Figure 47
However, if Public Access for the user is revoked, the usual quick search bar and related GUI components will not be available to them.
Figure 48
This behavior is consistent with the permission-based implementation of the Livelink system. If the Admin User was to navigate to the Slice folder within the System Object Volume (SOV), they would see a series of stored search queries corresponding to the various search slices or indices. Here is a screenshot of the Slice folder within the SOV:
www.opentext.com
60
Best Practices
Document Title
Figure 49
A further inspection of the Access Control List of the Slice Folder (or any of the individual queries stored within the folder) would reveal that Public Access has See and See Contents permissions. Unless the user was part of the Default Group or the Admin User, in this example, they would not have access to any of the Search Slices nor the search interface that was illustrated in previous screenshots.
Figure 50
The search interface for the user could be re-established by either re-enabling their Public Access on their user profile or by alternatively listing them (or a group they belong to) on the Access Control List for the needed Search Queries or Slices in the above Slice Folder and granting See and See Contents permissions.
www.opentext.com
61
Best Practices
Document Title
No Single Way
There is no single way or strict list of Best Practices that can be rigorously followed in the design and implementation of users and groups that will result in meteoric success (or failure). The design of users and groups will vary greatly from one organization to another or even one system to another, but there are methodologies that can be followed to ensure more cases of success rather than failures.
User Group Modeling Methodology

The key to designing a robust community model is to understand what business problem the organization is trying to solve. In order to do that, many questions need to be asked relating to the current and future operations of the business. The answers to the questions below will drive the creation of the community model: How is your organization structured? Hierarchically or laterally? Do you use a LDAP server or Directory Services to authenticate network users? Will the information stored in Livelink need to be arranged by division? Who adds users and groups? Will there be central or departmental administrators? How will information be maintained in Livelink? Will there be departmental knowledge managers? What groups will need to exist to support workflow routing? What workflows will be developed?
The following is a list of best practice recommendations for community modeling in Livelink: Groups should not contain more than 1000 objects (users or groups). The group hierarchies defined under Internal Users and External User should be as granular as possible. This will make assigning permissions much simpler and more precise. Add users into the lowest-level group to which they actually report or belong to under Internal Users or External Users.
In Livelink, a Livelink user has to belong to at least one group. This group that is captured as Department in user configuration page is Base Group. Users must belong to at least one group
Here is a summary of Best Practices regarding the [Department:] setting in the User Profile: Base Groups are the only Groups that should serve as containers for Livelink Users and exist only at the lowest level of a particular path in the Group Hierarchy Livelink Group should not contain both Users and other child Groups
www.opentext.com
62
Best Practices
Document Title
Managers and other Users who may have responsibility for, or perform duties across multiple departments. These may include administrators that work for multiple departments, however, Managers and Administrators should not belong in a Group that is the parent of (contains) other Groups. In other words, a Vice President of Sales User should not be put in a higher-level Sales Group that is the parent of two other child sales Groups. Instead, another child Group should be created as the Base Group to hold this User
Data Gathering
Before analysis can be performed to determine the best structure for users and groups within the Company, several pieces of information need to be obtained. These components and the information elements needed for analysis are explained below. Organizational charts understand which departments are sub departments of others Roles or Job Functionality Geography Skill Levels User Profile information its important to have a certain number of Users in the system to demonstrate the structure of the model and how it can be maintained and extended.
Key Questions in information gathering

What are your currently available users and groups, if any? If a Livelink hierarchy has been initially drafted or planned out, can the above users and groups be mapped to this hierarchy? Duplications? Any gaps or wholes? One office? Centralized? Multiple offices? Decentralized? One business activity? Multiple activities? User and group management centralized like A/D or LDAP? Need to spontaneously create groups? Plan for user-based growth? Policy for deleting users? Policy for disabling users? Org Chart Departmental? Hyperlinked, role-based or cross functional groups? Will the system have external users (extranet) or internal users (intranet)?
www.opentext.com
63
Best Practices
Document Title
Analysis
After the data gathering stage has been completed, analysis of the organizational charts can begin. A rough sketch of the group model can be drawn up at this time to include the top-level groups in the organization. Detailed analysis should be conducted during this stage to determine the how the group model will incorporate groups of administrators, workflow task groups, and functional groups requiring access to specific information within the enterprise.
Design
In this stage, a more complete group model is developed. This model should include all organizational groups of individuals who will have access to the Livelink system as well as those higher-level groups to which additional members of the Company within the organization will be added at a later time.
Groups of Administrators should be present in this model as well as the task groups to which workflows will be routed. Cross functional groups should exist in this model such that specific areas of collaboration can be assigned to them during the information-modeling phase. A common way of representing this information is in a flowchart type drawing or in a spreadsheet format.
Implementation
After the model has been developed, the user and group information is ready to be entered into Livelink. If no automation is required, the information gathered in the data gathering stage and the structure developed in the design stage must now be assembled and entered into Livelink using the standard GUI interface. For complex group models, Open Text offers alternative solutions where user and/or group information is inserted into Livelink including the Directory Services Module or using LAPI to program code that allows the importing of a CSV file.
Impact of User and Groups on Deployment of Access Rights to Livelink Documents

As previously stated, Livelink Groups provides a means by which access can be granted to Livelink nodes such as folders and documents. These Groups can also be used during the design of Workflow Maps or be used to assign System Privileges such as the ability to create Projects or Customviews. Keep in mind a few salient points regarding Livelink ACLs (Access Control Lists) and Livelink Groups:
www.opentext.com
64
Best Practices
Document Title
Keep the group nesting and structure simple to aid in future troubleshooting. The more levels and complexity of group nesting that is employed, the more difficult or complex the tracking of rights and permissions will become Avoid adding individual users to the ACL of an object. Always assign groups even if it there is only one user in the group Group membership are loaded at login time and there should be no difficulty in loading or using several thousand groups as long as the membership list for the group is short
Here is an example of ineffective use of Groups applied to an ACL. Before explaining why the ACL illustration to the left is ineffective, consider what the underlying business purpose of the Access Control List is. The ACL is provided as a means by which access to documents and other material can be controlled. Presumably, some people within the organization need to read (See, See Contents) the document while others need to update it (Reserve), while yet others need to manage the content and control permissions (Edit Permissions). If this organization generally shares information and have few secrets, Figure 51 then the use of groups could be established as follows: Knowledge Managers Full Control Managers, Directors, VPs No Edit Perms Team Leads, Senior Staff Delete Version General CS Staff Add, Reserve Organization See, See Contents
www.opentext.com
65
Best Practices
Document Title
This simplification means a rather long and complicated access control list can be reduced to a handful of entries, thus: OT-CS-KnowledgeManagers Group will be the Owner Group { See, See Contents, Modify, Edit Attribute, Add Item, Reserve, Delete Version, Delete, Edit Permissions }
Open Text (Company or Organization) Group { See, See Contents }
OT-CS-Managers Group { See, See Contents, Modify, Edit Attribute, Add Item, Reserve, Delete Version, Delete }
OT-CS-TeamLeads Group { See, See Contents, Modify, Edit Attribute, Add Item, Reserve, Delete Version }
OT-CS-Staff Group { See, See Contents, Modify, Edit Attribute, Add Item, Reserve }
Figure 52
If this same concept is applied, beginning at the top of a LES Enterprise Workspace, the total number of needed groups could be estimated as number of departments times 4.
www.opentext.com
66
Best Practices
Document Title
Diagrammatically, this concept would show that as a Manager navigated deeper down into their own content, additional department-related groups would be added to the Access Control Lists, so that as they approached their own departmental area, the ACL might only have several groups being listed.
Figure 53
NOTE: This is used for critical information (showstoppers). STOP and READ THIS FIRST is what is implied. Without this information the system may be compromised or data lost A comprehensive discussion of Livelink ACLs and permissions is outside of the scope of this document.
www.opentext.com
67
Best Practices
Document Title
Mature Systems
Returning to the previously mentioned second group of readers and Livelink Administrators, including those who already have one or more Livelink installations that could be considered as being mature, there are additional considerations that must be made. Acknowledging that their LES system was originally installed some time ago and has enjoyed considerable growth, perhaps during various stages in its lifecycle. These Administrators needs to review how their user and group community has been implemented and consider how it is affecting the overall usability and performance of their Livelink System. Over time, the Company may have experienced growth spurts or may have merged or assimilated other companies into itself. During the examination and reassessment of the user and group structure of the mature LES system, a review of best practices is also in order and implementation of any needed changes to the existing structure to the presented best practices in this document. A review of best practices or recommendations in the following areas is advisable: Users and Groups from the Admin Pages Users and Groups from the Opentext.ini File Key Tables that Affect Storage and Maintenance of Users and Groups Understanding User Licensing Distinguishing Active, Disabled and Deleted User Accounts How Customers Secure New License Keys General User and Group Best Practices and Considerations Managing User Accounts Groups Recursive Groups Group Strategy and Design Principals Group Naming Conventions for Usability Creating a Group Group Notification Deleting a Group User Rights or Privileges and Assigning Rights to Users or Groups Group Management and the Responsibility for Creating and Managing Groups Who Specifically Can Create, Edit and Delete Users and Groups? Why 1000 Users/Groups per Group Limit?
www.opentext.com
68
Best Practices
Document Title
Directory Services Back to the Basics Modeling Turn Public Access On or Off for Livelink Users Consequences of Disabling a Users Public Access User Group Modeling Methodology Data Gathering Impact of User and Groups on Deployment of Access Rights to Livelink Documents Mature Systems
www.opentext.com
69
Best Practices
Document Title
Taking a Survey of Current System and Where Things are Right Now
User and Group Verification
Using the built-in functionality from the Admin pages, it is advisable for the Livelink Administrator to run a Level 4 database diagnostic to identify any existing User and Group issues occurring at the database table level. The database verification is available from the Livelink Admin Pages | Database Administration | Maintain Current Database | Verify This Database | Level 4: Verify Users and Groups
Figure 54
What actually happens during the database verifications? For those familiar with the SDK Builder Development Environment, the corresponding modular code and related documentation can be found in | DBWIZAPI | DBWIZAPIRoot | VerifyPkg. Here is some of the key information extracted from a documentation feature within the above object: | DBWIZAPI | DBWIZAPIRoot | VerifyPkg VerifyPkg performs simple SQL queries against a Livelink database to find any errors in the Livelink schema or in the storage of Livelink information. VerifyPkg consists of a family of groups, each of which contains verification objects capable of performing independent verifications, and each of which returns a recArray of error information. The recArray is used by each verification object in the group for recording and reporting errors found in the database. fTableName Contains the string name of the database table being queried/verified. DBCols Contains the database columns needed to verify the table named in .fTableName and to report errors found. fWhereClause Contains the where clause of the select statement performed by the verification object. When combined with the .fTableName and .DBCols features, a complete SQL statement is formed for execution in the .Execute feature. fErrorMsg The text of the error message describing the problems detected by the verification object.
www.opentext.com
70
Best Practices
Document Title
The following are the current User-and-Group-related testing that is performed during the Level 4 Diagnostic GROUP NAME: KUAF GROUP NAME: KUAFChildren GROUP NAME: KUAFUser Administrators can also perform a customer verification from the same | Database Administration | Maintain Current Database | Verify This Database | interface: Go to Custom Verification Options
Figure 55
Verify the existence of members and leaders of groups Verify that each group recorded on KUAFChildren exists. Again, for those familiar with the SDK Builder Development Environment, the corresponding modular code can be found in | DBWIZAPI | DBWIZAPIRoot | VerifyPkg | KUAFChildren | | VerGroupmembers | Description: This function checks that an actual user exists for each ChildID on the KUAFChildren also | VerKUAFChildrenIDs | Description: This function checks that an actual group exists for each ID on the KUAFChildren table or group member
www.opentext.com
71
Best Practices
Document Title
Deal with Group Recursivity

Determine if there is any existing cyclic or recursive groups, correct the faulty recursivity and prevent the creation of future cyclic groups. The following document discusses the concept of a Recursive Group in greater detail and provides recommendations how to eliminate recursive groups.
https://knowledge.opentext.com/knowledge/llisapi.dll?func=ll&objId=9727109&objAction=prope rties&nexturl=%2Fknowledge%2Fllisapi%2Edll%3Ffunc%3Dll%26objid%3D6849437%26objAc tion%3Dbrowse%26sort%3Dname
The previous section in this document also provides details on the Prevent Recursive Group administrative setting.
Completely Lost: Must Output List of Users and Groups?

For those Livelink Administrators who find themselves completely lost and there seems to be no way to sort out their mature User and Group structure, do NOT use LiveReports. Instead, consider using a LAPI program to generate the needed output (see Appendix B for an example of the code that could be used).
www.opentext.com
72
Best Practices
Document Title
Glossary
Access Control List or ACL The list of users and groups with some sort of access permissions to a Livelink item. Administration Pages The Livelink Administration pages are accessed by the Livelink Administrator. Many maintenance functions are performed by accessing these pages including: enabling versions, browsing LiveReports, configuring server parameters, adding modules, creating indices, viewing and configuring audit trails, and restricting access. Department The group to which a user is assigned when the users login is first created. The user can be a member of any number of other groups, in addition to the group defined as the users Department group. Often your Livelink Department corresponds to the department you work in within your organization, but this is not a requirement. Enterprise Hierarchy The hierarchy of folders, documents, projects, and other items that is viewed from the Enterprise Workspace. Enterprise Workspace The Livelink location that serves as a public repository for shared knowledge. The Enterprise Workspace comprises a hierarchy of folders and other containers. See also Workspace. Group A subset of Livelink users. You can organize users who share common interests as a group. Users can belong to more than one group, and you can place groups inside other groups. Livelink Administrator The person at your organization who is responsible for creating user accounts and for maintaining and supporting Livelink on a day-to-day basis. Notification A feature that notifies you when specified Livelink events of interest happen. Notification reports can be viewed from the Notification page in Personal and Project menus in Livelink, and Personal Notification reports can be set for regular e-mail delivery. The interests about which you would like to be notified and schedule settings are configured from the Notification page in the Personal menu. Project coordinators can configure notification pages within projects. The Notification functionality is available only if your Livelink Administrator enabled Notification on the administration pages. Notification Report The messages generated by Livelink Notification according to time settings specified by a user or project coordinator. Each user can customize three report settings for
www.opentext.com
73
Best Practices
Document Title
personal use, and these are normally e-mailed to the user. Project coordinators can define up to three report settings for each project, and these reports are not e-mailed. Owner In the context of permissions, the first item on the ACL of a Livelink item. The Owner is initially set to the login of the user who created the item. The Owner can be changed to another user. The Owner permissions are copied to a new Livelink item from the parent of the item, and the name of the Owner of the new item is changed to be the user who created the new item. When setting the permissions for the Owner of a folder or other container, therefore, it is important to consider the permissions as the default permissions given to any user who adds an item to the container. Owner Group A special group of users on the ACL of a Livelink item. When an item is created, the Owner Group is copied from the items parent, as well as the permissions for the Owner Group. The Owner Group can be changed to another group. Often, the Owner Group is set to the group of knowledge managers for the item, and the Owner Group is given all permissions to the item. Privileges The set of rules that define basic parameters for what the user can do within the Livelink system, such as whether the user can log in, create a user, or create a group. Basic privileges are set when the user is created, as part of the users profile. The Livelink Administrator also has the ability to set item creation privileges from the Livelink Administration pages. User Profile The relevant information defining a Livelink user. The Livelink Administrator (and other users with the proper privileges) creates an account for each Livelink user, profiling their log-in name and password, full name, contact information, electronic mail information, and privileges.
www.opentext.com
74
Best Practices
Document Title
Appendix A: Database Activity during Creation and Deletion of a Livelink Group

NOTE: This is used for background information on a topic The following information was extracted from a LES 9.7.1 connect log using debug=2 with logging enabled during the following principal activities: Create new group Populate group with users and groups Set group notifications Establish this new group as a group leader for an existing group Delete the new group KUAF KUAFChildren KUAFPrefs NotifyInterests0 NotifyMessages AgentSchedule
Notice how the following tables are written to or updated:
update KUAFChildren set ID=:A0 where ID=:A0 and ChildID <snip> update KUAF set OwnerID=:A0 where OwnerID=:A0 | 1 | update KID set ID=ID+:A0 where IDType=0 | 1 | | | | | | | | | | | |
insert into KUAFChildren values (:A0,:A0) | 11 | delete from KUAFPrefs where PrefsID=:A0 | 1 | |
update KUAF set Name=:A0,Deleted=:A0 where ID=:A0 | 1 |
select * from AgentSchedule where UserID=:A0 and AgentID=:A0 | 3 |
select b.* from KUAFChildren a,KUAF b where a.ID=:A0 and a.ChildID=b.ID | 48 | | | select * from KUAF a where Deleted = 0 and Type = :A0 and SpaceID = :A0 and <snip> select * from NotifyInterests0 where UserID=:A0 | 1 | | |
select OwnerID, SpaceID, Name, UserPWD, PWDExpireDate, PWDExpireMode from KUAF <snip> select Type from KUAF where ID=:A0 and Deleted=0 | 11 | update KUAF set LeaderID=:A0 where ID=:A0 | 1 | | | from KUAF where | |
select ID,OwnerID,Type,SpaceID,Name,LeaderID,UserPrivileges ID=:A0 | 12 | | | select UserPrivileges from KUAF where ID=:A0 | 6 | | |
select ID from KUAFChildren where ID=:A0 and ChildID=:A0 | 11 |
www.opentext.com
75
Best Practices
Document Title
insert v<snip>
into
KUAF
(ID,OwnerID,Type,SpaceID,Name,UserData,LeaderID,Deleted)
select * from KUAF where Type=:A0 and SpaceID=:A0 and Deleted=0 order by Name | 4 | | | select * from AgentConfig where ConfigID=:A0 | 4 | | | | |
insert into NotifyInterests0 values (:A0,:A0,:A0,:A0) | 1 |
select PrefsValue from KUAFPrefs where PrefsID=:A0 and PrefsKeyword=:A0 | 4 | | | select a.*, from KUAF a,KUAF b where a.Type=:A0 and a.SpaceID=:A0 and <snip> select OwnerID,DataID,PermID,Name from DTree a where ((DataID in (-0,-0))) | 2 | | | update KUAF set GroupID=:A0 where GroupID=:A0 | 1 | | |
delete from KUAFChildren where ID=:A0 and ChildID in <snip> update KUAF set LeaderID=:A0 where LeaderID=:A0 | 1 | delete from NotifyMessages where UserID=:A0 | 1 | delete from KUAFChildren where ID=:A0 | 1 | | | | | | | | |
select ID from KUAF where Type=:A0 and SpaceID=:A0 and Name=:A0 | 2 |
select Type, OwnerID, LeaderID, SpaceID from KUAF where ID=:A0 and Deleted=0 | 11 | | | select * from KUAF where ID=:A0 | 80 | | | | | | |
delete from KUAFChildren where ChildID=:A0 | 1 |
select a.* from KUAF a,KUAF b where a.ID=:A0 and a.GroupID=b.ID | 17 |
select * from KUAF a where Deleted = 0 and Type = :A0 and SpaceID = :A0 and <snip> delete from NotifyInterests0 where UserID=:A0 | 1 | select * from KUAF where ID in (0) | 9 | select ID from KID where IDType=0 | 1 | | | | | | |
insert into AgentSchedule ( UserID,AgentID,Enabled,<snip> delete from AgentSchedule where UserID=:A0 | 1 | select <snip> from DTree where DataID=:A | 8 | | | | |
select * from KUAF a where Deleted = 0 and Type = :A0 and SpaceID = :A0 and <snip> select Name,Type from KUAF where ID=:A0 | 1 | | | | |
select * from KUAF where ID in (0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0) | 2 | insert into DAuditMore values ( :A0, :A0, :A0 ) | 13 | | | | |
delete from NotifyInterests0 where UserID=:A0 and NodeID=:A0 | 1 |
select distinct ProxyType from KUAFProxy where ProxyID=:A0 order by ProxyType | 6 | | |
www.opentext.com
76
Best Practices
Document Title
Appendix B: Example of LAPI Code for Outputting Livelink Users and Groups
mport com.opentext.api.*; import java.io.*; import java.util.*; import java.lang.*; // Recursively traverse the hierarchy of groups and display the groups, // subgroups, and users. Note the parameter 'level' is only for pretty printing public class listGroups { public static final int LL_OK = 0; public static final int GROUP = 1; public static void main( String[] args ) { try { int x; LLSession session; session = new LLSession( "localhost", 2099, "", "Admin", "livelink!" ); if ( Groups( session, "FirstTime", 0 ) == LL_OK ) { System.out.println( "\n Output succeeded \n"); } else { System.out.println( "\n Output failed \n" ); } } catch ( Throwable e ) { String x = e.getClass().getName(); String s = e.getMessage(); e.printStackTrace(); } } // end of main public static int Groups( LLSession session, String groupname, int level ) { String str = ""; int i, j, gtype, id, len = 0; LLValue LAPI_USERS table = ( new LLValue() ).setAssocNotSet(); users = new LAPI_USERS( session );
// Is this the first time this fuction is called? // Return all groups in Livelink if ( groupname.compareTo( "FirstTime" ) == LL_OK ) { if ( users.ListGroups( GROUP, table ) != LL_OK ) { System.out.println( "\n Couldn't get info about all groups." ); return 1; }
www.opentext.com
77
Best Practices
Document Title
} else { // This method has been called at least once so get sub groups // Get all subgroups of this group if ( users.ListMembers( GROUP, groupname, table ) != LL_OK ) { System.out.println( "\n Couldn't get info about group " + groupname ); return 1; } } len = table.size(); for( i = 0; i < len; i++ ) { // for each group, check to see if it has sub groups id = table.toInteger( i, "ID" ); str = table.toString( i, "Name" ); gtype = table.toInteger( i, "Type" ); if ( gtype == GROUP ) { // We have a group. // Print some tabs for (j = 0; j < level; j++) System.out.print("\t"); System.out.print("Group " + str + " contains \n" ); level++; // This is a group so recursively call the fcn Groups( session, str, level ); level--; } else { // Must be a user // Print some tabs for (j = 0; j < level; j++) System.out.print("\t"); System.out.print( str + "\n" ); } } return LL_OK; } // end of Groups } // end of listGroups
www.opentext.com
78
Best Practices
Document Title
Appendix C: Summary of User and Group Best Practices

User Login names
Provide Unique login name (<= 64 characters prior to LES 971;; 255 characters 971 or later) Provide Domain name if required O/S limitations or restrictions; for example Windows 2000 only recognizes first 20 characters Active Directory only supports 64 characters Avoid invalid character, when using various operating systems like Windows "/\{}:;|=,+*?<> Login name may be case sensitive; for LES, it will depends on database installation
User Account Passwords

Passwords should be difficult to guess for added security Strong password including numbers and added characters Upper case, lower case, numbers, non-alphanumeric characters and must not contain the username
Group Nesting
Minimize levels of nesting. Minimum nesting will reduce added maintenance of the users and groups and will improve performance. There also needs to be a good understanding how the groups will be utilized within the LES system. System performance. System performance will be impacted relative to the effective (or ineffective) nesting of groups. Proper nesting may also reduce network traffic (i.e. repeated database queries and checking for access rights) and simplify administration. Keep it simple to aid in future troubleshooting. The more levels and complexity of group nesting that is employed, the more difficult or complex the tracking of rights and permissions will become. Document nested group structure. There should be documentation on your LES group structure and membership. Tracking or documenting the users and groups can help in reducing clutter and eliminate or reduce un-needed duplication in groups. The documentation may also assist in preventing or avoiding group recursivity
www.opentext.com
79
Best Practices
Document Title
Group Names
Names should be easily recognized groups and administrators or knowledge managers do not have to guess at their meaning Similar groups should have similar names
A good naming convention provides the following benefits: Provides a hierarchically sorted list of Groups when using Livelink Helps Users understand which Groups belong to other Groups Makes assigning Permissions to knowledge assets powerfully simple Makes assigning Users to their respective base Group straightforward Creates a common naming structure for use when synchronizing Users & Groups to an external directory source with the Livelink Directory Services Module Aids in LiveReports used to analyze users and groups Significantly reduces the level of effort required to maintain the Community Model
Group and User Types

Not every group can fit into an org chart Regardless of your user and group formulation, keep duplication to a minimum and streamline where possible Create a company everyone group and do not use LES Public Access
Creating a Group
Organize users into Can-See and Can-Reserve functional groups to be used in applying permissions Assigning Workflow Steps to a Group rather than hard-coding an individual user making the WF Map easy to update when users change jobs Remember to strike a balance between the business needs of having additional groups and the overhead that will be created in having to maintain them If these groups are to be portable between systems, use the lowest common characteristics (i.e., 48 characters)
Assigning User and Group privileges:

In security situations, the Security Department may be exclusively responsible for administering users and groups If Knowledge Mangers are responsible for administering knowledge and thus content within a Livelink System, there will be no need to grant these Knowledge Managers any user or group management rights
www.opentext.com
80
Best Practices
Document Title
If Knowledge Mangers share equal responsibility for administering both knowledge or content as well as users and groups, the level of rights to administer users and groups must be established If granting the User Administrator privilege is required to meet various business needs or goals, these users will have system wide rights to manipulate and manage the entire user and group population of the Livelink system. This level of authority may not wish to be casually granted If a user with the Create/Modify User or the Create/Modify Group privilege creates a group they will be able to make subsequent modifications; unlike a user who did not create or own the account Use of the Group Leader functionality is a great choice when a company wants to provide decentralized user administration or where they do not wish to grant system wide rights to administer the users and groups. When Group Leaders are used, at least two users should be part of the sub-group and made Group Leaders to prevent creating weak links in their management of the users and groups Avoid individual users to the ACL of an object. Always assign groups even if it there is only one user in the group Do not grant permissions to Public Access anywhere in the folder hierarchy If a user falls into the Default Group they will only have access to the Default User folder and will need to follow instructions in the folder to be granted access to the <Company Name> Livelink instance The group hierarchies defined under Internal Users and External User should be as granular as possible. This will make assigning permissions much simpler and more precise. Add users into the lowest-level group to which they actually report or belong to under Internal Users or External Users. Users must belong to at least one group
Group Modeling
Groups should not contain more than 1000 objects (users or groups) The group hierarchies defined under Internal Users should be as granular as possible. This will make assigning permissions much simpler and more precise. Also, it reduces the possibility of exceeding 1000 objects within a group Add <Company Name> users into the lowest-level group to which they actually report or belong to within an organization The ACL for an object should be as short as possible. Ideally this should be no larger than 5-6 ACLs (remember that ACLs are loaded into memory) In most cases apply the correct set of ACL at the upper folder level of a subject area and make sub items inherit this ACL. Apply the least permissions at the top of the content hierarchy and apply more specific permissions near the bottom of this hierarchy
www.opentext.com
81
Best Practices
Document Title
Do not assign individual users to the ACL of an object. Always assign groups even if it there is only one user in the group Do not grant permissions to Public Access anywhere in the folder hierarchy If a user falls into the Default Group they will only have access to the Default User folder and will need to follow instructions in the folder to be granted access to the <Company Name> Livelink instance Users must belong to at least one group
[Department:] setting in the User Profile:

Base Groups are the only Groups that should serve as containers for Livelink Users and exist only at the lowest level of a particular path in the Group Hierarchy. Livelink Group should not contain both Users and other child Groups. Managers and other Users who may have responsibility for, or perform duties across multiple departments. These may include administrators that work for multiple departments, however, Managers and Administrators should not belong in a Group that is the parent of (contains) other Groups. In other words, a Vice President of Sales User should not be put in a higher-level Sales Group that is the parent of two other child sales Groups. Instead, another child Group should be created as the Base Group to hold this User.
www.opentext.com
82
Best Practices
Document Title
Credits
My sincere thanks and gratitude is extended to the following contributors to this Application Note for reviewing its content and providing invaluable feedback: Jamie Remes, Customer Support Communications Specialist, Open Text Corporation. Greg Kellogg, Technical Lead Consultant, Open Text Corporation. Kee Ng, Senior Software Architect, Open Text Corporation.
General Reference where no specific pages have been cited

Minasi, Mark etal. Mastering Windows Server 2003. M c. 2003. Sybex Inc. Pages 683-827. Russel, Charlie and Craeford, Charon. Microsoft Windows 2000 Server Administrators Companion. Microsoft Press. Redmond, Washington, USA. c. 2000. 1464 pages.
Disclaimer: The cited examples herein are intended to illustrate concepts but they are not / may not reflect or be associated with any real world company, organization, product person or event.
www.opentext.com
83
Best Practices
Document Title
Sales www.opentext.com
info@opentext.com
Americas United States

100 Tri-State Intl Parkway Lincolnshire, IL USA 60069 Phone: 847-267-9330 Fax: 847-267-9332
Europe Germany
Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Germany Phone: +49 89 4629 0 Fax: +49 89 4629 1199
Asia/Pacific United Kingdom Australia

Level 23 100 Miller St. North Sydney NSW 2060 Australia Phone: +61-2-9026-3400 Fax: +61-2-9026-3455
North America Sales

1-800-499-6544
International Sales
+800-4996-5440
Grosvenor House Horseshoe Crescent Beaconsfield, Buckinghamshire United Kingdom HP9 1LJ Phone: +44 1494 679700 Fax: +44 1494 679707
If you are an Open Text partner or customer, visit online.opentext.com for more information about this and other Open Text solutions. Open Text is a publicly traded company on the NASDAQ (OTEX) and the TSX (OTC).
Copyright 2008 by Open Text Corporation. Open Text, Livelink, Livelink ECM, and Great Minds Working Together are trademarks or registered trademarks of Open Text Corporation. All other trademarks or registered trademarks are the property of their respective owners. All rights reserved.
www.opentext.com
84

Livelink Users and Groups Explained With Best Practices (Ver 1 - Feb 2008)

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Livelink Users and Groups Explained With Best Practices (Ver 1 - Feb 2008)

Uploaded by

Copyright:

Available Formats

Product: Livelink ECM Enterprise Server Version: 9.5.x, 9.6.0, 9.7.

Livelink Users and Groups

Livelink Users and Groups

Champion Toolkit Document

Livelink Users and Groups

Champion Toolkit Document

Livelink Users and Groups

Champion Toolkit Document

Livelink Users and Groups

Champion Toolkit Document

Livelink Users and Groups

Champion Toolkit Document

Livelink Users and Groups

Champion Toolkit Document

Livelink Users and Groups

Champion Toolkit Document

Livelink Users and Groups

https://knowledge.opentext.com/knowledge/llisapi.dll?func=ll&objId=9808343&objActi on=properties&nexturl=%2Fknowledge%2Fllisapi%2Edll%3Ffunc%3Dll%26objid%3D 6849437%26objAction%3Dbrowse%26sort%3Dname

User and Group Settings from the Admin Pages

Configure Department Selection (drop-down list or department dialog)

Champion Toolkit Document

Livelink Users and Groups

Champion Toolkit Document

Livelink Users and Groups

Configure Group Settings (Prevent Recursive Groups)

Configure Password Settings

Champion Toolkit Document

Livelink Users and Groups

Configure User Name Display

Champion Toolkit Document

Livelink Users and Groups

User Tab Permissions

Champion Toolkit Document

Livelink Users and Groups

Champion Toolkit Document

Livelink Users and Groups

Communication (email). Feb 2008.

Champion Toolkit Document

Livelink Users and Groups

Champion Toolkit Document

Livelink Users and Groups

User and Group Settings from the Opentext.ini file

[UserSetting] RowColorOptions=#FFFFFF,#EEEEEE,#FFFFCC,#CCFFFF,#CCFFCC,#DDDDF F ColumnHeaderColorOptions=#CCCCCC,#A0B8C8,#83D8A4,#CCCC99 Row1Color=#FFFFFF Row2Color=#EEEEEE ColumnHeaderColor=#CCCCCC UserNameAppendID=1

[LicenseKeyInfo] CompanyName=Open Text - Customer Support ExpireDate=? NumUsers=500 LicenseKey=*******************************

Champion Toolkit Document

Livelink Users and Groups

Explanation of the Opentext.ini settings

License Key Section

Champion Toolkit Document

Livelink Users and Groups

Directory Services, LDAP and Other Considerations

Champion Toolkit Document

Livelink Users and Groups

Champion Toolkit Document

Livelink Users and Groups

Understanding User Licensing

Champion Toolkit Document

Livelink Users and Groups

What Does this Mean?

Configure Server Parameters Page

Champion Toolkit Document

Livelink Users and Groups

Using Up Available Licenses

Champion Toolkit Document