Search the Community

Hi Team, I'm aware you have SAML2 support, and we're currently making good use of that feature, however it'd be great if we could sync user information down from AD based on group membership. Even better if this includes the groups themselves, so we can manage users info and what Passwordstate security groups they get all from Azure AD. I see elsewhere you've suggested to just have your Azure AD sync with an on-prem AD, however that's not a great solution as it then requires that we manage our users from an on-prem AD, when we've moved to decommission such onsite servers. You can easily pull such information from something like Microsoft's own Graph API. List members - Microsoft Graph v1.0 | Microsoft Docs List group transitive members - Microsoft Graph v1.0 | Microsoft Docs Or even better use something like SCIM so any IDP that supports SCIM provisioning can provision users/groups to Passwordstate. SCIM: System for Cross-domain Identity Management (simplecloud.info) Tutorial - Develop a SCIM endpoint for user provisioning to apps from Azure Active Directory - Microsoft Entra | Microsoft Learn This feature would provide huge value for us in allowing us to centrally manage users for Passwordstate.

Hi all, My company is an MSP and uses PasswordState. We are moving many of our customer environments to Microsoft Azure. Customer VMs in Azure are accessed using RDP via an Azure Bastion host. I wanted to know if PasswordState supports the launching of RDP sessions to VMs hosted in Azure that must be accessed via an Azure Bastion service? I have searched the Internet and these forums and have not had a single hit on "PasswordState" with "Azure Bastion". I do see other vendors updating their products to support RDP connections via Bastion (e.g. RoyalTS just did this). The authentication scenarios would look like this: 1. Our engineers log into PasswordState using their in-house Active Directory accounts that we manage. 2. The engineer would launch an RDP session to a VM via Azure Bastion. The connection address would have to include the full path to resource in Azure. This could either be a Bastion shareable link which would look something like the following (both links are samples/obfuscated): https://bst-e5347507-0e14-42b3-971f-07058357fcbe.bastion.azure.com/api/shareable-url/70eac15e-b29b-4755-907b-b945213845a3 This will hit a logon web page like the following: Or, using the Azure Resource ID like the following: /subscriptions/2e5152ee-237e-44c6-b00a-682bff10711c/resourceGroups/ABC-RG-UK-MYRESGROUP/providers/Microsoft.Compute/virtualMachines/AMD-BKO-UKS-1 The latter is the method that RoyalTS now uses to specify the remote host. They use the Azure CLI Bastion extension to create the remote connection. 3. [Edited] The challenge as I see it is in being able to pass two sets of authentication credentials to Bastion to be able to log on, which will be required for some scenarios (see below). This is similar to how Terminal Server Gateway works - you need to authenticate to both the Bastion service (gateway), and to the target VM that you wish to logon to). In some scenarios, these credentials would have to come from two accounts: one with the privileges required to access Azure Bastion and the other to logon to the VM. PasswordState would have to be able to store and pass both. For reference, Bastion requires that the connecting user has the following Azure RBAC roles: Reader role on the virtual machine object. Reader role on the NIC with private IP of the virtual machine. Reader role on the Azure Bastion resource. Reader role on the virtual network of the target virtual machine (if the Bastion deployment is in a peered virtual network). Ref: Are any roles required to access a virtual machine? Logging on the VM itself would require one or two sets of credentials depending on how the VM is configured. Here are the scenarios I can think of: 1) The VM is Entra ID-joined. If this method is used, the account used to authenticate to Bastion could also be used to logon to the VM. In addition to the Entra ID RBAC roles given above, the account would also require the VM Admin Login or VM Login RBAC role. This would be the least common scenario for us. 2) The VM is joined to an AD DS domain. In this scenario, separate account credentials would have to be presented to authenticate: an Entra ID account (for Bastion) and then the AD DS domain account (for the VM). This would be very common for us. 3) The VM is in a local Windows Workgroup configuration. In this scenario, separate account credentials would have to be presented to authenticate: an Entra ID account (for Bastion) and then the local Windows account (for the VM). Has anyone done this already? Is there a config guide for this? If it's possible, I guess it's the connection string clarification that I need. As I say - I haven't found anything on the web around this config. Many thanks in advance, Garry