• State Suggested Answer
  • Locked Locked
  • Replies 25 replies
  • Answers 1 answer
  • Subscribers 94 subscribers
  • Views 8042 views
  • Users 0 members are here
Options
Related
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

Password Portal: QER_PasswordWeb_Start differences 8.0.1 vs. 8.1 (passwordItem collection bug?)

CVU
over 6 years ago

Hi,

I have a test employee with same accounts in both v8.0.1 and 8.1 environments.

If I change the password via Portal I've noticed the following behaviour:

  • In v8.0.1 the password change affects all password items including centralpassword.
  • In v8.1 the password change does not affect the central password.

Digging deep in the code:

The PasswordItem collection in v8.0.1 fills up with all accounts and passwords for the user, included the CentralPassword (Person account) and DialogUserPassword (Person account)

The PasswordItem collection in v8.1 fills up with accounts , but for the Person account will only fill up with the DialogUserPassword and not with the CentralPassword.

No customizations are done. QER\Person\UseCentralPassword\SyncToSystemPassword is checked in v8.1

If I try my own user, then it works fine in both environments (¿?). Then I went to another employee and found the same behaviour as for my test employee: Only the DialogUserPassword in v8.1

Am I hitting a bug or is there something in the Person object I should check ?

Regards!

Top Replies

Parents
  • 0 over 6 years ago

    In the password web portal, you normally choose between setting the central password (and use the password flow to implicitly set the password at all connected accounts) or setting the account (or Person.DialogUserPassword) password separately. Which method did you choose?

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

    Hi Markus, 

    Thanks for helping.

    Depending on the user, I'm not even presented the option to set the centralpassword.

    For my own user, I have the option to set the Central Password (interface in spanish):

    For my test user , I dont have the option:

    For another employee, I dont have the option either:

  • 0 over 6 years ago in reply to CVU

    Weird. Just asking and trying to corner the bug, the employees where the central password is not displayed, are they

    • Sub-identities or do they have a main identity assigned?
    • Are the marked as outstanding or to be deleted?
    • Are they marked as inactive?
    • Are they locked out (Person.IsLockedOut=True or Person.IsLockedPwdAnswer=True)?

    And, how did you authenticate against the Password Reset portal? 

