Best Practices for Multi-Domain AD Provisioning with IdentityNow + IQService

Dear community,

I would like to seek your guidance on the best approach for provisioning to Active Directory using SailPoint IdentityNow.

Current State

Our client has an Active Directory forest with four domains:

  • domain1
  • domain2
  • domain3
  • domain4

These domains are configured with bidirectional trust relationships. Our goal is to configure provisioning in a way that ensures centralized management, security, and scalability.

Request

We would appreciate your recommendations or experience on the following:

  1. Is it better to use a single IQService instance to handle all domains, or would you recommend deploying a dedicated IQService instance for each domain?
  2. If a per-domain IQService approach is preferred, is it best practice to install each IQService on a separate Windows Server dedicated to that domain?
  3. From a network connectivity and firewall configuration perspective, should the IQService host be allowed to connect to:
  • Only one Domain Controller per domain (e.g. a Global Catalog server), or
  • All Domain Controllers in each domain of the forest?

We are referring specifically to firewall-level access (inbound/outbound) needed for IQService to perform write operations reliably.

Any feedback, documentation references, or shared experience would be highly appreciated.

Thank you in advance!

@psalat8887100 -

Below is a synthesis of SailPoint documentation and recent field experience for multi‑domain Active Directory (AD) provisioning with IdentityNow. I’ve focused on the three design decisions you raised.


1 Single IQService vs. one IQService per domain

Option When it works well Drawbacks / risks
Single IQService instance (registered once on one Windows host) * All four domains have two‑way trust and can be managed by one AD service account with the required rights in every domain.
* Throughput is modest (tens of writes per minute).
* A bottleneck and single point of failure.
* More complex firewall matrix (one host must reach every DC in every domain).
* Troubleshooting logs mix traffic from all domains.
Dedicated IQService per domain (four instances) * Different service accounts per domain (common in least‑privilege designs).
* Higher change volumes or strict RTO/RPO requirements.
* Need for per‑domain change windows or HA/DR granularity.
* Four Windows services to patch and monitor.
* Slightly more virtual‑machine overhead if you separate hosts.

Field trend: most enterprise customers now deploy one IQService per domain even inside a single forest. Two recent threads in SailPoint’s developer community highlight that separate agents simplify least‑privilege service‑account design and scale better under bursty loads. ([Best approach to use IQ Service across different IDN Environments (Client has only 1 AD environment) - Compass], [IQService agent for multiple domains])


2 Where to install each IQService

  • Recommended – Install each IQService on a Windows member server that belongs to (or is closest to) the domain it services.

    • Benefits: native Kerberos tickets, nearest writable DC selection, and independent OS patching schedules.
  • Alternative – Run multiple IQService instances on a single host and bind each one to a unique port (5050, 5051, 5052 …) and unique Windows service name. This is fully supported but only worth it if you have acute VM sprawl constraints.

Either way, register every instance in IdentityNow Connections → Sources → AD Source → IQService Settings with its own hostname/port/TLS flag.


3 Domain‑controller connectivity & firewall rules

Minimum ports IQService needs to reach AD

Purpose Default ports*
LDAP / LDAPS 389 / 636
GC LDAP / GC LDAPS (multi‑domain look‑ups) 3268 / 3269
SMB / RPC for password resets, group membership writes, SID history, etc. 445 (+ dynamic RPC 49152‑65535)

* Exact dynamic RPC range depends on your domain GPO.

“One DC or all DCs?”

SailPoint’s IQService architecture – network ports & firewalls wiki states:

Integrations … must have firewall ports opened to all domain controllers to which provisioning requests will be sent. ([IQService architecture: Network ports and firewalls - Page 2 - Compass])

Why all DCs?

  • High availability – If the single GC/DC you whitelisted is offline, password changes and group writes will fail.
  • Site‑aware DC selection – IQService (through .NET DirectoryServices) automatically chooses the best DC for the target object’s site when more than one DC is reachable.

If security policy demands tighter scopes, you can:

  1. Whitelist the set of writable DCs in each domain (not just the GCs).
  2. Pin IQService to a specific DC by FQDN in the AD Source “Domain Controller” field, but this removes HA and is rarely recommended.

Putting it together – practical blueprint

  1. Create four AD Sources in IdentityNow (one per domain).

  2. Provision a service account in each domain with the least‑privilege rights SailPoint documents (password reset, group membership, user create/move, etc.).

  3. Deploy one small Windows Server (2019/2022) in each domain, install IQService (latest build), register it to its domain’s AD Source, enable TLS (port 5051) if possible.

  4. Open firewalls:

    • VA → IQService: TCP 5050/5051.
    • IQService → Domain’s DCs: ports in the table above.
  5. Test end‑to‑end: aggregation → password change → add/remove group. Watch IQService.log for each domain separately.

  6. Scale & harden: run a second IQService on a second host per domain for fail‑over, add Windows‑event‑log forwarding to SIEM, and enable TLS both VA→IQService and IQService→LDAPS if your PKI allows it.


Additional references

These documents include example sc create commands for multiple‑instance installs and detailed port diagrams.


Bottom line

Use one IQService per domain, installed on a domain‑joined host, and allow it to reach every writable DC in that domain.
This affords the cleanest security boundaries, easier troubleshooting, and resilient provisioning when DCs rotate or fail.

References -

  1. Best approach to use IQ Service across different IDN Environments (Client has only 1 AD environment) - Compass “Best approach to use IQ Service across different IDN Environments …”
  2. IQService architecture: Network ports and firewalls - Page 2 - Compass “IQService architecture: Network ports and firewalls - Page 2”
  3. IQService architecture: Network ports and firewalls - Page 3 - Compass “IQService architecture: Network ports and firewalls - Page 3”

Cheers!!!

1 Like