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 <sbose(a)redhat.com> 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 <sbose(a)redhat.com> 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 -- sssd-users(a)lists.fedorahosted.org
> > >To unsubscribe send an email to
sssd-users-leave(a)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.fedorahoste...
> > _______________________________________________
> > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> > To unsubscribe send an email to
sssd-users-leave(a)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.fedorahoste...
> >
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)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.fedorahoste...
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)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.fedorahoste...