Jump to content

Sync users from Azure AD


Dallin Wood
 Share

Recommended Posts

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

 

This feature would provide huge value for us in allowing us to centrally manage users for Passwordstate.

Link to comment
Share on other sites

  • 2 months later...
  • 4 weeks later...
  • 3 weeks later...
  • 3 weeks later...

+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.
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...