Systemd / systemd-userdbd not handling AD usernames only containing digits?

Ask Fedora
, ,
1

Coming from the server side, I have been tasked at integrating a handful of workstations running Fedora 42 with Active Directory.

It initially worked quite nicely, as expected, until we had a user logging in, with a username that only contained digits, which made something (inside systemd?) explode.

Setup:

  • A simple realm join and the machines were joined, no issues there.
  • This setup is only using a single AD domain, no cross forest trusts, etc, so SSSD has usually been configured with use_fully_qualified_names = False or set to true, but then with default_domain_suffix = <domain.tld> in the [sss] section, such that the users didn’t have to always login as ‘user@domain.tld’.

To the best of my recolection, this has worked as expected on the servers. However Fedora 42 clearly uses a much newer mix of systemd and its friends.

When setting use_fully_qualified_names = False, then I am able to login using a “normal” username (e.g. ‘user’), however i am experiencing mixed results, using a username that is entirely made up of numbers (e.g., ‘12345’), SSH will let me in, but fails to start dbus, and graphical logins throws me back to the login screen (presumably due to the missing dbus?).

When logging in through SSH, then i can see that systemd failed setting up the user session properly, as evident by this error:

12345@v-dev-f42:~$ systemctl --user status
Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)

And in journalctl, i can see the following errors duing login:

May 21 21:40:36 v-dev-f42 sshd-session[5869]: Accepted password for 12345 from x.x.x.x port 34200 ssh2
ay 21 21:40:36 v-dev-f42 sshd-session[5869]: pam_systemd(sshd:session): Failed to get user record: Invalid argument
May 21 21:40:36 v-dev-f42 sshd-session[5869]: pam_unix(sshd:session): session opened for user 12345(uid=427608069) by 12345(uid=0)

Setting use_fully_qualified_names = True , then both ‘user@domain.tld’ and ‘12345@domain.tld’, works as expected.
However setting the default_domain_suffix = domain.tld doesn’t work (as I would have expected). It fails with the same pam_systemd error.

From an old F3x bug i learnt about the systemd-userdbd.service and userdbctl cli tool (newer really interacted with this before).

I am unsure if this is what is being used, but at least it seems to fail in the same situations where the pam_systemd fails.

Question

  1. Is this a bug in systemd, that it can’t lookup users only consisting of numbers?
  2. From my test below, it seems that the userdbctl tools fails in quite a few situations where id returns a result. Is this expected or is that a bug that should be reported?
  3. Is there a way to configure Fedora 42, such that it doesn’t try to use “systemd” to lookup user accounts, since this fails so miserably in an interprise setting? This really doesn’t seem mature for GA.

Detailed information

With use_fully_qualified_names = False defined in sssd.conf, then I get the the following results, when trying to resolve my two example user accounts with various tools:

$ id user@domain.tld
uid=......

$ id user
uid=......

$ userdbctl user user@domain.tld
User user@domain.tld does not exist.      # NOT expected

I would expect, that it should be possible to lookup the user with full domain in the username, as `id` does?

$ userdbctl user user
   User name: user
 Disposition: container
...

Now testing the username only containing digits

$ id 12345@domain.tld
uid=......

$ id 12345
uid=......

The `id` command flawlessly returns the expected information

$ userdbctl user 12345@domain.tld
User 12345@domain.tld does not exist.      # NOT expected
...

$ userdbctl user 12345
User 12345 does not exist.          # NOT expected

With use_fully_qualified_names = True (and no default domain) defined in sssd.conf, then I get the the following results

$ id user@domain.tld
uid=......

$ id user
id: ‘user’: no such user       # as expected

$ userdbctl user user@domain.tld
   User name: user@domain.tld
 Disposition: container
...

$ userdbctl user user
User user does not exist.      # as expected

Here it is expected that it is not possible to lookup the user, without the full domain information, as this is the setting from sssd.conf.

$ id 12345@domain.tld
uid=......

$ id 12345
id: ‘12345’: no such user       # as expected

$ userdbctl user 12345@domain.tld
   User name: 12345@domain.tld
 Disposition: container
...

$ userdbctl user 12345
User 12345 does not exist.      # as expected

And when also enabling the default domain, then all tools that i have tested, other than systemd, will work whether or not a domain is specified:

$ id user@domain.tld
uid=......

$ id user
uid=......

$ userdbctl user user@domain.tld
   User name: user@domain.tld
 Disposition: container
...

$ userdbctl user user
User user does not exist.      # NOT expected. 

The `userdbctl` command should be able to find the user with AND without the domain.
1 Like
2

I would not invest any time in such an endeavor. An all numeric username is a bad choice and creates all kind of issues for obvious reasons.
It may somehow work as a local user, but I would not allow such a username authenticate using network services like AD / LDAP etc.

# adduser 12345
useradd: invalid user name '12345': use --badname to ignore

citing from User/Group Name Syntax

Common Core

Combining all rules listed above, user/group names that shall be considered valid in all systemd contexts and on all Linux systems should match the following regular expression (at least according to our understanding):

^[a-z][a-z0-9-]{0,30}$

3 Likes
3

Mark, thanks for the two insightful links. I had tried my best to search for similar info, but was unable to find it myself.

Sadly changing the corporate policy on this point is not likely to be easy, as the numeric username is the employee number, and is how it was originally implemented on the windows side of things.

4

@reenberg, if you’re willing to file issues at any of the relevant projects to gain support for numeric usernames, I’ll support you in the endeavour as far as I can. I’ve a desire for this, too.