Thanks. That’s what I’m doing.
Search DN
OU=Users,DC=Company,DC=com
Iterate Search Filter
sAMAccountName=ConfRoom
Sorry, @pmandal but that solution still didn’t work. I’m following all the documentation, LDAP filtering and what I’ve been asked to try on here; I’m not sure what else I could be missing.
Ok, I was able to clear out all the fields in the AD application config and just pull in the one account via iterator search and turning off “Only create links if they can be correlated to an existing identity” in the account aggregation. So now any time I want to aggregate the membership changes I need to remove all the AD DN config settings for all my other accounts? That seems a bit nuts 
Hi @angie_vetrone,
You can create another AD application solely to aggregate this particular orphan account. I was able to aggregate a lone orphan account by adding the account dn of the account I wanted to aggregate in the search dn
Pre-Aggregation
Aggregation Task Result
Post Aggregation
Search DN
I tried to create a new AD application but when I do, I get the error message that I can’t have the same default Forest or GC Server because it already exists. That error makes sense, but I’m unsure how I can get around that.
I got past the first default Forest error but now it’s throwing a error:
- All schema attribute names must be unique. These attribute(s) were found to be duplicates: sAMAccountName, msDS-PrincipalName
I am not facing these errors [same default Forest or GC Server nor the attribute duplication error].
- The actual AD I have have multiple forests configured with GC servers, domain config, search scope + IQService Config.
- The AD app I created for testing this scenario is barebones, just the forest in which the orphan account is situated, its domain config and Search DN for User Search Scope + IQService Config.
The test AD app set up allows me to aggregate the orphan account seamlessly.
Alright! I think I got it working! This was one of the first things I tried to do but for some reason it was duplicating schema attributes in the configuration. I just removed them and it’s working as I’d hoped. Thank you all for the help!
I will try to append the sanitized application objects here for your reference
I think what you are attempting is a target aggregation. My CoLab Spoofing Plugin includes a task MCPlugin Target Aggregation template which you can use to create a new task. You can specify the DN of the account, and it will aggregate it.
1 Like
Yes this is what I’m trying to do. I’d like to aggregate a specific OU or CN into SailPoint IIQ and be able to either create a new aggregation task to be able to turn off the option to" only create accounts if identity exists" and run it or maybe I’m approaching this completely wrong. All I’d like to be able to do is pull in a couple user objects that aren’t related to an identity and be able to add/remove an AD entitlement. Maybe this needs a whole new Lifecycle Manager Identity Provisioning Policy and/or Business Process, I’m not 100% sure. I’ve read through best practices and docs out there, so I’m trying to make this as simple as possible while also setting us up for the future if we need more of these types of accounts in the system for governance.
I’m in a one Forest AD with several Trees, so I’m unable to specify different Forests in where these Domains or OU’s live.
[Please Note: If the initial issue is resolved, always create another thread/post for any subsequent issues]
I am not able to clearly understand, could you elaborate?
Your AD environment is a single forest env. Lets say Forest: F, it has Domain: DF1, DF2… OU=DF1OU1, DF1OU2, DF2OU1, DF2OU2…
you need to read a single orphan account which is confRoom situatued in OU = CompanyUsers.
Which domain is holding this OU?
EDIT: From what I understood
I reconfigured my test AD config like this
IQService, Forest and Domain Config:
Search Scope and Test Connection
Accounts on Preview
Orphan accounts on different domain being read
Post Aggregation
Thanks @sreeram. I can open a new discussion if necessary. This is still the same issue, but maybe I didn’t explain it great when I intially opened it. I was able to aggregate them in now so maybe that’s the end of the thread. My goal of aggregating these in was to be able to add/remove entitlements from these accounts. Having it in the system was the first step, but it doesn’t appear to be something I can do without more developement work.
1 Like
Hi @angie_vetrone, Good to know the initial issue was resolved. Please consider marking this as solved in that case. Even though it is the larger picture, the people who already may have come to hit a wall on resolving the initial issue may not respond to the thread if we continue to discuss a new issue on the same thread. Please feel free to open a new thread in case you run into any subsequent issues. Happy to help!
Suggestion: You could create a delimited application (authoritative) where all the non-human accounts are stored and then correlate the non-human accounts from AD to the ones in the non-human auth source. This could help you better manage these service accounts.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.