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]
