It's all about the answers!

Ask a question

Authentication Failed using build BuildForge Agent v8.0.0.1-1-0021


Bruce Eifler (3912) | asked May 05 '14, 12:36 p.m.
I had a working build forge agent running in the Jazz Build System Toolkit ver (AIX 4.0.1).  This authenticated via a password file that was generated via the jbe.sh using the -createPasswordFile  parameter. The location of this password file is contained in the startbfa.sh script via several export statements.=>
export JAZZ_USER=<user>
export JAZZ_PASSWORD_FILE=<password_file>

Everything worked correctly. I could do remote build requests via the RTC build definition.  These builds would complete and return proper build information.

I was then directed to upgrade the build forge agent due to the vulnerabilities in OpenSSL=>
https://www-304.ibm.com/support/docview.wss?uid=swg21670165

I downloaded and installed the fix =>BuildForge Agent v8.0.0.1-1-0021

However now I have an authentication problem when I attempt to connect to the agent via the build engine I get the following =>
Message: Socket created successfully.
AUTH Unable to set user account to *AuthUnknownUser ("beifler")
Authentication Failed.

The only thing changed is the build agent. The startbfa.sh script is the same.  The password file is the same.
So I am guessing that something about the build forge fix requires a new password file to be generated.
However the jbe.sh is from the 4.0.1 toolkit.  So It is likely I will need to generate a new password file to match the new agent.  So what tool should I use to perform this task?  Or am I mistaken?
I would appreciate any help in this matter.

Thanks

3 answers



permanent link
Nick Edgar (6.5k711) | answered May 05 '14, 1:09 p.m.
JAZZ DEVELOPER
edited May 05 '14, 1:10 p.m.
Hi Bruce, you need to distinguish between the credentials used to connect to RTC from within the build (e.g. to run JBE to run the SCM phase of the build) vs. the credentials used to connect to the build agent from RTC to send the commands for the steps that make up the build.  The JAZZ_USER and JAZZ_PASSWORD_FILE env vars are used for the former (assuming the commands sent to the agent use these env vars). The credentials given in the RTC build engine corresponding to the agent are used for the latter (i.e. given in the Build Agent page of the build engine configuration where you click Test Connection).  

The build engine configuration would not have changed just by upgrading the agent, so as long as the build agent's bfagent.config file's settings for which authentication scheme it uses haven't changed, the same credentials should still work.

Is the user name "beifler" correct for connecting to the agent (i.e. your AIX user name), or is that your RTC user id?

To debug, you can try using telnet:
telnet YOUR_BA_HOSTNAME 5555  (or change port if not the default)
then after it connects:
username YOUR_AIX_USERNAME
password YOUR_AIX_PASSWORD
cmd ping
go

Note that the agent will complain about "AuthUnknownUser" if either the user name or password is incorrect.


Comments
Bruce Eifler commented May 05 '14, 3:49 p.m.

The userId/pw pair used to generate the password file and the RTC userID/pw used to define the build engine are identical.
Neither of these is the AIX user.

The telent command gives this=>
$ telnet localhost 5555
Trying...
Connected to loopback.
Escape character is '^]'.
200 HELLO - BuildForge Agent v8.0.0.1-1-0021
username beifler
password
cmd ping
go
320 AUTH AuthFail[*AuthUnknownUser,"beifler"]
251 RESULT 1
260 EOR


Bruce Eifler commented May 05 '14, 3:58 p.m.

I just realized that in your example above you used the AIX userId/pw.
My telnet session above used my RTC userId/pw.
So I repeated the telnet session using my AIX userId/pw however it fails in the same way=>AuthUnknownUser


Nick Edgar commented May 06 '14, 9:22 a.m.
JAZZ DEVELOPER

So this test shows that it's not a problem in the RTC / Build Agent integration, but rather that the expected credentials are not working against the agent itself.  It could be that there was previously a change made to the bfagent.conf file (usually found under /etc) to define the authentication scheme (perhaps using the same LDAP as RTC) that was overridden when the agent was upgraded.


In your excerpt above, the password is not shown after 'password' I suspect you replaced it with a value using angle brackets, and the forum software here thought it was a tag and stripped it.


Nick Edgar commented May 06 '14, 9:23 a.m.
JAZZ DEVELOPER

You could try editing bfagent.config to have:

magic_login build:buildpw

then try the telnet test again (after restarting bfagent, e.g. using bfagent -s).


Bruce Eifler commented May 06 '14, 12:58 p.m.

I edited the bfagent.conf. First I tried the literal string you offered "magic_login build:buildpw".  I performed "bfagent -s". Then I tried the telnet test and it failed as before.  Then I un-commented
the default magic_login line so now it reads=>
"magic_login build:eca0b7f2f4fbf110f7df570c70df844e1658744a4871934a"
Then I performed "bfagent -s".
Then I performed the telnet test.
However I get the same error => 320 AUTH AuthFail[*AuthUnknownUser,"beifler"]
So perhaps I am misunderstanding the usage of the magic_login.  Please advise.


Nick Edgar commented May 06 '14, 2:06 p.m.
JAZZ DEVELOPER

Sorry I wasn't clear. If you set the magic_login to build:buildpw, then you need to specify that username and password in the telnet session.  And yes, the magic_login line needs to be uncommented for it to take effect.  Without this, it normally uses the OS login creds.



Bruce Eifler commented May 07 '14, 3:45 p.m.

I edited the bfagent.conf file with the update => magic_login <username>:<password>
then restarted the agent.
However I get the same error => 320 AUTH AuthFail[*AuthUnknownUser,"beifler"]
I am using the same username/password for the telnet session as in the magic_login  update above.

showing 5 of 7 show 2 more comments

