The typical provisioning flow for the majority of SailPoint customers involves provisioning directly to Active Directory. Most environments that are using Okta typically sync from AD up to Okta. As a result, very few environments probably provision directly to Okta from SailPoint. (Note: this is a guess, I obviously don’t have stats on this.)
Here are my notes from provisioning directly to Okta.
Use delta aggregations. This isn’t really specific to provisioning, but if you’re doing full aggs against Okta, you’re going to have a bad time. Okta throttles API calls, and their rate limiting means you’re going to have a really bad time if you try to aggregate all your accounts. Like, a very bad time… aggregations will run for a very, very long time. Just use deltas.
Status. Okta has many of these! Unfortunately, SailPoint only has two: active and disable.
SailPoint will create an Okta account in a STAGEDstate (which SailPoint considers disabled). You can include activate in your Create profile and specify a value of true or false to determine whether the account is immediately activated.
Once activated, an account goes into a PROVISIONED state in Okta until the password is set or the account is explicitly activated by an admin, at which point it becomes ACTIVE. Both PROVISIONED and ACTIVE are considered active states by SailPoint.
You can set your connector to set Okta accounts to either SUSPEND or DEPROVISIONED status (both of which are, obviously, considered disabled states in SailPoint) when SailPoint disables the accounts. Unfortunately, this is either/or - you can’t change this on a case-by-case basis, and you can’t have different lifecycle states do different things.
Note that because STAGEDand SUSPEND/DEPROVISIONED are all considered disabled states, SailPoint will not change anything if an Identity gets termed before the Okta account is activated. For example, if you have an account for a new hire provisioned in a STAGED state, but the new hire backs out before their start date so they never get activated, SailPoint won’t change their Okta account to SUSPEND or DEPROVISIONED because as far as SailPoint is concerned, the account is already disabled. You can work around this with a Workflow or in some other way, but this is not out-of-the-box functionality.
Attribute Sync. Okta does not allow modification to accounts in a DEPROVISIONED state. This is a hard-and-fast rule, not something you can change in your Okta settings or SailPoint source configuration. Unfortunately, SailPoint doesn’t give a heck about this limitation at the moment (vote for this Idea to fix that), so it’ll attempt to sync attributes to DEPROVISIONED Okta accounts that are tied to Identities with active or inactive (short-term) lifecycle states. This will inevitably fail with an error, and SailPoint will then retry up to 10 times… per attribute. Depending on how many identities you have, this can cause issues where you have excess items in your IDENTITY-SYNC activity queue.
That’s all I’ve got off the top of my head at the moment, but I’ll be sure to add more as I think of it or as more inevitably comes up! If you’re provisioning directly to Okta from ISC, please add your gotchas below!
Something I’ve recently learned is that while SailPoint will set the Okta user type on account create, you can’t use attribute sync to update the user type. So if your use case involves an account moving from one type to another, it’s not supported.
Has any one else noticed a change related to Attrbute sync - for deprovisioned accounts
New error
[“sailpoint.connector.ConnectorException: [ ConnectorException ] \n [ Error details ] Failed to update the account. [ ConnectorException ] \n [ Error details ] Skipping the provisioning for Okta account id XXXXXXXX as it is in DEPROVISIONED status”]
But it seems to be applied to the enable action also?
We have a ticket in at the moment to identify the cause - seems to have started on the 15th or 16th October in our environment
Yep! I’ve noticed both of these things as well. It also does not allow group removal on deprovisioned accounts, which should still be allowed.
The underlying change here is, I believe, tied to a request I made to stop trying to update attributes on accounts in a deprovisioned state (tracked as CONCHENAB-7442 on the SailPoint side). The intent of this request was specifically to stop dumping errors, so throwing a different kind of error here is not exactly in-line with my request. I also specifically mentioned only blocking changes to attributes, but it appears the change that was made blocks any modifications to a deprovisioned account.
I have a support case open for this if you’d like to reference it in your case as well, so that work isn’t being duplicated - CS0419243.
Based of the logs we are seeing the issue related to these 2 feature flags
Seems to be a combination of
CON_OKTA_UPDATE_WITH_ENABLE feature flag set to false - skips enable step
CON_OKTA_SKIP_INVALID_RECORDS feature flag set to true - skips update\provisioning steps
Waiting to hear back but looks like new features which I can’t find any release notes for.
We have our Okta accounts federated with our parent’s EntraID tenant, so we don’t really need to go past of “PROVISIONING” state as users activate their accounts on their first login with their federated account.
However, whenever we modify some companywide roles, we have to pre-provision the group assignment in Okta, sync into SailPoint the change and then enable the role to avoid overloading our tenant due this “known issue”.
Unfortunately at this point working around SailPoint’s limitations is how we have been making progress because providing solutions to our problems doesn’t seem to be a priority for them.
I’ve learned a little more about this connector and why the full aggregations “will run for a very, very long time”.
The Okta /api/v1/users endpoint response body does not include group membership. Since the SailPoint approach to account aggregation is to include entitlements on each account, the connector must iterate through the /api/v1/groups/{groupId}/users endpoints to determine what groups each account is a member of. If an environment has a lot of groups, this will take ages. Even if your account filter on the aggregation settings only returns a single user object, it will still have to iterate through all the groups to see which entitlements that user has. Keeping the “group skinny user” setting enabled reduces the amount of data that has to be transferred while iterating through the Okta groups.
Furthermore, the applications attribute is not a part of the account schema by default, but you can add it. If you do, however, the connector will then have to iterate over all of the /api/v1/apps/{appId}/users endpoints (similar to finding group memberships), further compounding the number of operations for aggregating even a single user.
Yes, delta aggregations are helpful, but the biggest shortcoming is the object model that Okta has chosen. It forces SailPoint to make a lot of API calls where other systems provide entitlement data embedded directly in the user object model. In my experience in an environment with a lot of groups and apps, whether or not delta aggregation is used, aggregations that include the applications attribute are going to take 36 to 48 hours. Removing the applications from the schema brings the aggregation time back down to a “mere” 5 hours.
One last observation: If you set your API rate limit to 100, be aware that Okta will start responding with code 429 and the connector will have to retry those operations. 100 percent sounds faster than 90 percent, but it’s really not. Even worse, if your tenant sends a create account operation to Okta during an aggregation that’s using 100 percent of the API rate limit, your create user operation may fail, or worse, succeed but without SailPoint knowing that it succeeded - this leads to a continuous retry which fails because the object exists.
