uDecrypt Returns Null

[brandonbollin]

Hey fellow SCN ppl! Been awhile but I'm back. Hoping someone can assist with an issue I'm having.

I'm developing a patch for the project I'm working on. Basically, when performing a password reset, a notification is going out that tells the user if any of the systems they have accounts in failed when resetting the password and then a second email containing the randomly generated password the system produced.

In the event the user did a self password reset, i.e. the helpdesk didn't use the random generation task but the user did a self-service reset, since they set the password, they know what it is and that second email doesn't go out telling them the password, only the first confirming the status of the reset in all the systems.

Where I'm having an issue is, my job is using the global sap_core_getPassword script, which in turn uses uDecrypt on the MX_ENCRYPTED_PASSWORD to get the new password, no matter which task set it. Again, if it was self service, the results simply don't get emailed. In the case of a random generation, this all works fine. However, if it's a self service reset, the decryption returns a, "null" value. This causes the script to fail; "cannot convert null to an object".

Since the script fails, the whole job fails and no notifications go out. This is really puzzling to me since all this works just fine in DEV. Now that I'm testing in QA, I have this issue. This set of tasks also exists in PROD, it just doesn't work all the time thus the patch I'm developing, but when it does work, it's properly decrypting self-set passwords there too.

What the frick? Why would this work in all environments except QA and why does it only fail on self-set passwords but work on system generated passwords? Here's a screenshot from both situations showing success on the random and failure on the self-service.

Anyone see anything?

[brandonbollin · Accepted solution]

The problem here was that the keys.ini file in Netweaver did not match the keys.ini file in IDM. That's why when IDM generated the password randomly, it worked. All the encoding and decoding occurred within IDM. When the user was setting the password on the UI, Netweaver encoded the password with a different key and thus, IDM could not decode.

We have updated the keys files to match and we're functional now.

[former_member2987]

Hi Brandon,

I know off-line we discussed potential keys.ini issues, but have you also checked to make sure that the version of Java is consistent in the environments? If DEV and PRD have different versions of Java, can you try adjusting the DEV version and see if you get the same results in PRD?

Matt

[brandonbollin]

Matt, this did not turn out to be the solution but we figured it out; see my next comment.