Hi, Alexey is right.

The character @ is not expected in the username. A particular set of allowed characters may differ, depending on your setup.

I found nice summary here: https://systemd.io/USER_NAMES/

The SSSD default does not expect/allow '@' in username. To fix that you can configure the re_expression parameter according to your needs.
Setting

    re_expression = (?P<name>^@{0,1}[^@]+)@?(?P<domain>[^@]*$)

may help - this allows leading '@' (see '^@{0,1}' in the name. But there is not enough information about your environment to be sure that this change will work in all other cases as well.


HTH
Tomáš


On Mon, Mar 20, 2023 at 12:11 PM Alexey Tikhonov <atikhono@redhat.com> wrote:
Hi,

On Sat, Mar 18, 2023 at 12:04 AM Paul B. Henson <henson@acm.org> wrote:
>
> We are running the latest RHEL 8.7 which includes sss version
> 2.7.3-4.el8_7.3 and noticed some odd behavior. sss seems to ignore
> leading @ characters when looking up a username. For example:
>
> # getent passwd '@cpp.a'
> cpp.a:x:1000:1000:CPP admin service account:/home/cpp.a:/bin/bash
>
> The username is 'cpp.a', not '@cpp.a'. It doesn't seem to matter how
> many @ signs there are:
>
> # getent passwd '@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@cpp.a'
> cpp.a:x:1000:1000:CPP admin service account:/home/cpp.a:/bin/bash

In `sssd_nss.log`:
[sss_parse_name_for_domains] (0x0200): [CID#1] name '@@@ftp' matched
without domain, user is ftp

Did you try it with other domains (i.e. non-local users)?

Probably issue is with `SSS_DEFAULT_RE`:
https://github.com/SSSD/sssd/blob/master/src/util/util.h#L253

I guess the idea is that the username can't begin with '@'...


>
> This is a local account on the system, with the default sssd
> configuration, there is nothing explicitly set:
>
> # find /etc/sssd
> /etc/sssd
> /etc/sssd/conf.d
> /etc/sssd/pki
>
> If I update nsswitch.conf to remove sss from the passwd line this
> behavior goes away.
>
> The same behavior occurs on other systems that are integrated with our
> LDAP and kerberos systems. When logging in, not only is this invalid
> username successfully authenticated, it is passed to other pam modules:
>
> Mar 16 12:35:46 login-dev-01 sshd[3782209]: Skipped Duo login for
> '@@@@@@@henson' from 10.104.223.249: Allowing unknown user
>
> This is allowing a bypass of our security policies, in this case, a user
> who should have been forced to do MFA was able to login without it
> because the name passed to the other modules by the login stack was not
> the real username which ended up being logged in.
>
> Is this a bug? A configuration issue? I opened a support ticket with Red
> Hat but as have not as yet received a resolution. I wouldn't think this
> would be intended behavior out-of-the-box.
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue


--
Tomáš Halman