Valentijn Scholten

My understanding of the feature request is for Passwordstate to support Azure AD groups. So cloud only groups. The tutorial given by you, and the passwordstate manual, only works for on premise security groups. Those on premise groups have certain drawbacks and miss a lot of governance related features like access requests, access reviews, etc. So for passwordstate to keep up with modern Azure AD functionalities it "must" support these cloud groups. Or maybe more in general it should support the groups or roles claim in SAML.

Is that a question or a statement? The usecase is that if somebody requests access, they don't know who to ask to approve it. Not all approvers are constantly reading their emails or logging into passwordstate. In which case they come to the global passwordstate admins, but they cannot see access requests meant for other approvers. Simply showing the approver(s) would help to avoid this overhead.

Hi, In previous versions of Passwordstate it was possible for users to request access to a list (or password) they were trying to view via a permalink. Currently this is no longer possible, leading users somewhat to a dead end. Please note there are no administrators displayed as well, so the user might be lost on who to contact for access. The use case for us is: We link to Passwords and Password Lists from our WIki (Confluence) Users click on those links to access the Password or Password List. If they don't have access, they should be able to: Request access, or, See who the admins are so they can contact them. The second option in my opinion is only a quickfix as the user should be able to request access. If a user browses manually to the password list via the navigation tree, there is in fact a request access screen. Ideally that same screen shown, possiblt behind a "Request Access" button. This the old screen from v7:

Hi, Here is a request by the support team. In previous versions of Passwordstate the following features were present when requesting access to a password list: 1) The list of password list administrators was shown 2) The requester could choose which administrator to notify: 1 administrator from the, or all in the list The use case for this for user to know (or to choose) who will receive the access request. This allows them to choose somebody who is actually present or someone who they can ping to look at the request. Feature 2 would also be nice to have to prevent multipleadministrators from getting a notification e-mail when only 1 is enough. This is the old screen from v7: Valentijn

Hi, We have a generic setup where each of the projects we work on has 3 password lists: - develop - acceptance - production This more or less mimics the OTAP setup used in software development / hosting. Now when a password list admin gets an Delta Permissions Report email notification from passwordstate, it only shows the name of the password list. These emails only show 'develop' or 'acceptance' or 'production'. The email contains no information from which it can be concluded which project / folder the notification / permission changes applies to. Our suggestion would be to include the full path of the password list (or password) in the Passwordstate Tree. I tried modifying the email template, but the AdditionalBodyText variable is outside of our control. Valentijn

Hi, For our permission review we currently use the "What permissions exist (all users and security groups)?" report. This report enumerates all users with access for each password. So in the following scenario: - 1 password list, i.e. "Apple Devices"; - 100 passwords, i.e. MAC001, MAC002, ...; - 5 users have a permission assigned at the "Apple Devices" list level; In this scenario I would like to only review these 5 permissions. So ideally the report contains only 5 entries, 1 for each user. i.e. 5 rows. The current "What permissions exist (all users and security groups)?" report contains 500 rows as it lists all 5 users for each of the 100 passwords. We have over 500 password lists, so the current report is almost impossible te review as it's so big. Alternative might be to change the report / styling to make it clear which permission came from the list level and which permission is an individual password permission. I think I tried the other permission reports as well, but none of them provide the "non-enumerated" output we would ideally have. Valentijn

+1, especially because deleting a password lists currently also deletes all associated audit logs.

I also think the query above does not take the number of members of a group into account? I might take a look at adjusting the query as we are possibly looking at making sure all lists have at least 2 admins.

I agree the query works fine, but it requires SQL access. I wouldn't want to allow too many servicedesk people access to the database (and bypassing audit logs). So would be nice to have the report in place. The primary usecase I would use this report is when/before deleting a user. So ideally the report would be "Password lists for which a user is the only admin".

Hi, Sometimes it happens that people are leaving our company. When their account is deleted (or disabled) it can result in passwordlists having no admin anymore. As far as I can tell there's no easy way to generate a report of these lists, so that would be a welcome addition to passwordstate. Any work arounds maybe? Valentijn