Sumit, Good info.
Unfortunately for us, that would not work. A very high-level management decision is to use camel-case in AD for names. Windows doesn't care -- it's case-insensitive. But as we see here, Linux and Kerberos client very much cares. Luckily, we're good -- for our one use case. Spike On Tue, Nov 10, 2020 at 12:23 AM Sumit Bose <[email protected]> wrote: > On Mon, Nov 09, 2020 at 12:06:05PM -0600, Spike White wrote: > > All, > > > > In this particular case, it's an automation script that logs in (via SSH) > > and performs activities as those two service accounts. So we were able > to > > convert the automation to using lower case and then use lower case in our > > sshd 'Match User' block. So all is happy now. > > > > But in the general case, is there a way to have sssd disallow users > logging > > in with upper case or mixed case? I'd much prefer forcing the users to > log > > in with lower case, than not matching my sshd 'Match User' blocks. > > Hi, > > currently there is only 'case_sensitive = True' but this does not force > lower-case names but names which match the spelling from the > server-side. So if the name is stored with all-caps on the server it > must be all-caps at login as well. If the names on the server are all > lower-case it would do want you want. > > bye, > Sumit > > > > > I realize that sssd is mapping whatever entry the user types into lower > > case. But that's apparently too late (for sshd). > > > > BTW, I realize this is not a sssd problem. It's a sshd problem (when > > relying on a case-insensitive back-end user auth, such as AD). > > > > Spike > > > > On Thu, Nov 5, 2020 at 3:03 AM Sumit Bose <[email protected]> wrote: > > > > > On Wed, Nov 04, 2020 at 12:03:16PM -0600, Spike White wrote: > > > >sssd professionals, > > > > > > > >Interesting problem; seems to be an interaction with sshd daemon when > > > >using an AD back-end. > > > > > > > >When using sssd (with an AD back-end), what should my “Match” blocks > in > > > >/etc/ssh/sshd_config file look like for over-riding user values? > > > > > > > >Right now, my Match blocks look like: > > > > > > > > MaxSessions 10 > > > > > > > > .... > > > > > > > >Match User SERVICEPPTPRDVRA > > > > > > > > MaxSessions 999 > > > > > > > > ClientAliveInterval 360 > > > > > > > > ClientAliveCountMax 3 > > > > > > > > > > > > > > > >Match User SERVICEPPTPRDDCA > > > > > > > > MaxSessions 999 > > > > > > > > ClientAliveInterval 360 > > > > > > > > ClientAliveCountMax 3 > > > > > > > > > > > > > > > >And in the system log files, it looks like: > > > > > > > >Nov 4 10:40:22 peplpc1mom01 sshd[2400354]: debug2: > parse_server_config: > > > >config reprocess config len 1479 > > > >Nov 4 10:40:22 peplpc1mom01 sshd[2400354]: debug3: checking match for > > > 'User > > > >SERVICEPPTPRDVRA' user SERVICEPPTPRDVRA host 10.175.99.51 addr > > > 10.175.99.51 > > > >laddr 10.174.120.203 lport 22 > > > >Nov 4 10:40:22 peplpc1mom01 sshd[2400354]: debug1: user > SERVICEPPTPRDVRA > > > >matched 'User SERVICEPPTPRDVRA' at line 158 > > > >Nov 4 10:40:22 peplpc1mom01 sshd[2400354]: debug3: match found > > > >Nov 4 10:40:22 peplpc1mom01 sshd[2400354]: debug3: reprocess > config:159 > > > >setting MaxSessions 999 > > > >Nov 4 10:40:22 peplpc1mom01 sshd[2400354]: debug3: reprocess > config:160 > > > >setting ClientAliveInterval 360 > > > >Nov 4 10:40:22 peplpc1mom01 sshd[2400354]: debug3: reprocess > config:161 > > > >setting ClientAliveCountMax 3 > > > >Nov 4 10:40:22 peplpc1mom01 sshd[2400354]: debug3: checking match for > > > 'User > > > >SERVICEPPTPRDDCA' user SERVICEPPTPRDVRA host 10.175.99.51 addr > > > 10.175.99.51 > > > >laddr 10.174.120.203 lport 22 > > > >Nov 4 10:40:22 peplpc1mom01 sshd[2400354]: debug3: match not found > > > > > > > > > > > > > > > >Here's where it gets weird. Because this is an AD back-end, by > default > > > >sssd is setting > > > > > > > >case_sensitive = false > > > > > > > >That is, it matches any case of user names. Examples: > > > > > > > > SERVICEPPTPRDVRA > > > > > > > > servicepptprdvra > > > > > > > > ServicePPTPrdVra > > > > > > > >However, I notice that sssd maps all the user names to lowercase once > > > >you’re fully logged in. (this is what's desired.) > > > > > > > > > > > > > > > >Example: > > > > > > > > > > > > > > > >[root@peplpc1mom01 ssh]# su -l SERVICEPPTPRDVRA > > > > > > > >Last login: Wed Nov 4 10:03:31 CST 2020 on pts/12 > > > > > > > >[servicepptprdvra@peplpc1mom01 ~]$ id > > > > > > > >uid=3001425(servicepptprdvra) gid=3001425(servicepptprdvra) > > > > >groups=3001425(servicepptprdvra),1010(amerunixusers),2284221(puppetentrp) > > > > > > > >[servicepptprdvra@peplpc1mom01 ~]$ > > > > > > > > > > > > > > > >It looks like SSHD is looking at the raw “user name” input without any > > > >processing for its match blocks. So I’m guessing this is before any > PAM > > > or > > > >NSS processing. > > > > > > > > > > > >Originally, I naively assumed that my Match blocks should be > lowercase, as > > > >that's what I see on the command line. But now I think it has to be > > > >whatever raw input the user entered. > > > > > > Hi, > > > > > > yes, from looking at the OpenSSH code I would say that OpenSSH matches > > > the names case-sensitive and uses the name given at the client without > > > any kind of canonicalization on the server side. > > > > > > This is not unexpected since it corresponds to what is typical on > > > Unix/Linux systems and might even be defined in POSIX, e.g. you cannot > > > log in as 'ROOT', only as 'root'. > > > > > > If this is only about single user it might be the most easy to just use > > > a local user from /etc/passwd. If this is about multiple users you > might > > > need to disable the 'case_sensitive = false' convenience feature in > > > sssd.conf, since I guess OpenSSH maintainers won't be happy to change > > > the OpenSSH behavior here. But this would also mean that all your AD > > > users must know the right upper-lower case spelling of the login names. > > > > > > bye, > > > Sumit > > > > > > > > > > > > > > > > > >Spike > > > > > > >_______________________________________________ > > > >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] > > > _______________________________________________ > > > 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] > > > > > > _______________________________________________ > > 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] > _______________________________________________ > 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] >
_______________________________________________ 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]
