Active Directory Nested Groups

We are switching over from AD/DB to pure AD user source. It would be nice to be able to have nested groups in AD. For example, User A is part of Security Group A and Security Group B included Group A, however in Ignition the user is only reported as being a member of Group A, but AD recognizes that the user is also a member of group B.

Is there any way to have Ignition traverse the group membership to support nested groups?

I called into support for this very issue today. I haven’t been able to dedicate time to it yet, but they said I should be able to make this work by putting the correct search string into the Role Search Base setting for the AD user source.

Cool. Very interested in where you get.

I spent some more time on this today and was able to adjust the User List Filter to accommodate users within nested security groups for the searching. So, this way I am able to place all the Security groups for Ignition in a single Security group and ensure Ignition only pulls in users that are a nested member of this group.

(&(objectClass=user)(!(objectClass=computer))(!(userAccountControl:1.2.840.113556.1.4.803:=2))(memberOf:1.2.840.113556.1.4.1941:=CN=Ignition,OU=Ignition,DC=BLAHBLAH))

Now, the last piece would be to allow User Role Attribute to support an LDAP query for the user, but it appears that this is just an attribute? I tried shoving a query like below into this field, but then the user roles are blank.

(member:1.2.840.113556.1.4.1941:=cn=user1,cn=users,DC=x)

It would be PERFECT if I can have the users roles as a nested query of roles in a specific base…

Some info here: https://confluence.atlassian.com/crowdkb/active-directory-user-filter-does-not-search-nested-groups-715130424.html

1 Like

That first part will be helpful when I get to the point where I want to trim the list of users.

My users show up fine and my groups show up fine, but it doesn’t recognize that my user is part of a nested group.

I am not convinced the Role Search Base is used when searching for roles that are assigned to a user. I am only pulling in a subset of roles with the Role Search Base and in the gateway my users still have roles that are not in the roles list.

I tried setting the User Role Attribute to memberOf:1.2.840.113556.1.4.1941: hoping it would concatenate it into the appropriate LDAP search, but it resulted in my users not having any roles.

We probably need to know what LDAP search string Ignition is piecing together with the User Role Attribute.

From the first time I called in I told Inductive I didn’t think this was possible, but I would like to know for sure. I’ve gone back and forth with support several times. I even pointed them towards this thread. They claim it is possible if I knew how to write the queries correctly, but they can’t help with that because it is outside of Ignition/Inductive’s scope.

My testing has proven your earlier point. You can query for users and you can query for roles, but you can’t query for the relationship between the two. It is simply an attribute.

1 Like

Hi,
You said that you were able to use the “memberOf:1.2.840.113556.1.4.1941:=CN=Ignition,OU=Ignition,DC=BLAHBLAH” string as part of your User List Filter, and get it to filter only users that were in the Security group via nesting ?
Can you confirm this? As I have tried and the Users return blank.
My ‘modified’ string for the Filter is this:
(&(objectClass=person)(objectClass=user)(memberOf:1.2.840.113556.1.4.1941:=CN=MyNestedGroup_IGNITION_USERS,OU=IGNITION,OU=Somewhere,DC=my,DC=company,DC=com))
Would really appreciate your or someone else’s help on this. Its the missing bit to make all the magic happen…

The rest of the ldap settings will make a difference on how things import as well.

If you set the filter back to the default do the users import?

(&(objectClass=user)(!(objectClass=computer))(!(userAccountControl:1.2.840.113556.1.4.803:=2))(memberOf:1.2.840.113556.1.4.1941:=CN=Ignition,OU=Ignition,OU=BLAH))

yes, exactly: works without the memberOf: part, and when I put that, no users import.
I dont know how to look in the logs to see what’s going on :slight_smile: … n00b alert :wink:

Do you have users in that group or just groups?

Here is how I have the setup in AD

  • Ignition (security group)
    • Members: Ignition_ProjectA, Ignition_ProjectB, Ignition_GW_Admins, etc
    • Members of the main Ignition group (referenced in the user filter) only contain groups, no actual users
  • Ignition_ProjectA (security group)
    • Members: UserA, UserD
    • Members are only users not groups!
  • Ignition_ProjectB (security group)
    • Members: UserC, UserX
  • Ignition_GW_Admins (security group)
    • Members: UserA, UserX

Using the above filter all users will get imported that are members of the “sub” groups as long as the group is a member of the parent Ignition group. This way I was able to hand off user admin to our IT group and just tell them all user access is controlled through the series of user groups in a certain folder of AD. Our Ignition team still maintains adding any new groups.

Also, we filter the roles listing to only import the folder in AD containing the Ignition groups, that way we don’t get the other thousands of junk groups coming over to Ignition that we don’t care about and having to sort them out when designing.

3 Likes

Hi,
1st : Thank you so much for taking time to elaborate on this…

So, we’re just at PoC stage right now, to see how best we can move over to full AD role management.

The idea is to have a Universal Security group that will only contain all other groups.
We want to have multiple ‘Role level’ groups for a given Ignition server, and to have these groups duplicated for each site where we have or will have Ignition.
End users will be placed in one or more of these role groups, and each role group will be in the ‘All Ignition Users’ group.
We will then filter the users on each Ignition server based on nested membership of this ‘All Ignition Users’ group.
That’s on paper anyway :slight_smile:

Our groups are in global.company.int domain.
Our user accounts are in Europe.company.int, asia.company.int, America.company.int domains.
and we plan to have these users members of the groups, that are in the global.company.int domain.
All these are part of our AD Forest, normal trust etc in place . . .
Each domain controller on each of the stated domains is setup as a global catalog server, and we are using port 3268/(soon 3269 with LDAPS) and not 389.

Ive maybe not described it in a clear enough way, but we are doing (in our PoC, and planning to do in Production) the same way as you: users into the role/security groups, and these groups into the main group that i’m then referencing in the User List Filter.
I haven’t done anything (yet) on the role filter to get rid of the ‘irrelevant-to-Ignition’ groups & memberships that all our users obviously have too…

Maybe its due to the Global Catalog, or the groups that should be Universal, or Domain Local, something clunky like that…

(&(objectClass=user)(!(objectClass=computer))
(memberOf:1.2.840.113556.1.4.1941:=CN=MyNestedGroup_IGNITION_USERS,OU=IGNITION,OU=Somewhere,DC=my,DC=company,DC=com)) --> nesting works with this
(&(objectClass=person)(objectClass=user)(memberOf:1.2.840.113556.1.4.1941:=CN=MyNestedGroup_IGNITION_USERS,OU=IGNITION,OU=Somewhere,DC=my,DC=company,DC=com)) --> nesting doesn’t work with this.

so although the rest of the filter string was ok, what caused it to not work was the person + user filtering.
In case this helps anyone else, this is how I got nesting to work with the User List Filter.
thanks again all

Hi David -

I’m trying to configure Ignition to authenticate users in nested groups similar to what you’re doing and I’m not having any luck. I have configured the User List Filter as above which successfully limits the users displayed in the gateway Users,Roles -> AD -> Users view, but this does not do anything to allow the users to actually authenticate because Ignition is looking for memberOf groups to match. It seems that we need to return all of the group names for the user, rather than the users in the group. I haven’t been able to make this work. I found a note in the online documentation stating:

Certain properties in the Active Directory User Source allow you to filter users, such as the User List Filter . These filters only determine which users will be displayed on screen. They are not authentication filters, so even if a user does not show in the list they can still authenticate and may have access to unintended areas.

So the User List Filter is just for display? Am I missing something? Have you tested nested group user authentication?

Any insight would be appreciated - thanks!