Symptom
Having an Active Directory Provider your CloudBees CD (CloudBees Flow) Application performance is globally slow:
-
You are suffering delays accessing Pipelines, logs, etc.
-
Running pipelines you detect delays during stages transition.
Issue
CloudBees CD (CloudBees Flow) configuration is using Active Directory as Directory Provider with nested hierarchical groups and users, but the AD provider settings have not been properly configured for managing this scenario.
Resolution
CloudBees CD (CloudBees Flow) allows you to define in your Active Directory Provider > Membership Options the option Recursively Traverse Group Hierarchy.
Enabling this option, the users belonging to any nested groups in LDAP will automatically inherit the access control rules defined for the parent groups, as explained in Access Control for LDAP Group Hierarchies.
With this option enabled, we need to be aware of select the 'LDAP_MATCHING_RULE_IN_CHAIN' template for both 'Membership Filter' and 'Group Member Filter' in the 'Group Options' section to allow ActiveDirectory to return the nested group membership information.
This setting will get all the groups that the user either directly belongs to or their parent groups. It is a filter (LDAP_MATCHING_RULE_IN_CHAIN) used by Active Directory to automatically do recursive lookup in one call to get all the groups that the user either directly belongs to or their parent groups.
For details see LDAP_MATCHING_RULE_IN_CHAIN.
It defines LDAP_MATCHING_RULE_IN_CHAIN i.e 1.2.840.113556.1.4.1941 as:
This rule is limited to filters that apply to the DN. This is a special "extended" match operator that walks the chain of ancestry in objects all the way to the root until it finds a match.
The LDAP_MATCHING_RULE_IN_CHAIN is a matching rule OID that is designed to provide a method to look up the ancestry of an object. Many applications using AD and AD LDS usually work with hierarchical data, which is ordered by parent-child relationships. Previously, applications performed transitive group expansion to figure out group membership, which used too much network bandwidth; applications needed to make multiple roundtrips to figure out if an object fell "in the chain" if a link is traversed through to the end.
An example of such a query is one designed to check if a user "user1" is a member of group "group1". You would set the base to the user DN (cn=user1, cn=users, dc=x) and the scope to base, and use the following query.
(memberof:1.2.840.113556.1.4.1941:=cn=Group1,OU=groupsOU,DC=x)
Similarly, to find all the groups that "user1" is a member of, set the base to the groups container DN; for example (OU=groupsOU, dc=x) and the scope to subtree, and use the following filter.
(member:1.2.840.113556.1.4.1941:=cn=user1,cn=users,DC=x)
Note that when using LDAP_MATCHING_RULE_IN_CHAIN, the scope is not limited—it can be base, one-level, or subtree. Some such queries on subtrees may be more processor intensive, such as chasing links with a high fan-out; that is, listing all the groups that a user is a member of. Inefficient searches will log appropriate event log messages, as with any other type of query.