On Wed, Jul 01, 2015 at 10:12:54AM +0200, Jakub Hrozek wrote:
> On Tue, Jun 30, 2015 at 08:16:05PM +0000, Andy Thompson wrote:
> > > > >>>>
> > > > >>>>On Fri, May 15, 2015 at 09:44:31PM +0200, Lukas Slebodnik wrote:
> > > > >>>>>On (15/05/15 17:27), Andy Thompson wrote:
> > > > >>>>>>Is there a way to enforce case sensitivity for trusted AD users?
> > > > >>>>>>I am
> > > > >>>>>trying to use username for ssh chroots and I can authenticated
> > > > >>>>>with any case combination of <UsERname> but if ssh is set to
> > > > >>>>>match on <username> then the chroot is not enforced and the user
> > > > >>>>>is dropped to their usual home directory.  I found a
> > > > >>>>>case_sensitive option for sssd but it
> > > > >>>>does not
> > > > >>>>>seem to have any affect.   Running RHEL6.6 clients.
> > > > >>>>>IPA domain is by default case sensitive.
> > > > >>>>>So You will not change anything if you put "case_sensitive = true"
> > > > >>>>>into domain section of sssd.conf.
> > > > >>>>>
> > > > >>>>>But SSSD will create subdomains for each AD domain. It is
> > > > >>>>>different id_provider therefore different default values are used
> > > > >>>>>for subdomains and for AD provider it is case *insensitive* by
> > > default.
> > > > >>>>>
> > > > >>>>>Currently there's no way how to change it for subdomains (AD
> > > > >>>>>trusted
> > > > >>>>>domains)
> > > > >>>>>
> > > > >>>>What are you using for the SSH matching? The way the case
> > > > >>>>insensitiveness is implemented in SSSD is that all usernames are
> > > > >>>>forcibly lowercased on output, so as long as SSH uses the standard
> > > > >>>>NSS calls, you should be good with using the lowecase usernames..
> > > > >>>>
> > > > >>>They were initially all in lower case and working  when I tested
> > > > >>>and finalized
> > > > >>the setup.  I passed the credentials off and they used mixed case
> > > > >>and the match stopped working.
> > > > >>
> > > > >>What is "they" ? I guess not SSSD but grabbing the data directly from
> > > LDAP?
> > > > >The match clauses in the sshd config were set to use lower case names. 
> > > > > It
> > > is using sssd, just a regular ipa client installation.  If I logged in 
> > > using
> > > USERName insetad of username, the match clause did not work.
> > > > >
> > > > >-andy
> > > > >
> > > > Do we have any follow up on this thread? Have we closed the loop and
> > > > filed a ticket.
> > > > I had couple complains of the similar matter during Red Hat Summit.
> > > > I seems that this is one of the emerging issues for the trust 
> > > > environments.
> > > 
> > > I wonder if it's still an issue with 1.12.x and the Kerberos plugin Sumit 
> > > wrote.
> > > Do we have a way to track these requests?
> > > 
> > > Andy, if you have some test machines, could you give 6.7 a try?
> > > 
> > 
> > The usernames from AD are still not case sensitive on 6.7 so a
> > 
> > Match User Testuser
> > 
> > Stanza in the ssh config is not matched if they login as
> > 
> > testuser
> > 
> > but does match if they login with 
> > 
> > Testuser
> 
> Thanks for the reply. Then I guess sshd doesn't canonicalize the
> username with getpwnam(). But I admit I don't know exactly what sshd
> does, so I hope other developers would chime in here..

iirc sshd does call getpwnam() with the name given at the login prompt
to determine if the user exists at all and its home-directory, shell,
UID and GID which is needed later on. But it does not expect that the
name gets canonicalized and continues to use the name given at the login
prompt.

I wonder if it would be possible to use group names in the Match clause
in your setup? Since sshd must call getgroups() and getgrgid() to get
this information here the lower-case group name returned by SSSD should
work.

bye,
Sumit
> 
> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to