• State Verified Answer
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 95 subscribers
  • Views 2502 views
  • Users 0 members are here
Options
Related

Passing an already encrypted password to AD user creation via Account Definiton

Aaron Hope
over 4 years ago

Use Case: A new user registers an account and chooses a password in an outside system as we are sent this information via REST. A person record is then created. Then after approval an account definition is assigned and the AD user is created. 

Problem: I am unable to pass the already encrypted password from Person.UserDialogPassword column to the ADSAccount.UserPassword in a manner that successfully allows login. 

I have tried a few different routes and I've found that if I pass an unencrypted string the user will create as expect and work but if I pass the already existing password it will not. I suspect the job server is not decrpyting the password on insert and instead is using the encrypted string as the password directly. 

Current setup: 

I have modified the <process> Process, Create account step to pull the DialogUserPassword field from the Person record as a parameter for the insert process. It is marked as encrypted. That value is being passed as the encrypted string and the account does get created but the account will get a username/password failure when you attempt to log in. 

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

Thanks, 

-Aaron

Parents
  • 0 over 4 years ago

    First, which version are you using?

    Second, the password stored in Person.DialogUserPassword is hashed and not encrypted because it is used during the authentication against OneIM if an employee based authentication module is used. For your use-case, if you really want to store the password in OneIM (which I normally not recommend) I would create a new custom property at the Person that is able to keep an encrypted password (like Person.CentralPassword) and store the password there. Please remember to remove the password from the custom property after usage. And remember that all ootb password reset or synchronization procedures are based on Person.CentralPassword and not Person.DialogUserPassword.

Reply
  • 0 over 4 years ago

    First, which version are you using?

    Second, the password stored in Person.DialogUserPassword is hashed and not encrypted because it is used during the authentication against OneIM if an employee based authentication module is used. For your use-case, if you really want to store the password in OneIM (which I normally not recommend) I would create a new custom property at the Person that is able to keep an encrypted password (like Person.CentralPassword) and store the password there. Please remember to remove the password from the custom property after usage. And remember that all ootb password reset or synchronization procedures are based on Person.CentralPassword and not Person.DialogUserPassword.

Children
  • 0 over 4 years ago in reply to Markus Weiss-Ehlers

    Hi Markus, 

    This is 8.1.1

    The password only needs to be stored for a short time between when the REST calls come in for the person record to be created and when the approval to create the AD Account. However, we can't store it in clear text which is why I am not using QER\Person\UseCentralPassword\PermanentStore config param and calling it from there. 

    If DialogUserPassword is a hash then that route will not work. Are there suggested encrypt/decrypt functions available OOTB or should I just wrote my own?

    Thanks, 

    -Aaron

  • +1 over 4 years ago in reply to Aaron Hope

    Hi Aaron,

    first of all Person.CentralPassword is encrypted if you had encrypted the database. In regards to the permanent storage of the central password (even encrypted) please notice that this feature has been deprecated according to the release notes of 8.1.

    You can use the OOTB functions to encrypt your stored password, even in a custom created property and used the encrypted value as you have shown in the screenshot. You just cannot use the one stored in DialogUserPassword because a hash is irreversible by design.

  • 0 over 4 years ago in reply to Markus Weiss-Ehlers

    Thanks for the info, Markus. I appreciate the help.