+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.
[Azure] "Hosting Passwordstate in Microsoft Azure" Base Passwordstate Installation in Azure and AWS (clickstudios.com.au) Passwordstate Installation Instructions (clickstudios.com.au)
Create one Azure IaaS Windows Server and one Azure SQL Database/server.
You can do the Passwordstate server installation and the Initial Setup Wizard on a non domain joined Windows Server and later join the server in Azure AD DS.
Or you can first do the steps 3 and 5, and then do the Passwordstate server installation. note1: If you have mostly password data and only a handful of Documents in your Passwordstate database, the cheapest Azure SQL Server (DTUs, Basic) $5/month will most likely be enough. note2: For the VM, I would start with Standard B2s. It's a 2 vCPU, 4 GB RAM and Standard SSD. Make sure to select Standard storage, as the more expensive Premium SSD is selected by default. You don't need the additional IOPS on this server as the database is hosted elsewhere. Also, you don't need any additional storage, as the Windows Server VM already includes a 128 GB C:\ Drive. Cost is around $35/month. note3: For the production install. If the Passwordstate will be accessible from Internet, consider setting up two VMs. Passwordstate server VM will be joined to the AADDS domain, will not have public IP. Another VM in a separate DMZ vNet will have the Passwordstate web server, not joined to AADDS, has a public IP. Create vNet peering between AD joined vNet and DMZ vNet. note4: Also for the production install, I suggest you do some basic hardening with private endpoint feature, so that the Azure SQL Server is accessible only from your Passwordstate server through Azure's internal network, and not from anywhere else. Azure Private Link - Azure SQL Database and Azure Synapse Analytics | Microsoft Docs
[Azure] Web Server DNS record and TLS Certificate
Go to Azure Portal > search your VM > Overview > click on Public IP address
If it says Dynamic: Stop the VM > change to Static > start VM
Register public DNS name, for example pass.mycompany.com = A record pointing to your VM's Public static IP address
Go to Azure Portal > search your VM > Networking
Make sure HTTP and HTTPS are allowed in the Inbound port rules and Source is Any.
Open RDP to the VM and install a TLS Certificate on the Passwordstate IIS Site.
For certificate automation I suggest the free WinCertes tool which can create Let's Encrypt certificates.
WinCertes.exe -e me@mycompany.com -d pass.mycompany.com -w=c:\inetpub\Passwordstate -b "Passwordstate" -p note1: Make sure you set the same DNS name in Passwordstate.
Go to Passwordstate > Admin > System Settings > Miscellaneous > Specify the Base URL for your site note2: Depending on the use case, you might be able to harden the Passwordstate installation security even further, by disabling public Internet access to the DNS Name/Web Server, and setting up for example Azure AlwaysOn VPN User Tunnel on your users endpoints. This is also called a "Point-to-Site VPN connection". You can still use SAML2 with this hardening. It will work as long as the end user's browser can access both the Passwordstate URL and the Azure/M365 login portal. https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-always-on-user-tunnel
[Azure] Create Azure AD DS resource Tutorial - Create an Azure Active Directory Domain Services managed domain | Microsoft Docs note1: As a security practice, install it in a separate vNet. After the AADDS is Running, create a vNet peering between AADDS vNet and the vNet that has your Passwordstate server. note2: Make sure you change Passwordstate server's vNet DNS Servers to IP addresses shown in AADDS Properties. They are the Domain Controllers for your AADDS. note3: The AADDS DNS Name cannot be changed afterwards. If you have a custom domain in your tenant, say mycompany.com, I would suggest you use aadds.mycompany.com as the DNS Name. In this case, the AADDS NetBIOS Domain Name would become AADDS. If you have user1 in your Azure AD, it would show up as UserID aadds\user1 in Passwordstate Admin. edit: Microsoft recommends to use aaddsmycompany.com. In this case the whole DNS namespace would be unique. So if you want to be safe, you would need to buy the public DNS Domain aaddsmycompany.com. And now you have yet another operational responsibility... They don't give any actual technical reasons for the recommendation, but my guess is that, if you would need to later do some cross organisation stuff in this AADDS, your AD Domain NetBIOS Names would not conflict. But we shouldn't have to worry about AD trusts in the cloud anymore, right Microsoft? Bueller... Bueller...? My opinion is that just keep it simple and use aadds.mycompany.com. note4: AADDS starts around $100/month. The vNet peering cost is insignificant. note5: Azure takes a while to deploy your AADDS. When you're finished setting it up and it is at the "deploying" stage, it could take couple of hours. note6: If you mess up this step, just delete the AADDS resource and create a new one. This isn't related to Azure AD Connect or any other critical AD service in Azure. Also, you can have more than one AADDS resource. edit: Correction. You can create only one per Azure AD directory. Plan accordingly.
[Azure] Create Service Account for Passwordstate's LDAP sync Add or delete users - Azure Active Directory | Microsoft Docs
For example, svc_passwordstate@mycompany.com.
You will use this in Passwordstate Admin > Privileged Account Credentials.
This is basically a read-only account that reads data from AADDS LDAP and saves it to Passwordstate SQL database.
Does not need any specific licenses, M365 features, or group memberships.
You can't use an Azure AD Service Principal here, because the user must be able to login with username and password. Service Principals can use only Certificate or Client secret authentication. note1: After you have created the Azure AD user, do a Password Reset and it will show a temp password. Login to https://myaccount.microsoft.com/ as the Service Account user with the temporary password, and change the password again. This is just to make sure that the user's password hashes are synced initially to the AADDS domain, so that you can use this Service Account later in the Passwordstate Admin.
[Azure] Join your Passwordstate server to the AADDS domain you created at step 2 Join a Windows Server VM to an Azure AD Domain Services managed domain | Microsoft Docs
Normal AD join operation for the Windows Server. Domain name would be aadds.mycompany.com.
If it fails, do some basic troubleshooting, ex. "nslookup aadds.mycompany.com" and "test-netconnection aadds.mycompany.com -port 389". After you changed the vNets DNS Servers, make sure you rebooted the VM once.
If you do the join operation with Azure user myaccount@mycompany.com, you can use myaccount as the username in the join dialog. note1: If you get This device is joined to Azure AD..., then you have enabled the "login with Azure AD" feature for your VM. You need to disable it because we will join this same VM back to Azure AD, and we can't reuse the existing Device resource in this join operation. Go to Azure Portal > search your VM > Identity > System Assigned > Set Status = Off > Save and confirm change. Make sure you have a local admin account on the VM, so that you can RDP to it, if you previously used only the "login with Azure AD". note2: If you get The referenced account is currently locked out and may not be logged on to, the AADDS domain does not have the users NTLM hash. You need to change your password once in Azure AD. The join operation uses NLTM authentication. When you change a password in Azure AD, the NTLM hash is synced to the AADDS domain. This is just for the Windows Server AD join operation. You don't need to worry about NTLM hash sync for the actual Passwordstate users as they will authenticate with SAML2.
[Passwordstate] Emergency Access password Passwordstate Security Administrators Manual (clickstudios.com.au) (page 32)
Just a heads up, before you start changing your Passwordstate configuration.
In case you mess up your Passwordstate config and get locked out, or the authentication is incorrectly set, you can always login with Emergency Access password.
[Passwordstate] Set Admin > Privileged Account Credentials
Go to Passwordstate > Admin > Privileged Account Credentials > Read Active Directory Security Groups and User Accounts
If the DNS Name at step 2 was aadds.mycompany.com, and the Service Account at step 3 was svc_passwordstate@mycompany.com, enter the following and Save.
UserName = svc_passwordstate@mycompany.com
Site Location = Internal
Account Type = Active Directory
Password = (the password you set/reset at step 3)
Link to Password = (Not Required)
[Passwordstate] Add Admin > Active Directory Domains
Go to Passwordstate > Admin > Active Directory Domains > Add
If the DNS Name at step 2 was aadds.mycompany.com, and the Service Account at step 3 was svc_passwordstate@mycompany.com, enter the following and Save.
AD Domain NetBIOS Name = aadds
FQDN = aadds.mycompany.com
AD Domain LDAP Query String = dc=aadds,dc=mycompany,dc=com
Domain Controller FQDN = (leave as empty)
Site Location = Internal
Account with Read Access = Read Active Directory Security Groups and User Accounts
Used For Authentication = Yes
Protocol = LDAP (Port 389)
[Azure] Create your Passwordstate user groups Create a basic group and add members - Azure Active Directory | Microsoft Docs
For example, Passwordstate Admins = add your Global Administrator user accounts directly to this user group Passwordstate Users = add your normal user accounts directly to this user group note1: If you already have a working SAML2 authentication in Azure AD and you have limited the Enterprise Application access to specific groups, you can now use those directly inside Passwordstate, and you don't need to create new user groups. note2: If you are using the free/trial Passwordstate, maximum users is 5.
[Passwordstate] Add Azure AD groups
Go to Passwordstate > Admin > Security Groups > Add AD Group
Search for some group you know you have in your Azure AD.
You can't search for wildcard only *. You need to enter a few characters from a group name.
When it lists the groups you wanted, you now have a working, always up to date Azure AD user and group sync to your Passwordstate installation.
For example, add the groups you created in the previous step. To grant the Passwordstate Admin access for Azure AD group:
Go to Passwordstate > Admin > Security Groups > Add AD Group
Go to Passwordstate > Admin > Security Administrators > Add note1: M365 Role Assignment "groups" do not show up here. For example, Global Administrator role group.
[Azure and Passwordstate] SAML2 Authentication Passwordstate Security Administrators Manual (clickstudios.com.au)
(page 99, "Primary Site's SAML2 Authentication Settings")
(page 106, "Azure Active Directory") note1: You can configure the SAML2 differently, depending on the use case, but I suggest you use UserPrincipalName as the "Name Identifier - NameID", because that field is always populated for users synced from AADDS. You can double check that these actually exist by going to Passwordstate > Admin > User Accounts > select a user that's synced from AADDS LDAP.
For this to work, make sure you set the following: In Azure > Enterprise Application > Single sign on > Attributes & Claims > Unique User Identifier = user.userprincipalname In Passwordstate > Admin > System Settings > Authentication Options > (scroll down) Primary Site's SAML2... > Select which field in Passwordstate... = UserPrincipalName
Test SAML2 login
Go to the DNS Name you created at step 2, ex. https://pass.mycompany.com/
Login as a normal user you added in step 9 to Azure AD user group Passwordstate Users.
It should open the Passwordstate screen, without Admin Tab.
Logout and login as an administrator account you added in step 9 to Azure AD user group Passwordstate Admins.
It should open the Passwordstate screen, with Admin Tab.
