This article describes a number of best practices for managing user accounts when implementing BoKS in your organization.

Managing user accounts

A BoKS Unix user may exist across a number of individual Unix machines.
A BoKS username has the syntax : where may be a single host or a group of hosts.
defines on which actual hosts the account exists.

It is good practice to associate users to Host Groups instead of single hosts.
This because this approach will create fewer user entities to manage and also ensure that the password and other user attributes will be associated with a single BoKS Unix account. Hence, a physical user that is using several BoKS Unix accounts will be forced to remember several passwords.
Host Groups have a dual use; both for defining on which hosts a user exists but also to define access rights from and to which hosts a user is allowed to access a certain service.

Recommended best practice:

Try to make users part of as large, non-overlapping Host Groups as possible.
Using the predefined Host Group "ALL" for users will make the users exist on all hosts in a BoKS domain. This is extreme, but may be OK depending on circumstances (see "Exceptions" below).
Having a large number of users on a large set of hosts intuitively means that all users have access to all hosts. With BoKS, however, this is not the case since the access to a host is controlled by access routes.

Exceptions:
There may be reasons to deviate from this approach:

  1. If BoKS has to be deactivated on a host and that host still has to remain accessible on the network for some reason, all users defined for the Host Group in which the host belongs may log in to this machine as the BoKS access routes are no longer enforced.
  2. The number of users is so large that performance problems are expected on either the Master or on the Server Agents due to excessive updates of passwords and other user information.
  3. Certain machines may be more likely to be subject to a security breach than others. This may be due to them being in less physically secure areas or similar. The problem of having all users on all hosts is then that, since BoKS will propagate the user password to the local password databases, an attacker may gain a large number of hashed passwords that may be subject to dictionary attacks or similar.
  4. This may not be possible if there are BoKS hosts on which there are services that aren't controlled by BoKS and that use the local user database for authentication and access control. In such cases, it is probably still best to have most users belong to a large Host Group from which the hosts with this type of services are excluded. An alternative may also be to BoKS-enable the applications in question and have the access control to them handled by BoKS.
  5. Administrator accounts such as "root" are best kept to individual machines or smaller Host Groups to isolate them from one another.

Still have questions? We can help. Submit a case to Technical Support.

Last Modified On: May 25, 2018