Random Passwords at initial load

[Former Member]

Hi IdM Gurus,

I have a custom script to genrate random passwords at initial load from AD. I'm storing the random password to MX_PASSWORD and MX_ENCRYPTED_PASSWORD. When I tried to log into IdM UI for self-service tab using that random password it is failing, how ever if I define a global constant a DEFAULT_PASSWORD and set that value to MX_PASSWORD and MX_ENCRYPTED_PASSWORD it is working. Why does it fail when I call the password string from the script.

MX_PASSWORD $FUNCTION.custom_initializePassword()$$

MX_ENCRYPTED_PASSWORD $FUNCTION.sap_core_encryptPassword(%MX_PASSWORD%)

Not sure if I'm calling it the right way.

Thanks,

Joe.P

[Former Member · Accepted solution]

Try to see the value of the password before it is written to DB by placing something like

uErrMsg(1, "my pwd=" + the_pwd_variable_you_are_using)

to your custom_initializePassword script and then check job log.

And if you create an user from the UI, are you able to log-on with that user? So the encrypting the password works correctly? (Just trying to understand/limit the scope of the issue.)

Edited by: pasikuikka on Oct 20, 2011 5:06 PM

[Former Member · Accepted solution]

Thanks guys,

That helped I was able to fix the problem in my script. SAP had to improve the debugging features on the scripting.

Thanks,

Joe.P

[Former Member · Accepted solution]

Hi Sandeep,

If we define that password in TEMP_PWD the script won't be able to read that from attribute, so when I go the second pass to read the password from that attribute I 'm getting null. Here is what I'm trying to do. I'm generating a random password and before encrypting I want to save to another attribute so I can trigger email notification to users ones their password is changed.

Thanks,

Joe.P

[Former Member · Accepted solution]

Hi Joe,

Let me just clarify what I believe you're trying to do; you want to generate the random password and store it to a temporary variable before encrypting it and then send an email notification to the user giving them the new password? or just informing them that their password is changed?

Either way, you should be able to use this

Pass 1

TEMP_PWD  $FUNCTION.custom_initializePassword()$$

Pass 2

MX_PASSWORD   $FUNCTION.sap_encryptPasswordMD5(%TEMP_PWD%)$$
MX_ENCRYPTED_PASSWORD   $FUNCTION.sap_encryptPassword(%TEMP_PWD%)$$

to make sure that your script is in fact returning a random password and not null, like pasikuikka suggested you can add a warning or an error message for debugging purposes within your initialize password script, like this:

an error message

uErrMsg(1, "my pwd=" + the_pwd_variable_you_are_using);

or a warning message

uWarning("my pwd=" + the_pwd_variable_you_are_using);

After you set this up and run a test, you can check the job log to see whether or not a random password has been outputted as part of your script (in the form of an error or a warning); once you have confirmed that TEMP_PWD is in fact getting a password and not a null value then your script is working fine; as a result Pass 2 should work as expected and your random password should be successfully set and encrypted. You should still be able to access the unencrypted password from the TEMP_PWD attribute which you can use to send to the end user via an email notification; after the email notification you would ideally want to clear out the TEMP_PWD attribute for security purposes.

Let me know if that works!

Cheers,

Sandeep

[Former Member · Accepted solution]

Hi Sandeep,

In my first pass where I'm generating the random password and writing that to a temp attribute TEMP_PWD.

In the second pass when I refer to that attribue as you mentioned I see a null value being passed. but when I looked at sql table I see a value in that attribute TEMP_PWD. Here is what I'm doing in the second pass

MX_PASSWORD $FUNCTION.sap_core_encryptPasswordMD5(%TEMP_PWD%)

even if I do just MX_PASSWORD %TEMP_PWD% I still see a null value being passed.

Thanks,

Joe.P

[Former Member · Accepted solution]

Hi Joe,

That's quite odd; what value do you see within the SQL table for TEMP_PWD? and is this value the same one you see within the job log errors/warnings (the debugging messages you should have set up) from your password script?

do you have your keys.ini file set up correctly in visual administrator? if not, then your password might not be getting encrypted properly.

Cheers,

Sandeep

[Former Member · Accepted solution]

Hi Sandeep,

This is what I've found out, though my string in TEMP_PWD is same as the one that's encrypted under MX_PASSWORD but I still can't authenticate the user. If encrypt the password first then I can log in and authenticate the user but if encrypt it I cant decrypt it since that's a one way encryption. Wont there be another way that we can communicate these passwords to users

Thanks,

Joe.P

[Former Member · Accepted solution]

Hi Joe,

