Below is a practical hardening checklist that folds in the newest SailPoint guidance (IQService Feb-2025) together with Microsoft AD security best practices. I kept the language “hands-on” so you can copy the settings straight into your build or security-review documents.
1 Choose the right service-account type
| Option | When to choose | Key pros | Key cons |
|---|---|---|---|
| gMSA (Group Managed Service Account) | • Running the latest AD connector (June-2024 +) and IQService Feb-2025 or later • You can meet the domain/forest prerequisites (2012 DCs, KDS root key) |
• Automatic 30-day password rotation—nothing to vault • Built-in “Allowed to log on as a service” and no interactive logon • SPN/Kerberos handled for you |
• Still needs a separate domain (or local) user for the IQService Settings → Client authentication field – SailPoint’s own doc calls this out (Using gMSA as a Service Account) • Event logs show the computer account (harder to trace who triggered an action) • Not supported for Exchange on-prem / hybrid Remote Mailbox cmdlets ([Configure Kerberos authentication for load-balanced Client Access services |
| Traditional domain user | • You are on an older connector/IQService • You must run Exchange (on-prem/hybrid) remote-mailbox commands through the account |
• Works everywhere; easier to troubleshoot Exchange-related tasks | • Manual (or privileged-access-workstation) password rotation • Must harden with GPOs to stop interactive logon |
Bottom line:
If you never have to run Exchange Management Shell commands (Enable-RemoteMailbox, Set-RemoteMailbox, etc.) from the connector box, a gMSA is the cleaner and safer path. Otherwise keep a hardened user account.
2 Isolate the account in its own OU + GPO
- Create a dedicated OU such as OU=SailPointSvcAccts,OU=Identity.
- Link a custom GPO with at minimum:
- Computer Configuration → Windows Settings → Security Settings → User Rights Assignment
- Deny log on locally, Deny log on through Remote Desktop Services – add the service account(s).
- Allow log on as a service – add the account (gMSA does this automatically).
- Security Options → Accounts: Limit local account use of blank passwords → Enabled.
- Computer Configuration → Windows Settings → Security Settings → User Rights Assignment
- Block inheritance on that OU so future domain-wide GPOs don’t weaken the settings.
These steps implement Microsoft’s least-privilege advice (Implementing Least-Privilege Administrative Models - Learn Microsoft, Secure user-based service accounts in Active Directory).
3 Restrict where the account can run
| Control | Setting |
|---|---|
| Log On To | In Active Directory Users & Computers → Account → Log On To, list only the IQService host(s). |
| Service ACL | On the Windows host, use sc.exe sdset or Services.msc → IQService → Permissions to ensure only the connector account (gMSA or user) can start/stop the service. |
| Local groups | IQService needs Read on %ProgramFiles%\SailPoint\IQService and the HKLM registry key it creates. It does not need to stay in Local Administrators once the installation phase is done. |
4 Turn on auditing & monitoring
-
Advanced Audit Policy (Group Policy → Security Settings → Advanced Audit Policy Configuration):
Sub-category Purpose Logon/Logoff → Logon Captures successful logons (Event ID 4624, 4625). Account Management → User Account Management Shows changes to the service account itself (4720-4726). DS Access → Directory Service Changes Records attribute-level changes in the OU (5136). -
Forward to SIEM (Azure Sentinel, Splunk, etc.) and create alerts for:
- Interactive or RDP logon attempt by the service account.
- Membership changes in the OU or the service account.
- Service control events (7040, 7036) for IQService.
Microsoft publishes the recommended AD event IDs to watch (Appendix L - Events to Monitor | Microsoft Learn).
5 Lock down IQService itself
| Area | Hardening step |
|---|---|
| Transport security | From IQService Feb-2025 onward you can enforce TLS 1.2 on the service port (5050-5052) and enable SASL/Kerberos “strong” authentication in Domain Settings. |
| Firewall | Allow inbound 5050–5052 only from the Virtual Appliance / connector host IPs; block all others. |
| Patching | Keep to the latest quarterly IQService release (Feb-2025 is current (New Capability: Integration Service (IQService-Feb-2025) is now LIVE!)). |
| Run as gMSA | Follow SailPoint’s step-by-step (PowerShell New-ADServiceAccount, Install-ADServiceAccount, then set Log On user to gmsaName$) (Using gMSA as a Service Account). |
6 Other less-obvious but field-tested tips
| Tip | Why it helps |
|---|---|
| Two-account model (read-only for aggregation, write account for provisioning) | Reads can run under a low-privilege account that has no write ACLs; incident blast radius is smaller. |
| Set “Account is sensitive and cannot be delegated.” | Blocks Kerberos constrained-delegation attacks if the IQService host gets compromised. |
Prefix naming convention (e.g., svc-sp-iqad-g vs svc-sp-iqad-rw) |
Makes log searches and conditional-access rules far easier. |
| Automatic certificate renewal on the VA ↔ IQService TLS channel (use AD CS or internal PKI) | Removes the “forgot to renew” outage class. |
Regularly export the OU ACLs (dsacls.exe /save) and compare in code review / CI pipeline. |
Picks up drift that a change-management process might miss. |
7 Remote-mailbox / Exchange considerations
| Scenario | Compatible with gMSA? | Notes |
|---|---|---|
| Connector only sets AD attributes (targetAddress, msExchRemoteRecipientType) | Yes | The gMSA simply needs write permissions on those attributes. |
Connector (or SailPoint rule) runs Exchange Management Shell cmdlets (Enable-RemoteMailbox, etc.) |
No | Exchange (on-prem or hybrid) explicitly does not support gMSA for Kerberos auth (Active Directory Connector: Supporting Group Managed Service …, [Configure Kerberos authentication for load-balanced Client Access services |
| Exchange Online PowerShell calls via modern auth | No native token flow for gMSA | Still use a service principal / app registration or user account with modern auth. |
Quick decision tree
- Need Exchange cmdlets? → Use a hardened user.
- No Exchange cmdlets + latest connector? → Use gMSA.
- Hybrid? → Often a split: user account for mailbox work, gMSA for everything else.
Final checklist (copy/paste into your runbook)
[ ] OU + GPO created, inheritance blocked
[ ] Service account denied interactive/RDP logon
[ ] Log on to only IQService hosts
[ ] Advanced Audit Policy applied, events forwarding to SIEM
[ ] IQService ports limited and TLS enforced
[ ] gMSA password rotates (or manual rotation schedule for user account)
[ ] “Account is sensitive and cannot be delegated” set
[ ] Documentation of who owns the account lifecycle
Following the above will bring your SailPoint ⇄ AD integration in line with modern least-privilege and auditing standards while positioning you for painless upgrades down the road.
Cheers!!!