PIM Manager on a private network: your options for DNS, routing, segmentation and policy

Written by the PIM Manager team for PIM Manager 2.4.579 · 2026-10-10

This chapter describes the decisions you make before you run PIM Manager in private (internal) mode. Both step-by-step guides refer to it: Install PIM Manager in private mode and Convert a public environment to private.

It uses the same terms as the Architecture and Security presentation:

• Public (external) mode. The PIM Manager has a public HTTPS address with Entra sign-in in front of it.
• Private (internal) mode. The PIM Manager has a private IP address in your virtual network. People reach it only through your private path: VPN, ExpressRoute, Entra Private Access, or a jump host.

The topology names are Single (one tenant), Managing tenant (a provider that manages other tenants) and Managed tenant (a customer tenant managed by a provider).

We do not configure your network for you. The PIM scripts build only what lives inside the PIM resource group: the Container Apps environment, the private endpoints for PIM’s own registry and database, and their private DNS zones. They can also create the peering to a hub and link DNS zones to it, but only when you ask them to and only when the identity running them has rights on the hub. Your firewall, routing, DNS forwarding, the NAT gateway, NSGs and Azure Policy stay under your control. For every decision below, this chapter lists the options, what PIM needs from you, and what the scripts do.

0. Who does what

Prerequisites

Regions

You choose the region (PIM 2.4.577+); data residency is your decision. The guided install, Invoke-PimDeployAll.ps1 and Invoke-PimMspBuild.ps1 check in their preflight, before anything is created, that every service PIM Manager needs is available in that region for your subscription (Container Apps, Azure SQL S0, registry, Key Vault, storage, Log Analytics, managed identity). If one is missing, the preflight names it and suggests the nearest region that has all of them. If your Azure Policy has an allowed locations list, it must include the region you pick.

Address plan

The PIM VNet must not overlap with your hub or any network it peers with. The peering plan refuses overlapping ranges.

Roles for the person (or Invardia support session) running the install

These are the same roles the guided install documents:

• Owner, or Contributor + User Access Administrator, on the PIM subscription.
• In Entra ID: Privileged Role Administrator (Graph permissions for the managed identities, and the role-assignable SQL admin group) and Application Administrator (the PIM Manager’s sign-in app). Exchange Administrator only if the install should create the notification mailbox.
• Owner or User Access Administrator at the tenant root management group. This is recommended: it gives the engine Reader there so Discovery can see Azure. If it is missing, the install ends with a warning and the command to run later.
• Network Contributor on the hub VNet, only if the scripts should create the hub side of the peering. Add Private DNS Zone Contributor on the DNS resource group if the environment’s zone goes next to the hub. If you do not want to grant these, use -SkipPeering and hand the hub owner the script written by New-PimHubPrepareScript.ps1.

Resource providers

New-PimHostingPrerequisites registers these itself: Microsoft.App, Microsoft.ContainerRegistry, Microsoft.OperationalInsights, Microsoft.Network, Microsoft.Sql, Microsoft.Storage and Microsoft.KeyVault.

Where you run the scripts from

In private mode the deploy host does not need a route into the VNet for most steps:

• the database schema, the database users and the feature switches are applied inside the environment by the bootstrap job ca-pim-dbinit;
• the image build runs on the registry’s build pool.

Three things do need a host inside your network, or one that can reach the private SQL endpoint:

• the end-of-install check, Confirm-PimInstall.ps1;
• registering a licence file, Set-PimLicense.ps1 (an enrollment key is refused when SQL is private);
• the first sign-in test of the PIM Manager.

1. DNS resolution

1.1 What must resolve, and for whom

1.2 Who hosts the zones: options

1.3 On-premises clients and custom DNS servers

A VNet whose DNS servers are your own, such as domain controllers or a DNS appliance, does not resolve Azure private zones by itself. You need one of these:

1. Azure DNS Private Resolver (recommended). Put an inbound endpoint in the hub and link the zones to the hub. Then add conditional forwarders on your on-premises DNS:

   • the environment’s default domain (<unique-name>.<region>.azurecontainerapps.io);
   • privatelink.database.windows.net and privatelink.azurecr.io, if anyone outside Azure must reach them (usually only admins running checks);
   • your custom name’s zone, if it is an Azure private zone.

   Point the forwarders at the resolver’s inbound IP.

