I'm using this piece of code in a scope mapping which works for me. It's just something I've had ChatGPT write for me quickly and there is probably a better way. Also no idea if it works for LDAP.

from authentik.core.models import Group

def get_user_effective_groups(user):
    """Return all groups the user belongs to, including descendants of their groups."""
    # Direct + indirect memberships (via parent chain)
    user_groups = list(user.all_groups())
    user_group_names = {g.name for g in user_groups}

    effective = set(user_group_names)

    # Iterate over every defined group
    for group in Group.objects.all():
        # Walk up the parent chain to see if it descends from any user group
        parent = group.parent
        while parent:
            if parent.name in user_group_names:
                effective.add(group.name)
                break
            parent = parent.parent

    return effective

You can think of authentik's group hierarchy as either

• child groups inherit their parent groups' permissions, or
• parent groups "inherit" their child groups' members

These two are equivalent, but I recommend using the first one, because group memberships are all about permissions anyway.

This behavior is indeed opposite to what you're describing, but I find that it's the more common approach in the industry. Case in point: this Active Directory page seems to indicate that permissions are also the inherited property in AD, not members. At least by default. AD is extremely complicated and I'm sure you can set it up the other way around if you want to.

In your example, I'm not entirely sure what permissions Global Admin is supposed to have. If it should have every possible permission in authentik, I suggest making it a group with is_superuser and no relations to other groups.

If Global Admin's permissions is supposed to be the union of App ${n} Admin permissions, then I suggest setting all the individual app admin groups as the parent groups of Global Admin. (You'll have to wait for #17050 with this, which adds the possibility of multiple parents.)

This behavior is indeed opposite to what you're describing, but I find that it's the more common approach in the industry. Case in point: this Active Directory page seems to indicate that permissions are also the inherited property in AD, not members. At least by default. AD is extremely complicated and I'm sure you can set it up the other way around if you want to.

The parent child relationship as used by authentik is opposite any group nesting system I've ever seen as a user.

The page you're linking is not describing group nesting /inheritance, it is only describing permission inheritance on objects in the AD tree.

AD is built as a tree structure based on 'organizational units' which are collections of identities in the tree. They are distinctly different from groups.

What the page about AD describes is that permissions are inherited down to lower objects in the ad OU tree. It does not talk about groups at all.

Groups in AD are more like identities, whereas OU's should be more seen as locations in the tree. Groups being identities means that groups can contain groups as members, this is the thing Authentik is missing, and this is what everyone means by parent child relationship.

In AD one would create a group called Readers and give that group Read permission on whatever. You can then create a group called Writers and give them Write permission. You can then make the group Writers a member of the Readers group. If you would place my user in the Readers group I would not get Write permission, only Read. If you place my user in the Writers group I would get both Write and Read permissions because my user is a member of Writers group and Writers group is a member of Readers group. Indirectly my user is in the Readers group.

I don't think anyone actually needs groups to have parent child relationships in Authentik, I think they just want groups to accept groups as members.

Authentik parent/child groups hierarchy seems weird to me. Parent group members are "inherited" from the child group instead of the opposite way. It is confusing in its wording as well.

Since each group only accepts one parent group, the general admin group cannot "inherit" the members from multiple app admin groups. In this case, I have to bind multiple app admin groups to each user, instead of simply binding the general admin group. Happy to see #17050 is merged, but this hierarchisation logic doesn't really sound like the common practice in the industry.

Like what @rouke-broersma has mentioned, we just need the parent group to be able to inherit its members to all the child groups.