Best Practices for Hardening the Active Directory Service Account in ISC

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

Hi everyone,

I’ve gone through the official SailPoint AD connector documentation, especially the domain settings section here:

While it’s helpful for understanding the required permissions and basic setup, I’m looking for additional guidance on hardening the AD service account from a security and infrastructure best practice standpoint.

Specifically, I’m interested in:

  1. Is it recommended to use a Group Managed Service Account (gMSA) as the service account? Are there pros and cons, especially around logging, lifecycle, or compatibility?
  2. Would it make sense to place the service account in a dedicated OU with custom GPOs to enforce restrictions (e.g., logon rights, password policy, deny interactive login)?
  3. Should we apply logon restrictions, such as denying interactive logon or limiting logon to the IQService host?
  4. Any best practices for auditing, monitoring, or alerting activity tied to the account?
  5. Suggestions for securing IQService, especially when running under a gMSA?
  6. Any other “less obvious” hardening tips you’ve found useful?

Additionally, I have a question regarding the integration of remote mailboxes with Active Directory via the connector. If we need to manage remote mailboxes, are there any specific challenges or limitations when using a gMSA versus a standard domain user account for the service account? Would one approach be more compatible than the other?

Thanks in advance for your insights!

Kind regards,
Paolo

2

@psalat8887100 -

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

  1. Create a dedicated OU such as OU=SailPointSvcAccts,OU=Identity.
  2. 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.
  3. 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

  1. 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).

  2. 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

  1. Need Exchange cmdlets? → Use a hardened user.
  2. No Exchange cmdlets + latest connector? → Use gMSA.
  3. 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!!!

1 Like
3

Hi,
thank you for your detailed and comprehensive response. Your checklist, combined with SailPoint and Microsoft AD security best practices, is outstanding and exceeds expectations. The practical approach and clarity make implementation easy, your response provides a robust framework for security in SailPoint ⇄ AD integrations. Thank you for sharing your expertise.

Kind regards,
Paolo