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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 < >> [email protected]> >> > > 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 <[email protected] >> > >> > > 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 <[email protected]> >> wrote: >> > > > >> >> > > > >>> And wanting to learn all I can about sssd. >> > > > >>> >> > > > >> _______________________________________________ >> > > > >> sssd-users mailing list -- [email protected] >> > > > >> To unsubscribe send an email to >> > > [email protected] >> > > > >> 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/[email protected] >> > > > >> >> > > > > _______________________________________________ >> > > > > sssd-users mailing list -- [email protected] >> > > > > To unsubscribe send an email to >> > > [email protected] >> > > > > 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/[email protected] >> > > > > >> > > >> > > > _______________________________________________ >> > > > sssd-users mailing list -- [email protected] >> > > > To unsubscribe send an email to >> [email protected] >> > > > 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/[email protected] >> > > _______________________________________________ >> > > sssd-users mailing list -- [email protected] >> > > To unsubscribe send an email to >> [email protected] >> > > 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/[email protected] >> > > >> >> > _______________________________________________ >> > sssd-users mailing list -- [email protected] >> > To unsubscribe send an email to [email protected] >> > 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/[email protected] >> _______________________________________________ >> sssd-users mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> 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/[email protected] >> > > On Thu, Mar 19, 2020, 06:40 Sumit Bose <[email protected]> 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 <[email protected]> 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 < >> [email protected]> >> > > 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 <[email protected] >> > >> > > 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 <[email protected]> >> wrote: >> > > > >> >> > > > >>> And wanting to learn all I can about sssd. >> > > > >>> >> > > > >> _______________________________________________ >> > > > >> sssd-users mailing list -- [email protected] >> > > > >> To unsubscribe send an email to >> > > [email protected] >> > > > >> 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/[email protected] >> > > > >> >> > > > > _______________________________________________ >> > > > > sssd-users mailing list -- [email protected] >> > > > > To unsubscribe send an email to >> > > [email protected] >> > > > > 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/[email protected] >> > > > > >> > > >> > > > _______________________________________________ >> > > > sssd-users mailing list -- [email protected] >> > > > To unsubscribe send an email to >> [email protected] >> > > > 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/[email protected] >> > > _______________________________________________ >> > > sssd-users mailing list -- [email protected] >> > > To unsubscribe send an email to >> [email protected] >> > > 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/[email protected] >> > > >> >> > _______________________________________________ >> > sssd-users mailing list -- [email protected] >> > To unsubscribe send an email to [email protected] >> > 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/[email protected] >> _______________________________________________ >> sssd-users mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> 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/[email protected] >> > _______________________________________________ > sssd-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] >
_______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
