[Freeipa-users] username case sensitivity

[Andy Thompson]

> 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.
> 

Yes since the groups are retrievable with the new sssd without requiring the user to login any longer, that will work in my use case now.  The only reason I ran into the case issue what that I can't use groups on 1.11.x since groups aren't available until a first login.

-andy