... agreed, filtering either by SSSD directive or with search base or even search base + attributes are great options for most use cases.

... but to be clear my suggestion was to use the "files" provider, not the deprecated "local" provider.


-- lawrence 

On Thu, Mar 19, 2020, 8:50 AM Sumit Bose <sbose@redhat.com> wrote:
On Thu, Mar 19, 2020 at 07:34:18AM -0500, Thomas Harrison wrote:
> What I'm trying to avoid is the creation of the App ID with the wrong UID
> and GID.  If I can define it locally ( ie. /etc/passwd ) then the local
> values over-ride the AD values.  Also trying to do it without POSIX
> attributes because InfoSec has been slow there.
> I believe I can stop SSSD and add the local ID but ran across the
> sss_useradd command along w other sss_* commands.  I need to setup a
> [domain/local] stanza in sssd.conf though.

Hi,

please don't do this, the local provider is deprecated. I think it would
be better to filter out the unwanted users from AD. You can do this by
tuning the 'ldap_user_search_base' option (see man sssd-ldap for
details). If dedicated OUs are used in AD to store the "real" users and
the App IDs and other unwanted users you can just list the "wanted" OUs
with the option. If they are mixed in a single or multiple OUs you have
to look for an LDAP attribute which can be used to separate them and use
this in a filter.

HTH

bye,
Sumit

