This is an error that can occur when the pam configuration files have been changed since the agent has been installed. A user tries to log into the machine and has two failed attempts. On the third attempt he logs in just fine. When the user then tries to authenticate with the agent it fails. The server auth within Build Forge fails as well.
Error: CRRBF0158I: Unable to set user account to account disabled (cdcuser)at com.buildforge.services.common.api.APIException
When connectivity fails, to verify that this could be the potential problem, Navigate to the IBM INFO CENTER and search "Troubleshooting Agent". This will provide you instructions on how to gather helpful debugging information you can use to verify.
Authentication with the Agent Fails, Build Forge server authentication with specific user credentials fails. The user in questions however can log into the machine as usual.
This is due to the PAM.conf file being improperly set. When the Agent is first installed, it copies the current pam configuration for "Account Management, Password Management, Session Management, and Authentication" It first looks to copy the SSH security settings. If it can not find the SSH files or they do not exist. The agent will then copy the LOGIN settings specified in the PAM file. Many times when the Unix admins make changes to the pam modules and or settings, this is not properly relayed to the four agent properties found within the pam file.
The user can still log into the machine per usual, just the agent will not authenticate through a ping test and or a Server Auth within build forge.
This has been seen in AIX
Diagnosing the problem
When you see this problem, locate your pam configuration files. These are system/company specific so if you do now know where they are, please ask an admin. A common place where to find this file is listed below.
Locate the four bfagent auth, account, password, and session values at the bottom of the pam.conf Do the pam modules used for the "login" or "SSH" under "Account Management, Password Management, Session Management, and Authentication" match those of the four bfagent entries?
NOTE: Any type of typo within this file can cause the agent and or the security settings to not work and or partially work. You may also receive unexpected behavior.
Resolving the problem
You can just uninstall, re-install the agent. Thus causing it to create a new copy of the new pam security files. If available, updating the agent via the update script in bfhome dir works as well.
IF you are unable to change the pam file and need a work around or root cause. Please continue to read on.
When you notice a difference in the values as shown below? This is most likely your issue.
login auth required /opt/boksm/lib/pam/pam_boks.so.1
login account required /opt/boksm/lib/pam/pam_boks.so.1
login password required /opt/boksm/lib/pam/pam_boks.so.1
login session required /opt/boksm/lib/pam/pam_boks.so.1
Notice how the four pam config sections all use pam_boks.so.1 for their login ability.
bfagent auth required /usr/lib/security/pam_aix
bfagent account required /usr/lib/security/pam_aix
bfagent password required /usr/lib/security/pam_aix
bfagent session required /usr/lib/security/pam_aix
Notice how the bfagent is using a different module. pam_aix. Something has changed in the security settings of AIX and the agent was not aware. Thus causing the user to be able to log in to the machine while the Build Forge Agent fails to authenticate after two failed log in attempts when accessing the machine directly.. Why after two attempts? That is because the pam_module that was used for the user is different/more strict than what is being used for the agent.
root# chuser unsuccessful_login_count=0 <Funtional ID>
root# chuser maxage=0 <Funtional ID>
The first commands sets the user login attempts to zero.
You need to do both of the commands. The maxage to 0. This simply says to cache the response. It is stale from the get-go and so it should revalidate the response. This causes a whole new authentication attempt regardless.
Make sure that the pam modules for the agent are the same. This has been seen at least twice.