There are some significant differences between Tivoli Framework and Tivoli Endpoint Manager (Version 7) when it comes to creating and authenticating administrators and operators. These differences will need to be considered when migrating administrators from Framework to TEM.
Firstly looking at Tivoli Framework, when it was installed in my environment a root administrator was created which has administrator privileges on the Windows TMR. This root Administrator in my case is authenticated against the Windows operating system, any administrators that need access to Tivoli functionality need to be authenticated against a TMR or managed node’s host operating system.
Tivoli Framework supports multiple platforms for TMR’s and managed nodes, so there is also a function to map administrator accounts on different operating systems to an individual Tivoli Administrator.
To create a new Tivoli Administrator an existing Tivoli administrator needs to have the Senior role at TMR level, so there can be more than one Tivoli Administrator that is capable of creating new Administrators.
When a Tivoli Administrator is created it can represent a single user or a group of users that need access to the same Tivoli functionality. Which means multiple user logins can be assigned to a single Tivoli Administrator, simplifying the assignment of resources and roles.
Comparing this with TEM, when I installed the software a Site Admin was created, identified by the password protected site level signing key license.pvk. This site level signing key and password are required to run the TEM Administration Tool (used to create users), so don’t lose it as without it you cannot administer your TEM environment. Only users with access to the site level signing key and password will be able to create new TEM operators.
When creating a new TEM user in the TEM administration tool, you are required to provide a user name and password which are used to create the publisher.crt (certificate) and publisher.pvk(private key) files associated with this individual user. The publisher certificate is stored in the TEM database and the publisher.pvk file is required to login to the TEM console. The authentication for logging into the console is split into two parts:
The first part authenticates against the TEM SQL Server database.
The TEM console requires a 32-bit ODBC System DSN to be created to access the TEM BFEnterprise database, which has two methods for authentication SQL Server Authentication or Integrated Windows authentication. If your database is set to use SQL Server Authentication, then the username and password created in the TEM administration tool are required. Alternatively if the database is set to use integrated Windows authentication, the user logged into the operating system hosting the TEM consoles is authenticated against the users or groups that have defined access to the TEM database.
The second part authenticates against the operators publisher.pvk file.
The second part of the authentication requires the user logging into the TEM console to have access to their password protected private key publisher.pvk file. The login prompts the user for their publisher.pvk file and the password. Once logged in a TEM operator is required to provide the password associated with their publisher.pvk file in order to complete any actions.
The TEM server and console is only supported on Windows, so there is no need to have any functionality for mapping accounts between multiple operating systems.
In summary the main differences that need to be considered are:
- Only users with access to the Site Admin license.pvk and password in TEM can create new operators.
- TEM operators are individuals and do not represent groups of administrators.
- TEM operators are authenticated in two ways, against the SQL Server and an individual’s Operator private key.
- All actions made by TEM Operators require their password and private key file.
Next I am going to take a look at the mapping of Tivoli Framework Administrator Roles to TEM Operator Roles.