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(a)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(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org