2. A DNS forwarder VM in the hub that forwards those names to 168.63.129.16. That address answers only from inside an Azure VNet.

3. AD DNS records (option D above). Remember to update them after every rebuild, because the default domain changes.

A hosts-file entry pointing at the static IP is acceptable for a first test only.

1.4 Default name or custom name

• The default Container Apps name (ca-pim-manager.<unique-name>.<region>.azurecontainerapps.io) needs no certificate. Its weakness: it changes every time the environment is rebuilt. That includes the conversion from public to private. Bookmarks, mail links and the sign-in app’s reply address all move with it.
• A custom name (Set-PimManagerCustomHost.ps1 -HostName pim.contoso.com|pim.contoso.local) survives rebuilds. The script adds the name to the app and binds your certificate. It then creates the DNS record, adds the name to the PIM Manager’s mail links (PIM_MANAGER_HOSTNAMES), and adds the reply address to the sign-in app.
  • Private environment: you must bring the certificate, from Key Vault (-KeyVaultName -KeyVaultCertName) or as a PFX (-PfxPath -PfxPassword). A free managed certificate cannot be validated on a private environment, and the script refuses it.
  • Private-only top-level names (.local, .lan, .internal, .intranet, .corp, .home, .localdomain, .private) are refused on a public environment and allowed on a private one.
  • The conversion script does not take a custom name (not yet automated: a custom name with your own certificate during the conversion). Run Set-PimManagerCustomHost.ps1 right after the conversion.

2. Routing

2.1 Hub and spoke

New-PimHostingPrerequisites creates the PIM VNet isolated. A private PIM Manager in an isolated VNet has no route from any client, while every resource check still reports success. The deploy warns about this when you give no hub.

2.2 The outbound path

The PIM engine, the PIM Manager and the updater only make outbound calls. Nothing calls into the engine in any mode. PIM’s Container Apps environment uses a workload profiles environment (the Consumption profile), which is the kind that supports user-defined routes and a NAT gateway.

SQL and the outbound path.

• With a SQL private endpoint, database traffic stays inside the VNet.
• Without one, the deploy’s sqlaccess step authorises the subnet (the Microsoft.Sql service endpoint plus a VNet rule), so the database does not depend on your egress IP. Service-endpoint traffic goes straight to Azure SQL, not through your 0.0.0.0/0 route.
• A NAT gateway changes the source address for everything else. A storage account elsewhere that admits PIM by an IP rule must then admit the new IP or the subnet.

SQL ports. The default connection policy from inside Azure is Redirect: port 1433, then 11000–11999 to the database node. If your firewall allows only 1433, install with -SqlConnectionPolicy Proxy (on Invoke-PimDeployAll and New-PimHostingPrerequisites). Otherwise connections authenticate and then hang.

2.3 Outbound allow-list (derived from the code)

Runtime: the PIM Manager, the engine job, the updater and the other jobs (TCP 443 unless noted)

Where updates are downloaded from.

• Pro / trial (the in-cloud updater ca-pim-update): only https://invardia.com. The updater asks POST https://invardia.com/api/updates/pim-manager/manifest for its ring’s signed manifest and downloads the release from the link in that answer, which Invardia serves as https://invardia.com/api/updates/pim-manager/code/<version>/archive (streamed from Invardia’s own storage, so there is no separate storage host to allow). The updater accepts the archive only if its SHA-256 and size match the signed manifest, and only over https. The download link is decided by Invardia’s answer, not fixed in the product; Invardia has confirmed that every Pro download is on invardia.com, and will announce any change on its egress page first: <https://invardia.com/docs/egress/> (the full list of hosts PIM Manager reaches, split into always / only when used / your own Azure / the admin machine during setup).
• Community: releases come from GitHub: github.com and objects.githubusercontent.com (on the deploy host that runs Update-PimCommunity.ps1, and on the updater if your Community install has one).
• Microsoft endpoints the updater itself uses: login.microsoftonline.com (its managed identity’s tokens), management.azure.com (the registry build, rolling the apps), *.blob.core.windows.net (the build context is uploaded to the registry build service’s storage; the exact account is returned at run time), your registry and your SQL server (over their private endpoints when private).
• Mirroring releases to your own storage is a support-led setup; ask Invardia support.

