SailPoint ISC Greenfield Implementation Field Guide
Active Directory and Mailbox Provisioning
On this page
Active Directory was the first target and the one every user notices. It was also the place where the legacy tool's behaviour had to be reproduced most faithfully, because changing naming, container placement or group membership rules affects mail, VPN, single sign-on and licensing at once.
What was in scope
| Source | Purpose |
|---|---|
| Main corporate domain | The primary workforce directory; create, move, enable, disable, group membership |
| Administrator accounts in the same domain | Privileged accounts with their own correlation rule |
| Second corporate domain | A separate domain with its own joiner and rehire workflows |
| External-user domain | A third domain for external staff; it shared an Asia-region cluster with the second domain |
| A product governed through AD groups | A fund-accounting product whose access is AD group membership, so it is an AD source in its own right |
Use one AD source per domain, one cluster per estate. Do not stretch one source across forests.
The create policy
The create policy for the main domain defined about 50 fields. The important ones:
| Field | How it is set |
|---|---|
sAMAccountName | A cloud rule: first 3 of first name + last 3 of last name + a two-digit counter, 8 characters maximum, with a uniqueness check |
cn | The login name, which keeps the distinguished name unique across containers |
distinguishedName | CN=<cn>, plus a path built from region, department and work location. Built by a transform on the identity |
mail, userPrincipalName, proxyAddresses | A cloud rule generates a unique address; UPN equals mail; proxy addresses hold the primary SMTP and the SIP address |
manager | A transform that finds the manager's distinguished name |
displayName, title, department, company, co, c, l, physicalDeliveryOfficeName, employeeType | Direct identity attribute mappings |
employeeID | The HR identifier |
extensionAttribute1, extensionAttribute2, a custom department attribute | Used by sync into the cloud directory and by downstream apps |
info | A note "Created by SailPoint Automation on <date>" |
pwdLastSet | Forces a change at first sign-in |
password | See the warning below |
The disable policy moves the object to a disabled container, hides it from the address list and stamps a note. The enable policy moves it back, un-hides it, sets a new password and stamps a note.
Do not derive passwords from HR attributes. The policy built the initial password by concatenating slices of HR attributes. That is deterministic and guessable by anyone who knows the pattern and has the HR record. Use a generated random value or a temporary access pass, deliver it through a controlled channel (to the manager only), and force a change on first sign-in.
Containers, groups and location rules
- Container (OU) placement depends on location. The legacy tool had large spreadsheets mapping office location to default groups, country finance and HR contacts, and web-presence contacts. Port the contacts into lookup transforms. Port the default groups into criteria-based birthright roles, one per office, each wrapping an access profile of that office's groups (see the access model page). Keep the source spreadsheet under change control.
- Default groups per location are part of onboarding. In hypercare the first thing missed for one office was its default security groups for the internet gateway and remote access; without them users could not browse or connect from home. Verify each office's default group set during UAT, not only the global ones.
- Baseline groups for every joiner: cloud sync, multi-factor authentication, self-service password reset, an "all IDM users" group, and a licence group. A different licence group applies to one country, so the licence logic is conditional on country.
- Groups to preserve on leaver. Domain users plus the cloud-sync group must survive for a week or more after termination so mail and records stay reachable. Implement as an allow-list.
- Group aggregation timing. If you read groups into ISC, aggregate them before accounts. Newly created accounts otherwise reference group objects ISC has not seen.
Standard human-account scope
Directory aggregation should read only the OUs that hold human accounts. A reconciliation file listing the standard human OUs (and the accounts under them) was used to confirm scope. Service accounts and shared mailboxes in those OUs end up uncorrelated or, worse, disabled by lifecycle actions. Decide:
- Which OUs are in scope for aggregation.
- How non-human accounts are identified (naming, an attribute, an OU).
- Whether they get a separate source and profile.
The before-provisioning rule
A before-provisioning cloud rule on the main domain handled everything the policy could not. Its 16 KB of Java covered:
- Name-change movers. Generate a new unique address (first.last, then first.last1...), set mail and UPN, rebuild proxy addresses with the new primary and the old one demoted, and optionally rename the object when the OU changes at the same time.
- Leaver group cleanup. Remove every group except an allow-list.
- Distinguished name targets read from identity attributes.
Guidance for this kind of rule:
- Keep it as small as you can. It is a sandboxed Beanshell script; you cannot unit test it outside the platform and every change is a production change.
- Log inputs and decisions at a low level and turn logging off after a diagnostic window. The rule logged mover details at error level, which buried genuine errors.
- Handle the both changed at once case (name and OU in the same refresh) explicitly. It is easy to forget and it happens.
- A stock "services standard" before-provisioning rule also sat in the tenant. Know whether you use it; do not delete it without checking references.
Native rules on the directory source
An AfterModify native rule ran on the main domain source. IQService can run before and after scripts around operations. Use them sparingly: they run on the Windows host, outside the cloud rule sandbox, and they are the place where mailbox and licence side effects live if you keep them as scripts.
Mailbox and licence side effects
The legacy IDM ran PowerShell for several cloud mail operations. Decide where each lands:
| Legacy step | Options in the new design |
|---|---|
| Add baseline and licence groups on create | Directory group membership in the create policy, or an IQService after-script |
| Convert to shared mailbox on leave | A script, or a group-based policy on the mail side |
| Set out-of-office with the manager's text | A script run from a workflow or an after-script, using the leaver form answer |
| Hide from the address list | A directory attribute set in the disable policy (what we used) |
| Assign a leaver licence | A licence group added on disable |
| Log which licence was assigned | An audit trail somewhere; the legacy scripts wrote files |
Authentication for mail scripts moved from basic authentication to certificate-based authentication during the legacy period. Do not build new automation on basic authentication.
Aggregation and sync schedule
- The main domain aggregated every two hours across the night and day; the HR source every hour. Offset the two so a joiner's HR record, the directory create, the mail round-trip and the next directory aggregation line up.
- Allow about an hour for a directory change to replicate across domain controllers before assuming a failure.
- Set the delete threshold to 10% on every directory source. A bad LDAP search or a lost domain controller can return nothing.
Known sharp edges
| Symptom | Cause |
|---|---|
| Account missing in AD although a "credentials sent" email went out | Duplicate distinguished name or non-unique UPN rejected the create; fix the data, then re-provision from ISC |
| User name shows as login ID in the admin console | CN equals login name by design |
| Display name has two spaces | CN-derived name with no middle name; use a collapse-spaces transform |
| Group membership gone after leaver date | No allow-list or no delay; see the lifecycle page |
| Wrong HR or finance contact on a joiner | The contact lookup table is stale |
| Rehire has the wrong mailbox state | The old mailbox was converted to shared; reactivation needs the reverse |
| User cannot get online or on VPN | The location's default groups are missing |
| Old and new accounts for the same person | The rehire rule was not followed in HR |
Actions
- Port legacy contact mappings into lookup transforms with defaults and location-to-group mappings into per-office birthright roles.
- Define the human-account OU scope and how you recognise non-human accounts.
- Write the group allow-list for leavers and the delay.
- Replace derived initial passwords with generated ones.
- Decide the new home for every mailbox and licence script.
- Set TLS and delete-threshold values on every directory source.