You could add a SSSD domain using the "files" provider for local account
resolution and use files (maybe?) or even LDAP or Kerberos auth for those
accounts.
I've implemented files+kerberos configurations for similar use cases. Works
well. A relatively current version of the daemon is required to use the
files provider. Man the sssd.conf for insight to its availability on your
systems.
Since you're introducing change I would recommend you use remote auth even
if you resolve users locally.
-- lawrence
On Thu, Mar 19, 2020, 8:34 AM Thomas Harrison <pjcp64(a)gmail.com> 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.
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(a)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(a)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(a)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/...
> > > > >
> > > > >
> > > > > 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(a)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(a)gmail.com>
> wrote:
> > > > >>
> > > > >>> And wanting to learn all I can about sssd.
> > > > >>>
> > > > >> _______________________________________________
> > > > >> 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://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.fedorahoste...
> > > > >>
> > > > > _______________________________________________
> > > > > 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://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.fedorahoste...
> > > > >
> > >
> > > > _______________________________________________
> > > > 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://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.fedorahoste...
> > > _______________________________________________
> > > 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://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.fedorahoste...
> > >
>
> > _______________________________________________
> > 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://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.fedorahoste...
> _______________________________________________
> 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://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.fedorahoste...
>
On Thu, Mar 19, 2020, 06:40 Sumit Bose <sbose(a)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(a)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(a)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/...
> > > > >
> > > > >
> > > > > 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(a)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(a)gmail.com>
> wrote:
> > > > >>
> > > > >>> And wanting to learn all I can about sssd.
> > > > >>>
> > > > >> _______________________________________________
> > > > >> 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://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.fedorahoste...
> > > > >>
> > > > > _______________________________________________
> > > > > 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://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.fedorahoste...
> > > > >
> > >
> > > > _______________________________________________
> > > > 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://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.fedorahoste...
> > > _______________________________________________
> > > 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://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.fedorahoste...
> > >
>
> > _______________________________________________
> > 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://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.fedorahoste...
> _______________________________________________
> 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://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.fedorahoste...
>
_______________________________________________
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://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.fedorahoste...