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.

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

@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?

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?

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.

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

(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:

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

If a group with the same UGID already exists but has a different name, we should rename it to the new 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

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.

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.

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