Identity Awareness (IA) OUs and nested AD groups

[Carsten_Weber]

Hi everyone,

R77.30
I just noticed an unfortunate behaviour of the Identity Awareness (IA) in regards to handling OUs inside "Access Role"-objects. Maybe you know if this is known not to work, or you even have a workaround/fix for this.

One of our customers has a working Access Role listing a OU called "OU=LocationA" comprising of other OUs and inside those are users (DN):
OU=LocationA,DC=blablub,DC=corp,DC=int

Example user entries inside the used OU or sub-OUs (DN):
CN=UserA,OU=CB,OU=LocationA,DC=blablub,DC=corp,DC=int
CN=UserB,OU=Extern,OU=CB,OU=LocationA,DC=blablub,DC=corp,DC=int
etc.

They also have a not working Access Role using one OU with AD-groups only inside called "OU=JIRA" (DN):
OU=JIRA,OU=Applications,OU=Global-Groups,DC=blablub,DC=corp,DC=int

Example AD-groups entries inside the used OU (DN):
CN=JIRA_PX,OU=JIRA,OU=Applications,OU=Global-Groups,DC=blablub,DC=corp,DC=int
CN=JIRA_QA,OU=JIRA,OU=Applications,OU=Global-Groups,DC=blablub,DC=corp,DC=int
etc.

not working means: The "Access Role" does not match connections of users that are members of the according AD-group.
working means: The "Access Role" does match connections of users that are members of the according OU or sub-OUs.

These are the only two occasions we used OUs. Normally AD-groups are the standard entry for "Access Roles". And in this case we really need the not working OU to work.

I can browse those AD branches inside the SmartDashboard "Objects list" under (Users and Administrators) ok. Users are being listed for the AD-groups and OUs when double clicking.

I'm not too deep into AD, but I believe IA has an issue with nested AD-groups inside an OU when a OU is used as entry in an Access Role.

Does anyone have any experience with this situation? Your thoughts are highly appreciated.

best regards
Carsten

[Daniel_Taney]

I haven't messed around with nested groups in IA much, but this SK explains some CLI options to configure and debug nested groups. 

Also, the Identity Awareness Admin Guide says this specifically about nested groups and the three types of group queries:

Identity Awareness supports the use of LDAP nested groups. When a group is nested in another group, users in the nested group are identified as part of the parent group. For example, if you make Group_B a member of Group_A, Group_B members will be identified by Identity Awareness as being part of Group A.

There are three ways to configure nested group queries:

• Recursive nested groups - The gateway sends a query with the user name to the LDAP server. The server finds the groups that the user is a member of and sends it to the gateway. To know if a group is nested in another group, and for each nesting level, you must send a new query. This feature is enabled by default. The default nesting depth is configured to 20. For details, see sk66561 http://supportcontent.checkpoint.com/solutions?id=sk66561.

• Per-user nested groups - With one LDAP query, the response includes all groups for the given user, with all nesting levels. The server sends the groups of a given user as a flat list.

• Multi per-group nested groups - The gateway sends one LDAP query, which includes the user name and the group. The server responds if the user is in this group or not. Best Practice - Use this configuration for Microsoft Active Directory environment with many defined users and groups, and less groups defined in SmartConsole.

[Carsten_Weber]

Thanks for your quick reply Daniel_Tane.

I did check the SK before (which I didn't mention) but could not find the mentioned command "pdp nested_groups" helping in identifying the issue. We have the default setting applied (active / 20 level). The commands output did not list any users that were not fetched due to depth settings. Depth does not appear to be the issue.

I hope you Daniel will or anyone else has tried this and Iis willing to share the result. Maby also in version >=R80.30
I will feedback once I have an answer, too.

BR
Carsten

[Carsten_Weber]

While working with Check Point Support on a solution (well first I am working on explaining the situation) I have drawn a quick and simplified picture of the situation:

Either using the red or the green marked OU to try and match a user

Basically I am trying to use a "high level" OU in order to match all the users that are either directly listed in sub OUs or inside the AD groups within those OUs. From an end user perspective...why shouldn't this work?

AD groups are to me the very essence of grouping users for certain purposes. Why sholdn't I be able to use an OU that consists of a longer list of AD groups? Using each AD group seperately would work. Why not use the parent OU to simplify and flexify ( I wish that were a word) the use of those AD groups?

Using the working OU (Vienna), there are users to be found inside at the end of the "folder tree/branch".
The other OU (Applications) does not host users directly. In here there are AD groups at the end of the "folder tree/branch". 

In case it wasn't already...I hope this does make my request more clear?
Does this spawn any new insights? 🙂