sss_override - when to run it?

[John Hearns]

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.

[Sumit Bose]

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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]....

[John Hearns]

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

On 4 July 2018 at 08:41, Sumit Bose  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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/

[Sumit Bose]

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  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 -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> > > 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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]....

[John Hearns]

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  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  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 -- [e-mail]
> > > > 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 -- [e-mail]
> > > 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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/

[Sumit Bose]

On Thu, Jul 05, 2018 at 09:21:06AM +0200, John Hearns wrote:
> 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  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  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 -- [e-mail]
> > > > > 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 -- [e-mail]
> > > > 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 -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> > > 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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]....