Managing system users
The BMC Discovery Administrator is responsible for setting up details of all the users who are permitted to use the BMC Discovery system. Users are allocated a user name and a password, which they must enter in order to log in to the system. Each user is a member of one or more user groups, which define the parts of the system that user is permitted to access. For example, users defined as members of the Admin group are able to create and edit user details, while members of the Public group cannot access these areas.
BMC Discovery can integrate with your corporate LDAP infrastructure. LDAP groups can be mapped to BMC Discovery groups and hence assigned permissions on the system. For information about setting up LDAP, see Managing LDAP.
As well as being the means of controlling user security, a user is actually set up on the system as a Person data object, and can subsequently be associated with other objects.
All actions on the system are recorded against a user's ID for audit purposes. Users should always use their own ID and keep their security details safe.
The following topics are provided in this section:
Enabling other users
Use the system user only for configuration tasks which require system privileges.
To enable other users
- From the main menu, click the Administration Settings icon.
- In the Security Policy section of the Administration page, ensure the "Disabled Accounts can be reactivated" option is set to Yes
- In the Security section of the Administration page, click the Users icon.
- For each user, click the Set Password link.
- On the Set Password page, enter the new password in each text entry field and click Apply.
- After you have changed the passwords for each user, log off from the system user account by clicking the logout icon at the top right of the page.
Creating a new user
The BMC Discovery Administrator can set up new users and assign them to groups. Before creating users, you must ensure that you have set up all the groups that you need. For more information, see Managing groups.
To create a new user
- From the Users page, click Add at the bottom of the page.
In the Add User page, enter details for the new user:
Template Select one of the following user types:
• User to create a standard UI login user account.
• API Access to create a user account only to be used for access to an API.
• Event Source to create a user account only to be used as an event source.
The appropriate fields are enabled or disabled to make populating the user details simpler. For example an API user does not require a password, so the password field are disabled.
Login ID of the user.
Full name of the user.
Password to be allocated to this user. Not used for API Access or Event Source users.
Verify Password Verify the password; it must match. Not used for API Access or Event Source users.
(Read-only display) Rules that are used to validate the password strength.
Options . Specifies that users must change their password when they first login. You can deselect this option if you do not want to force new users to change their passwords, though this is not recommended.
One or more groups that this user will be a member of. By default, all new users are members of the public group.
For API Access users, the api-access and never-deactivate checkboxes are automatically selected.
For Event Source users, the event-source and never-deactivate checkboxes are automatically selected.
To save your changes, click OK.
User names are case sensitive. That is, user names with the same spelling but different case are permitted; for example, Johnson and JOHNSON are not recognized as duplicates.
Amending a user's details
You can change a user's name and the groups that they are a member of. The access defined by the group membership will apply the next time this user logs on.
To amend a user's details
- From the Users page, select Edit from the Action list for the user.
The Set Password page is displayed.
- Amend or overwrite Full Name field.
- Select one or more Groups that this user is to be a member of.
- To save the changes, click OK.
Changing a user's password
If users forget their passwords or if a password is not kept secure, you can assign a new password.
To set a new password for a user
- From the Users page, select Set Password from the Action list for the user.
The page is redisplayed, showing blank Password fields. The existing password is not displayed.
If the password policy requires a password to be changed, the label "MUST be changed" is displayed next to the user.
- Enter a new password for this user in the Password field. Confirm the password in the Verify Password field.
- To save the changes, click Apply. The new password will apply the next time the user attempts to log on.
You can also specify that the user changes their password on their next login. To do this, select Must Change Password from the Action list for the user.
The preferred way to set or reset user passwords is using the UI. However, you can also change users passwords at the command line.
To reset the BMC Discovery user password at the command line
tw_passwd utility enables you to change the password of a specified user interface user. To use the utility, enter the following command at command prompt:
where username is the name of the UI user to change.
Changing passwords for command line users
tw_passwd utility is for changing UI users' passwords. To change the passwords for command line users, as the root user, use the Linux command
passwd. This is described in Changing the root and user passwords
Generating an API token for an account
API Access and Event Source accounts do not have passwords, they use a generated token to enable external clients to make API calls using that account. You can also create a token for any other user account, with the exception of the system user, so that API calls can be made using that account.
API Access users can access the REST API using a token. To connect to the CSV or XML export APIs, a user must connect with a username and password.
To generate an API token for a user
- From the Users page, select Generate API Token from the Action list for the user.
A dialog is displayed containing the token.
- Copy the token and save it for use by external clients.
You cannot revoke an API token for an existing user. You must delete the user.
Reactivating a user account
If a user's account is not used for a specified period of time, their account is deactivated. See Managing security policies for information about configuring account deactivation. To reactivate a deactivated user account, you must be logged in as a member of the unlocker group, and reactivating user accounts must be enabled in the Security Policy page. You can also deactivate a user's account manually.
A deactivated account is never automatically reactivated.
To reactivate a locked user account
- Check that account reactivation is allowed (see Managing security policies)
- From the Users page, select Reactivate from the Action list for the user account to be reactivated.
Unblocking a user account
If a user unsuccessfully attempts to log in to their account more than the account blocking threshold, their account is blocked. See Managing security policies for information about configuring account blocking. To unblock a blocked user account, you must be logged in as a member of the unlocker group.
To reactivate a locked user account
From the Users page, select Unblock from the Action list for the user account to be reactivated.
If you have been locked out and cannot access the UI, use the tw_upduser command line tool to activate the user account.
Deleting a user
You can delete any existing user except for yourself or the default system-created users.
To delete an existing user
From the Users page, select Delete from the Action list for the user.
User permissions in BMC Discovery are additive. When you grant a user an additional permission (through adding the user to another group), that permission is added to the user's existing permissions. For example, if you grant appmodel permissions to a user with discovery permissions, the user gains no additional permissions because all of the appmodel permissions were already granted in the discovery permission set. Similarly, you cannot add readonly permissions to a system user in the hope of achieving a read-only system user.