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

Bruce Eifler

(3●9●12) 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

0 votes

3 answers

9,495 views

0 votes

3 answers

Permanent link

Nick Edgar

JAZZ DEVELOPER (6.5k●7●11) 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

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

0 votes

Comments

Bruce Eifler

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

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

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

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

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

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

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

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

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

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

JAZZ DEVELOPER (6.5k●7●11) May 08 '14, 1:45 p.m.

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.

0 votes

Comments

Nick Edgar

JAZZ DEVELOPER May 08 '14, 1:47 p.m.

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

username foo

password bar

cmd ping

When successful it shows:

320 AUTH AuthOk["foo"]

…

320 PING PingOk

251 RESULT 0

Bruce Eifler

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

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

> 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

May 14 '14, 3:35 p.m.

Thanks for your help!

Permanent link

Arumugaraj swamynathan

(13●1●11) 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

0 votes

Comments

Arumugaraj swamynathan

Jul 14 '17, 7:14 a.m.

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

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.

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers

Answers and Comments

Question details

installation

× 2,381

build

× 563

agent

× 14

forge

× 4

Question asked: May 05 '14, 12:36 p.m.

Question was seen: 9,495 times

Last updated: Jul 14 '17, 7:14 a.m.

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

3 answers

9,495 views

0 votes

3 answers

Comments

Comments

Comments

Your answer

Follow this question

Question details

Related questions