- Newest
- Most votes
- Most comments
Afraid its not supported with ENTRA ID. Nested Groups in groups are not enumerated because the group membership returned in the SAML response is just the list of groups the user is a memeber of if using Entra ID
See NESTED GROUPS :- https://docs.aws.amazon.com/singlesignon/latest/userguide/idp-microsoft-entra.html
However, Im lead to belive ADFS Does support this:-
"Expanding nested groups" in the context of ADFS means that when a user is a member of a group which is itself a member of another group (a nested group), ADFS will automatically include both the parent group and the child group in the user's claims when generating a token, effectively listing all the groups a user belongs to even if they are nested within other groups
Based on the information available, it appears that AWS Client VPN authorization rules do not support recursive searching of Active Directory group memberships by default. The authorization rules seem to only consider direct group memberships, not nested or inherited group memberships.
When you create "gathering" AD groups that contain other groups (like Project_A, Project_M, etc.), the VPN authorization rules are not recognizing the users within those nested groups. This behavior suggests that the AD query being performed is not using the equivalent of the memberOf:1.2.840.113556.1.4.1941 LDAP matching rule, which would allow for recursive group membership evaluation.
Unfortunately, there doesn't seem to be a setting in AWS VPN Endpoints or AWS AD Connector that allows you to enable recursive group membership searches for authorization rules. This limitation means that the authorization rules are only effective for direct group memberships.
Your proposed workaround of programmatically expanding the membership of the various Project groups and adding each user to a "flattened" gathering group is a valid approach, albeit with the added maintenance burden you mentioned. This method ensures that all users are directly members of the group used in the authorization rules, which will work with the current behavior of the VPN Client Endpoint.
Another potential approach, though it may not reduce complexity, would be to create separate authorization rules for each Project group rather than using a gathering group. This would allow you to maintain the existing AD structure without the need for flattening groups, but it would result in more authorization rules to manage in the VPN Client Endpoint configuration.
Given the lack of documentation on this specific behavior and the absence of a setting to enable recursive group membership searches, it may be worth reaching out to AWS Support for clarification and to inquire about any potential future enhancements to this functionality.
Relevant content
asked 4 months ago
- AWS OFFICIALUpdated 4 years ago
- AWS OFFICIALUpdated 3 years ago
Ah, that's a pity. We chose AD as an identity provider because it's a much easier integration with AWS SSO. If we ever get to move off of our own AD, we'll use something that properly supports this functionality (either the dynamic groups in Azure, or the expanding nested groups in ADFS). Thanks for the clarification!