pp9nz (pp9nz) asked a question.
We are using Okta to provision accounts from our HRIS into Active Directory. We set up group rules to push new users by department (or sometimes title) into their appropriate OUs.
I want to create a catch-all group that will find users who don't fall into the other groups and push them into a generic OU. We had issues recently when HR created a new department and didn't tell IT, and we ended up with users who were not getting provisioned, because we had no rules for that new department. So if I create a catch-all, at least the user can sign in and we can proceed from there.
My first thought was to use a group rule that catches all users without an active directory account. I created this rule and group.
This would catch all users without an AD account. However, there doesn't seem to be any configurable precedence for how the group rules process on a new user. My first test user came out fine and went to their department-specific OU, because the other group rules processed first. When I created another test user, the catch-all rule ran before the others and the user ended up in the generic OU, which is not what we wanted. That user was later added to their correct groups, but Okta doesn't move them to the right OU, and they don't leave the catch-all group despite being provisioned.
I tried renaming the group rule with a "Z" in front to see if it processed alphabetically, but that doesn't seem to make a difference.
Maybe I'm going about this all wrong. Is there a better way?
Hi Jesse,
Ionut from Okta support here, currently Okta does not have the option under the group rules to filter users based on their source of truth.
You would need a specific attribute which is standardized across all your user base that needs to be filtered.
For example : For user A we will use Attribute B and send him to group C, for user D you would need to use attribute E and send him to group G.
You also have the option to filter users based on their group membership :
For example : If user is member of group A send him to group B as well.
For us to assist you with this use case better, I recommend opening up a support ticket.
In regards to the OU membership that is not reflected in Okta even though it was updated in AD, you would need to run a full import.
Hi Ionut,
Regarding the attribute mapping, that is basically what we are currently doing. However we got thrown off a bit when our HR department entered some unexpected values for the attribute and the rules did not apply, thus the users did not get provisioned to AD.
Regarding filters based on group membership, I don't see how this could work to solve our problem. We could potentially filter based on the lack of membership to any of our active directory provisioned groups, but when a user is first created they would fall into that group until the other rules are ran. Since we can't set a priority for one group rule to run higher than another, there is a chance that users would get provisioned to the wrong OU first.
A full AD import will not resolve our issue with the incorrect OU. Okta does not currently move users from one OU to another. So if a user is provisioned for say, the marketing OU originally, and moves into the IT department later, it is still a manual process to move the user in AD. I do know that there is an early access feature to turn this ability on, but we have not yet requested it and it is untested for our organization.
So far, the only real method I can see to make this work is to do an inverse of all other group rules that we have. To simplify it, let's say we have three group rules. If user.department = IT, join group IT. If user.department=Marketing, join group Marketing. If user.department=Finance, join group Finance. Each of those groups would be provisioned to their proper OUs in Active Directory. To catch all others, we would have to say If user.department != IT AND user.department != Marketing AND user.department != Finance then join group "users" and provision to a generic lost-and-found OU. In our recent case, this would work. However, we have dozens of group rules and building the full inverse of all of them into one rule is cumbersome to say the least.
We can't base a rule on the lack of membership to the other groups, because if that rule happens to run before the others, then it will apply, and they will end up in lost in found, negating the work we've done on the other rules.