The registry build pool (private registry only). The build pool runs in the private-endpoint subnet and fetches the base images and packages: mcr.microsoft.com, *.data.mcr.microsoft.com and api.nuget.org. It also needs the outbound access Microsoft documents for dedicated build agent pools.

The deploy host (setup only)

3. Segmentation: the access-request (RFA) portal

3.1 What it is

RFA (“request for authorization”) lets a disabled administrator, typically a consultant, ask for their account to be enabled for a period:

1. They sign in with a one-time PIN.
2. The request is approved automatically or by the department’s owners.
3. The engine enables the account, and disables it again when the window ends. Roles are still activated through normal PIM with MFA.

External systems such as ServiceNow can submit requests through the access-request API.

RFA is Pro only (features rfa.portal and api.broker, hard-enforced).

The broker and the engine never talk to each other. Their only link is the RFA store, and the engine pulls.

3.2 Placement options (Deploy-PimRfaBroker.ps1 -Placement)

In both placements the broker’s environment is public. The deploy refuses an internal environment, because the portal exists to be reached by people who are not on your network. To limit it to known systems, use -ApiAllowedIps. That applies to the whole broker app, so the PIN portal then stops being public. It is the API-only shape.

4. Routing between the segments

There is exactly one flow between the RFA segment and the PIM segment:

PIM engine job (private VNet)  --HTTPS 443, outbound-->  RFA store  <--HTTPS 443--  RFA broker (public)

5. Policies and firewall rules

5.1 NSGs

The PIM scripts create no NSG on the Container Apps or private-endpoint subnets. The RFA broker subnet is the one exception. If you add NSGs:

5.2 Azure Policy effects that commonly break the deploy

5.3 Firewalls on the PaaS services

5.4 Inbound for admins: how people reach the PIM Manager

The PIM Manager is the only thing people connect to. The engine never accepts inbound connections.

Sign-in still works in private mode. The browser is sent to login.microsoftonline.com and comes back to the private address. The admin’s browser needs internet access to Entra, and the environment needs outbound access to login.microsoftonline.com (section 2.3). Conditional Access applies as usual.

Use the default name, or a custom name with the same reply address. The reply address is the PIM Manager’s own address. The deploy’s easyauth step and Set-PimManagerCustomHost.ps1 keep it in step.

6. The scripts named in these guides, and how you run them

Every script below has its own documentation page at https://invardia.com/docs/pim/scripts/<Script>/ (what it does, the rights it needs, every change it makes, -WhatIf and undo). Every script previews its changes with -WhatIf (or runs as a plan without -Apply), prints its name, version and documentation page as its first line, and writes a local log.

Standalone support scripts. One self-contained file each, published at https://invardia.com/support/pim/<Script>.ps1 with a checksum list https://invardia.com/support/pim/SHA256SUMS.txt. Two lines: line 1 downloads the file, line 2 runs it (never pipe a download into Invoke-Expression). Whoever wants to verify first compares Get-FileHash with the file’s line in SHA256SUMS.txt – never as lines in the shown command:

Invoke-WebRequest https://invardia.com/support/pim/New-PimHubPrepareScript.ps1 -OutFile New-PimHubPrepareScript.ps1
.\New-PimHubPrepareScript.ps1 -WhatIf

Package scripts. These load the engine libraries next to them, so they run only from the PIM Manager release package, never as a single downloaded file:

• Pro / trial: Install-Invardia downloads the signed release package for your installation and runs the guided install from it. For a consultant-led step (private mode, a managing tenant, the access-request portal), open PowerShell in that downloaded package folder and run the script as .\tools\setup\<Script>.ps1.
• Community: the public repository at the release tag; run the script from its folder in the same way.

None of these scripts needs the Azure CLI or a PowerShell module, and neither does the file that New-PimHubPrepareScript.ps1 writes for the hub owner (section 2.1): it signs in through the browser and calls Azure Resource Manager directly.