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.
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