If the password is changed for a user during an upgrade of BoKS Master and Replicas, the password change may not be reflected in the password files (/etc/shadow, /etc/security/passwd, etc.) on the Server Agents.
During a Rolling Upgrade the $BOKS_etc/bcastaddr file on the BoKS Server Agent hosts typically contains the addresses of BoKS Replicas where some have been upgraded and others are running without a Master waiting for their turn to be upgraded. This scenario is known as a "Rolling Upgrade" as it allows for authentication and authorization services to function during the upgrade.
When the password is changed for a user on the new or upgraded Master the change is carried out in the BoKS database. When that has been done, a number of messages are stored in the batch queue (aka the fque) on the Master for delivery to the Server Agents. These messages don't contain the full user information but a list of user login names and an action to be carried out for each of the users.
The message is received by the boks_clntd daemon on the Server Agent (which will initially store it in a local file - $BOKS_var/pswqueue). To be able to update the password files with new information the boks_clntd will have to contact the boks_servc service on one of the Replicas (or the Master). This is done through the normal "broadcast" mechanism, i.e. typically a bunch of UDP messages are sent to the addresses listed in $BOKS_etc/bcastaddr in order to locate a BoKS server.
In this situation the Server Agent may bind to a Replica that has not yet been upgraded and thus still has the old user information (including the password) in its database. Thus the password files on the Server Agent will then be updated with old information.
Resolution / Workaround
This problem will disappear as soon as all Replicas have been upgraded and their databases have been synchronized with the Master.
It may be a good idea to inform users to avoid changing their passwords during the Rolling Upgrade.
You may also try to prevent users whose passwords are about to expire from running into Forced Password Changes during this time. This can be done by temporarily extending the global parameter that controls Password Expiration in BoKS. You can control this parameter from the command line on the BoKS Master or from the BoKS Administration GUI (FCC).
Command Line Interface:
- List current global setting
# bksdef -sg | grep 'Password.*validity'
Password term of validity: 365 days
- Change current global setting to e.g. 730 days
# bksdef -d 730
FCC Administration GUI:
- See Password Security in the Global Security Configuration section in the Domain menu.
Note however that any users with a custom password validity date (this can either be set for the individual user or inherited from the user's primary User Class) are not affected by the global value.
Still have questions? We can help. Submit a case to Technical Support.