... 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 <[email protected]> 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 <[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] >
_______________________________________________ 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]
