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

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?

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:

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? 

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. 

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?

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.

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.

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?

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.

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.

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!

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.

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? 

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>

In v8.0.1 I copied QER_PasswordWeb_Start and create a substitution rule. In the new module, I removed the options to set individual passwords , forced isSetCentralPassword to 1 and this one and only password to be reset. But this assuming that the CentralPassword was among the list of passwords available to change, which is not happening in version 8.1. Again I need to say that I'm not using any modifications or customizations here: Just the OOTB v8.1 code for the QER_Passwordweb.

I did run the query and this is what I get:

None of the accounts have isPrivilegedAccount=1 , all zero. That applies for the account I am presented with the CentralAccount option and the ones I am not.

The parameter QER\Person\UseCentralPassword is set.

The only thing I can think of to nail this one is to debug the script QER_PasswordWeb_IsByCentralPwd in System Debugger with the values of one line of the log where  the log says "Is managed by central password => false"

For example this one here:

ebbdcf2b-3b98-4bd6-9ea5-9e172893e1dd <Key><T>ADSAccount</T><P>47ae8464-168f-4274-ae14-3596ac8a952b</P></Key> UserPassword

The script parameters would be:

UID_Person=ebbdcf2b-3b98-4bd6-9ea5-9e172893e1dd

ObjectKey=<Key><T>ADSAccount</T><P>47ae8464-168f-4274-ae14-3596ac8a952b</P></Key>

ColumnName=UserPassword

When you test this, I would like you to test it two times. The first time with an user similar to viadmin, just to avoid any permission issue. The second time you nee to use the same authentication as in the password reset portal (Employee role-based) and the person matching UID_Person.

Markus,

Thanks for your time, again.

I think we're getting close to it and it seems we're dealing with a permissions problem. Although I wasnt able to understand what you meant on your last sentence (the test with viadmin), the results show that:

• For users odc01, ipp143 and others with no relevant permissions: In PasswordWeb, I cannot see the option to change the Central Password. In the debug I can read that the result of the script for each of the users accounts is always false, so no password is handled by the central password and then the option is not visible in PasswordWeb. However, if I run the script with the same parameters in the debugger in Manager, the result is true. 

• For user juancar, who has several admin roles, it works fine: The results in web portal vs. the debugger do match.

Some logs for user odc01:

In PasswordWeb debug log:

odc01

2019-05-22 12:07:41.7738 DEBUG (    WebLog k1auk35msghjvrklta2sc0ku) : Is managed by central password: 367d50c5-f086-4e5c-99ed-5e494e09f0f2 <Key><T>Person</T><P>367d50c5-f086-4e5c-99ed-5e494e09f0f2</P></Key> DialogUserPassword => False

2019-05-22 12:07:41.7738 DEBUG (    WebLog k1auk35msghjvrklta2sc0ku) : Is managed by central password: 367d50c5-f086-4e5c-99ed-5e494e09f0f2 <Key><T>GAPUser</T><P>e882c700-9f89-4622-bd30-eca2a71f70db</P></Key> Password => False

2019-05-22 12:07:41.7738 DEBUG (    WebLog k1auk35msghjvrklta2sc0ku) : Is managed by central password: 367d50c5-f086-4e5c-99ed-5e494e09f0f2 <Key><T>ADSAccount</T><P>00221077-2af5-487e-93f2-78012aadfae6</P></Key> UserPassword => False

2019-05-22 12:07:41.7738 DEBUG (    WebLog k1auk35msghjvrklta2sc0ku) : Is managed by central password: 367d50c5-f086-4e5c-99ed-5e494e09f0f2 <Key><T>LDAPAccount</T><P>32df69b8-d580-4c3c-9dc8-6959cdfc8320</P></Key> UserPassword => False

2019-05-22 12:07:41.7738 DEBUG (    WebLog k1auk35msghjvrklta2sc0ku) : No password is centrally managed -> not showing central password.

In Manager:

Results of executing QER_PasswordWeb_IsByCentralPwd

User: odc01

UID: 367d50c5-f086-4e5c-99ed-5e494e09f0f2

ADSAccount:

<Key><T>ADSAccount</T><P>00221077-2af5-487e-93f2-78012aadfae6</P></Key>

Result: True

LDAPAccount:

<Key><T>LDAPAccount</T><P>32df69b8-d580-4c3c-9dc8-6959cdfc8320</P></Key>

Result: True

GAPUser:

<Key><T>GAPUser</T><P>e882c700-9f89-4622-bd30-eca2a71f70db</P></Key>

Result: True