This section documents the setup of our privileged access management lab using ManageEngine PAM360, hosted in a cloud-based environment on Microsoft Azure. The goal was to establish a secure infrastructure where privileged credentials, remote access, and session activity are centrally managed and monitored.

1. Create a dedicated resource group in Azure to manage all resources for this PAM360 environment.
2. Set up a VNet with two subnets:
   • Subnet 1: For hosting PAM360 (Windows Server)
   • Subnet 2: For your test resources (e.g., Windows 10, Ubuntu VMs)

Azure VNet Help: Create and Manage Virtual Networks

An example configuration:

1. Create the following VMs, assigning them to the appropriate subnet:
   • PAM360 Server (Windows Server) – Hosts the PAM360 application.
     • Recommended: Standard D4s_v3, 16GB RAM and 100GB SSD (minimum 8 GB RAM and adequate storage)
   • Windows 10 Client VM – Used to test RDP access and local user credential management.
     • Recommended: Minimal specs sufficient
     • Create multiple user accounts for testing
   • Ubuntu VM – Used to test SSH-based access control.
     • Recommended: Minimal specs sufficient

Important: When creating VMs, ensure to:

• Attach them to the VNet you configured

• Set up Network Security Group (NSG) rules as shown below:

  

🔗 Official Installation Reference: ManageEngine PAM360 Installation Guide

1. Download Installer from the ManageEngine website.
2. Run Installer and and follow the on-screen instructions.
3. Choose the Installation Type:
   • Select “High Availability – Primary Server” setup.
   • Use "Read-Only Server" only for end-users or secondary setups.

1. Access the Web UI via http://localhost:8282 and log in with default credentials (admin / admin).

1. Change Default Password and update admin contact information.

To enable email alerts for password changes, user creation, etc., configure the SMTP settings :

1. Go to Admin → Mail Server Settings

1. For our PoC we created a Gmail account and generated an App Password.
   • Create a Gmail account
   • Navigate to Google Account → Security → App Passwords
   • Generate an app password for "PAM360"
2. Configure SMTP settings in PAM360:
   • Server: smtp.gmail.com
   • Port: 587
   • Sender Email: your Gmail address
   • Access URL: https://PAM:8282
   • Authentication: Enable and set manually
   • Username / Password: your Gmail + app password
   • Protocol: TLS

1. Go to Resources → Add → Add Resource Manually
2. Fill in:
   • Resource Name: VMWindows
   • IP Address: IP of your Windows 10 VM
   • Type: Windows

1. Add a user account manually using the credentials you defined during VM creation.

1. Click Discover Accounts to automatically fetch all users from the VM using the added admin credentials.

Use the Discover Resources feature:

1. Go to Resources → Discover Resources
2. Select:
   • Type: Linux
   • Discover By: Hostname or IP (you can also specify a range)
3. Create a discovery profile:
   • Name: LinuxProfile
   • SSH Port: 22
   • Authentication: Manual (enter the Ubuntu VM username and password)
   • Account Discovery: Enabled

1. Run the discovery scan.
2. Add the discovered VM to PAM360.

Now that the Windows and Linux VMs are added, try initiating remote sessions directly from PAM360 to ensure proper configuration and user mapping.

🎉 Congratulations! You’ve successfully set up PAM360 in a cloud-based Azure environment. Your privileged accounts are now centrally managed and ready for secure usage.

One of the goal when implementing a PAM in your architecture is access control, if we push this principle a bit further we can imagine using PAM console as a single entry point to access sensitive computer and it is also one of the best practices recommended by ManageEngine.

In order to achieve this we can set up a vpn connection between a work computer (external) and our secure network.

The desired state is the following :

We will keep this simple for our POC to better understand the principle and don’t overload with many details.

We need several things to initiate a vpn connection to azure private network:

• Self signed certifcate
• Virtual network gateway from Azure
• Public Ip from Azure
• Point to site connection

Let’s go through the process!

In your resource group, create a "Virtual network gateway" resource.

Add a Gateway subnet address range (like 10.1.1.0/27). You will also need a public IP:

Once your VPN gateway is deployed correctly, click on it and go under Settings => Point-to-Site Configuration.

"Address pool" is for the IP that will be dynamically associated to your computer when initiating a VPN connection

Tunnel type → choose IKEv2 and SSTP so that you can use it on Windows and MAC devices.

Short reminder

• IKEv2 (Internet Key Exchange v2): VPN protocol that supports mobility and auto-reconnect. Commonly used with IPsec for secure tunneling. Great for mobile devices.
• SSTP (Secure Socket Tunneling Protocol): VPN protocol that uses HTTPS (TCP 443) to tunnel traffic. Useful for bypassing firewalls and works well behind proxies. Built into Windows.

For this proof of concept, both the root certificate and the corresponding client certificate were self-signed and generated locally on my local computer using PowerShell. This approach was chosen for its simplicity and speed — it allowed full control over certificate creation and easy integration into Azure’s Point-to-Site (P2S) VPN setup. The root certificate was then uploaded to the Azure VPN Gateway, and the client certificate was installed locally to authenticate the VPN session.

