Issue: EntraID groups that are renamed result in auth failures because GID conflicts

[arion-ch]

Is there an existing issue for this?

• I have searched the existing issues and found none that matched mine

Describe the issue

Authd appears to cache the name of each group a user is a member of, as supplied by the OIDC claim, with a randomly generated GID. However, group names can be changed at any time within EntraID. I'm not sure what is actually included in the claim, but if I explicitly rename a group, after having previously logged in to a server, the new group name immediately starts causing a conflict. This only impacts password authentication -- I can still SSH using a key -- but there is no way a user can resolve this without admin intervention.

User experience looks like this:

$ ssh [email protected]@192.168.1.1
Insert 'r' to cancel the request and go back
([email protected]@192.168.1.1) Enter your local password:
authentication status failure: can't check authentication: failed to update user "[email protected]": GID for group "NEW_GROUP" already in use by a different group
Insert 'r' to cancel the request and go back
([email protected]@192.168.1.1) Enter your local password:

The log files show the following entries:

2024-11-06T23:22:37.528555+00:00 analysis authd[14833]: 2024/11/06 23:22:37 ERROR GID 1499969210 for group "NEW_GROUP" already in use by group "OLD_GROUP"
2024-11-06T23:22:37.533334+00:00 analysis authd[14833]: 2024/11/06 23:22:37 WARN can't check authentication: failed to update user "[email protected]": GID for group "NEW_GROUP" already in use by a different group

This work-around seems to work:

• Remove the user from the EntraID group
• Log into the authd-enabled server, then log out
• Add the user back to the EntraID group
• Log back into the authd-enabled server

Steps to reproduce

• Add a user to an EntraID group
• Log into an authd-enabled server, then log out
• Renamed the EntraID group
• Attempt to log back into authd-enabled server, observe GID conflict error

System information and logs

authd version

authd   0.3.6

authd-msentraid broker version

name:      authd-msentraid
summary:   MSEntra ID broker for authd
publisher: Canonical**
store-url: https://snapcraft.io/authd-msentraid
license:   GPL-3.0
description: |
  This is the MS Entra ID broker snap for authd  to provide MS Entra ID OIDC
  based authentication on Ubuntu with authd.
services:
  authd-msentraid: simple, enabled, active
snap-id:      vS3oJLMss6lgWwoFcPqYDUA2HB20I1Dc
tracking:     0.x/edge
refresh-date: today at 01:15 UTC
channels:
  0.x/stable:    0.1+4fe9826.0f76acc 2024-10-02 (51) 18MB -
  0.x/candidate: ^
  0.x/beta:      ^
  0.x/edge:      0.1+fef0c13.918f3f8 2024-11-05 (61) 18MB -
installed:       0.1+fef0c13.918f3f8            (61) 18MB -

gnome-shell version

gnome-shell:
  Installed: 46.3.1-1ubuntu1~24.04.1authd2
  Candidate: 46.3.1-1ubuntu1~24.04.1authd2
  Version table:
 *** 46.3.1-1ubuntu1~24.04.1authd2 500
        500 https://ppa.launchpadcontent.net/ubuntu-enterprise-desktop/authd/ubuntu noble/main amd64 Packages
        100 /var/lib/dpkg/status
     46.0-0ubuntu6~24.04.5 500
        500 http://us.archive.ubuntu.com/ubuntu noble-updates/main amd64 Packages
     46.0-0ubuntu6~24.04.3 500
        500 http://security.ubuntu.com/ubuntu noble-security/main amd64 Packages
     46.0-0ubuntu5 500
        500 http://us.archive.ubuntu.com/ubuntu noble/main amd64 Packages

Distribution

Distributor ID: Ubuntu
Description:    Ubuntu 24.04.1 LTS
Release:        24.04
Codename:       noble

Logs

[180724.694978] analysis authd[14833]: 2024/11/06 23:22:37 ERROR GID 1499969210 for group "NEW_GROUP" already in use by group "OLD_GROUP"
[180724.694978] analysis authd[14833]: 2024/11/06 23:22:37 WARN can't check authentication: failed to update user "[email protected]": GID for group "NEW_GROUP" already in use by a different group

authd broker configuration

/etc/authd/brokers.d/msentraid.conf

# This section is used by authd to identify and communicate with the broker.
# It should not be edited.
[authd]
name = Microsoft Entra ID
brand_icon = /snap/authd-msentraid/current/broker_icon.png
dbus_name = com.ubuntu.authd.MSEntraID
dbus_object = /com/ubuntu/authd/MSEntraID

authd-msentraid configuration

[oidc]
issuer = https://login.microsoftonline.com/<UUID redacted>/v2.0
client_id = <UUID redacted>

[users]
# The directory where the home directory will be created for new users.
# Existing users will keep their current directory.
# The user home directory will be created in the format of {home_base_dir}/{username}
home_base_dir = /home

