Sumit, thankyou.
I should say why the sss_override is being run here.
We have around 100 users in a local /etc/passwd file
Those users are also in AD and we would like to exploit AD more, in terms
of gorup memberships etc. Thats why we use sssd
The nsswitch is set to files sss
If sss_override is NOT used to create an override for a user, getent
passwd userxyz returns:
userxyz:*:localuid:localgid
And also the user can log in, do stuff etc etc.
However at login time kinit is run to get a Kerberos ticket. It turns out
that the ticket file $KRB5CCNAME is generated using the Active Directory
uid/gid
(ie the ones generated from the SID)
If you do an ls on this Kerberos ticket file it returns that it is owned
by userxyz
But if you stat the file the uid is longaduserid not localuid
I hope this makes sense.
Yes, this is basically the use case the overrides were added for, making
migration from one source (/etc/passwd) to another (AD) more easy.
bye,
Sumit
I therefore want to make sure that the sss_overrides is run when the
system
boots up.
Also there is the case of having the /var/lib/sss/db on a tmpfs for
performance (we dont do that)
Again sss_override would have to be run at boot time.
Sorry for the long response. I hope this helps someone in furture.
In short - kinit is run early int h login sequence, and you get the wrong
ownership on the Kerberos ticket file if you do not run sss_override
in the case where there are locally defined users in the passwd fie.
On 4 July 2018 at 14:43, Sumit Bose <sbose(a)redhat.com> wrote:
> On Wed, Jul 04, 2018 at 09:06:50AM +0200, John Hearns wrote:
> > Sumit, thankyou.
> > What I have done is to write a Python script which loops over all local
> > users.
> > The script calls sss_override user-set for each user. Then the script
> runs
> > user-export to create a file as you suggest.
> >
> > I have edited the sssd.service unit file, and placed the changed copy in
> > /etc/systemd/system/sssd.service
> > This has an added Post Start action to read in the file using
> user-import.
> > These are the lines I added:
> >
> >
> > ExecStartPost=-/usr/sbin/sss_override user-import /etc/sssd/overrides
> > TimeoutStartSec=180
>
> ok, this should do no harm, but as said, as long as the cache file is on
> a disk and is not removed during reboots or on other circumstances this
> should not be needed.
>
> bye,
> Sumit
>
> >
> >
> >
> >
> > On 4 July 2018 at 08:41, Sumit Bose <sbose(a)redhat.com> wrote:
> >
> > > On Thu, Jun 14, 2018 at 02:33:22PM +0200, John Hearns wrote:
> > > > We have an existing set of users in a local passwd file
> > > > I want to run sss_override to create mappings from the AD SID
> numbers to
> > > > the existing uid numbers.
> > > >
> > > > What is the concensus on running sss_override?
> > > > I can script it to either parse through the existing passwd file and
> make
> > > > an override entry per user,
> > > > or to parse the file and create an import file which is run once
with
> > > > import-user
> > > >
> > > > But when is a good time to run this?
> > > >
> > > > In a daily cron job
> > > >
> > > > When sssd is started, which would involve editing the systemd unit
> file
> > > >
> > > > Creating a new systemd service which depends on sssd.service . This
> > > service
> > > > runs sss_override and then restarts sssd.service
> > > >
> > > > Or am I misunderstanding something?
> > > >
> > > > I am assuming here we have on-disk sssd databases. If the databases
> are
> > > on
> > > > a tmpfs then clearly the sss_override must be run at boot time by
> one of
> > > > the above methods also.
> > >
> > > As long as the cache file in /var/lib/sss/db is not removed it should
> be
> > > sufficient to run sss_override for each user once and then the override
> > > data should stay in the cache.
> > >
> > > I once got a report that the link between the original user data and
> the
> > > override data got lost, but I wasn't able to reproduce this so far.
> > >
> > > It is always a good idea to call user-export/group-export to have a
> > > backup file around.
> > >
> > > HTH
> > >
> > > bye,
> > > Sumit
> > >
> > >
> > > > _______________________________________________
> > > > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> > > > To unsubscribe send an email to sssd-users-leave@lists.
>
fedorahosted.org
> > > > Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> > > > List Guidelines:
https://fedoraproject.org/
> wiki/Mailing_list_guidelines
> > > > List Archives:
https://lists.fedoraproject.
> org/archives/list/sssd-users@
> > >
lists.fedorahosted.org/message/TMGIPZGSONS6Q62RGKFBI5EDZ7GPCEUU/
> > > _______________________________________________
> > > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> > > To unsubscribe send an email to sssd-users-leave@lists.
>
fedorahosted.org
> > > Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> > > List Guidelines:
https://fedoraproject.org/
> wiki/Mailing_list_guidelines
> > > List Archives:
https://lists.fedoraproject.
> org/archives/list/sssd-users@
> > >
lists.fedorahosted.org/message/R3L7BBZGZ5URRV7VYSBIUMRSKVZRYIMJ/
> > >
>
> > _______________________________________________
> > 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://getfedora.org/code-of-conduct.html
> > List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
https://lists.fedoraproject.org/archives/list/sssd-users@
>
lists.fedorahosted.org/message/VGGBZZJLEZINWOJJTY7WEEQ4LVGVFZ2N/
> _______________________________________________
> 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://getfedora.org/code-of-conduct.html
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/sssd-users@
>
lists.fedorahosted.org/message/2VXDFTQ7LU63YIIPBOCRD4KS2VKEJVOU/
>
_______________________________________________
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://getfedora.org/code-of-conduct.html
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahost...