Leveraging AD Nested Groups With AM

This article comes from an issue raised by multiple customers, where ForgeRock Access Management (AM) was not able to retrieve a user’s group memberships when using Active Directory (AD) as a datastore with nested groups. I’ve read in different docs about the “embedded groups” expression, as well as the “transitive groups” or “recursive groups” or “indirect groups”, and finally, the “parent groups” expressions. I’m just quoting them all here for search engines.

As a consequence, it was not, for example, possible for AM agents or any policy engine client, such as a custom web application, to enforce access control rules based on these memberships. In the same manner, applications relying on the AM user session or profile, or custom OAUTH 2, or OpenID Connect tokens could not safely be used to retrieve the entire list of groups a user belonged to. In the best case scenario, only the “direct” groups were fetched from AD, and other errors could occur. Read more about it below:

Indeed, historically, AM has used the common memberOf or isMemberOf attribute by default, (depending on the type of LDAP user store), while AD had a different implementation that also evolved across time.

So, initially, when AM was issuing “(member=$userdn)” LDAP searches against an AD, if, for example, a user was member of the AD “Engineering” group, and that group was itself member of the “Staff” group, the above search was only returning the user’s direct group; in this case, the “Engineering” group.

A patch was written for AM to leverage a new feature of AD 2003 SP2 and above, providing the ability to retrieve the AD groups and nested groups a user belongs to, thanks to a search like this: (member:1.2.840.113556.1.4.1941:=$userdn).

See, for example, Microsoft Learn Community Content | Microsoft Learn this topic.

This worked in some deployments. But for some large ones, that search was slow and sometimes induced timeouts and failing requests; for example, when the AM agent was retrieving a user’s session. Thus, the agent com.sun.identity.agents.config.receive.timeout parameter had to be increased (by 4 seconds by default).

Fortunately, since AD 2012 R2, there’s a new feature available—a base search from the user’s DN (the LDAP DN of the user in AD) with a filter of
“(objectClass=user)”. Requesting the msds-memberoftransitive attribute will return the whole of the user’s groups, including the parent groups of the nested groups a user is member of. That search can be configured from the AM console.

You can find more information about that attribute here: [MS-ADTS: msds-memberOfTransitive | Microsoft Learn]

But from now on, you should hopefully be able to leverage AD nested groups gracefully with AM.