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 <[email protected]> wrote: > Hi, > > On Sat, Mar 18, 2023 at 12:04 AM Paul B. Henson <[email protected]> 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 -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Tomáš Halman
_______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