permanent link
Nick Edgar (6.5k711) | answered May 08 '14, 1:45 p.m.
JAZZ DEVELOPER
Hm, it's likely due to either:
a) magic_login is ignored if bfagent is run as root user (sudo bfagent -s)
and/or
b) the password actually needs to be encrypted, using bfagent -P THE_PASSWORD, and the resulting hash used in the bfagent.conf file (sorry, I thought it would convert an unhashed password to hashed form if given as clear text).

For details, see http://www-01.ibm.com/support/docview.wss?uid=swg21295611

I was able to get magic_login working on my dev machine by running it as a regular user (had to copy bfagent first), and after editing /etc/bfagent.conf to have:
magic_login foo:f4dcf9f8ab64bec313618710b430918c3fdd4087cb5b3902

where the hash there was obtained with: ./bfagent -P bar

It's possible to debug further by uncommenting:
#activity_log /tmp/bfagent.log

The given log file gets an entry like the following for a successful auth using the magic_login creds:

Thu May  8 13:32:55 2014 [   12987] agent.c         : 670: tag: username
Thu May  8 13:32:58 2014 [   12987] agent.c         : 670: tag: password
Thu May  8 13:32:59 2014 [   12987] agent.c         : 670: tag: cmd
Thu May  8 13:33:00 2014 [   12987] agent.c         : 558: tag: go
Thu May  8 13:33:00 2014 [   12987] agent.c         : 471: agent_process_request
Thu May  8 13:33:00 2014 [   12987] agent.c         : 340: agent_process_command cmd=[ping]
Thu May  8 13:33:00 2014 [   12987] agent.c         : 181: agent_authenticate
Thu May  8 13:33:00 2014 [   12987] agent.c         : 219: AUTH normal
Thu May  8 13:33:00 2014 [   12987] misc.c          : 446: AUTH ok (magic_login)
Thu May  8 13:33:00 2014 [   12987] agent.c         : 380: AUTH ok

For an unsuccessful auth, it looks like:

Thu May  8 13:33:11 2014 [   12990] agent.c         : 670: tag: username
Thu May  8 13:33:13 2014 [   12990] agent.c         : 670: tag: password
Thu May  8 13:33:15 2014 [   12990] agent.c         : 670: tag: cmd
Thu May  8 13:33:15 2014 [   12990] agent.c         : 558: tag: go
Thu May  8 13:33:15 2014 [   12990] agent.c         : 471: agent_process_request
Thu May  8 13:33:15 2014 [   12990] agent.c         : 340: agent_process_command cmd=[ping]
Thu May  8 13:33:15 2014 [   12990] agent.c         : 181: agent_authenticate
Thu May  8 13:33:15 2014 [   12990] agent.c         : 219: AUTH normal
Thu May  8 13:33:15 2014 [   12990] misc.c          : 449: AUTH failed (magic_login)
Thu May  8 13:33:15 2014 [   12990] agent.c         : 377: AUTH failed

If bfagent is running as root, magic_login is disabled so it tries to auth using 'PAM', i.e. using the OS account credentials by default (see http://en.wikipedia.org/wiki/Pluggable_authentication_module).  So trying to log in as foo:bar fails with:

Thu May  8 13:35:10 2014 [   13010] agent.c         : 670: tag: username
Thu May  8 13:35:13 2014 [   13010] agent.c         : 670: tag: password
Thu May  8 13:35:15 2014 [   13010] agent.c         : 670: tag: cmd
Thu May  8 13:35:15 2014 [   13010] agent.c         : 558: tag: go
Thu May  8 13:35:15 2014 [   13010] agent.c         : 471: agent_process_request
Thu May  8 13:35:15 2014 [   13010] agent.c         : 340: agent_process_command cmd=[ping]
Thu May  8 13:35:15 2014 [   13010] agent.c         : 181: agent_authenticate
Thu May  8 13:35:15 2014 [   13010] agent.c         : 219: AUTH normal
Thu May  8 13:35:15 2014 [   13010] pam.c           :  89: AUTH using PAM
Thu May  8 13:35:16 2014 [   13010] agent.c         : 377: AUTH failed

In the end, it may not be productive for you to pursue the magic_login test. I was just trying to use it to determine whether you could authenticate in any way to the agent (separately from RTC).  The main issue is that after the upgrade you're no longer able to authenticate to the agent using your credentials that worked before.  Unfortunately, I'm out of ideas for why that may be happening. I suggest opening a ticket with Rational Support.


Comments
Nick Edgar commented May 08 '14, 1:47 p.m.
JAZZ DEVELOPER

Just to be clear, the commands I sent after telnet 5555 were:

username foo
password bar
cmd ping 
go

When successful it shows:
320 AUTH AuthOk["foo"]
320 PING PingOk
251 RESULT 0 


Bruce Eifler commented May 12 '14, 5:22 p.m.

I encoded the password in the magic_login then restarted the bfagent.
Now I can authenticate via the telnet test.  Also I can perform a build from my remote client.
Additionally I had a different user successful perform a build as well.
So I am good for now.  The big question at this point is why the authentication changed at all.  I figure we can run like this for development purposes however I don't think magic_login is supposed to be used for standard operations.


Nick Edgar commented May 13 '14, 3:21 p.m.
JAZZ DEVELOPER

> The big question at this point is why the authentication changed at all. 

I agree. To dig deeper on this, I think you'll need to engage Rational Support.


Bruce Eifler commented May 14 '14, 3:35 p.m.

Thanks for your help!


permanent link
Arumugaraj swamynathan (13111) | answered Jul 14 '17, 7:13 a.m.

 Hi all,

        I tried all these steps but still facing the same error .Could anyone help me to resolve this error.Thanks in advance


Comments
Arumugaraj swamynathan commented Jul 14 '17, 7:14 a.m.

 My Rational build agent is running on IBM i(AS/400)

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.