Passing password to ADSAccount after assigning Account Definition

Our use case is:  A user creates an account and password in an outside system and we are passed the relevant values via rest calls to create the person. Then later, after approval, an account definition is applied to the person so generate an AD Account, 

The issue is that I am not able to pass the DialogUserPassword value to the ADAccount in a way that results in the password being set correctly due to the encryption in Person.DialogUserPassword.

I have tried a few different methods without success The current st-up is:

1) on the ADS_PersonHasTSBAccountDef_Autocreate_ADSAccount/Contact process, on the Create account step I have added the password field pulling from the person record. It is marked as Encrypted.

2) the value does get passed and is shown as the encrypted value and the account is created. However, any attempt to log in gives a user/password error

I've been able to remove the encryption flag and send an unencrypted string in a  similar manner and the account will create and be able to log in. However, I won't be able to use that method for production. 

Any thoughts on how I can accomplish this, or what I am doing wrong?

Parents
  • For anyone who finds this in the future:

    Our solution was to create a new schema extension field on the person record. This field is marked as encrypted. On Person insert we store the password in the new field. Then on ADSAccount creation we use that field for the value being sent to the ADS Insert. After the insert the temporary password field is blanked out. 

Reply
  • For anyone who finds this in the future:

    Our solution was to create a new schema extension field on the person record. This field is marked as encrypted. On Person insert we store the password in the new field. Then on ADSAccount creation we use that field for the value being sent to the ADS Insert. After the insert the temporary password field is blanked out. 

Children
  • Just as an explanation, the password stored in DialogUserPassword is hashed because it is used for authentication against OneIM itself if you are using a person baes authentication module. Therefore reusing this hash or decrypt the has is impossible by design.

    I would generally advise against permanently storing a password in the OneIM database as best practice. I would re-design your use-case instead so that the AD user gets a random password instead that needs to be changed by the person (owner of this account) during the first login. OneIM has the option to send this password to the user itself or to his manager ootb. Another option would be to enforce the user to change his password in the password portal.