I attempted this. Logged in as my user, saw that the defaults were being
applied. Logged out, expired the cache, and logged back in with the same
non-defined shell and GECOS field.
FYI: the user being logged in is an AD user from an AD one-way trust with the
IPA domain.
David Eddleman
On 8/29/17, 10:56 AM, "Sumit Bose via FreeIPA-users"
<freeipa-users@lists.fedorahosted.org> wrote:
On Tue, Aug 29, 2017 at 06:11:43PM +0300, Alexander Bokovoy wrote:
> On ti, 29 elo 2017, Sumit Bose via FreeIPA-users wrote:
> > On Tue, Aug 29, 2017 at 05:00:06PM +0300, Alexander Bokovoy via
FreeIPA-users wrote:
> > > On ma, 28 elo 2017, Eddleman, David via FreeIPA-users wrote:
> > > > So I've created a ID override on the IPA master called
"TestShellView"
> > > > to test out changing per-user requirements for shells.
> > > >
> > > > Verify the ID override on the master:
> > > > [root@ipamaster01 ~]# ipa idoverrideuser-find TestShellView
> > > > --------------------------
> > > > 1 User ID override matched
> > > > --------------------------
> > > > Anchor to override: user@domain
> > > > GECOS: TEST ID VIEW
> > > > Login shell: /bin/ksh
> > > > ----------------------------
> > > > Number of entries returned 1
> > > > ----------------------------
> > > >
> > > > Good, looks as expected. I also tested the GECOS override just in
case such a thing was needed in the future.
> > > >
> > > > [root@rhel7template ~]# getent passwd user@domain
> > > > user@domain:*:689709720:689709720:TEST ID
VIEW:/home/domain/user:/bin/ksh
> > > >
> > > > Looks good. It's doing what it's supposed to be doing.
> > > > So now we remove the GECOS and shell settings in the webUI and
verify via CLI that they're gone:
> > > >
> > > > [root@ipamaster01 ~]# ipa idoverrideuser-find TestShellView
> > > > --------------------------
> > > > 1 User ID override matched
> > > > --------------------------
> > > > Anchor to override: user@domain
> > > > ----------------------------
> > > > Number of entries returned 1
> > > > ----------------------------
> > > >
> > > > Still good so far. No overrides defined.
> > > >
> > > > Clear the cache to verify that the data is fresh.
> > > >
> > > > [root@rhel7template ~]# sss_cache -E
> > > > [root@rhel7template ~]# getent passwd user@domain
> > > > user@domain:*:689709720:689709720:TEST ID
VIEW:/home/domain/user:/bin/ksh
> > > >
> > > > That's not right...
> > > > The default and fallback don't call for ksh either:
> > > >
> > > > [root@rhel7template ~]# cat /etc/sssd/sssd.conf | grep shell
> > > > allowed_shells = /bin/bash,/bin/sh,/bin/ksh
> > > > shell_fallback = /sbin/nologin
> > > > default_shell = /bin/bash
> > > >
> > > > So let's try purging the cache files...
> > > > [root@rhel7template ~]# cd /var/lib/sss/db/
> > > > [root@rhel7template db]# ls
> > > > <cache file listing>
> > > > [root@rhel7template db]# rm -f *
> > > > [root@rhel7template db]# ls
> > > > [root@rhel7template db]# service sssd restart
> > > > Redirecting to /bin/systemctl restart sssd.service
> > > > [root@rhel7template db]# getent passwd user@domain
> > > >
user@domain:*:689709720:689709720:Username:/home/domain/user:/bin/bash
> > > >
> > > > Now it's showing what it's supposed to.
> > > >
> > > > This shouldn't be happening. If we have to purge sss cache files
each
> > > > time we make an ID Override change, this won't work. Is this
expected
> > > > behavior, or is this a bug?
> > > You should not need to expire SSSD cache. However, it is by design
that
> > > ID overrides only change with SSSD restart. The reason for that is
> > > because in POSIX environment one cannot change already running
processes
> > > where UID/GID set by the kernel at session login time. Changing SSSD's
> > > view of the ID View/overrides on the fly also means inconsistence of
the
> > > access controls for file systems. SSSD does read and refresh ID view
> > > which applies to the specific host on its startup so a restart is
> > > enough.
> >
> > Yes, but this is only for a complete change of the view e.g. from viewA
> > to viewB. Individual changes in the user overrides of the current view
> > should be made available if the cached entry expires. There is of course
> > the risk to change the UID or GID at runtime of a single user. But on
> > the other hand changing e.g. the default shell of a user would be
> > cumbersome.
> Yes. I think we should not conflate multiple things into one "yes/no"
> answer, though. Below is my attempt to have a simple explanation, let me
> know if this is right or wrong from the SSSD point of view:
>
> Changing which ID view is applied to the host requires SSSD restart.
>
> Changing user properties within ID view is applied when user information
> is expired in SSSD cache. In practice, an easiest way to apply that is
> by doing a new user session because on authentication SSSD does refresh
> user's information. Another way is to use sss_cache utility for an
> individual user (sss_cache -u username).
>
> These are two simple rules right now.
Yes, this is my understanding about SSSD should behave as well.
bye,
Sumit
>
> --
> / Alexander Bokovoy
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