> Us, Im unsure of removing /var/lib/sss/db/* and mc/* would wioe out any
> settings if not defined in /etc/passwd.
>
> On Thu, Mar 19, 2020, 06:40 Sumit Bose <sbose@redhat.com> wrote:
>
> > On Thu, Mar 19, 2020 at 06:13:38AM -0500, Thomas Harrison wrote:
> > > Certainly at first.  Phase 1 is to replace Quest for the cost saving with
> > > as little change to the overall function as possible.  Since pbly mapfile
> > > users authenticate via AD in Quest, only those IDs are being "realm
> > > permitted" at this time.
> >
> > Hi,
> >
> > ok, so assuming user joe is allowed and expected to log in. What you
> > want to avoid is that user joe calls 'su - App_ID', enters the App_ID
> > password stored in AD and then can run commands as App_ID user?
> >
> > bye,
> > Sumit
> >
> > >
> > > On Thu, Mar 19, 2020, 04:53 Sumit Bose <sbose@redhat.com> wrote:
> > >
> > > > On Wed, Mar 18, 2020 at 10:13:51PM -0500, Thomas Harrison wrote:
> > > > > Wow Spike! You're faster and better than the support we pay for!  8)
> > > > >
> > > > > Summary.
> > > > > RHEL 6 and 7.  Plus AWS.
> > > > > I already wrote the scripts to convert user IDs to match. ( our
> > > > > /etc/opt/quest/vas/mapfile had jdoe  mapped to jdoeXX
> > > > > We are limiting for the most part, the above conversion to only
> > entries
> > > > in
> > > > > the mapfile.  This would exclude App IDs, and Slervice Account IDs.
> > > >
> > > > Hi,
> > > >
> > > > do I understand correctly that you want that SSSD only handled "real"
> > > > users from AD and ignores all other accounts like App IDs?
> > > >
> > > > bye,
> > > > Sumit
> > > >
> > > > >
> > > > > Unfortunately, the scenario I've run across, is that I only limit the
> > > > users
> > > > > and not the Service Accounts to login via *realm permit* and
> > > > inappropriate
> > > > > *su - App_ID" can create it if *getent passwd App_ID* works.  I've
> > tried
> > > > > encouraging that local accounts not have AD names, but that seems to
> > have
> > > > > fallen on deaf ears.
> > > > >
> > > > > I would like to create these IDs locally with UID:GID etc... that I
> > > > specify
> > > > > but I'm having issues when SSSD is running.  It appears that setting
> > up a
> > > > > [domain/local] might be the key, along with sss_useradd?  But I would
> > > > like
> > > > > the ID to be created in /etc/passwd as well if possible.  We are
> > > > discussing
> > > > > a 2500 Linux Server environment.
> > > > >
> > > > > Thanks!
> > > > >
> > > > > Thom
> > > > >
> > > > > On Wed, Mar 18, 2020 at 10:01 PM Spike White <spikewhitetx@gmail.com
> > >
> > > > wrote:
> > > > >
> > > > > > Thomas,
> > > > > >
> > > > > > Greetings!  I work at a company that is now far along in
> > transitioning
> > > > > > from Quest to sssd.   We have a fairly complex AD forest, with
> > multiple
> > > > > > older Linux OS versions we support.
> > > > > >
> > > > > > An excellent place to start is here:
> > > > > >
> > > > > >
> > > > > >
> > > >
> > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/windows_integration_guide/index
> > > > > >
> > > > > >
> > > > > > Focus on the "direct integration" section.
> > > > > >
> > > > > > How simple or difficult your migration journey is -- depends on two
> > > > things:
> > > > > >     1. How complex your AD forest is (multiple trusted subdomains?
> > > > > > Extensive use of GC and universal groups?  Or a simple flat
> > one-domain
> > > > > > forest?)
> > > > > >     2. How far back in Linux OS versions do you wish to support?
> > > > > >
> > > > > > If you have a simple flat forest and if you don't have to support
> > > > anything
> > > > > > earlier than RHEL7, the conversion should be relatively easy.
> > > > > >
> > > > > > With some effort, you can support cross-domain authentication with
> > > > RHEL6
> > > > > > as well.  RHEL5?  Forget about it!
> > > > > >
> > > > > > BTW, I'm quite familiar with the VAS commands and what are the sssd
> > > > > > analogs.  (About 99% of what we did in VAS, we have figured out
> > how to
> > > > do
> > > > > > in sssd.)
> > > > > >
> > > > > > About your specific question.  There's multiple answers, depending
> > on
> > > > what
> > > > > > you want to do.
> > > > > >
> > > > > > 1. You can define "files" first in /etc/nsswitch.conf before
> > "sss".  It
> > > > > > will find your local /etc/passwd entry first, instead of your AD
> > entry.
> > > > > > That masks your AD entry.
> > > > > >
> > > > > > 2. However, if there's just some item of that AD entry you wish to
> > > > > > override locally (like the login name or UID), but you otherwise
> > wish
> > > > to
> > > > > > use the AD entry -- then you would run the "sss_override" command
> > to
> > > > > > locally override the specified item of that AD entry.
> > > > > >
> > > > > > Spike
> > > > > >
> > > > > >
> > > > > > On Wed, Mar 18, 2020 at 9:38 PM Thomas Harrison <pjcp64@gmail.com>
> > > > wrote:
> > > > > >
> > > > > >> You'd like a specific question... So here it is.  How do I create
> > a
> > > > local
> > > > > >> user ( /etc/passwd ) so I can define UID,GID, gecos, shell ) when
> > it
> > > > > >> already exists in a getent lookup?
> > > > > >>
> > > > > >> On Wed, Mar 18, 2020, 21:32 Thomas Harrison <pjcp64@gmail.com>
> > wrote:
> > > > > >>
> > > > > >>> And wanting to learn all I can about sssd.
> > > > > >>>
> > > > > >> _______________________________________________
> > > > > >> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > > > >> List Guidelines:
> > > > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > > >> List Archives:
> > > > > >>
> > > >
> > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> > > > > >>
> > > > > > _______________________________________________
> > > > > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > > > > List Guidelines:
> > > > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > > > List Archives:
> > > > > >
> > > >
> > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> > > > > >
> > > >
> > > > > _______________________________________________
> > > > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > > > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > > List Archives:
> > > >
> > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> > > > _______________________________________________
> > > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > List Archives:
> > > >
> > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> > > >
> >
> > > _______________________________________________
> > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> > _______________________________________________
> > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> >
>
> On Thu, Mar 19, 2020, 06:40 Sumit Bose <sbose@redhat.com> wrote:
>
> > On Thu, Mar 19, 2020 at 06:13:38AM -0500, Thomas Harrison wrote:
> > > Certainly at first.  Phase 1 is to replace Quest for the cost saving with
> > > as little change to the overall function as possible.  Since pbly mapfile
> > > users authenticate via AD in Quest, only those IDs are being "realm
> > > permitted" at this time.
> >
> > Hi,
> >
> > ok, so assuming user joe is allowed and expected to log in. What you
> > want to avoid is that user joe calls 'su - App_ID', enters the App_ID
> > password stored in AD and then can run commands as App_ID user?
> >
> > bye,
> > Sumit
> >
> > >
> > > On Thu, Mar 19, 2020, 04:53 Sumit Bose <sbose@redhat.com> wrote:
> > >
> > > > On Wed, Mar 18, 2020 at 10:13:51PM -0500, Thomas Harrison wrote:
> > > > > Wow Spike! You're faster and better than the support we pay for!  8)
> > > > >
> > > > > Summary.
> > > > > RHEL 6 and 7.  Plus AWS.
> > > > > I already wrote the scripts to convert user IDs to match. ( our
> > > > > /etc/opt/quest/vas/mapfile had jdoe  mapped to jdoeXX
> > > > > We are limiting for the most part, the above conversion to only
> > entries
> > > > in
> > > > > the mapfile.  This would exclude App IDs, and Slervice Account IDs.
> > > >
> > > > Hi,
> > > >
> > > > do I understand correctly that you want that SSSD only handled "real"
> > > > users from AD and ignores all other accounts like App IDs?
> > > >
> > > > bye,
> > > > Sumit
> > > >
> > > > >
> > > > > Unfortunately, the scenario I've run across, is that I only limit the
> > > > users
> > > > > and not the Service Accounts to login via *realm permit* and
> > > > inappropriate
> > > > > *su - App_ID" can create it if *getent passwd App_ID* works.  I've
> > tried
> > > > > encouraging that local accounts not have AD names, but that seems to
> > have
> > > > > fallen on deaf ears.
> > > > >
> > > > > I would like to create these IDs locally with UID:GID etc... that I
> > > > specify
> > > > > but I'm having issues when SSSD is running.  It appears that setting
> > up a
> > > > > [domain/local] might be the key, along with sss_useradd?  But I would
> > > > like
> > > > > the ID to be created in /etc/passwd as well if possible.  We are
> > > > discussing
> > > > > a 2500 Linux Server environment.
> > > > >
> > > > > Thanks!
> > > > >
> > > > > Thom
> > > > >
> > > > > On Wed, Mar 18, 2020 at 10:01 PM Spike White <spikewhitetx@gmail.com
> > >
> > > > wrote:
> > > > >
> > > > > > Thomas,
> > > > > >
> > > > > > Greetings!  I work at a company that is now far along in
> > transitioning
> > > > > > from Quest to sssd.   We have a fairly complex AD forest, with
> > multiple
> > > > > > older Linux OS versions we support.
> > > > > >
> > > > > > An excellent place to start is here:
> > > > > >
> > > > > >
> > > > > >
> > > >
> > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/windows_integration_guide/index
> > > > > >
> > > > > >
> > > > > > Focus on the "direct integration" section.
> > > > > >
> > > > > > How simple or difficult your migration journey is -- depends on two
> > > > things:
> > > > > >     1. How complex your AD forest is (multiple trusted subdomains?
> > > > > > Extensive use of GC and universal groups?  Or a simple flat
> > one-domain
> > > > > > forest?)
> > > > > >     2. How far back in Linux OS versions do you wish to support?
> > > > > >
> > > > > > If you have a simple flat forest and if you don't have to support
> > > > anything
> > > > > > earlier than RHEL7, the conversion should be relatively easy.
> > > > > >
> > > > > > With some effort, you can support cross-domain authentication with
> > > > RHEL6
> > > > > > as well.  RHEL5?  Forget about it!
> > > > > >
> > > > > > BTW, I'm quite familiar with the VAS commands and what are the sssd
> > > > > > analogs.  (About 99% of what we did in VAS, we have figured out
> > how to
> > > > do
> > > > > > in sssd.)
> > > > > >
> > > > > > About your specific question.  There's multiple answers, depending
> > on
> > > > what
> > > > > > you want to do.
> > > > > >
> > > > > > 1. You can define "files" first in /etc/nsswitch.conf before
> > "sss".  It
> > > > > > will find your local /etc/passwd entry first, instead of your AD
> > entry.
> > > > > > That masks your AD entry.
> > > > > >
> > > > > > 2. However, if there's just some item of that AD entry you wish to
> > > > > > override locally (like the login name or UID), but you otherwise
> > wish
> > > > to
> > > > > > use the AD entry -- then you would run the "sss_override" command
> > to
> > > > > > locally override the specified item of that AD entry.
> > > > > >
> > > > > > Spike
> > > > > >
> > > > > >
> > > > > > On Wed, Mar 18, 2020 at 9:38 PM Thomas Harrison <pjcp64@gmail.com>
> > > > wrote:
> > > > > >
> > > > > >> You'd like a specific question... So here it is.  How do I create
> > a
> > > > local
> > > > > >> user ( /etc/passwd ) so I can define UID,GID, gecos, shell ) when
> > it
> > > > > >> already exists in a getent lookup?
> > > > > >>
> > > > > >> On Wed, Mar 18, 2020, 21:32 Thomas Harrison <pjcp64@gmail.com>
> > wrote:
> > > > > >>
> > > > > >>> And wanting to learn all I can about sssd.
> > > > > >>>
> > > > > >> _______________________________________________
> > > > > >> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > > > >> List Guidelines:
> > > > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > > >> List Archives:
> > > > > >>
> > > >
> > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> > > > > >>
> > > > > > _______________________________________________
> > > > > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > > > > List Guidelines:
> > > > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > > > List Archives:
> > > > > >
> > > >
> > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> > > > > >
> > > >
> > > > > _______________________________________________
> > > > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > > > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > > List Archives:
> > > >
> > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> > > > _______________________________________________
> > > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > List Archives:
> > > >
> > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> > > >
> >
> > > _______________________________________________
> > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> > _______________________________________________
> > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> >

> _______________________________________________
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
_______________________________________________
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org