Is it possible to synchronize AD accounts into Okta using security groups or user attributes instead of OUs? Skip to main content
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Ask Search:
Dalton KoleDalton Kole 

Is it possible to synchronize AD accounts into Okta using security groups or user attributes instead of OUs?

Our AD structure contains all employees under this EndUser OU.
However we don't want to synchronize the whole population into Okta as of now.
Is there a way to select specific users by making them members of a security group or reading an attribute?

Directory | Directory Integrations | Active Directory | Settings | Import and Account Settings
We can select only an specific OU to synchronize.

James GarvinJames Garvin (Okta)
Hi Dalton,

As of right now, no.  Okta can only filter by OU.  On the bright side, we are working to make this more robust and give you a better experience.  
Dalton KoleDalton Kole
Hi James,
Do you have an ETA when this feature will be available?

Also, yesterday I received an e-mail with the following workaround, would that be a valid try? Thank you!
We implemented something similar. At a high level, what we did is identify an AD attribute we were not using, then set up attribute mapping to Okta, but set up a transformation rule so that the value was only populated on the Okta side under certain circumstances (based on values in other attributes.)
Then, we set that attribute as required on the Okta side. Accounts that don't meet the requirement do not get a value and so cannot be created in Okta. 
Asher RosenbergAsher Rosenberg

That earlier reply was from me, but I was having an issue with the way my name was being displayed so I deleted the comment and was coming back now to make the same comment now that Support fixed the display name. 

The only issue we've had with this approach is that we're excluding almost 10,000 AD users, and so every time the AD Import runs we get 10,000 messages in the System Log that say: Skipping import of user '<User>'. Expected required AD attribute: <Attribute>, (Okta attribute: <Attribute>) to not be null. Please consult with your Active Directory admin if you believe this user should be imported.

However, since we never use the System Log without filtering anyway, those messages can be ignored quite easily.

Dalton KoleDalton Kole
Hey guys,

We solved this issue by making extensionattribute10 a required attribute. We only populate the users we want to be synchronized to Okta and the remaining is skipped.

Do you see any issues with this approach? Seems to work perfectly.

Thank you.
jones leungjones leung

May I have more details about how the transformation can be done? Perhaps with the real expression shared here. I tried few times and still couldn't work it out. 

I have written an expression and tried to leverage the appuser side department attribute to run it isMemberOfGroupNameContains("eval") ? : null. It is to check if the user is in eval group, if yes insert the to the okta side user.department attribute, if not return null.

But after that, how can I leverage this result to ask Okta to check this Okta user side user.department field and make it required before any import? From User attributes, all attributes are from the variable type active directory, so even I make it required, it will actually check the original AD department field (which is always empty here), and ignore the expression result. It is because Okta is not forcing user.department to be required, it is forcing app.department (from AD to be required).

Welcome any sharing.

Ben EstevesBen Esteves
Has anything changed since this question was asked? I also want to only import users into OKTA that are added to a specific security group. Similar to the way that users are assigned to apps but I want it to work for the import as well.