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

Product:

Version:

Task/Topic:

Audience:

Platform:

Document ID:

Updated:

February 29, 2008

Best Practices Livelink Users and Groups

Livelink ECM – Enterprise Server

9.5.x, 9.6.0, 9.7.x

Features & Functionality

Administrators

All

700036

Colin T. Sim, Senior SDK Support Specialist (Certified Livelink SDK Developer & System Administrator)

Document Title

C h a m p i o n T o o l k i t D o c u m e n t w w w . o p e n t e x t . c o m


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

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 User’s 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

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

Document Title

C h a m p i o n T o o l k i t D o c u m e n t w w w . o p e n t e x t . c o m 1


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

Document Title



• Back to the Basics – Modeling

• Turn Public Access On or Off for Livelink Users

• Consequences of Disabling a User’s 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

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&objAction=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.

http://www.opentext.com/training/



Document Title Best Practices Livelink Users and Groups

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/744073/2598689/3692538/customview%2Ehtml?func=ll&objId=3692538 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 software’s 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:


https://knowledge.opentext.com/knowledge/llisapi.dll/fetch/2001/744073/2598689/3692538/customview%2Ehtml?func=ll&objId=3692538




https://knowledge.opentext.com/knowledge/llisapi.dll?func=ll&objId=9808343&objAction=properties&nexturl=%2Fknowledge%2Fllisapi%2Edll%3Ffunc%3Dll%26objid%3D6849437%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 pre-existing 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.






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



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:


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






• 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 user’s name. When activated, the user’s full first name and last name (etc) will be appended to their login ID.



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



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.

C h a m p i o n T o o l k i t D o c u m e n t w w w . o p e n t e x t . c o m 1 0


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 passwords1. 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

1 Bancroft, Chris. “Referencing Bug LPAD-12694 and ITSM ticket 353499”. Internal Customer Support Communication (email). Feb 2008.



The following table represents a synoptic view of these bit-masked KUAF.userprivileges binary and digital values used in the SQL statement above:

Privilege Bit(s) Binary Value Decimal Value

Login Enabled 0

Have a record 1, 2, 3 000000001111 15

User Administration 4 100001111111 2175

Create/Modify Users 5 100000101111 2095

Create/Modify Group 6 100001101111 2159

System Administration 8 100010111111 2431

Public Access 11 100000001111 2063

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.


http://www.opentext.com/training

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,#DDDDFF

ColumnHeaderColorOptions=#CCCCCC,#A0B8C8,#83D8A4,#CCCC99

Row1Color=#FFFFFF

Row2Color=#EEEEEE

ColumnHeaderColor=#CCCCCC

UserNameAppendID=1

[LicenseKeyInfo]

CompanyName=Open Text - Customer Support

ExpireDate=?

NumUsers=500

LicenseKey=*******************************


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 user’s 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.


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.


• 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&objId=13621570&objAction=properties&nexturl=%2Fknowledge%2Fllisapi%2Edll%3Ffunc%3Dll%26objid%3D13621345%26objAction%3Dbrowse%26sort%3Dname







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

2 Dobbie, Stacey. “ELUA Text and Terminology Used to Explain Livelink Licensing.” Internal Customer Support Communication (email). 29 Jan 2008.



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 Livelink’s 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



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.


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?


http://en.wikipedia.org/wiki/Concurrent_user





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.


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 who’s 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 who’s 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 in (0,1 )and floor(k.userprivileges / Power (2, 0)) %2 = 0

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:






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.



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


http://knowledge.opentext.com/


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 form-based page to request a new key.

Figure 22



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 [email protected] .


mailto:[email protected]

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.


User Login names3 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 Passwords4 • Passwords should be difficult to guess for added security

• Strong password including numbers and added characters (see previous section on LES password hardening)

3 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.




Document Title



• Upper case, lower case, numbers, non-alphanumeric characters must not contain username


Managing User Accounts

Disabling and Enabling Accounts For users with the appropriate privileges, they will have the rights to disable or re-enable 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 user’s 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 user’s 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.



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 user’s 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:


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.






Figure 27



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


Document Title



Group Nesting5 6 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.

5 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 6 Finnel, Lynn. MCSE Training Kit: Microsoft Windows 2000 Server. MCSE Study Guide for Exam 70-215. Microsoft Press. Redmond, Wahington. 2000.1033 pages.

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:


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).




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 Abbreviation

Project PRJ

Program PRGM

Community COM

Committee CMTE

Folder FLD

Legacy LGC

Workspace Manager WM

Consumer CONS

Contributor CNTR

Coordinator 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.


The first approach (illustrated in the diagram below, on the left) starts with the largest group or company–wide 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 community7.

Acronyms (also refer to the previous abbreviation table):

Top Level (Universe) Group Livelink Universe

Community Group Livelink Community – ABC Internal Users

Division, Role or Relational Group S:Sales

Level 1 child Group S-NA: Sales North America

Level 2 Child Group S-NA-SW: Sales North America Software

Base Group S-NA NA-SW SW-IN: Sales North America Software

7 Open Text PS. "Knowledge Management Community Modeling Design and Best Practices" 28 Feb 2002.


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) Group Livelink Universe

Community Group Livelink Community – ABC Internal Users

Division, Role or Relational Group 10000:Sales

Level 1 child Group 11000: Sales North America

Level 2 Child Group 11100: Sales North America Software

Base Group 11110: Sales North America Software