If you're storing the password in cleartext within the TEMP_PWD variable only in order to communicate it to the user, you really don't need to do it that way; you could very well just use the sap_getPassword script to decrypt the MX_ENCRYPTED_PASSWORD; just pass it in the MX_ENCRYPTED_PASSWORD as a parameter and it will return the decrypted password in cleartext, just like this:

sap_getPassword(%MX_ENCRYPTED_PASSWORD%)

Let me know if that helps in any way.

Cheers,

Sandeep

[Former Member · Accepted solution]

Hi Sandeep,

Yes you are write but, there is a issue with that when I store the same password in MX_ENCRYPTED_PASSWORD and if try to log in with that password I'm not able to authenticate, I've tried all different ways. IDM 7.2 is not that stable and found many issues in the scripts.

Thanks,

Joe.P

[Former Member · Accepted solution]

Hi Joe,

This is very puzzling; the sap_getPassword script is a relatively basic script in that it's just using a built-in function to decrypt a DES encrypted string, so I would imagine it should work with no issues; in your usage is the sap_getPassword script not returning the expected password?

Just to confirm when you were able to authenticate using the DEFAULT_PASSWORD global constant, you were encrypting it both times when storing it to MX_PASSWORD as well as MX_ENCRYPTED_PASSWORD, right? Try using the sap_getPassword script in that instance and see if it works as expected; if it does I would imagine it should work when using any password other than the default one.

Cheers,

Sandeep

[former_member2987 · Accepted solution]

Gents,

Remember that MX_ENCRYPTED Password must be stored as a DES Encrypted string and MX_PASSWORD as an MD5 hash and that IDM only authenticates against MX_PASSWORD.

Joe, you also might want to check the KEYS.INI file. If you have multiple entries make sure that your encryption and hash scripts are both using the same key entry

Sandeep, you make an excellent point about them being well known and simple scripts, but it might make sense for Joe to regenerate them. Stranger things have happened. At the same time it might also make sense to recreate the task. I've seen that fix strange behavior in IDM as well.

M

[Former Member · Accepted solution]

Sandeep,

Thanks and really appreciate your help. I'm aware of the MX_ENCRYPTED_PASSWORD, the standard scripts that are delivered functions strangely, however even though my DES encrypted password is same as the one in MX_Password my authentication fails, the only time my authentication works if I do MD5 encryption first and then followed by DES, even the alternate approach of storing in temp attributes fails due the same reason. Again I'm debugging the scripts and checking the value passed as it is same all thru and also stripped spaces to make sure i'm not sending any spaces.

So what I have done is to write a script to encrypt and trigger email within the script which worked for me. Definetly the scripts that came with IdM 7.2 has some minor coding errors. Hope SAP will fix those with SP3 or before the GA

Thanks,

Joe.P

[Former Member · Accepted solution]

Matt,

Yes; very true! Like you said, checking the Keys.ini file might be the best bet, or even just regenerating the scripts or recreating the task; Yes, those things can often fix strange behavior within IDM.

Joe,

Like Matt sugested, you might want to try validating your keys.ini file to see that everything is in order and that the same key entry is being used; apart from that just try recreating the task from scratch or removing and re-adding the SAP Provisioning framework, so as to regenerate the supplied scripts.

Thanks and Best regards,

Sandeep

[Former Member]

not able to read the attribute set in the previous pass. how do I store the password before it's encrypted.

Thanks,

Joe.P

Edited by: Joe Padidham on Oct 20, 2011 7:04 PM

[Former Member]

Hi Joe,

Try doing it this way: Create a To Identity Store Pass prior to the one where you set MX_PASSWORD and MX_ENCRYPTED_PASSWORD and within the pass write the random password to an attribute for temporary storage, like:

TEMP_PWD  $FUNCTION.custom_initializePassword()$$

and in your original pass, change it to this:

MX_PASSWORD %TEMP_PWD%
MX_ENCRYPTED_PASSWORD %TEMP_PWD%

There can sometimes be problems when trying to read from an attribute you wrote to within the same pass.

Let me know if that works!

Cheers,

Sandeep

[Former Member]

Hi Sandeep,

Thanks you for responding to my post.

Even after following your steps I still get authentication failed when I tried to log into IdM UI. Not sure why it only works with a DEFAULT_PASSWORD as a global constant but not for any random generated password on the fly. I even tried timming the leading and trailing spaces for the random generated password before encrypting the string.

Thanks,

Joe.P

[Former Member]

Hi Joe,

OK; just as a sanity check try changing the main pass to this:

MX_PASSWORD      testpassword
MX_ENCRYPTED_PASSWORD      testpassword

then try logging in with "testpassword"; if that works then the problem lies with your random password generator script.

Cheers,

Sandeep