This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Changing employee account password in Portal (v8.0.1). Strange behaviour

Hi there,

In version 8.0.1 ,using the Password Portal, once authenticated, the user is presented with two options:

  1. Change one or more passwords.
  2. Change the central password.

Option 1 shows the employee account along with other accounts the employee has.

Option 2 shows a popup informing of all the accounts affected by the central password. One of them,  is the employee account too.

If I chose the first option and mark the employee account then the change is performed successfully.

If I chose the second option, then the password is changed for all the accounts successfully, except for the employee account. This latter gets somehow corrupted and it is not usable anymore. 

How can this be? Note: the database is encrypted.

Thanks!!

  • Hello,

    This makes sense for the second option as the central password is used to change passwords on downstream target systems, i.e. the ADSAccount.

    Resetting the central password does not reset the DialogUserPassword for the Employee, but the first option does.

    So if you want to change the Employee password, use the first option; to change just the password for the target system user, use the second.

    But I don't understand what is happening to your Employee password.  Are you trying to use the original password for the Employee or that of the central password?

    George explained the password differences in an earlier post: www.quest.com/.../difference-and-uses-of-centralpassword-person-and-dialoguserpassword-person.

    Trevor

  • I am certain that you do have a custom template in place at Person.DialogUserPassword that pulls the value from Person.CentralPassword. That is the reason why the employee password is listed in the list of updated passwords by central password. 

    Thing is, that you cannot use a template to flow the encrypted CentralPassword to the hashed DialogUserPassword.

    That‘s one of the reasons why version 8.1 is not using the templates anymore to distribute the CentralPassword to the linked accounts. 

    Solution: Remove your custom template and set the DialogUserPassword via a custom process when the CentralPassword has changed. 

  • Thanks Trevor. I do not want the user to select which accounts the password change will be applied on. That somehow creates some confusion among them. So instead of that, I want the password to be unique for all the systems, even the web portal (employee password) and the password portal (employee password too). And that's where Markus comes into scene with exactly the origin of my problem: Yes, there's a custom template that transfers the CentralPassword to the DialogUserPassword. 

    Options that I have:

    1. Wait for v8.1 . I cannot, my users need a solution. Now they're changing the password via Portal. The password works for the rest of their accounts but they're unable to log to the web portals anymore.
    2. Could unencrypting the database work temporarily if I used the template? 
    3. If I create that custom process will it even work?  I mean, what is the difference between using the template versus the custom process to set the DialogUserPassword? All in all the CentralPassword is encrypted in both cases.

    Thanks you both for your answers

  • In your custom process you can use the jobserver to decrypt the centralpassword (keep the value hidden) and then use that decrypted value in a step that does a handleobjectcomponent update on the DialogUserPassword ...... that way you end up with same password in DialogUserPassword that is saved as a hash.

  • That did the trick Thank you sooo much.

    Configured and working.