Support setting UID and GID via authctl

[callanova]

Is there an existing request for this feature?

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

Describe the feature

Currently, authd creates a random UID and GID for any users / groups it creates.
For example, during first authentication, firstname.lastname@company.com creates a UID of 1021432359 and a GID of 1021432359.
We have a workflow that requires a user's UID and GID to be set to a specific value like 1001.
usermod and groupmod don't allow us to modify the UID and GID of firstname.lastname@company.com because, the user and group don't exist in /etc/passwd and /etc/group respectively.
It would be great if there was a way to modify a UID and GID for users / groups created by authd.

Describe the ideal solution

A CLI cmd that can manage and modify /var/cache/authd/auth.db allowing us the ability to update the UID and GID for users / groups created by authd.

Alternatives and current workarounds

Use a non-authd account.

System information and logs

Environment

• broker version: please run snap info authd-msentraid

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: yesterday at 18:11 PST
channels:
  0.x/stable:    0.1+4fe9826.0f76acc 2024-10-02 (51) 18MB -
  0.x/candidate: ↑
  0.x/beta:      ↑
  0.x/edge:      0.1+a94565a.ed309a2 2024-11-12 (69) 18MB -
installed:       0.1+3c70d4e.048f86b            (67) 18MB -

• authd version: please run /usr/libexec/authd version

authd   0.3.6

• gnome shell version: please run apt policy gnome-shell

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: (NAME in /etc/os-release)

"Ubuntu"

• Distribution version: (VERSION_ID on /etc/os-release):

24.04

Log files

Please redact/remove sensitive information:

Authd entries:

journalctl -u authd.service

N/A

MS Entra ID broker entries:

journalctl -u snap.authd-msentraid.authd-msentraid.service

N/A

Application settings

Please redact/remove sensitive information:

Broker configuration:

cat /var/snap/authd-msentraid/current/broker.conf

[oidc]
issuer = https://login.microsoftonline.com/TENANT_ID/v2.0
client_id = CLIENT_ID

