We have been live on ISC for a few years and successfully creating AD accounts on our primary domain. We are trying to see a secondary domain where we put a external users. We have had the seconday AD souurce connected for a while we are just now trying to create the accounts in that network.
We have mirrored the source create account config between the existing and “new” domain. The AD account is being created but all of the attributes are not being set. We get sAMAccount, distingusedName, manager, title for example but givenName, sn, userPrincipalName are blank.
Any suggestions on where to look for why some attributes work and some don’t?
Look in account activity in search and find the provisioning plan to see what ISC is sending. Also, typically if one attribute fails, the attributes that are set after it will not be set either, so look at the order of your create policy, the first attribute that fails to be set might be the issue. Fix that, then try again, and continue down the line as needed.
That’s a good start. If those suggestions don’t give you answers, at that point you might want to look at the IQService logs.
It sounds like you’re hitting that frustrating “it works in Dev but not in Prod” kind of wall. Since you’ve already mirrored the config, the logic is likely fine, but the secondary domain is probably being a bit pickier than your primary.
First, definitely check the Provisioning Plan in your account activity. If those missing attributes (like sn or givenName) aren’t showing up in the plan, then ISC isn’t even trying to send them. This usually happens if the external user identities don’t have those fields populated—ISC won’t push a null value.
Second, check your attribute order. AD provisioning can be a bit of a domino effect; if the connector hits an error on one attribute, it sometimes just gives up on the rest of the list. If givenName is failing for some reason, everything after it might be getting skipped.
Lastly, double-check the permissions for your Service Account on that specific secondary domain. It’s surprisingly common for an account to have the rights to create the object, but not the “Write” permissions needed to actually fill in the details in that specific OU.
If the plan looks perfect but the fields are still empty, take a peek at the IQService logs. It will give you the exact culprit which is causing this issue.
Since the account is getting created and only a few attributes are being populated, I’d start by checking the provisioning plan in SailPoint Search to confirm whether values for givenName, sn, and userPrincipalName are actually being sent. If they are present, then review the Create Account policy mapping and attribute order, as one invalid or failing attribute can sometimes stop the remaining attributes from being processed. I’d also compare the secondary AD domain configuration with the primary one (schema, permissions, UPN suffix, required attributes, etc.) and check IQService logs for any attribute-level errors. That should help narrow down where the update is failing.
Another person on my team and I manually compared the working and not working sources and missed the typo. A case of “I know what it’s supposed to say”. I wound up making sure that all of the attributes in the working and non-working AD sources where in the same order. Then I pulled both files into a text compare utility. At that point the typo was pretty obvious. The attribute with the typo was userPrincipalName.
(see above)