<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
0D51Y00009QXds5SADOkta Classic EngineAdministrationAnswered2024-06-19T09:01:48.000Z2020-09-09T15:48:47.000Z2020-09-12T02:37:52.000Z

cpj24 (cpj24) asked a question.

September 9, 2020 at 3:48 PM
Group Rule by AD OU

I would like to configure a rule that populates a group based on the Active Directory Organizational unit of an AD mastered user account. I have found the String.stringContains function for Okta Expressions, and when I use raw strings it works properly. However, when I attempt to reference the AD OU field, I always receive an error that "Unsupported expression constructs are used in expression String.stringContains(<fieldindicator>,"<data>")."

 

This occurs with any of the below structures

String.stringContains(active_directory.dn,"<data>")

String.stringContains(ad.dn,"<data>")

String.stringContains(app.dn,"<data>")

String.stringContains(active_directoryuser.dn"<data>")

String.stringContains(aduser.dn,"<data>")

String.stringContains(appuser.dn,"<data>")

 

The same is the case if I fully spell out distinguishedname or distinguished_name.

 

I have also tried creating a new custom attribute in Okta called addn and mapping the active_directory.dn to it. The mapping appears to be correct, but the new attribute is not populating. That is the case with both an incremental and a full import.

  • 12 answers
  • 1.93K views

  • cpj24 (cpj24)

    I opened a ticket with Okta support. They had me recreate the mapping and it started populating existing users with the data. It is unclear why the original mapping did not update existing users.

     

    The technician also confirmed that it is not possible to reference application or directory data in the expression editor for group rules. It is only possible to reference Okta managed data.

    Expand Post
    Selected as Best

  • User15978384364548105606 (Customer)

    Is your active directory dn referred to as : active_directory.dn?

    Did you try using active_directory.distinguishedName?

  • cpj24 (cpj24)

    As far as I know, yes, the distinguished name field for the Active Directory data is active_directory.dn. Under Profile Editor - Directories, the AD directory has "active_directory" below the directory identifier. When looking at the profile itself the display name "distinguishedName" has a variable name of dn.

     

    I had not tried using active_direcotry.distinguishedName (specifically in that case sensitive string) previously. I did try it at your suggestion and receive the same error.

    Expand Post

  • feok4 (feok4)

    We do this with a RBG, using basic condition, not using the expression editor. Our rule looks something this:

    If user attribute distinguishedname contains OU=SOME_VALUE,DC=DOMAIN,DC=LOCAL

    Then assign to GROUP-OF-YOUR-CHOICE

     

    Does this help? I can look for an expression editor as i'm sure we have one. I can also provide a screenshot if needed.

    Expand Post

  • cpj24 (cpj24)

    Jeff,

    Thanks. The basic condition does not detect the active_directory.dn attribute, which is why I initially started looking at the expression editor.

     

    I have added a custom attribute to the Okta profile called addn that is mapped to the active_directory.dn, but it is only populating on net-new users. It does not populate for existing users, even with a full import.

     

    Either being able to reference active_directory.dn in the expression editor or causing the new addn Okta attribute to populate on existing users will resolve the issue for me.

     

    That being said, it appears that the basic condition can only use one criteria. Since there is a limit to the number of rules you can have, the expression editor would be preferred because it can use OR logic.

    Expand Post

  • feok4 (feok4)

    Robert - thats odd since I see DN in our profile editor. Perhaps i'm not understanding your question.

    Image is not available

    Expand Post

  • feok4 (feok4)

    And we map that attribute to Okta

    Image is not available

    Expand Post

  • feok4 (feok4)

    BTW - the Attribute in Okta is a custom string attribute we created

  • cpj24 (cpj24)

    Jeff,

     

    I also see dn in the profile editor for active_directory. However, active_directory.dn (meaning the attribute in the active_directory directory/application) cannot be referenced from Basic Conditions.

    In Group Rules Basic Conditions it only has Okta attributes available.

    Image is not available

     

    In this field "User Attribute" is specifically restricted to Okta attributes. The pull down to the right will only display attributes of the Okta data.

     

    Because of that, and my inability to get the Expression Editor to reference non-Okta directory attributes I created a similar custom string attribute in Okta as you described. My issue there is that it is only populating on net-new users imported since the attribute was created. It is not populating on users that were present in Okta prior to the attribute being created. I have tried a full import and that new custom attribute does not update for existing users.

     

    Expand Post

  • cpj24 (cpj24)

    To demonstrate what I mean about the attribute not populating, here is a screenshot of the custom attribute for two Active Directory mastered users. The top is a user that was created after the custom attribute was defined and mapped. The bottom is a user that existed before the custom attribute was defined and mapped.

    Image is not available

     

    Expand Post

  • User15978384364548105606 (Customer)

    Robert, If import is correctly importing the DN value after the the custom attribute was defined and mapped, the full import should update it for all existing users as well.

    If it's still not happening, you can try by updating an existing user in AD, and then trying to run the partial import.

10 of 12
This question is closed.
Loading
Group Rule by AD OU