[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 = @company.com

Broker authd configuration:

cat /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

Relevant information

N/A

Double check your logs

• I have redacted any sensitive information from the logs

[adombeck]

That's something we could support in the command-line tool which we plan to implement at some point (see #640).

[ajm370]

@adombeck I'm unsure whether to class this as a new Feature Request or not, but I would be interested to know whether the proposed solution (authd CLI utility) would have the ability to set the UID/GID manually via a particular EntraID attribute?

For example, if an extension attribute was created for all AD accounts in advance, ID integer values populated automatically (and are created then procedurally incremented for new accounts), then finally synced to Entra... would it be possible to lookup this value for any account and set the UID/GID to it via the authd CLI utility? Many thanks!

[adombeck]

Hi @ajm370!

For example, if an extension attribute was created for all AD accounts in advance, ID integer values populated automatically (and are created then procedurally incremented for new accounts), then finally synced to Entra... would it be possible to lookup this value for any account and set the UID/GID to it via the authd CLI utility?

authctl will allow you to set the user/group ID of authd-managed users/groups. If you do everything else you mention with your own tooling, including looking up the user/group ID in an extension attribute, then yes, you can use authctl to set that ID.

We might also be able to add some basic functionality to the broker to assist with the lookup of the extension attribute: Entra supports adding directory extension attributes as token claims to OIDC tokens, see https://learn.microsoft.com/en-us/entra/identity-platform/schema-extensions. The authd Entra ID broker already retrieves OIDC tokens when authenticating a user, extracts some claims from it and stores those (along with additional user info retrieved via the Graph API) in /var/snap/authd-msentraid/current/<issuer>/<user>/token.json. We could add a config option in broker.conf to specify additional claims which should be stored in the token.json as well, which you could then parse to retrieve the ID values and call authctl to set the user/group ID. Do you think that would help your use case?

[ajm370]

Hi @ajm370!

For example, if an extension attribute was created for all AD accounts in advance, ID integer values populated automatically (and are created then procedurally incremented for new accounts), then finally synced to Entra... would it be possible to lookup this value for any account and set the UID/GID to it via the authd CLI utility?

authctl will allow you to set the user/group ID of authd-managed users/groups. If you do everything else you mention with your own tooling, including looking up the user/group ID in an extension attribute, then yes, you can use authctl to set that ID.

We might also be able to add some basic functionality to the broker to assist with the lookup of the extension attribute: Entra supports adding directory extension attributes as token claims to OIDC tokens, see https://learn.microsoft.com/en-us/entra/identity-platform/schema-extensions. The authd Entra ID broker already retrieves OIDC tokens when authenticating a user, extracts some claims from it and stores those (along with additional user info retrieved via the Graph API) in /var/snap/authd-msentraid/current/<issuer>/<user>/token.json. We could add a config option in broker.conf to specify additional claims which should be stored in the token.json as well, which you could then parse to retrieve the ID values and call authctl to set the user/group ID. Do you think that would help your use case?

Hi @adombeck! Yes, that's all very useful information and I think that would definitely help regarding our use case. Are extension attributes exposed in the token.json currently? I believe that they are of the form: extensionAttribute1, ... , extensionAttribute15? For clarity, I am not requesting Schema Extension interoperability, although saying that I will need to double-check that our org has not used all of these already!

It looks like only users and not groups are able to make use of extension attributes: https://learn.microsoft.com/en-us/graph/extensibility-overview?tabs=http#comparison-of-extension-types. Speaking of which, are we able to use 365 Security groups as standard Linux groups for Authd-configured devices? Or is it only the documented 'linux-<group_name>' format that we can use for this purpose? I can see that all of my Entra account's groups are enumerated with (non-unique) GID's on my test device.

[adombeck]

Yes, that's all very useful information and I think that would definitely help regarding our use case.

Great!

Are extension attributes exposed in the token.json currently?

No, currently not, but I could prepare a patch which you could try out.

It looks like only users and not groups are able to make use of extension attributes: https://learn.microsoft.com/en-us/graph/extensibility-overview?tabs=http#comparison-of-extension-types.

This doc is about making "directory extension attributes" available via token claims. My understanding is that this refers to the "Directory extensions" in the table you're linking. Do you understand it differently?

Speaking of which, are we able to use 365 Security groups as standard Linux groups for Authd-configured devices? Or is it only the documented 'linux-<group_name>' format that we can use for this purpose?

Yes, currently authd creates a group for each Entra security group the user is a member of, and adds the user to that group. For groups with the linux- prefix, it's assumed that a group of that name (without the prefix) already exists on the local system (for example the sudo group), and the user is added to that existing group instead of creating a new group.

I can see that all of my Entra account's groups are enumerated with (non-unique) GID's on my test device.

What do you mean with non-unique? Do you see multiple groups with the same GID?

[ajm370]

Are extension attributes exposed in the token.json currently?

No, currently not, but I could prepare a patch which you could try out.

That would be extremely helpful, but let me check that we are talking about the same thing, and that it is in theory possible, before I commit to that (see below).

It looks like only users and not groups are able to make use of extension attributes: https://learn.microsoft.com/en-us/graph/extensibility-overview?tabs=http#comparison-of-extension-types.

This doc is about making "directory extension attributes" available via token claims. My understanding is that this refers to the "Directory extensions" in the table you're linking. Do you understand it differently?

Yes, although I think that is a Microsoft-clarity issue 😆 in the link you posted, they do state that 2 of the 4 extensions aren't "available as sources for claims in tokens":

The remaining two are Directory Extensions (as you mentioned) as well as Extension Attributes (the standard 1-15 on-premises AD gives you, without needing to extend your LDAP Schema), which is what my colleagues who manage our Entra tenant have said should be possible for us to use internally for this.

In the OAuth/OIDC token, my (limited) understanding is that the relevant section of the JSON could look something like:

{ "onPremisesExtensionAttributes": { "extensionAttribute12": "100001", "extensionAttribute13": "100011" } }

Speaking of which, are we able to use 365 Security groups as standard Linux groups for Authd-configured devices? Or is it only the documented 'linux-<group_name>' format that we can use for this purpose?

Yes, currently authd creates a group for each Entra security group the user is a member of, and adds the user to that group. For groups with the linux- prefix, it's assumed that a group of that name (without the prefix) already exists on the local system (for example the sudo group), and the user is added to that existing group instead of creating a new group.

I understand this functionality and it is useful in theory; unfortunately, my organisation mandates departmental prefixes for all groups, so I will raise a feature request for optional "-linux" suffix functionality with default "linux-" prefix functionality on Entra -> Authd group creation and membership (depending on how possible the next part is).

I can see that all of my Entra account's groups are enumerated with (non-unique) GID's on my test device.

What do you mean with non-unique? Do you see multiple groups with the same GID?

They are unique per device, but if I log into two devices via Authd, the Entra group GID's don't match across the two systems. Sorry I've not been clear enough: what I am asking is whether the non "linux-" prefixed Entra groups can be used practically on a Ubuntu system setup with Authd (i.e. file permissions, sudo rights, etc.), excepting the login and SSH options present in the broker.conf file?

Cheers!

[adombeck]

The remaining two are Directory Extensions (as you mentioned) as well as Extension Attributes (the standard 1-15 on-premises AD gives you, without needing to extend your LDAP Schema), which is what my colleagues who manage our Entra tenant have said should be possible for us to use internally for this.

Those are indeed only available on user and device resources, so you can't use those to store a GID in a group resource. So it doesn't help with your goal of setting the same GID for the same group on different authd instances.

I understand this functionality and it is useful in theory; unfortunately, my organisation mandates departmental prefixes for all groups, so I will raise a feature request for optional "-linux" suffix functionality with default "linux-" prefix functionality on Entra -> Authd group creation and membership (depending on how possible the next part is).

That's a separate feature request, please file a GitHub issue for it.

what I am asking is whether the non "linux-" prefixed Entra groups can be used practically on a Ubuntu system setup with Authd (i.e. file permissions, sudo rights, etc.), excepting the login and SSH options present in the broker.conf file?

authd creates the groups on the system and adds the users to them, so yes, they can be practically used. For example, if your user is a member of an Entra group "admin", a group of the same name will be created locally when you log in via authd. By default, /etc/sudoers allows members of a group named "admin" to use sudo. You could define other groups which should have sudo access in the sudoers file.

File permissions also work. Once the group was created locally (i.e. a user who is a member of that group logged in), you can make files owned by that group.

I don't understand what you mean with "excepting the login and SSH options present in the broker.conf file".

[ajm370]

Hi @adombeck, thanks again for your time and detailed responses :)

