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.

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@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@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@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@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@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/VGGBZZJLEZINWOJJTY7WEEQ4LVGVFZ2N/
_______________________________________________
sssd-users mailing list -- sssd-users@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/2VXDFTQ7LU63YIIPBOCRD4KS2VKEJVOU/