ISC is SaaS, but anything it governs inside your network is reached through virtual appliances you run. Most connectivity incidents on the program traced back to a network or cluster decision made in the design phase, so this page is about getting those decisions right.
The shape of the solution
HR system (authoritative)Hires, moves, leavers, termination dates, manager, location, time zoneWeb Services over REST, hourly
▼
ISC tenant (sandbox + production)Identity profile, transforms, cloud rules, lifecycle states, access model, workflows, forms, campaignsSaaS, outbound-only from your network
▼
HR cluster2 VAs, close to the HR API
Directory clustersOne per forest or region, with IQService for writes
App cluster AREST, SaaS and SQL Server apps
App cluster BFlat-file sources and region-specific apps
▼
TargetsActive Directory, REST applications, SQL databases, SaaS finance and workflow products, an ITSM mailbox
Tenants and region
Two tenants: sandbox and production. Build in sandbox, promote to production. They are separate organisations, so credentials, VA registrations and some objects do not travel (see the migration page).
Region is a one-time choice. Both tenants sat in the same cloud region. The VA firewall allow-list needs the region-specific service endpoints (object storage, queue, database, container registry) as well as the US-east defaults, so write the region into the network request.
Org time zone matters. The tenant has an organisation time zone that governs scheduled aggregation times. Workflow schedules carry their own time zone, and identities carry a work-location time zone. That is three time zones in play. Document each one, because a "run at 10pm local" requirement spans all three.
Virtual appliances and clusters
Principles that held up
One cluster per network boundary and blast radius. Group sources by which network they can reach and by how badly you want a fault to spread. We had an HR cluster, a domain cluster per directory estate, an external-directory cluster in another geography, and two general application clusters.
At least two VAs per cluster. VAs update by taking turns, so a single VA means an outage during every update. The design document said two per cluster; the production listing showed the busiest application cluster with one. It also sat in a warning state, and we never proved the cause. Do not run your biggest cluster on one appliance.
Put a cluster near its targets. Latency between a VA and a database shows up as slow or timing-out aggregations. A region-specific app (a platform reachable only from one geography) justified its own placement.
A source cannot simply be moved between clusters. The cluster decides what the source can reach, so choose before you onboard fifty sources onto it.
Clusters fail together. When several unrelated integrations fail at once, suspect the cluster, not the integrations. Write that into your runbook.
Watch cluster status. Two clusters showed a configuring state with an undefined version string for long periods while sources on them still worked. Learn what normal looks like on your tenant so you can spot a real change.
Cluster layout. Redrawn from the design's cluster segregation figure: one cluster for the HR system, one per directory estate (reading directly and writing through a directory agent) and two for applications. The cluster in another geography has a single appliance, a risk the design should have closed.
Sizing and hosting
Decision
Guidance
VAs per cluster
Minimum two, in different hosts or availability zones
VM to VA ratio
One to one
Configuration
Standard (direct outbound). Deep packet inspection is not supported on the path
Hosting
Public cloud and on-premises hypervisors are both fine, but check the vendor's support list first
Unsupported hypervisor
We ran some VAs on a hyperconverged stack outside the official support list. SailPoint's answer was that it may work, config is not supported, and they would support the VA once running. Get that in writing before design sign-off
Network requirements to hand to your network team
The VA only makes outbound calls. Typical requirements:
Requirement
Detail
Outbound HTTPS 443 to all destinations
Service, update and source traffic
DNS 53 and NTP 123
Use an internal NTP server if you block outbound 123, and configure each VA individually
SSH 22 inbound
Internal only, only if you want to log in to the appliance
URL allow-list
SailPoint domains, the update service for the appliance OS, feature-flag service, object storage, queue and database endpoints in the US-east region and your region, the container registry in both
No proxy interference
Web filters and caching products can break the VA. Allow the listed destinations without inspection
Network methods. The appliance only ever calls out; the one inbound connection is optional administrator SSH. A proxy carries all web traffic while time sync still goes direct. SailPoint advises against the DMZ for security, proximity and connectivity reasons.
IQService for Active Directory
Writes to Active Directory (create, move, disable, group changes) go through IQService, a small Windows service. Reads can go direct from the VA. Requirements to plan:
A supported Windows Server with.NET Framework 4.5.2 or later and PowerShell 3.0 or later.
A service account that is a local administrator on the IQService host and an Account Operator or Domain Admin in AD. This is a high-privilege account; scope it as tightly as your model allows and put it under review.
Connectivity from the IQService host to domain controllers on the usual directory ports: LDAP and LDAPS (389, 636), Kerberos (88, 464), AD Web Services (9389), global catalog (3268, 3269), DNS (53), SMB (445) and NetBIOS name and authentication ports.
The Microsoft APIs IQService calls choose their own dynamic ports, so a firewall between the host and the domain controllers must be permissive. Put IQService close to the domain controllers.
Transport security. Ours was configured without TLS to IQService and with plain LDAP to the domain. Decide on TLS from the start; retrofitting it later means touching every domain setting.
Anything that used to be done by scripts in the legacy tool (mailbox conversion, out-of-office, adding licence groups, hiding from the address list) needs an explicit home in the new design. See the Active Directory page.
Connection types you will use
Pattern
Used for
Notes
Active Directory connector
Domain accounts and groups
Preferred pattern wherever an application authenticates through AD
Web Services
HR system, REST applications
All logic in endpoint definitions plus before and after rules
JDBC
SQL Server applications
Aggregation SQL plus a provisioning rule; there is no provisioning SQL on the source
Flat file via SFTP (SQL Loader / delimited file)
Applications without an API, and access-review data
Cheap to build and ideal for review-only governance
Delimited file with no cluster
A tiny admin-identity profile
File upload, no VA needed
Native SaaS connectors
Dynamics 365, ITSM
Use when the product ships one
Selection principle used in the design: AD connector first, then a purpose-built direct connector, then JDBC or Web Services, then flat file as fallback. Disconnected (ticket-based) fulfilment is the last resort and should be replaced as soon as a direct integration exists.
API access and versions
Admin automation uses OAuth 2.0 client credentials against the tenant token endpoint, or personal access tokens. Treat both as production secrets (see the security page).
API versions in use were v3, beta and v2025. Newer object families (forms, workflows, launchers) are only on the newest version. Beta endpoints can change shape.
You will script against the API for dumps, bulk changes and campaign creation. Give those scripts their own API client with a documented scope, rather than reusing someone's personal token.
Administration and break-glass
Configure SSO to the production tenant and test it before go-live; the rollout checklist flagged this as a key task.
Create break-glass administrator accounts that do not depend on SSO, and confirm the client's administrators can log in with them.
Keep a Config Hub backup schedule running. The tenant had weekly automated backups plus manual full backups, which made it possible to compare and restore configuration.
4 processors, 16 GB memory, 128 GB storage (AWS M5.xlarge, GCP n2-standard-4 or equivalent). The readiness guide quotes a smaller range for local hypervisors and a different Azure size, so trust the requirements page
Clusters
At least one production cluster and one sandbox cluster, and at least two VAs in each, sandbox included. No load balancer is needed
Placement
One VA per virtual machine host. Keep a local cluster close to its source system. A DMZ deployment is not recommended
Updates
Clusters update by rolling, one VA at a time, which is why one VA means an outage
Network methods
Standard (direct outbound through the firewall, recommended), HTTP proxy, or network tunnel for firewalls that cannot allow domain names. The tunnel is not available in the FedRAMP environment
Reserved ranges
A source in 10.255.255.241/28 cannot be routed to from any VA. 172.16.0.0/22 is also unusable with the network tunnel
Inspection
VAs can trust a private root CA but reject untrusted certificates, so a TLS-inspecting proxy needs its CA installed
Monitoring
Third-party monitoring of the VA is not supported
Geography
VAs cannot be installed in countries with data residency or transmission restrictions, and the page names Russia and China
Tenant naming
The org name is 3 to 13 characters, and sandbox gets an -sb suffix on its URL
Administrators
Name break-glass administrators separately for sandbox and production
The readiness guide also lists who should attend the connectivity kick-off: HR system owners, directory and entitlement source owners, identity architects, network and firewall engineers and an infrastructure lead. Invite the network team before the call, not after.
Actions
Write the cluster plan (names, VAs, hosts, networks, which sources go where) before onboarding sources.
Get platform-support confirmation in writing for any non-standard VA host.
Send the network team the URL, port and region list, and test from the VA with the real tenant.