It’s 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 Types8 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)

8 Zimmerman, Maureen Williams. Microsoft Windows 2000 Professional Resource Kit. Microsoft Press. 2000. Redmond, Washington. 1767 pages.

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 Functional Role Similar Needs Org Regions Skill Level

• Finance

• IT

• Sales

• Support

• Marketing

• Support

• Administrative

• Executive

• Technical

• Manage users and groups

• Manage executing WFs

• Create Categories

• North America

• United Kingdom

• Europe

• Asia

• Pacific Rim

• Basic Skill

• Advanced Skill

Org Chart Type of work being performed

Task-based work Geography or location

Knowledge Based – skill based

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.


The same concept of creating and maintaining cross–functional 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)



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


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 department10

• Editing a user (changing the user’s department, adding the user to other groups, etc.) has no effect upon the user’s notification settings

• Once a user begins to set up their own notification, these settings no longer have any effect11

9 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. 11 Open Text Learning Services. Open Text Training Session 97-201. Enterprise Server – System Administration. Release 1.1. 15 Oct 2007.


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&objAction=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.

12 Open Text Learning Services. Open Text Training Session 97-201. Enterprise Server – System Administration. Release 1.1. 15 Oct 2007. 13 Open Text PS. “KM – Livelink Configuration”. 6 Feb 2002.





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 •KUAFChildren • KUAFPrefs

• NotifyInterests0 • NotifyMessages • 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 | | |



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.


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


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


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.

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 owner’s 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:


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 system’s data, you will be prompted to enter the Admin User’s password for these pages before being allowed to proceed further.





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



hire to perform their daily work. This process can be illustrated diagrammatically:

Figure 38

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

group administration is performed by their

who will or will not be able to manage the users and groups within a Livelink System.

In other Companies much of the user andInformation Technology (IT) department.

Regardless, considerations need to be made within each organization as to



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

Modify User

Delete User

Create Group

Modify Group

Delete Group

Create / Modify User Yes Only if Own

Only if Own

No No No

Create / Modify Group

No No No Yes Only if Own

Only if Own

User Administrator Yes Yes Yes Yes Yes Yes

System Administrator No No No No No No

Admin User Yes Yes Yes Yes Yes Yes

Group Leader No Yes Yes No Yes Yes

User Tab Right No Yes Yes No 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



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



• General Tab password, first name, last name, middle initial, [job] title, email address, phone, fax, office location, time zone14(**) 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.


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 system’s 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.

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, you’ll 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


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.



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 below15. 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.


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


• 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).

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 ACL’s (remember that ACL’s 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:


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 User’s Public Access If a Livelink user, who is responsible for administering the user community, was to disable the Public Access to a user’s profile, the user would usually not be able to login to the Enterprise Workspace and the system would generate an error message.



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:



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.


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

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 – it’s 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)?

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 ACL’s (Access Control Lists) and Livelink Groups:


• 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.

Figure 51

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, 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



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.



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 ACL’s and permissions is outside of the scope of this document.


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?

Document Title



• Directory Services

• Back to the Basics – Modeling

• Turn Public Access On or Off for Livelink Users

• Consequences of Disabling a User’s Public Access

• User Group Modeling Methodology

• Data Gathering

• Impact of User and Groups on Deployment of Access Rights to Livelink Documents

• Mature Systems


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.



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 or group member 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


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=properties&nexturl=%2Fknowledge%2Fllisapi%2Edll%3Ffunc%3Dll%26objid%3D6849437%26objAction%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).




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 user’s login is first created. The user can be a member of any number of other groups, in addition to the group defined as the user’s 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

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 item’s 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 user’s 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.


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 Notice how the following tables are written to or updated: • KUAF • KUAFChildren • KUAFPrefs • NotifyInterests0 • NotifyMessages • AgentSchedule

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 | | |

select ID,OwnerID,Type,SpaceID,Name,LeaderID,UserPrivileges from KUAF where ID=:A0 | 12 | | |

select UserPrivileges from KUAF where ID=:A0 | 6 | | |

select ID from KUAFChildren where ID=:A0 and ChildID=:A0 | 11 | | |


Document Title



insert into KUAF (ID,OwnerID,Type,SpaceID,Name,UserData,LeaderID,Deleted) v<snip>

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 | | |


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 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 | | |

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 table = ( new LLValue() ).setAssocNotSet(); LAPI_USERS 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; }

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

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

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


• 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

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



• 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.


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 ACL’s (remember that ACL’s 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

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




[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.

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.


Document Title

Sales Americas Europe Asia/Pacific www.opentext.com

[email protected] North America Sales

1-800-499-6544 International Sales

+800-4996-5440

United States 100 Tri-State Int’l Parkway

Lincolnshire, IL USA 60069

Phone: 847-267-9330 Fax: 847-267-9332

Germany Technopark 2

Werner-von-Siemens-Ring 20 D-85630 Grasbrunn

Germany Phone: +49 89 4629 0 Fax: +49 89 4629 1199

United Kingdom Grosvenor House

Horseshoe Crescent Beaconsfield, Buckinghamshire

United Kingdom HP9 1LJ Phone: +44 1494 679700

Fax: +44 1494 679707

Australia Level 23

100 Miller St. North Sydney

NSW 2060 Australia

Phone: +61-2-9026-3400 Fax: +61-2-9026-3455

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.

w w w . o p e n t e x t . c o m 8 4