Reply
  • 0 over 6 years ago in reply to CVU

    Weird. Just asking and trying to corner the bug, the employees where the central password is not displayed, are they

    • Sub-identities or do they have a main identity assigned?
    • Are the marked as outstanding or to be deleted?
    • Are they marked as inactive?
    • Are they locked out (Person.IsLockedOut=True or Person.IsLockedPwdAnswer=True)?

    And, how did you authenticate against the Password Reset portal? 

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

    Thanks again, Markus.

    I thought the same about my test account , but the other one (ipp143) is correct and works perfectly.  So, all in all, these three accounts:

    • They are not sub-identities. They are primary ones.
    • No , not at all.
    • They are active users.
    • False on both attributes.

    I always authenticate using the centralpassword and this one is transferred to the dialoguserpassword (system user password). In v8.0.1 I had a custom process, in v8.1 (thanks for the feature!!!) that transfer is carried out via the QER_Person_Publish_CentralPassword. The former custom process in v8.0.1 has been disabled. 

  • 0 over 6 years ago in reply to CVU

    Now, I am confused. I thought the employee ipp143 is non-functional as well?

    For clarification, you are using the Employee (role-based) authentication module in the QBMWebApplication entry for the password reset web portal?

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

    The employee ipp143 is functional but he's not presented with the option to reset the centralpassword.

    I've tried three users: 

    • One test user. Not presented.
    • Two active users mine and another employee. For my user it works. I am presented with the option. But the other one, it does not, same as the test user.

    I'm trying to demonstrate that this behaviour seems to be random. 

    Yes, employee (role based) is the auth module for both versions.

  • 0 over 6 years ago in reply to CVU

    Honestly, we do not write code that decides randomly what to do :-) There must be a reason for the behavior but we just haven't found it yet.

    I know that you did some customizing work as well. Are we talking about a plain OOTB password reset web or do you have any customizations in place?

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

    Hehehe, good point. I didnt mean that you write code that decides ramdonly what to do. It's a way of saying "I do not know why it happens to some users and others doesn't". Apologies for that.

    Yes I've done some customizations. In fact I replaced the module QER_PasswordWeb_Start for one of my own. In v8.0.1 it works fine, in v8.1 does not.

    But as I said, all customizations have been removed.  This OOTB code upgraded from v8.0.1 to v8.1 .

    The fact that it happens to some users makes me think that the problem lies on the person object layer rather than the web code.

    Thanks again, Markus.

  • 0 over 6 years ago in reply to CVU

    Can you provide a debug log from the password web, for the user where it doesn't show the radio button for the central password reset? I do have suspicions but want to back it with the log.

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

    Sure.

    In the mean time, I've called one of my customers , asked her to change the password and it worked. Took her to the v8.1 page and , again, showed no central password button. 

    Let me know if the following link works for both sql and log files.

    https://drive.google.com/drive/folders/1AHl03klaeCmmP_nZE5_rGb6acNR8Jsja

    Thanks!

  • 0 over 6 years ago in reply to CVU

    Thanks, I was able to fetch the logs from the links. 

    The reason why the radio button for the central password reset is hidden is that the script QER_PasswordWeb_IsByCentralPwd, which is called by the Reset Web for each of the potential passwords to reset, returns false (means, is not managed by the central password) for each of the passwords.

    Question is if you have overridden the script QER_PasswordWeb_IsByCentralPwd in version 8? Due to the changes in the central password flow from version 8 to 8.1, the old version may lead to unexpected results.

    In addition, can you check the results of the SQL statement

    select * from QERVPersonCentralPwdColumn order by TableName, ColumnName

    As you can see in the screenshot, by default all privileged accounts are not handled by the central password flow.

    A sample set for these script calls in the logs are:

    2019-05-21 12:56:13.6543 DEBUG (    WebLog 3ofv13maypv1klbgell0e15g) : Is managed by central password: ebbdcf2b-3b98-4bd6-9ea5-9e172893e1dd <Key><T>Person</T><P>ebbdcf2b-3b98-4bd6-9ea5-9e172893e1dd</P></Key> DialogUserPassword => False

    2019-05-21 12:56:13.6543 DEBUG (    WebLog 3ofv13maypv1klbgell0e15g) : Allow set password: ebbdcf2b-3b98-4bd6-9ea5-9e172893e1dd <Key><T>Person</T><P>ebbdcf2b-3b98-4bd6-9ea5-9e172893e1dd</P></Key> CentralPassword => True

    2019-05-21 12:56:13.6543 DEBUG (    WebLog 3ofv13maypv1klbgell0e15g) : Allow set password: ebbdcf2b-3b98-4bd6-9ea5-9e172893e1dd <Key><T>ADSAccount</T><P>94ec2b04-d9a9-4ad7-976f-62bef019b980</P></Key> UserPassword => True

    2019-05-21 12:56:13.6543 DEBUG (    WebLog 3ofv13maypv1klbgell0e15g) : Is managed by central password: ebbdcf2b-3b98-4bd6-9ea5-9e172893e1dd <Key><T>ADSAccount</T><P>94ec2b04-d9a9-4ad7-976f-62bef019b980</P></Key> UserPassword => False

    2019-05-21 12:56:13.6543 DEBUG (    WebLog 3ofv13maypv1klbgell0e15g) : Allow set password: ebbdcf2b-3b98-4bd6-9ea5-9e172893e1dd <Key><T>ADSAccount</T><P>d34ebe37-cadd-4794-8419-35f367ed6ddd</P></Key> UserPassword => True

    2019-05-21 12:56:13.6543 DEBUG (    WebLog 3ofv13maypv1klbgell0e15g) : Is managed by central password: ebbdcf2b-3b98-4bd6-9ea5-9e172893e1dd <Key><T>ADSAccount</T><P>d34ebe37-cadd-4794-8419-35f367ed6ddd</P></Key> UserPassword => False

    2019-05-21 12:56:13.6543 DEBUG (    WebLog 3ofv13maypv1klbgell0e15g) : Allow set password: ebbdcf2b-3b98-4bd6-9ea5-9e172893e1dd <Key><T>ADSAccount</T><P>47ae8464-168f-4274-ae14-3596ac8a952b</P></Key> UserPassword => True

    2019-05-21 12:56:13.6543 DEBUG (    WebLog 3ofv13maypv1klbgell0e15g) : Is managed by central password: ebbdcf2b-3b98-4bd6-9ea5-9e172893e1dd <Key><T>ADSAccount</T><P>47ae8464-168f-4274-ae14-3596ac8a952b</P></Key> UserPassword => False

    2019-05-21 12:56:13.6543 DEBUG (    WebLog 3ofv13maypv1klbgell0e15g) : Allow set password: ebbdcf2b-3b98-4bd6-9ea5-9e172893e1dd <Key><T>LDAPAccount</T><P>b9aeb84c-785d-4e60-b6fb-132e515d9550</P></Key> UserPassword => True

    2019-05-21 12:56:13.6543 DEBUG (    WebLog 3ofv13maypv1klbgell0e15g) : Is managed by central password: ebbdcf2b-3b98-4bd6-9ea5-9e172893e1dd <Key><T>LDAPAccount</T><P>b9aeb84c-785d-4e60-b6fb-132e515d9550</P></Key> UserPassword => False

    2019-05-21 12:56:13.6543 DEBUG (    WebLog 3ofv13maypv1klbgell0e15g) : Allow set password: ebbdcf2b-3b98-4bd6-9ea5-9e172893e1dd <Key><T>GAPUser</T><P>172ac23f-922b-4eb0-a76a-89a4ee9fa14c</P></Key> Password => True

    2019-05-21 12:56:13.6543 DEBUG (    WebLog 3ofv13maypv1klbgell0e15g) : Is managed by central password: ebbdcf2b-3b98-4bd6-9ea5-9e172893e1dd <Key><T>GAPUser</T><P>172ac23f-922b-4eb0-a76a-89a4ee9fa14c</P></Key> Password => False

    2019-05-21 12:56:13.6543 DEBUG (    WebLog 3ofv13maypv1klbgell0e15g) : No password is centrally managed -> not showing central password.

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

    Hi Markus, thanks again for you help.

    The script QER_PasswordWeb_IsByCentralPwd was not overriden. Nor in v8.0.1 or now in 8.1

    My setup is really simple: Users change their password mostly in Windows , where we have Pass Sync installed and that password should be transferred to all of the accounts needed by the products the user is entitled with , even the employee account.  Same if they change the password in the web portal. I dont need the user to select which accounts will be affected, I want this data to be obscured to them. So you change your password and that'll be the only password (company policies) across all systems.

    This is the way we've been working in version 8.0.1. If I may ask, what are your suggestions then? 

  • 0 over 6 years ago in reply to CVU

    What did you do in 8.0.1 to prevent the display of the single accounts in the password reset portal?

    In addition, can you run the SQL query from my previous post? Did it return the same results?

    Is the configuration parameter QER\Person\UseCentralPassword enabled?

    Did you check that the account from the log file does not have the flag IsPrivilegedAccount=1 set? For example the ADSAccount with the XObjectKey <Key><T>ADSAccount</T><P>47ae8464-168f-4274-ae14-3596ac8a952b</P></Key>