[SSSD-users] Re: Migrating from Quest...
... 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 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 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 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 < > spikewhit...@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
[SSSD-users] Re: Migrating from Quest...
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 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 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 > > > > > > 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
[SSSD-users] Re: Migrating from Quest...
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 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 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 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 < >> spikewhit...@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.) >> > > > > >> > > > >
[SSSD-users] Re: Migrating from Quest...
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 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 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 > > > > 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
[SSSD-users] Re: Migrating from Quest...
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 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 > > 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 > > 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 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-le...@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: > > > >> > >
[SSSD-users] Re: Migrating from Quest...
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. On Thu, Mar 19, 2020, 04:53 Sumit Bose 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 > 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 > 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 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-le...@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-le...@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] Re: SSSD and PKI: capability of checking trust/validation/revocation
On Wed, Mar 18, 2020 at 10:42:52AM -, Hristina Marosevic wrote: > > On Tue, Mar 17, 2020 at 02:17:06PM -, Hristina Marosevic wrote: > > > > Hi, > > > > about 'certificate_verification = no_verification', there is an issue > > which was fixed by > > https://pagure.io/SSSD/sssd/c/31ebf912d6426aea446b2bdae919d4e33b0c95be > > but the fix is not in the build you are using. So better continue with > > 'certificate_verification = no_ocsp'. > > > > > > Please add all CA certificates to the NSS database /etc/pki/nssdb with > > the help of the certutil command: > > > > certutil -A -n "CA cert nickname" -t C,C,C -i /path/to/CA_cert_file -d > > /etc/pki/nssdb > > > > each CA certificate should get an individual nickname. If your > > CA_cert_file is in PEM format (with BEGIN CERTIFICATE and END > > CERTIFICATE lines) you might need to add a '-a' option as well. > > > > If there are still issues please send the strace output. > > > > HTH > > > > bye, > > Sumit > > > Hello, > > I just tried to add the certificates (intermediate and root CA) to the > database and I got the error: "certutil: function failed: > SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, > unsupported format." for each one. Hi, can you send the output of ls -al /etc/pki/nssdb and certutil -L -d /etc/pki/nssdb -h all bye, Sumit > > The confirugation in sssd is still not changed and no other step is executed > due to this error. I think it is important to solve this problem first, and > that this one is not related to the sssd configuration and option > certificate_verification in the config file. > Can you propose me a solution for this? > > > BR, > Hristina > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@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-le...@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] Re: Migrating from Quest...
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 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 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 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-le...@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-le...@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-le...@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] Re: Change primary group
On Thu, 19 Mar 2020, Sumit Bose wrote: Hi, not really. Since you say the primary group is called 'Domain Users' I assume you are using AD. With AD SSSD can derived UIDs and GIDs automatically from the SID of the AD objects with 'ldap_id_mapping = True' (see man sssd-ldap for details. With this users will get private primary groups automatically, but all UIDs and GIDs on your systems will change. The alternative would be to change the primary group for all users in AD. I'm not sure having all users with the same primary group is in itself a security issue. They're free to be in secondary groups too, and if you're allocating permissions on those secondary groups, all is well. The only issue would be if you're writing files out and making them group accessible without thinking about which group that should be. jh ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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] Re: Change primary group
On Thu, Mar 19, 2020 at 08:52:51AM +0100, Jannis Mann wrote: > Hi Sumit, > > I saw that option the moment I've sent this mail. Unfortunately we've a lot > of ubuntu 16.04 and debian 9 machines where 1.16 doesn't run. It is not > planned to upgrade these machines anytime soon. > > Is there another possibility to achieve this? Hi, not really. Since you say the primary group is called 'Domain Users' I assume you are using AD. With AD SSSD can derived UIDs and GIDs automatically from the SID of the AD objects with 'ldap_id_mapping = True' (see man sssd-ldap for details. With this users will get private primary groups automatically, but all UIDs and GIDs on your systems will change. The alternative would be to change the primary group for all users in AD. bye, Sumit > > Thanks :) > > Am Do., 12. März 2020 um 11:19 Uhr schrieb Sumit Bose : > > > On Thu, Mar 12, 2020 at 09:26:49AM +0100, Jannis Mann wrote: > > > Hi, > > > > > > I've sssd running with ldap provider and therefore use a binding account. > > > > > > In general everything works. I've a question regarding the primary group. > > > > > > When I login with any user who I permitted to in the sssd.conf all users > > > have the Domain Users gorup as primary group. > > > > > > So if I create a file with User a ownership is UserA:Domain\ Users > > > Same goes for UserB etc. > > > > > > Can I have influence on the primary group of the sssd users? Because this > > > seems quite insecure for me. Because I use different permissions for > > > different users (configured via sudoers files). But if every user is in > > the > > > same group.. > > > > Hi, > > > > recent versions of SSSD have the option 'auto_private_groups', please > > check the sssd.conf man page if this option is available for your > > version and if yes you can find more details their as well. > > > > If this option is not listed in your man page you can check > > https://mzidek.fedorapeople.org/sssd/2.2.3/man/sssd.conf.5.html if it > > might be worth to upgrade? > > > > HTH > > > > bye, > > Sumit > > > > > > > > Thanks for your input! > > > > > > Jannis > > > > > ___ > > > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > > > To unsubscribe send an email to sssd-users-le...@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-le...@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-le...@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-le...@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] Re: Change primary group
Hi Sumit, I saw that option the moment I've sent this mail. Unfortunately we've a lot of ubuntu 16.04 and debian 9 machines where 1.16 doesn't run. It is not planned to upgrade these machines anytime soon. Is there another possibility to achieve this? Thanks :) Am Do., 12. März 2020 um 11:19 Uhr schrieb Sumit Bose : > On Thu, Mar 12, 2020 at 09:26:49AM +0100, Jannis Mann wrote: > > Hi, > > > > I've sssd running with ldap provider and therefore use a binding account. > > > > In general everything works. I've a question regarding the primary group. > > > > When I login with any user who I permitted to in the sssd.conf all users > > have the Domain Users gorup as primary group. > > > > So if I create a file with User a ownership is UserA:Domain\ Users > > Same goes for UserB etc. > > > > Can I have influence on the primary group of the sssd users? Because this > > seems quite insecure for me. Because I use different permissions for > > different users (configured via sudoers files). But if every user is in > the > > same group.. > > Hi, > > recent versions of SSSD have the option 'auto_private_groups', please > check the sssd.conf man page if this option is available for your > version and if yes you can find more details their as well. > > If this option is not listed in your man page you can check > https://mzidek.fedorapeople.org/sssd/2.2.3/man/sssd.conf.5.html if it > might be worth to upgrade? > > HTH > > bye, > Sumit > > > > > Thanks for your input! > > > > Jannis > > > ___ > > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > > To unsubscribe send an email to sssd-users-le...@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-le...@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-le...@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
