Lombardi Admin Training Notes 17dec2008

Lombardi Admin Training Notes 16dec2008

User/Role Management

First, we want to remove all the default user rights, create our own admin account, and assign our new user admin rights to everything (add them to all groups)

- Launch the teamworks process server console.  Login as tw_admin. Browse to teamworks admin->security->teamworks provider->maintain internal users
    - add a new admin user for yourself (im my case "bryan" is my admin user)
- tw_admin and tw_webservice are used by the system.  The other 4 default accounts could be deleted or disabled.  We need to keep tw_admin and tw_webservice.
- Groups under teamworks admin->security->teamworks provider->maintain groups
    - The admin group tw_admins_internal grants access to the process server console to any users in this group.  This group should not be deleted, its used internally by teamworks.
    - tw_portal_admins_internal grants access to the portal as an administrator.
- under group management teamworks admin->security->teamworks provider->group membership Remove all default tw_* users from all the groups.  Place your own admin user in each of these groups.
- Test to confirm the tw_* accounts have no access.  Login via the authoring tool and confirm you cant see any libraries.

Even at this point, the tw_* accounts can still login to the process admin console and change their password.  If they did this, it would break the server because those passwords are hard coded in config files.  We can remove access to the link and page that allows changing the password to everyone not in the tw_admin group.

Lock down the Change Password page
- Edit  C:\Teamworks61bsr\process-server\resources\console.xml
    - you can change the value of the constraint for the "Change Password" item, in order to disable the change password link and page from the admin console.

A closer look at groups and logical roles

- under teamworks admin->User Organization->All Roles you can manage the internal role hiarchy.
    - A role is a group or logical role
    - role naming conventions at lombardi is tw_<username> for a logical group or tw_<username>_internal for local groups

- under teamworks admin->User Organization->Logical Roles you can manage logical groups and membership
    - you can only add groups into one logical role.
    - AD groups will display in the "available roles" section of this page, so that you can directly assign AD groups to a logical group.
    - Logical roles can be then used in a participant group (only one group can be assigned to a single participant group) which then becomes the role assigned to a swim lane in the BPD.  The participant group gives us the rights to act on items in a given swim lane.



To change the tw_admin password (and/or username)

- change the tw_admin password in the admin console via teamworks admin->security->teamworks provider->maintain internal users
- shutdown the process server
- generate java encrypted password
- edit C:\Teamworks61bsr\process-server\resources\config\system\99Local.xml
- Change the encrypted password for tw_admin to match your newly encrypted password

    - continue to update the other startup config files in the same manner. There is no need to re-encrypt the password. Just copy from the one you created above.
        - C:\Teamworks61bsr\process-server\resources\config\system\80EventManager.xml
        - C:\Teamworks61bsr\process-server\tools\impexp\build.xml
        - C:\Teamworks61bsr\process-server\resources\config\system\50AppServer.xml
    - to change the tw_admin user or delete it, you must replace every instance of tw_admin user in these files with another valid user (it could be a local user account or a AD user account).

External Provider Security Issue to be aware of
- The login.xml file needs to have an account to connect to LDAP if LDAP is locked down.  The password and username is transmitted as clear text by default.  How can this be encrypted? 

Access Control (ACL's)
- Permissions can only be one of the following
    - Full Access
    - Read Only Access
    - No Access
- Permissions can only be set on folders, not assets/elements.  Assets are then grouped into folders.

Implementing ACL's
- if you create a folder or two, then create a new BPD, you can change ACL's on a folder by right clicking on it, then selecting "Access Control..."

 

- When setting permissions, teamworks uses a strange inheritance model of, the parent has the least permissions, the children have the most permissions.  In short, if your parent folder grants full access to tw_authors, you cant change a subfolder to give tw_authors read only access.
- you should make the root teamworks folder full control to tw_admins group, nobody else should have any access.
- The system folder should only have read only access.
- to set permissions on folders, you must be in the tw_admin group

The delete issue and ACL's
- when you delete an item, if its used by other items, it will warn you and prompt you to do a cascade delete of all dependencies. 
- If you have permissions to delete all the dependencies and you click okay, you will delete all the items. 
- If you dont have full access to one of the dependencies, your delete will fail if you try to do it, with a message saying you dont have access to delete one or more of the dependencies.

Group/Role Naming Conventions
- List of users and groups:
    - Local Lombardi Group - <groupname>_internal_group
    - external provider group (AD/LDAP) - <groupname>_external_group
    - Logical Role - <groupname>_lr
    - participant group - <groupname>_pg
- when you do an export, the only thing you take with you in the export is the participant group, which is mapped to a logical role (or list of users) that did not get exported. It must exist in the environment where you then later import that export.