Considerations:

This document will be important to you if..

• You require Migration Agent for the migration of Windows Workstations
   
• You require one or more of: Password Sync Agent, Proxy Agent or Remote Sync Agent. This might be projects to synchronise Active Directory (AD). Or you may need to sync users and computers for a Migration Agent project where you do not have network line of sight to a Domain Controller.
   
• You require all the above

NOTE: in this article we will be referring to the common ports used for publishing PowerSyncPro (443, 5000, 5001). For a full list of port requirements, consult the PowerSyncPro Prerequisites guide (Downloads and Documentation)

There are various ways for you to communicate with your PowerSyncPro server endpoint when using Migration Agent, Password Sync Agent, Proxy Agent or Sync Agent endpoints.

Windows Workstation Migration Agent

For the PowerSyncPro Migration Agent, most customers will almost certainly need the PowerSyncPro server (that orchestrates everything) accessible over the internet and restricted to only the /agent URL. Workstations (laptops) will not necessarily always be on the corporate LAN e.g. remote workers.  

The device join state will most likely be changing, but we need to maintain continuous uninterrupted access to the PowerSyncPro server.

Windows Workstations need to be able to receive their schedule and understand if they are in scope (this is called a Batch), download the user translation table and configuration to run (called a Runbook). You setup communication between the server and workstation using an endpoint (the webserver dedicated to your project). This endpoint needs to always be available so that you can also receive logging telemetry such as when the machine becomes registered and receive other information like user profile harvesting and the actual migration event logs.

The PowerSyncPro server should be accessible from all networks where your workstations might be connecting from, e.g. corporate LAN, working from home, or at client offices.

Windows Workstation migration event traffic to the Kestrel webserver endpoint is always secured via the Public/Private certificate configuration inside the PowerSyncPro sever, even over the http endpoint.  However, most organisations will still want to wrap the entire network communications to the server endpoint over an SSL/HTTPS connection.

SSL Certificates

Choices for securing the endpoint:

Self-Signed Certificate 
A self-signed certificate is quick and easy to configure on the PowerSyncPro server and the installation and is free.  However, the downside is that the certificate must be added to every Workstation in advance so that it can be trusted.

Internal Certificate
If you already have an Active Directory integrated PKI environment, then you can secure your endpoint with a certificate that is implicitly trusted by all devices with little to no additional configuration and is free.  The downside is that when your Windows Workstation leaves the Active Directory Domain, then almost certainly the trusted root certificate will be removed midway during the migration event (for example when your devices are being removed from the control of GPOs) and your Workstation will no longer have a trusted SSL connection to the PowerSyncPro endpoint to complete the migration.  If any of the process has problems you will not receive the logging telemetry from the workstation if it cannot connect to the PowerSyncPro server.

3rd Party Certificate (recommended)
Using a 3rd Party certificate applied to the PowerSyncPro endpoint requires additional configuration to acquire and install the SSL cert and carries a small cost - but has the benefit of being trusted by all devices explicitly with no additional touchpoint configurations on the Workstations (or remote agents). It is likely that most organisations may have a wildcard corporate certificate that can be leveraged that would reduce cost and configuration.

Recommendation
We recommend using a 3rd Party SSL certificate from an official authority for your PowerSyncPro project.

Migration Agent: (recommended endpoint)

A dedicated subdomain using your corporate domain, with a 3rd Party SSL certificate. 

https://pspmigration.corp.com/agent

Firewall/server port required to be open: 443

The above requires port 443 available end-to-end to the PowerSyncPro server. You should use a 3rd Party Certificate bound to port 443 on IIS on your PowerSyncPro Server with an IIS rewrite rule to Kestrel.

Directory Synchronisation

If your PowerSyncPro server has direct line of sight / network connectivity to your on premises Active Directory Domain Controllers, and you are not doing modern password sync, then Remote Agents leveraging gRPC with HTTP/2 endpoints are not needed.

For Password Sync Agent, Proxy Agent and Sync Agent you will need a gRPC endpoint.

These all require gRPC with HTTP/2 endpoints which cannot be via IIS due to gRPC technical limitations (and therefore 443 is already taken), but it is still mandated to be an SSL (https) connection.

