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
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.
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 
ā¦ n00b alert 
Do you have users in that group or just groups?
Here is how I have the setup in AD
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.
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
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!
Hello,
I completely missed your reply/question, apologies for that.
I don't have enough experience to answer what you're asking : maybe an inductive engineer can clarify.
We are using nesting though, and without it active the target user AD accounts cannot authenticate against a gateway.
My nesting setting is needed as i'm allowing only members of a certain group in the user list filter: each person having an AD account with a membership in an Ignition role AD group is a nested member of this core group.
I know this thread is old, but nested group membership is a highly requested feature so I wanted to give an update here.
First-class support for Active Directory nested group membership within Ignition will be available in the 8.3 release of Ignition! The 8.3 beta is tentatively scheduled to be available in Sept. of this year.
Thank you @Jesse_Van_Hill for the update.
Meanwhile, is there any other way to get nested roles, e.g. manipulating any other field filter string?
I see @david.wooffindin above mentioning he could get nested groups, but I did not have any success.
I believe what David did was update the User Search Filter so that it would only return users that were a member of his specified group. He did this by using the memberOf LDAP_MATCHING_RULE_IN_CHAIN rule in his filter. It is a work around, but means no users that are not a member of that group can be returned. In other words, he used it to filter out users instead of looking up the groups for that user.
This may not be an option for your system.
I am not aware of any work around that would allow you to retrieve all nested groups for a user.
Thank you!
Yes though I use the memberOf:1.2.840.113556.1.4.1941 rule in the user list filter to only pull in users that are a member of that group or members of sub-groups. So the site All Users group contains all of the sub-member groups as roles that the user belongs to. Similar to David.Wooffindin we had to point our AD connection to port 3268 in order to allow the connection to clarify some roles for the users and set the referral process to 'Ignore' so we don't send queries around the globe. Haven't found a way to limit the user query to only look at specific roles to import yet, but the above made everything a lot smoother.
example groups
(&(objectCategory=user)(!(objectClass=computer))(!(UserAccountControl:1.2.840.113556.1.4.803:=2))(memberOf:1.2.840.113556.1.4.1941:=CN=Ignition-Site-All Users,OU=Groups,DC=network,DC=local)