Sync users from Azure AD

[Dallin Wood]

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.

[support]

Hi Tim and Dallin,

 

Thanks for your votes - we appreciate it. As per the voting rules (https://forums.clickstudios.com.au/topic/2340-voting-for-features-please-help/), please only add one vote per organization, so it does not skew the results.

 

Thanks

Click Studios

[Jonas Franzén]

+1

[YannR]

+1

[feek]

+1

[Hans]

+1

[rolftn]

+1

[Hans Kurppa]

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

 

1. [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
   
   
    
2. [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
   
   
    
3. [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.
   
   
    
4. [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.
   
    
5. [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.
   
    
6. [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.
   
   
    
7. [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)
   
    
8. [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)
   
   
    
9. [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.
   
   
    
10. [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.
    
    
     
11. [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
    
    
     
12. 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.

[support]

Hans, thank you so much for sharing - we very much appreciate it

Regards

Click Studios

[BigDaddyJ]

+1

[Tore]

+1

 

Heard from sales that this is planned for v10. Looking forward to this. 

[Knightdragon89]

+1

[J S]

+1

[demain1]

+1

[MKay]

+1

[Haim Harush]

+1

[Valentijn Scholten]

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.

[support]

Hello Valentijn,

 

This feature will be coming in version 10.

Regards

Click Studios

[Tore]

When can version 10 be expected? In december 2022 I was told it was expected to be 6 months away.

[support]

Hi Tore,

 

Unfortunately we do not have a time frame for the release of version 10 yet.

We'll let all customers know, once we do.

Regards

Click Studios

[Eileen]

+1

[timj_envista]

+1

 

I see this is coming with v10, will we also be able to utilize Azure Guest accounts at this point?  That is a key feature we need.  Also, is there a tentative ETA for v10?

[BCoole]

+1

[Hans Kurppa]

On 9/21/2023 at 1:43 PM, Valentijn Scholten said:

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.

True. My tutorial takes advantage of AADDS which is an "on-premises AD copy" of Entra ID itself, that's residing inside the Azure tenant. The DC servers for AADDS are fully managed by Microsoft.

 

AADDS (Entra Domain Services) is not cheap but it's one solution to migrate legacy "onprem AD only" apps to the cloud. If you have AAD (Entra ID Connect) in the on-premises environment, AADDS is not useful because with AAD you already sync your cloud groups to onprem and vice versa.

[Hans Kurppa]

We do not have ETA for native cloud security groups. It could be in two months or two years.

 

If you have a requirement to decommission your onprem now, you could "lift" your Passwordstate installation to Azure with AADDS and then afterwards "shift" it to cloud native supported security groups when v10 is released (and decommission your AADDS because it's not needed anymore).