https://pspmigration.corp.com:5001/agent

Firewall/server port required to be open: 5001

If your traffic is all internal, and you are not going over the internet, it is perfectly acceptable to use an internal CA or a manually created certificate which is made to be trusted by the servers involved. However, a public certificate authority SSL cert is recommended.

As Sync Agent, Proxy Agent and Sync Agent are likely to be on machines which are static, or from known endpoints, you should use the firewall to only allow those IP addresses to communicate with the PowerSyncPro kestrel endpoint on port 5001.

Scenario using sync agent, proxy agent and password agent

The following image depicts a fictious scenario of two companies requiring to bidirectionally synchronise passwords and identity over the internet. corp.local also has RC4 disabled, whereas other.local is using password hashes. 

1. Syncing identities internally from the corp.local domain using PowerSyncPro Sync Agent installed on a member server.
    
2. RC4 is disabled in corp.local, so passwords are being taken from the corp.local DC using Password Sync Agent installed on the Domain Controller.
    
3. Using PowerSyncPro Proxy Agent in a DMZ for transiting communication to the internal other.local network. No credentials stored. Proxy Agent is not a requirement, it is only for demonstration to utilise the features available to you with PowerSyncPro, you can communicate directly with Remote Sync Agent if desired.
    
4. Using Remote Sync Agent in other.local which has the credentials encrypted for the other.local AD domain.
    
5. Syncing identities to an external company other.local, RC4 is not disabled in other.local so we are just using the Remote Sync Agent to apply password hashes. 
    
6. No credentials for other.local are configured or stored on the PowerSyncPro server residing in corp.local, a one time PSK and approvals process was used to authorise the communication to the Remote Sync Agent.
    
7. We are using https://pspmigration.corp.com:5001/agent for external endpoint
    
8. We are using https://pspmigration.corp.local:5001/agent for internal endpoint
    
9. The firewall for both corp.local and other.local has been configured to only allow port 5001 traffic between the endpoints so no other actors can attempt communicate with PowerSyncPro.

PowerSyncPro admin portal

We always recommend restricting any external access to the admin portal. The most secure method to access the admin interface is via the localhost interface below. PowerSyncPro recommends ALL configuration to be performed directly on the server itself and controlling accessing using user accounts in the PSP admin interface.

Therefore, you should only access the admin interface by navigating to the following address when remotely controlling the server.

http://localhost:5000/

NOTE: do not try to change this configuration as you will not be able to create a bulk enrolment token with the provided github scripts.

Hardening Recommendations

In production environments we recommend usual hardening to keep the service as secure as possible, this includes:

1. Prevent access to the logon page Restrict access to Logon page from the internet. Restrict access to Logon page from the internet. - PowerSyncPro
    
2. Disable SSL, TLS 1.0 and TLS 1.1 on the PSP Server https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/operations/manage-ssl-protocols-in-ad-fs 
    
3. Disable less secure ciphers on the PSP Server http://www.waynezim.com/2011/03/how-to-disable-weak-ssl-protocols-and-ciphers-in-iis/ 
    

More advanced configurations for the enterprise.

1. Use https throughout, this could be via Application Gateway, IIS Reverse Proxy, Firewall restrictions, etc.  If using IIS, then consider enabling HSTS to ensure https is used and reduce the possibility of MITM attacks
    
2. Consider limiting the hostnames that are allowed, be that via reverse proxy settings, or directly by adding AllowedHosts to appsettings.json https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel/host-filtering?view=aspnetcore-8.0
    
3. Consider using HSTS to further guard against MITM attacks. https://learn.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10-version-1709/iis-10-version-1709-hsts 

Migration Agent - Proof of Concept or testing configuration 

For circumstances when you have an Always on VPN or all workstations on the LAN, you can choose to not have an SSL cert and use HTTP with port 5000 direct to Kestrel for Migration Agent. The connection will still be secure as we also always use the internal private PSP certificate for communication. This is not recommended for migration of devices over the internet. So you could configure PowerSyncPro Migration Agent endpoint as the following.

http://psp.companydomain.com:5000/agent

Firewall/server port required to be open: 5000