# The username suffixes that are allowed to login via ssh without existing previously in the system.
# The suffixes must be separated by commas.
# ssh_allowed_suffixes = @example.com,@anotherexample.com
ssh_allowed_suffixes = @<redacted>

Double check your logs

• I have redacted any sensitive information from the logs

[junebugin]

Experiencing the same issue via GDM.

In my case, the issue is easily reproducible when 2 conditions are met:
-A group the user is a member of has had a name change.
-Password change for the user takes place

EDIT: I see the author is using edge - just for awareness, I am using stable.

[adombeck]

Thanks a lot for the report. We're able to reproduce this and will look into solutions.

[adombeck]

@didrocks @denisonbarbosa:This bug is caused by this check.

If we merge https://github.com/canonical/authd-private/pull/9 as is (we should move that to the public repo btw), there won't be a failure anymore but instead the renamed group will receive a new GID. That's also incorrect behavior, because files created by the old group won't be accessible to users of the renamed group.

For groups which are managed in Microsoft Entra, I think we actually want to rename the group in the authd database if we notice that it has been renamed in Microsoft Entra. That would require that we store a "remoteID" field in the database, which contains the ID of the group in Microsoft Entra. Then when we add the user to groups during login, we check if there is another group with the same remoteID, and if so, rename that group to the new name. What do you think?

[didrocks]

That makes sense to me. Also, we can probably derive the GID from this remoteID? (there is still the issue with backward compatibility and potential collisions), but at least, we won’t have to explicitly track it ourself that way in an extra metadata column, wdyt?

[adombeck]

The collision issue is a problem which I still think we should fix (either via https://github.com/canonical/authd-private/pull/9 or by storing the GIDs and UIDs in Microsoft Entra), so for that reason I don't think it would be good to derive the GID from the remote ID.

[didrocks]

Please, refresh my memory: we do already pass the ugid (what you call remote id) in the userinfo, right?

[adombeck]

(Moving here from ubuntu/authd-oidc-brokers#172 (comment))

@shiv-tyagi Quick summary of the problem: We currently store groups with their name and the GID we generate for it in the authd database:

• authd/internal/users/cache/db.go

  Lines 65 to 69 in faeecc8

  	type GroupDB struct {
  	Name string
  	GID uint32
  	Users []string
  	}

• authd/internal/users/cache/update.go

  Lines 101 to 102 in faeecc8

  	updateBucket(buckets[groupByIDBucketName], groupContent.GID, groupDB{Name: groupContent.Name, GID: groupContent.GID})
  	updateBucket(buckets[groupByNameBucketName], groupContent.Name, groupDB{Name: groupContent.Name, GID: groupContent.GID})

  
  We generate the GID from the "UGID", which is the ID used by the identity provider to identify the group:

• authd/internal/users/manager.go

  Line 122 in faeecc8

  gidv := m.GenerateGID(u.Groups[i].UGID)

• https://github.com/ubuntu/authd-oidc-brokers/blob/b5fa6f28769a3c6d9ed55d2dde145220f19961b9/internal/providers/msentraid/msentraid.go#L163-L185

That results in the issue that when a group is renamed in the identity provider (Microsoft Entra), then we treat it as a different group because it has a different name, but we generate the same UID for it (because the UGID did not change), so the login fails at this check:

authd/internal/users/cache/update.go

Lines 94 to 98 in faeecc8

	// If a group with the same GID exists, we need to ensure that it's the same group or fail the update otherwise.
	if existingGroup.Name != "" && existingGroup.Name != groupContent.Name {
	log.Errorf(context.TODO(), "GID %d for group %q already in use by group %q", groupContent.GID, groupContent.Name, existingGroup.Name)
	return fmt.Errorf("GID for group %q already in use by a different group", groupContent.Name)
	}

I think the best solution is to also store the UGID in our database and use that to check if a group already exists in

authd/internal/users/cache/update.go

Lines 89 to 92 in faeecc8

	existingGroup, err := getFromBucket[groupDB](buckets[groupByIDBucketName], groupContent.GID)
	if err != nil && !errors.Is(err, NoDataFoundError{}) {
	return err
	}

If a group with the same UGID already exists but has a different name, we should rename it to the new name.

[shiv-tyagi]

I think the best solution is to also store the UGID in our database and use that to check if a group already exists in

Instead of storing the UGID, can we store a field which identifies who created this group? That way if MS Entra tries to create a group with UID conflicting with another group (that can only happen if the UGID is same), we can rename the group and if someone else (like some other broker) tries to create a group with conflicting UID, we deny the request.

[adombeck]

That way if MS Entra tries to create a group with UID conflicting with another group (that can only happen if the UGID is same)

That assumption is incorrect, it can happen that different UGIDs result in the same GID. That's the issue tracked in #509. How likely it is for these collisions to occur depends on the GID range configured in /etc/authd/authd.yaml.

[shiv-tyagi]

@adombeck Thanks for the explanation. I'll start working on it as suggested by you in previous comments.