UC_JOBMD returning only two chars?

[Reed Byers]

At Oregon State University, we've just started migrating from Application Manager to AWA.  We started on AWA version 12.2 (I think), and just upgraded to 12.3.0+build.1563349870418 when it was released.

We took some training courses, and our instructor gave us the following code so we could extract and decrypt a password from a login object, for use in a BASH script:

:PSET &db_pass# = get_login(&login#, &$INT_ACCOUNT#, "ORACLE", PASSWORD)

export DB_PASS=$(&UC_JOBMD CMD="echo &db_pass#")

This worked just fine prior to the upgrade.  When we upgraded to 12.3, it broke.

The result from the above code now, is that the BASH variable simply contains two dashes ("--").

We recognized that this is just the first two characters of the encrypted password, so we tried this test:

&UC_JOBMD CMD="echo sharitest"

This resulted in "sh" being output.

&UC_JOBMD seems determined to only give us two characters from our echo commands.  Can anyone explain this?

Did we break something?  Is there a setting we need to fix?  Is this a bug in 12.3?

Thanks for your help...

------------------------------
Reed Byers
Programmer/Analyst
Oregon State University
------------------------------

[Christian Boeck]

Hi,

I've also detected that error and I already opened a ticket. The windows jobmd works correctly.

------------------------------
Thx & rgds
Christian
------------------------------

[Reed Byers]

Thank you for the quick response!  It's good to know this isn't something we did.  :)

Could you post a link to the ticket, so we can add a comment to it (if that's possible)?

------------------------------
Reed Byers
Programmer/Analyst
Oregon State University
------------------------------

[Carsten Schmitz]

​In the "early days" it was possible to extract passwords from LOGIN objects by simply echoing them with the Job Messenger.

Some time around 10.x, it appears they introduced a sort of "blacklist" preventing you from using that method with the pre-defined password types ("UNIX", "WINDOWS", "R3" and another I can't remember). You could go around this by temporarily changing the type of password from the pre-defined one to a custom type, which were not subject to the "blacklist" and could still be exported. Of course, fully at your own risk as this approach required writing a field in the database. I recently tried this method in 12.2, and couldn't get it to work, so it appears they are patching holes with the printing of passwords. Unfortunately I can't recall anymore why specificially I couldn't get it to work any more (it was late ... ;) but I remember thinking it looks like done on purpose, then gave up.

You specified "ORACLE" as a "type" parameter to get_login, which is a custom login type, right?

I have the strong feeling the inability to get passwords back is now "by design". But since this was not communicated, the ticket is the way to go regardless. I'd be very interrested in what the outcome is (since we occasionally also need a password back), so if you could keep us up to date here, much appreciated.

Best,
Carsten

[Christian Boeck]

Hi Carsten, 
of course, as soon as i get an answer from the support team I'll bring up that ticket up to date.

------------------------------
Thx & rgds
Christian
------------------------------

[Christian Boeck]

Hi @all,

my latest information ​"11-September-2019 00:57:51"

"The bug AE-22017 has been opened. We will notify you as soon as the patch is available"

------------------------------
Thx & rgds
Christian
------------------------------

[Paschalis Kapoukranidis]

Hi,

we were just wondering if there is an update on this issue.

Our company recently updated some agents from 11.2.2 to 12.3.1 and many jobs are failing because of it.

The reason is the same as described in the original post. It seems that the older 11.2.2 agents can "decrypt" the passwords correctly, while any updated 12.3.1 agents produce errors because of login failures, since the passwords are not decrypted.

OS: AIX 7.2

Agent version: 12.3.1+hf.4.build.1576940004687 (UNIX)

The older Agents with 11.2.2+hf.6.build.706 are fine and we downgraded them, so we don't have to touch the many jobs in production.

Thanks for your update in advance.

[Christian Boeck]

Hi,
I haven't received an update from broadcom but I've seen a similar bugfix at 12.3.2

"Fixed an issue where the UC_JOBMD CMD command with the UNIX Agent truncated the given command. AE-22024"

may be it is already fixed there.

------------------------------
Thx & rgds
Christian
------------------------------