Jump to content

Valentijn Scholten

Members
  • Posts

    26
  • Joined

  • Last visited

Posts posted by Valentijn Scholten

  1. On 4/10/2022 at 5:14 PM, Hans Kurppa said:

    +1

     

    While we are all waiting for the eventual Privileged Account Credential "Read Azure Active Directory Security Groups and User Accounts", you could use Azure AD DS in your Azure tenant and join your Passwordstate Windows Server to that domain. This does not require any servers or services on-premises.

     

    We have one Azure native Passwordstate instance now in production with this setup. And we are in the process of doing a similar lift and shift for another onprem instance.

     

    With this setup, your Azure tenant syncs users and groups to the Azure AD DS domain and they will show up in the Passwordstate Admin, so that you can use them in Security Groups or User Accounts. From Passwordstate's point of view, the Azure AD DS will be an always up to date read-only copy of your Azure AD. If you need to provision and deprovision Passwordstate users or change group memberships, you do that in Azure AD as you would do with your normal identity management or user provisioning process.

     

    You would need to do the following steps. I suggest you first test this with a completely new VM (Windows Server 2022 Datacenter Azure Edition) and the free/trial version of Passwordstate.

    TL;DR
    Install Passwordstate on Azure IaaS VM Windows Server.
    Create Azure AD DS.
    Join Passwordstate server to Azure AD DS.
    Add AD Domain in Passwordstate.

    Add AD Security Groups in Passwordstate.
    Enable SAML2 auth.

     

    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.

  2. 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.

  3. 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.

     

    image.thumb.png.c7b0ebeaafb380b4873a933e9f8f455f.png

     

    The use case for us is:

    1. We link to Passwords and Password Lists from our WIki (Confluence)
    2. Users click on those links to access the Password or Password List.
    3. 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:

    image.thumb.png.024c92ffe31b76161815bbcdb9102c5f.png

  4. Hi,

     

    Here is a request by the support team.

     

    image.png.5ceb6e91e51de4c5b73ca5c9ef31f66a.png

     

    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:

     

    image.png.15033e507b2d40d4b28f93f35da3bbcd.png

     

    Valentijn

  5. 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.

     

    image.png.2ad98f0ff83f367305a0462390a66394.png

     

    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

     

  6. 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

     

×
×
  • Create New...