Security Controls
Setting up a new user, or changing the various settings for a user in Maximo, is bread and butter for an admin. However, there are a few parts of the system that are not used very often, and this article and the second part will go over the Security Control options. Some of the dialogues are used in combination to get a desired result, others are actually offering a duplication or another way to do the same thing.
The Security Controls dialogue is accessed via the select action menu, or the left-hand pane depending on your system set up. We will be going through a V7.6 screenshot, but the dialogue is similar in all V7 versions.
The dialogue is made up of 4 main sections, each with unique functionality for user interaction with the system. In this first article we will be going through the first 2 sections, User defaults and Login tracking. Next time we will go through the rest of the dialogue.
User Defaults
This section contains the option to select which security group will be used for all users. By default, this is the EVERYONE group (In earlier versions I believe it was MAXEVERYONE).
This is the group used for all conditional interface options that affect all users. It also has the option to select the security group to be added to all new users and the status of users created via the self-registration. In addition to this there are 2 options for workflows to be used.
The first is to select the workflow for the self-registration of users and a second for users created via LDAP integration. Those admins using those pieces of functionality will know which ones to choose and set them up here. Last, but by no means least, is the option to display the user ID when electronic signatures are required. When doing certain activities, like making changes to the database, the user has to re-authenticate that they are the user and enter the password. Some policies will not want the logged in ID to be visible to add another small layer of security to this. To use this you need to have login Tracking enabled, which we cover next.
Login Tracking
Log in tracking allows the system to do a couple of things. It allows for the electronic signatures I talked about in the section above. It also allows the system to limit the number of log in attempts and the number of forgotten password attempts before blocking that user ID.
There is no archiving on the login tracking table so it can grow to fairly enormous sizes. System administrators need to be aware of that, so they can be prepared to manage it.
It is recommended by support teams that this option be switched on; it is very helpful when they are trying to identify which of the users was logged onto the JVM when it hit a serious problem e.g. ran out of memory because someone tried to perform a massive data load incorrectly.
Before you turn this on you need to be aware of some items. If you are using a load balancer and it is not correctly configured, you could log all users out when one user fails to enter the correct password. Take a look at this article by Vetasi’s Mark Robbins, IBM Champion, on the subject before making a decision; logging tracking implications.
Also, in this section, you can set how long a password can be used for, such as 90 days and then force the user to change it. Remember though, this is only when the user is authenticating via Maximo, and not through an LDAP integration for single sign on. As well as how long the password can last, you can set up a reminder to users that their password will expire in X days a number of days before the expiry. Nothing is more annoying though than a password that lasts only 30 days and a 14-day reminder. The system will still allow you to reset your password after it has expired so go for a 5-day reminder.
The last setting in this section is the one where you can set how many days must pass before a user can use an old password again. How long this will be will depend on your security policies, but it’s well worthwhile making this a very high number, so its effectively never reused.
When setting limits on password life, give thought to the users, if they have to change it every 30 days, it will eventually lead to the passwords they use will be less secure and not more. They start with something like Sophie@1 and just change the number each month. If you allow them to keep the password for longer, they will be more likely to devote some effort to have a more secure password.
Hackers will steal encrypted password lists and then decode them. They then repeatedly try them on sites. A lot of people reuse the same password across different sites and may not remember to change them. You can register to see if your email address (and the password) has appeared on some of the hacker databases using this mailing list; https://haveibeenpwned.com
In the next article we will go through the rest of the dialogue, covering password generation, requirements and excluding passwords.
Summary
The security options can help to make the system more secure, especially if LDAP is not being used. However, be cautious of being too restrictive with the settings as you will find you do not get the resulting behaviour you thought you would from users. Readers are advised to test any changes/recommendations thoroughly before use.
Share this Blog Post: