exploration of AD-groups

[stefanoostwegel]

I'm writing an intranet application and would like to use our Azure AD SSO integration for users to be granted access.
We have AD-groups project based and would like to use that groupname to restrict access for project members.

If i understood correctly, i cannot use the name of the group but need to use the group GUID.
Is there a way to have Django request the available groups in the AD and create a GUI in django to select the proper group (GUID)?
It would be difficult to maintain to retrieve the GUID manually from the AD to connect new projects to their corresponding AD group.

[JonasKs]

No need for group IDs, the group name is what is in the token. So if your user is in a group called "adminGroup", then it would arrive as "adminGroup" in the token.

[stefanoostwegel]

So, if i understand correctly, i can add groupnames to the database, and verify if a usertoken contains a group that is equal to the name in my database?

I am confused regarding the statement in the introduction on read the docs:
Groups are listed with their GUID in the groups claim. Meaning you have to create your groups in Django using these GUIDs, instead of their name

[JonasKs]

Auto creates users and adds them to Django groups based on info received from ADFS.

It also creates the groups for you.

[JonasKs]

So:

1. User logs in with ADFS or Azure AD
2. This package verifies the login and creates the user and all the groups (if the group don't exist)
3. The user is added to the groups
4. You can create middleware a/checks for the views doing logic like this:

if not request.user.groups.filter(name=required_group):
    ...

[jmartens]

It depends on the configuration of your application whether the UID or sAMAccountName of something else is returned by the API by configuring the groups claim through the Add groups claim of App Registration > Application Name > Token Configuration screen.
At least in our tennant we have the following options to choose from with Group Id being the default (even if not configured):

If you explicitly define it and choose sAMAccountName you get a much more readable group name.

[JonasKs]

I'll close this, as it's gone stale.

@jmartens setting for sAMAccountName in the Access-token is indeed the right way to configure this. You'll then get a list of roles in the token.

[tim-schilling]

I'm using Azure AD and I can't get the human readable names to come through within the groups claim despite having selected sAMAccountName for all types. I bring this up because it contradicts the walkthrough for the integration with Azure AD in the documentation.

[JonasKs]

@tim-schilling , normally takes a while.. Try again tomorrow.

[jmartens]

Perhaps too many group memberships and a graph uri is supplied? If that is the case specify groups in your application to limit groups returned. On Jan 21, 2022 19:06, Jonas Krüger Svensson ***@***.***> wrote: @tim-schilling , normalt takes a while.. Try again tomorrow. —Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: ***@***.***>

[tim-schilling]

@jmartens @JonasKs Looks like sAMAccountName is not available for groups entirely managed within Azure AD: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-group-claims

sAMAccountName and On Premises Group SID attributes are only available on Group objects synced from Active Directory. They aren't available on groups created in Azure Active Directory or Office365. Applications configured in Azure Active Directory to get synced on-premises group attributes get them for synced groups only.