I am working on improving full account aggregation performance for an LDAP application in SailPoint IdentityIQ and I am trying to determine the best supported approach for partitioning a large user population.
Current scenario:
Source is an LDAP application aggregating inetOrgPerson accounts.
Base search is under ou=People,ou=na,dc=...,dc=....
Full aggregation volume is large enough that I am concerned about size limits, long runtimes, and potential timeout issues.
I want a partitioning approach that is both effective and supported by SailPoint, not just something that looks right in XML.
What I have today:
One approach is application-level partitioning using multiple searchDNs entries with iterateSearchFilter values split by uid.
Example partitions are:
(!(uid>=a))
(|(uid=a*)(uid=A*))
(|(uid=b*)(uid=B*))
…
(|(uid=z*)(uid=Z*))
(!(uid<=z))
This is essentially a hard-coded alphabetical partitioning model in the application XML.
Second approach I am considering:
A rule-based partitioning model where the aggregation task includes arguments like:
enablePartitioning=true
partitionBaseDn
partitionObjectClass
partitionKeyAttribute
partitionRule=...
I have a custom Beanshell rule that builds partitions dynamically and returns a list of LDAP filters, for example 15 partitions such as:
values less than a
a-b, c-d, e-f, etc.
values greater than z
My main question:
Does SailPoint IdentityIQ account aggregation or account group aggregation actually support invoking a custom partitionRule like this during standard LDAP aggregation?
Or is the only reliable/supported approach to keep partitioning in the application configuration itself using multiple searchDNs / iterateSearchFilter entries?
What I am trying to evaluate:
Which approach is truly supported by SailPoint for LDAP aggregation?
If both can work, which is more stable in production?
If custom partition rules are not supported for this use case, what is the recommended pattern for large LDAP aggregations?
Would you recommend:
multiple searchDNs in the application,
multiple separate aggregation tasks,
connector-native partitioning only,
or some other design?
My goals:
reduce full aggregation runtime
avoid LDAP administrative size limit issues
keep configuration maintainable
stay within supported SailPoint behavior
If anyone has implemented this successfully in IIQ, especially for LDAP or similar large directories, I would appreciate guidance on what is actually supported versus what only appears configurable.
@NissyM May i know how many users you have in AD? and how many task servers and how many partitions are there per server?
We used to have 400K accounts + 120K groups and every user used to have atleast 750 AD Groups.. our AD aggregation used to completed in ~15mins and group aggregation in 1 hour.
It was full aggregation. Initially we had 4 servers, but later we increased it to 8. That also helped us. Our AD, IQService and IIQ, all were in the same network. We didn’t keep any customization rule or any complex attribute evaluation during aggregation task. We tried to keep AD integration as standard as possible.
searchDNs + iterateSearchFilter is the actual supported partitioning mechanism for LDAP. The connector combines those two values into the partition context — that’s the documented code path. Your alphabetical split isn’t a workaround, it’s the intended pattern.
The partitionRule/dynamic-filter-generation approach is not documented as supported for the LDAP connector. That pattern belongs to generic task-level partitioning (used when a connector doesn’t support partitioning natively). If you enable it on top of an app that already does app-level partitioning, you’re relying on undocumented behavior — it may run without erroring, but there’s no guarantee it survives an upgrade, and support likely won’t back it if it misbehaves.
So to your specific question: no, standard LDAP aggregation doesn’t invoke a custom partitionRule to build search filters dynamically. Keep partitioning in the application config.
Recommendation:
Keep searchDNs/iterateSearchFilter partitions in the application config.
Make sure Enable Partitioning is checked on the Account Aggregation task itself — without it, IIQ just walks your searchDNs sequentially instead of in parallel.
Also set “objects per partition” at the task level — this lets IIQ further split large partitions automatically instead of you hand-balancing 26+ alphabet buckets.
Watch your total partition count — there’s a platform ceiling (~200 for aggregation partitioning), so don’t over-fragment.
If uid distribution is uneven (way more S’s than X’s), consider partitioning by OU/container instead of pure uid-prefix, if your DIT allows it.
Multiple separate tasks isn’t needed here — partitioning already solves your throughput/timeout problem within a single task.
I am able to aggregate the accounts and in the entitlement catalog my posixgroups are also appearing but they are not correlating, i have used the groupmemberattribute as shown in teh above solution but even that did not seem to help.