Those are indeed only available on user and device resources, so you can't use those to store a GID in a group resource. So it doesn't help with your goal of setting the same GID for the same group on different authd instances.

I've thought on this more; I think we can make do with Extension Attributes as is, and would be very happy to test the patch if you and/or colleagues can put one together please.

Would there be an issue setting the GID of a user to be identical to their UID via authctl? I've noticed on all test Authd devices I've logged into that my GID and UID haven't matched (for my username@org.tld account, to clarify), and wasn't sure if that was simply due to randomisation or for a specific reason.

That's a separate feature request, please file a GitHub issue for it.

Sure, will do!

`authd creates the groups on the system and adds the users to them, so yes, they can be practically used. For example, if your user is a member of an Entra group "admin", a group of the same name will be created locally when you log in via authd. By default, /etc/sudoers allows members of a group named "admin" to use sudo. You could define other groups which should have sudo access in the sudoers file.

File permissions also work. Once the group was created locally (i.e. a user who is a member of that group logged in), you can make files owned by that group.

I don't understand what you mean with "excepting the login and SSH options present in the broker.conf file".`

That's fine, that all makes sense. Alongside with the previous part about 'linux-...' -> '...-linux' automatic group creation from Entra (to be a separate feature request), this will work for us. The login/SSH options are the part I understand definitely work, but require manual definition per-device/group of devices. I was asking about Entra group usage on Ubuntu authd-based systems so that we can manage permissions and trust via Entra policies & possibly other features like PIM, in a more automated way.

Many thanks again!

[adombeck]

I've thought on this more; I think we can make do with Extension Attributes as is, and would be very happy to test the patch if you and/or colleagues can put one together please.

That's now tracked in #963

[adombeck]

Would there be an issue setting the GID of a user to be identical to their UID via authctl? I've noticed on all test Authd devices I've logged into that my GID and UID haven't matched (for my username@org.tld account, to clarify), and wasn't sure if that was simply due to randomisation or for a specific reason.

No, that will not be an issue. It currently doesn't match because we choose random IDs for users and groups. However, we actually plan to change that soon for user private groups, to use the same ID for the user and the user private group, as it should be according to https://wiki.debian.org/UserPrivateGroups#UPGs.

[ajm370]

Hi @adombeck, thanks again for putting the requested patch together.

Would it be possible to implement a similar function that pulls down on-premises AD custom extension attributes, e.g. extensionAtrribute5 , for user who is logged in? I'm not sure if this could look something like the following request+response:

https://learn.microsoft.com/en-us/graph/extensibility-overview?tabs=javascript#request

Cheers!

[adombeck]

Hi @ajm370!

Would it be possible to implement a similar function that pulls down on-premises AD custom extension attributes, e.g. extensionAtrribute5 , for user who is logged in?

Maybe, but first I'd like to understand the use case that would solve. Since these extension attributes can't be used for groups, I don't think it makes sense to use these for synchronizing user and group IDs - I think the directory extensions make more sense for that. Can you explain why you want to use the on-premises AD extension attributes instead?