Regarding the Expiration of Password View Requests

[MARUBUN SUPPORT]

This concerns situations where PAM has two approvers for password display requests.

The first approver accepts the password display request, and the second approver then marks the accepted request as expired.
However, without the System Admin Group, the second approver could not mark the request expired that the first approver had already approved. Is this group necessary?

Thanks,

[Ralf Prigl]

Hello, Whether or not it is necessary is subject to debate, but I tested this use case with 4.2.3 and I had no problem expiring a request with a second approver that had been approved by the first approver. Neither of them had a global administrator role. Are you sure the account in question was in the scope of both approvers?

[MARUBUN SUPPORT]

A customer asked a question about how after updating from 4.1.3 to 4.2.2, they were no longer able to deny approval.
They said that they were able to deny approval without any issues in 4.1.3.
The permissions used are equivalent to FirecallApprover, and the authentication manager group is password manager.
The authentication group settings have not been changed, and there is currently no System Admin Group registered.

If the System Admin Group is required, could it be possible that the functionality working in 4.1.3 was actually a bug?

[Ralf Prigl]

I revised my first update after testing this myself with 4.2.3. Regarding your latest question, are you saying that your approvers can no longer deny requests, only approve them? That wouldn't make any sense and I don't think that can be true. Note that there is no Deny option for a request that had been approved already by someone else, all you can do is expire it. This makes me wonder whether you just have some confusion about Delete vs Expire vs Deny. A global administrator actually cannot Expire a password view request, if not included in the approver list of the PVP. But the global administrator can delete any request, which has the same effect as expiring it.

[MARUBUN SUPPORT]

There was an error in the wording.
In my experiment, there were two approvers. 
For the second approver to perform an Expire on an item approved by the first approver, they needed to be in the System Admin Group.
These two approvers are registered in PVP.

According to the customer's understanding, in the previous version(4.1.3), there were two approvers. 
The second approver could perform an Expire on an item approved by the first approver even if they were not set in the System Admin Group.
The customer believes this behavior may be a bug.

[Ralf Prigl]

Hello, Are the second approvers getting the following PAM UI error?

It turns out that in the system I tested the old workaround documented in knowledge document PAM-CM-0161: You do not have sufficient permissions after applying vulnerability fix was in place and I did not observe the problem for that reason. With the default firecall approver role I can see the same problem even with PAM 4.3. It looks like the fix in 4.2.1+ only addresses the problem for the initial approval. The user who approved the request can edit and update it later on, but other users that do not have the "Get User Group" privilege will run into the PAM-CM-0161 error. Users in the System Admin group of course have this privilege and don't see the problem. As the knowledge document suggests, you can make a copy of the FirecallApprover role, add the "Get User Group" privilege and assign that new role to your CM user groups for approvers instead of the FirecallApprover role.

We will take this up with PAM Engineering to get the remaining problem fixed in a future release.

[MARUBUN SUPPORT]

> Hello, Are the second approvers getting the following PAM UI error?

Yes, this error appeared.

[Ralf Prigl]

Ok, that's good to know. The PAM-CM-0161 error is a bug and we hope to get that fixed in the next releases, which should be 4.2.4 and 4.3.1. Look for identifier DE650894 in the release notes (list of resolved issues) once those releases are out. Once fixed, it should work as it did in 4.1.3. Until then the workaround mentioned in the knowledge document we pointed you to should do it.

[MARUBUN SUPPORT]

I have an additional question.
When adding this Get User Group permission, do you know what specific permissions become enabled?

[Ralf Prigl]

"Get User Group" is a specific permission, more accurately the label for permission getUserGroup, which is listed on documentation page Add or Modify Credential Manager Roles. When you create or edit a CM role on the UI, you see the labels, not the names listed on the documentation page, which is why we refer to it as "Get User Group" rather than "getUserGroup".