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:

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.

Working on it right now!

Thanks Markus!!

Working on it right now!

Thanks Markus!!