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:

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.

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.

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

Can you post the resulting permissions groups from one of the users where it is not working? You can get these in the Manager for example when you log in with one of these users using the employee (role-based) authentication module.

Additional Info:

I've tested my plain 8.1 installation with an employee having that minimum permission set and the password reset web portal displays everything okay.

Thanks, Markus,

Same permissions as in 8.0.1

Markus Weiss-Ehlers said:

Are they marked as inactive?

You said that it wasn't the case but I am pretty sure it is the case because the employee is missing the permission group VI_4_AllUser_Lookup.

Or did you change the condition of the dynamic group Person in Base roles\Everyone (Lookup)?

The missing permissions are the reason, why the updated script QER_PasswordWeb_IsByCentralPwd is returning false in your case.

Thanks Markus.

No, they are not inactive as I said. 

I've granted permissions for that same user in v8.1 and now the Central Password option appears en PasswordWeb... well I'm glad and not glad to know :)))

The reason why they dont have that dynamic group (Everyone Lookup) is that I dont want the users to be able to search and find other users data when they log in the web portal. I removed this permission a long ago when some users (and I agree with them) told me that they were able to search and display other employees sensible data as their login name,or their official ID number. 

I guess the system would be more secure if the updated script should not depend on that , as it did in v8.0.1.

Oh well... one problem solved , another one arises xD

I do not wanna argue about defining a login name, that is constructed by a human-understandable algorithm, as sensible data. In addition the property Person.SecurityIdent will not be displayed for all users, it would have been a perfect match for your official ID number.

Instead of removing a complete read-only permission group, that may lead to several other issues in the web portal, it would have been the better solution to copy the original permission group and adapt it to your needs.

The script code from 8.x wasn't more secure, but it didn't have any additional permission check because it worked differently. The downside was it was not precise as the new one and it wouldn't be able to support the new password policy handling features of 8.1. Especially having the new flexibility option for having more than one password policy at the person table.

Workaround for you:

You need to add table and column read permission for the table QERVPersonCentralPwdColumn to a custom role-based permission group and add that permission group to all your users.

I am going to discuss internally, if we are good to add these permissions to the permission group VI_4_ALLUSER in the future.

Thank you Markus, I really appreciate your remarks and your keeping from going into arguments :)) Aint the goal.

The official ID number is one of the examples. We use a custom attribute as proposed by our old product partner. It is official in the country and needs some calculations and checks. And it is used for all procedures across the spanish administration , sort of Social Security number.  Also our  national security protocol advises not to give away any part of the credentials data. We are checked on that from time to time. 

All in all, the working address, email, personal email address, telephone, name of the manager, department.. they were all displayed when any user searched any part of the users data in the search box. Things we dont want to share with everyone else. Yes, it is our duty to control this as managers of the system, but that's the product's ootb behaviour too. Please do not feel like I'm being hard on the product. We are really happy with it, we want it improved release after release. And yes, we know that the product wont fit into everyone's needs, that'd be impossible to achieve. We are developers too, I know the feeling.

This said. I didnt remove the group, I just removed the memberships. I'll try to find a better solution to it, even if that delays our upgrading to 8.1

Again, thank you so much for your help.

Have a great day.

Thank you for your open words. I didn't want to be rude and I apologize if I did.

To help you with your issue and allow you to migrate to 8.1 please consider my workaround.

I do not know if you already have a custom role-based permission group that everybody gets or if you have to create one. In both cases, you just need to add the following permissions to it and the password reset should be working normally.

Thanks again for your input and faith in the product.

Have a great day.