While this local generation method is perfectly acceptable for testing and lab environments, in a production scenario it is generally recommended to issue certificates from a centralized and secured Certificate Authority (CA). This ensures better management of the certificate lifecycle, revocation, and trust hierarchy.

An alternative might have been to generate the certificates directly on the PAM server. However, this does not offer a security advantage for P2S VPN use cases, as the PAM server is not intended to act as a CA and doesn't provide dedicated tools for secure certificate issuance or distribution. In contrast, generating the certificates locally gave more flexibility during the PoC phase without adding server-side complexity.

Furthermore, PAM360 itself does not support generating certificates for Azure VPN authentication. Its certificate management capabilities are oriented toward managing SSL certificates and SSH keys, not issuing identity certificates for network authentication.

In summary, local certificate generation was appropriate for this controlled environment, but in a real-world deployment, certificates should be handled by an enterprise-grade CA with policy enforcement, revocation capabilities, and secure issuance workflows.

You will use Powershell and the following commands to generate a root and client certificate on your local computer.

$cert = New-SelfSignedCertificate -Type Custom -KeySpec Signature `
>> -Subject "CN=VpnP2SRootCert" -KeyExportPolicy Exportable `
>> -HashAlgorithm sha256 -KeyLength 2048 `
>> -CertStoreLocation "Cert:\CurrentUser\My" `
>> -KeyUsageProperty Sign -KeyUsage CertSign

New-SelfSignedCertificate -Type Custom -DnsName P2SChildCert `
>> -KeySpec Signature -Subject "CN=VpnP2SClientCert1" `
>> -KeyExportPolicy Exportable -HashAlgorithm sha256 -KeyLength 2048 `
>> -CertStoreLocation "Cert:\CurrentUser\My" `
>> -Signer $cert -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2")

If you want to install VPN on many computers, execute the second command multiple times in order to generate several client certificates. The benefit from this action is that you can revoke it in Azure using the thumbprint of the client certificate(.pfx), so if an employee doesn’t work for your company anymore, no need to uninstall his certificate, just revoke it instead.

You will then export your certificates to reuse them later in your local machine. You can manage this using certmgr on windows (typing "certificates" in the Windows search bar).

Here you will see all your certificate and those we have just created (GfgP2SClient & GfgP2SRootCert)

For the Root certificate:

• Do not export private key
• X.509 encoded base 64 (.cer)

For the Client certificate:

• Export private key
• PKCS format (.pfx)
  • Include all certificates in certification path → YES
  • Enable certficate privacy → YES
• Enter a password (remember it) testvpn

To sum up, the .pfx file will be the client certificate that you will install on your computer and on other that needs to have the VON.

Go back to your VPN in Azure and under root certificate paste the value of .cer generate previously.

TIP→ open it with notepad and copy value inside Azure

the .cer is used in azure as root certificate for your vpn connection.

Then choose your .pfx client certificate and install it on the required computer(give the password you set during the exportation - testvpn -)

.pfx → store a certificate along with its private key in a single, encrypted file.

.cer → digital certificate used to verify the identity of a server, user, or device and to establish secure communications using public key infrastructure (PKI).

X.509 → standard that defines the format of public key certificates used in secure communications, such as SSL/TLS, to verify identities and enable encrypted data exchange.

The last step is to download the VPN client from Azure and install it on our own computer. Then, launch the VpnClientSetupAmd64.exe(for Windows).

Check that you have the VPN connection from your settings and connect it.

Once you are connected : test the URL — https://10.0.0.4:8282 — you should be able to see the PAM console (verify that your PAM server is started)

Here are a few sources to help you debugging if something went wrong.

https://www.youtube.com/watch?v=Yshpo6V1qUQ

powershell - VpnClientSetupAMD64.exe missing in Azure point-to-site VPN download - Stack Overflow

Configure User VPN clients: certificate authentication: Azure VPN client: Windows - Azure Virtual WAN | Azure Docs

Now that we have our VPN and that we can connect to the console (as it should be implemented in a real world entreprise), the final step is to configure the subnets so that you can only access PAM console from the VPN and initiate remote session through it, and not directly from other tools like RDP from your own computer. Keep in mind that this is a PoC and that in a real world implementation there will be more specific rules and strict access.

In order to achieve this, lets make a Network security group (NSG) for our ressource subnet in Azure and add the following rules:

1. Deny all access from our VPN connection to our subnet “ressources”

2. Deny direct RDP from our VPN to Pam server

Like this we are sure we can ONLY access ressources via the PAM console while being connected with VPN and that we respect our initial architecture.

Ressource subnet:

PAM server:

In order to take RDP or remote sessions from the PAM console to our sensitive ressources you need to add a rule in the firewall of pam server since gateway for rdp go through the port 8283.