<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
System Status
Announcements
Announcements
Search
Search
Select Language
Knowledge Base
Knowledge Articles
Support Videos ↗
Documentation
Product Documentation ↗
Developer Documentation ↗
Product Release Notes ↗
Community
Events & Webinars
Okta Ideas ↗
Resources
Product Hub
Customer Success Hub
Product Release Update
Learning
Okta Learning ↗
Get Support
Open a Case
HomeCommunityForum
0D50Z00008C3jlISAROkta Classic EngineLifecycle ManagementAnswered2024-04-30T09:18:25.000Z2015-11-03T20:38:20.000Z2020-10-21T20:00:12.000Z

j5v7c (j5v7c) asked a question.

Edited by tim.lopez1.5480328098306519E12 October 22, 2020 at 6:02 PM
Syncing AD accounts 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?

 

Under:

Directory | Directory Integrations | Active Directory | Settings | Import and Account Settings

We can select only an specific OU to synchronize.

 

Thanks!
  • 8 answers
  • 1.26K views

  • James Garvin - Okta (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.

  • j5v7c (j5v7c)

    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!

    -----

    Reply:

    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. 

    Expand Post

  • SSOS.08384 (Citrix)

    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.

    Expand Post

  • j5v7c (j5v7c)

    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.
    Expand Post

  • jonesl.81378 (Customer)

    Hi,

     

    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") ? appuser.email : null. It is to check if the user is in eval group, if yes insert the appuser.email 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.

     

    Thanks.
    Expand Post

  • lmbt0 (lmbt0)

    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.

  • JaspreetS.48197 (Customer)

    is there any update on this? We want to import only Security Groups and its members into Okta however Okta only shows OU while migration not the security groups.

  • MikeM.89811 (Guidewire)

    You have to put in a service ticket to have ldap filtering enabled for the AD integration.

This question is closed.
Loading
Syncing AD accounts using security groups or user attributes instead of OUs