You'd like a specific question... So here it is. How do I create a local user ( /etc/passwd ) so I can define UID,GID, gecos, shell ) when it already exists in a getent lookup?
On Wed, Mar 18, 2020, 21:32 Thomas Harrison pjcp64@gmail.com wrote:
And wanting to learn all I can about sssd.
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/htm...
Focus on the "direct integration" section.
How simple or difficult your migration journey is -- depends on two things: 1. How complex your AD forest is (multiple trusted subdomains? Extensive use of GC and universal groups? Or a simple flat one-domain forest?) 2. How far back in Linux OS versions do you wish to support?
If you have a simple flat forest and if you don't have to support anything earlier than RHEL7, the conversion should be relatively easy.
With some effort, you can support cross-domain authentication with RHEL6 as well. RHEL5? Forget about it!
BTW, I'm quite familiar with the VAS commands and what are the sssd analogs. (About 99% of what we did in VAS, we have figured out how to do in sssd.)
About your specific question. There's multiple answers, depending on what you want to do.
1. You can define "files" first in /etc/nsswitch.conf before "sss". It will find your local /etc/passwd entry first, instead of your AD entry. That masks your AD entry.
2. However, if there's just some item of that AD entry you wish to override locally (like the login name or UID), but you otherwise wish to use the AD entry -- then you would run the "sss_override" command to locally override the specified item of that AD entry.
Spike
On Wed, Mar 18, 2020 at 9:38 PM Thomas Harrison pjcp64@gmail.com wrote:
You'd like a specific question... So here it is. How do I create a local user ( /etc/passwd ) so I can define UID,GID, gecos, shell ) when it already exists in a getent lookup?
On Wed, Mar 18, 2020, 21:32 Thomas Harrison pjcp64@gmail.com 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-leave@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.o...
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.
Unfortunately, the scenario I've run across, is that I only limit the users and not the Service Accounts to login via *realm permit* and inappropriate *su - App_ID" can create it if *getent passwd App_ID* works. I've tried encouraging that local accounts not have AD names, but that seems to have fallen on deaf ears.
I would like to create these IDs locally with UID:GID etc... that I specify but I'm having issues when SSSD is running. It appears that setting up a [domain/local] might be the key, along with sss_useradd? But I would like the ID to be created in /etc/passwd as well if possible. We are discussing a 2500 Linux Server environment.
Thanks!
Thom
On Wed, Mar 18, 2020 at 10:01 PM Spike White spikewhitetx@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/htm...
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.
- 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.
- However, if there's just some item of that AD entry you wish to
override locally (like the login name or UID), but you otherwise wish to use the AD entry -- then you would run the "sss_override" command to locally override the specified item of that AD entry.
Spike
On Wed, Mar 18, 2020 at 9:38 PM Thomas Harrison pjcp64@gmail.com wrote:
You'd like a specific question... So here it is. How do I create a local user ( /etc/passwd ) so I can define UID,GID, gecos, shell ) when it already exists in a getent lookup?
On Wed, Mar 18, 2020, 21:32 Thomas Harrison pjcp64@gmail.com 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-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...
Simple Forest too.
On Wed, Mar 18, 2020 at 10:13 PM Thomas Harrison pjcp64@gmail.com 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.
Unfortunately, the scenario I've run across, is that I only limit the users and not the Service Accounts to login via *realm permit* and inappropriate *su - App_ID" can create it if *getent passwd App_ID* works. I've tried encouraging that local accounts not have AD names, but that seems to have fallen on deaf ears.
I would like to create these IDs locally with UID:GID etc... that I specify but I'm having issues when SSSD is running. It appears that setting up a [domain/local] might be the key, along with sss_useradd? But I would like the ID to be created in /etc/passwd as well if possible. We are discussing a 2500 Linux Server environment.
Thanks!
Thom
On Wed, Mar 18, 2020 at 10:01 PM Spike White spikewhitetx@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/htm...
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.
- 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.
- However, if there's just some item of that AD entry you wish to
override locally (like the login name or UID), but you otherwise wish to use the AD entry -- then you would run the "sss_override" command to locally override the specified item of that AD entry.
Spike
On Wed, Mar 18, 2020 at 9:38 PM Thomas Harrison pjcp64@gmail.com wrote:
You'd like a specific question... So here it is. How do I create a local user ( /etc/passwd ) so I can define UID,GID, gecos, shell ) when it already exists in a getent lookup?
On Wed, Mar 18, 2020, 21:32 Thomas Harrison pjcp64@gmail.com 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-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...
I've successfully converted iur entire nonorod Rhel6 and 7 environment. Its only since its fully out there that this issue has occurred.
On Wed, Mar 18, 2020, 22:29 Thomas Harrison pjcp64@gmail.com wrote:
Simple Forest too.
On Wed, Mar 18, 2020 at 10:13 PM Thomas Harrison pjcp64@gmail.com 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.
Unfortunately, the scenario I've run across, is that I only limit the users and not the Service Accounts to login via *realm permit* and inappropriate *su - App_ID" can create it if *getent passwd App_ID* works. I've tried encouraging that local accounts not have AD names, but that seems to have fallen on deaf ears.
I would like to create these IDs locally with UID:GID etc... that I specify but I'm having issues when SSSD is running. It appears that setting up a [domain/local] might be the key, along with sss_useradd? But I would like the ID to be created in /etc/passwd as well if possible. We are discussing a 2500 Linux Server environment.
Thanks!
Thom
On Wed, Mar 18, 2020 at 10:01 PM Spike White spikewhitetx@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/htm...
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.
- 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.
- However, if there's just some item of that AD entry you wish to
override locally (like the login name or UID), but you otherwise wish to use the AD entry -- then you would run the "sss_override" command to locally override the specified item of that AD entry.
Spike
On Wed, Mar 18, 2020 at 9:38 PM Thomas Harrison pjcp64@gmail.com wrote:
You'd like a specific question... So here it is. How do I create a local user ( /etc/passwd ) so I can define UID,GID, gecos, shell ) when it already exists in a getent lookup?
On Wed, Mar 18, 2020, 21:32 Thomas Harrison pjcp64@gmail.com 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-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...
On Wed, Mar 18, 2020 at 10:13:51PM -0500, Thomas Harrison wrote:
Wow Spike! You're faster and better than the support we pay for! 8)
Summary. RHEL 6 and 7. Plus AWS. I already wrote the scripts to convert user IDs to match. ( our /etc/opt/quest/vas/mapfile had jdoe mapped to jdoeXX We are limiting for the most part, the above conversion to only entries in the mapfile. This would exclude App IDs, and Slervice Account IDs.
Hi,
do I understand correctly that you want that SSSD only handled "real" users from AD and ignores all other accounts like App IDs?
bye, Sumit
Unfortunately, the scenario I've run across, is that I only limit the users and not the Service Accounts to login via *realm permit* and inappropriate *su - App_ID" can create it if *getent passwd App_ID* works. I've tried encouraging that local accounts not have AD names, but that seems to have fallen on deaf ears.
I would like to create these IDs locally with UID:GID etc... that I specify but I'm having issues when SSSD is running. It appears that setting up a [domain/local] might be the key, along with sss_useradd? But I would like the ID to be created in /etc/passwd as well if possible. We are discussing a 2500 Linux Server environment.
Thanks!
Thom
On Wed, Mar 18, 2020 at 10:01 PM Spike White spikewhitetx@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/htm...
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.
- 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.
- However, if there's just some item of that AD entry you wish to
override locally (like the login name or UID), but you otherwise wish to use the AD entry -- then you would run the "sss_override" command to locally override the specified item of that AD entry.
Spike
On Wed, Mar 18, 2020 at 9:38 PM Thomas Harrison pjcp64@gmail.com wrote:
You'd like a specific question... So here it is. How do I create a local user ( /etc/passwd ) so I can define UID,GID, gecos, shell ) when it already exists in a getent lookup?
On Wed, Mar 18, 2020, 21:32 Thomas Harrison pjcp64@gmail.com 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-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...
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 sbose@redhat.com wrote:
On Wed, Mar 18, 2020 at 10:13:51PM -0500, Thomas Harrison wrote:
Wow Spike! You're faster and better than the support we pay for! 8)
Summary. RHEL 6 and 7. Plus AWS. I already wrote the scripts to convert user IDs to match. ( our /etc/opt/quest/vas/mapfile had jdoe mapped to jdoeXX We are limiting for the most part, the above conversion to only entries
in
the mapfile. This would exclude App IDs, and Slervice Account IDs.
Hi,
do I understand correctly that you want that SSSD only handled "real" users from AD and ignores all other accounts like App IDs?
bye, Sumit
Unfortunately, the scenario I've run across, is that I only limit the
users
and not the Service Accounts to login via *realm permit* and
inappropriate
*su - App_ID" can create it if *getent passwd App_ID* works. I've tried encouraging that local accounts not have AD names, but that seems to have fallen on deaf ears.
I would like to create these IDs locally with UID:GID etc... that I
specify
but I'm having issues when SSSD is running. It appears that setting up a [domain/local] might be the key, along with sss_useradd? But I would
like
the ID to be created in /etc/passwd as well if possible. We are
discussing
a 2500 Linux Server environment.
Thanks!
Thom
On Wed, Mar 18, 2020 at 10:01 PM Spike White spikewhitetx@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/htm...
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.
- 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.
- However, if there's just some item of that AD entry you wish to
override locally (like the login name or UID), but you otherwise wish
to
use the AD entry -- then you would run the "sss_override" command to locally override the specified item of that AD entry.
Spike
On Wed, Mar 18, 2020 at 9:38 PM Thomas Harrison pjcp64@gmail.com
wrote:
You'd like a specific question... So here it is. How do I create a
local
user ( /etc/passwd ) so I can define UID,GID, gecos, shell ) when it already exists in a getent lookup?
On Wed, Mar 18, 2020, 21:32 Thomas Harrison pjcp64@gmail.com 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-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o... _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...
On Thu, Mar 19, 2020 at 06:13:38AM -0500, Thomas Harrison wrote:
Certainly at first. Phase 1 is to replace Quest for the cost saving with as little change to the overall function as possible. Since pbly mapfile users authenticate via AD in Quest, only those IDs are being "realm permitted" at this time.
Hi,
ok, so assuming user joe is allowed and expected to log in. What you want to avoid is that user joe calls 'su - App_ID', enters the App_ID password stored in AD and then can run commands as App_ID user?
bye, Sumit
On Thu, Mar 19, 2020, 04:53 Sumit Bose sbose@redhat.com wrote:
On Wed, Mar 18, 2020 at 10:13:51PM -0500, Thomas Harrison wrote:
Wow Spike! You're faster and better than the support we pay for! 8)
Summary. RHEL 6 and 7. Plus AWS. I already wrote the scripts to convert user IDs to match. ( our /etc/opt/quest/vas/mapfile had jdoe mapped to jdoeXX We are limiting for the most part, the above conversion to only entries
in
the mapfile. This would exclude App IDs, and Slervice Account IDs.
Hi,
do I understand correctly that you want that SSSD only handled "real" users from AD and ignores all other accounts like App IDs?
bye, Sumit
Unfortunately, the scenario I've run across, is that I only limit the
users
and not the Service Accounts to login via *realm permit* and
inappropriate
*su - App_ID" can create it if *getent passwd App_ID* works. I've tried encouraging that local accounts not have AD names, but that seems to have fallen on deaf ears.
I would like to create these IDs locally with UID:GID etc... that I
specify
but I'm having issues when SSSD is running. It appears that setting up a [domain/local] might be the key, along with sss_useradd? But I would
like
the ID to be created in /etc/passwd as well if possible. We are
discussing
a 2500 Linux Server environment.
Thanks!
Thom
On Wed, Mar 18, 2020 at 10:01 PM Spike White spikewhitetx@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/htm...
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.
- 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.
- However, if there's just some item of that AD entry you wish to
override locally (like the login name or UID), but you otherwise wish
to
use the AD entry -- then you would run the "sss_override" command to locally override the specified item of that AD entry.
Spike
On Wed, Mar 18, 2020 at 9:38 PM Thomas Harrison pjcp64@gmail.com
wrote:
You'd like a specific question... So here it is. How do I create a
local
user ( /etc/passwd ) so I can define UID,GID, gecos, shell ) when it already exists in a getent lookup?
On Wed, Mar 18, 2020, 21:32 Thomas Harrison pjcp64@gmail.com 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-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o... _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...
What I'm trying to avoid is the creation of the App ID with the wrong UID and GID. If I can define it locally ( ie. /etc/passwd ) then the local values over-ride the AD values. Also trying to do it without POSIX attributes because InfoSec has been slow there. I believe I can stop SSSD and add the local ID but ran across the sss_useradd command along w other sss_* commands. I need to setup a [domain/local] stanza in sssd.conf though. Us, Im unsure of removing /var/lib/sss/db/* and mc/* would wioe out any settings if not defined in /etc/passwd.
On Thu, Mar 19, 2020, 06:40 Sumit Bose sbose@redhat.com wrote:
On Thu, Mar 19, 2020 at 06:13:38AM -0500, Thomas Harrison wrote:
Certainly at first. Phase 1 is to replace Quest for the cost saving with as little change to the overall function as possible. Since pbly mapfile users authenticate via AD in Quest, only those IDs are being "realm permitted" at this time.
Hi,
ok, so assuming user joe is allowed and expected to log in. What you want to avoid is that user joe calls 'su - App_ID', enters the App_ID password stored in AD and then can run commands as App_ID user?
bye, Sumit
On Thu, Mar 19, 2020, 04:53 Sumit Bose sbose@redhat.com wrote:
On Wed, Mar 18, 2020 at 10:13:51PM -0500, Thomas Harrison wrote:
Wow Spike! You're faster and better than the support we pay for! 8)
Summary. RHEL 6 and 7. Plus AWS. I already wrote the scripts to convert user IDs to match. ( our /etc/opt/quest/vas/mapfile had jdoe mapped to jdoeXX We are limiting for the most part, the above conversion to only
entries
in
the mapfile. This would exclude App IDs, and Slervice Account IDs.
Hi,
do I understand correctly that you want that SSSD only handled "real" users from AD and ignores all other accounts like App IDs?
bye, Sumit
Unfortunately, the scenario I've run across, is that I only limit the
users
and not the Service Accounts to login via *realm permit* and
inappropriate
*su - App_ID" can create it if *getent passwd App_ID* works. I've
tried
encouraging that local accounts not have AD names, but that seems to
have
fallen on deaf ears.
I would like to create these IDs locally with UID:GID etc... that I
specify
but I'm having issues when SSSD is running. It appears that setting
up a
[domain/local] might be the key, along with sss_useradd? But I would
like
the ID to be created in /etc/passwd as well if possible. We are
discussing
a 2500 Linux Server environment.
Thanks!
Thom
On Wed, Mar 18, 2020 at 10:01 PM Spike White <spikewhitetx@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/htm...
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.
- 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.
- However, if there's just some item of that AD entry you wish to
override locally (like the login name or UID), but you otherwise
wish
to
use the AD entry -- then you would run the "sss_override" command
to
locally override the specified item of that AD entry.
Spike
On Wed, Mar 18, 2020 at 9:38 PM Thomas Harrison pjcp64@gmail.com
wrote:
You'd like a specific question... So here it is. How do I create
a
local
user ( /etc/passwd ) so I can define UID,GID, gecos, shell ) when
it
already exists in a getent lookup?
On Wed, Mar 18, 2020, 21:32 Thomas Harrison pjcp64@gmail.com
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-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o... _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...
On Thu, Mar 19, 2020, 06:40 Sumit Bose sbose@redhat.com wrote:
On Thu, Mar 19, 2020 at 06:13:38AM -0500, Thomas Harrison wrote:
Certainly at first. Phase 1 is to replace Quest for the cost saving with as little change to the overall function as possible. Since pbly mapfile users authenticate via AD in Quest, only those IDs are being "realm permitted" at this time.
Hi,
ok, so assuming user joe is allowed and expected to log in. What you want to avoid is that user joe calls 'su - App_ID', enters the App_ID password stored in AD and then can run commands as App_ID user?
bye, Sumit
On Thu, Mar 19, 2020, 04:53 Sumit Bose sbose@redhat.com wrote:
On Wed, Mar 18, 2020 at 10:13:51PM -0500, Thomas Harrison wrote:
Wow Spike! You're faster and better than the support we pay for! 8)
Summary. RHEL 6 and 7. Plus AWS. I already wrote the scripts to convert user IDs to match. ( our /etc/opt/quest/vas/mapfile had jdoe mapped to jdoeXX We are limiting for the most part, the above conversion to only
entries
in
the mapfile. This would exclude App IDs, and Slervice Account IDs.
Hi,
do I understand correctly that you want that SSSD only handled "real" users from AD and ignores all other accounts like App IDs?
bye, Sumit
Unfortunately, the scenario I've run across, is that I only limit the
users
and not the Service Accounts to login via *realm permit* and
inappropriate
*su - App_ID" can create it if *getent passwd App_ID* works. I've
tried
encouraging that local accounts not have AD names, but that seems to
have
fallen on deaf ears.
I would like to create these IDs locally with UID:GID etc... that I
specify
but I'm having issues when SSSD is running. It appears that setting
up a
[domain/local] might be the key, along with sss_useradd? But I would
like
the ID to be created in /etc/passwd as well if possible. We are
discussing
a 2500 Linux Server environment.
Thanks!
Thom
On Wed, Mar 18, 2020 at 10:01 PM Spike White <spikewhitetx@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/htm...
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.
- 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.
- However, if there's just some item of that AD entry you wish to
override locally (like the login name or UID), but you otherwise
wish
to
use the AD entry -- then you would run the "sss_override" command
to
locally override the specified item of that AD entry.
Spike
On Wed, Mar 18, 2020 at 9:38 PM Thomas Harrison pjcp64@gmail.com
wrote:
You'd like a specific question... So here it is. How do I create
a
local
user ( /etc/passwd ) so I can define UID,GID, gecos, shell ) when
it
already exists in a getent lookup?
On Wed, Mar 18, 2020, 21:32 Thomas Harrison pjcp64@gmail.com
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-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o... _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...
You could add a SSSD domain using the "files" provider for local account resolution and use files (maybe?) or even LDAP or Kerberos auth for those accounts.
I've implemented files+kerberos configurations for similar use cases. Works well. A relatively current version of the daemon is required to use the files provider. Man the sssd.conf for insight to its availability on your systems.
Since you're introducing change I would recommend you use remote auth even if you resolve users locally.
-- lawrence
On Thu, Mar 19, 2020, 8:34 AM Thomas Harrison pjcp64@gmail.com wrote:
What I'm trying to avoid is the creation of the App ID with the wrong UID and GID. If I can define it locally ( ie. /etc/passwd ) then the local values over-ride the AD values. Also trying to do it without POSIX attributes because InfoSec has been slow there. I believe I can stop SSSD and add the local ID but ran across the sss_useradd command along w other sss_* commands. I need to setup a [domain/local] stanza in sssd.conf though. Us, Im unsure of removing /var/lib/sss/db/* and mc/* would wioe out any settings if not defined in /etc/passwd.
On Thu, Mar 19, 2020, 06:40 Sumit Bose sbose@redhat.com wrote:
On Thu, Mar 19, 2020 at 06:13:38AM -0500, Thomas Harrison wrote:
Certainly at first. Phase 1 is to replace Quest for the cost saving
with
as little change to the overall function as possible. Since pbly
mapfile
users authenticate via AD in Quest, only those IDs are being "realm permitted" at this time.
Hi,
ok, so assuming user joe is allowed and expected to log in. What you want to avoid is that user joe calls 'su - App_ID', enters the App_ID password stored in AD and then can run commands as App_ID user?
bye, Sumit
On Thu, Mar 19, 2020, 04:53 Sumit Bose sbose@redhat.com wrote:
On Wed, Mar 18, 2020 at 10:13:51PM -0500, Thomas Harrison wrote:
Wow Spike! You're faster and better than the support we pay for! 8)
Summary. RHEL 6 and 7. Plus AWS. I already wrote the scripts to convert user IDs to match. ( our /etc/opt/quest/vas/mapfile had jdoe mapped to jdoeXX We are limiting for the most part, the above conversion to only
entries
in
the mapfile. This would exclude App IDs, and Slervice Account IDs.
Hi,
do I understand correctly that you want that SSSD only handled "real" users from AD and ignores all other accounts like App IDs?
bye, Sumit
Unfortunately, the scenario I've run across, is that I only limit
the
users
and not the Service Accounts to login via *realm permit* and
inappropriate
*su - App_ID" can create it if *getent passwd App_ID* works. I've
tried
encouraging that local accounts not have AD names, but that seems
to have
fallen on deaf ears.
I would like to create these IDs locally with UID:GID etc... that I
specify
but I'm having issues when SSSD is running. It appears that
setting up a
[domain/local] might be the key, along with sss_useradd? But I
would
like
the ID to be created in /etc/passwd as well if possible. We are
discussing
a 2500 Linux Server environment.
Thanks!
Thom
On Wed, Mar 18, 2020 at 10:01 PM Spike White <
spikewhitetx@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/htm...
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.
- 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.
- However, if there's just some item of that AD entry you wish to
override locally (like the login name or UID), but you otherwise
wish
to
use the AD entry -- then you would run the "sss_override" command
to
locally override the specified item of that AD entry.
Spike
On Wed, Mar 18, 2020 at 9:38 PM Thomas Harrison <pjcp64@gmail.com
wrote:
> You'd like a specific question... So here it is. How do I
create a
local
> user ( /etc/passwd ) so I can define UID,GID, gecos, shell )
when it
> already exists in a getent lookup? > > On Wed, Mar 18, 2020, 21:32 Thomas Harrison pjcp64@gmail.com
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-leave@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.o...
> _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o... _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...
On Thu, Mar 19, 2020, 06:40 Sumit Bose sbose@redhat.com wrote:
On Thu, Mar 19, 2020 at 06:13:38AM -0500, Thomas Harrison wrote:
Certainly at first. Phase 1 is to replace Quest for the cost saving
with
as little change to the overall function as possible. Since pbly
mapfile
users authenticate via AD in Quest, only those IDs are being "realm permitted" at this time.
Hi,
ok, so assuming user joe is allowed and expected to log in. What you want to avoid is that user joe calls 'su - App_ID', enters the App_ID password stored in AD and then can run commands as App_ID user?
bye, Sumit
On Thu, Mar 19, 2020, 04:53 Sumit Bose sbose@redhat.com wrote:
On Wed, Mar 18, 2020 at 10:13:51PM -0500, Thomas Harrison wrote:
Wow Spike! You're faster and better than the support we pay for! 8)
Summary. RHEL 6 and 7. Plus AWS. I already wrote the scripts to convert user IDs to match. ( our /etc/opt/quest/vas/mapfile had jdoe mapped to jdoeXX We are limiting for the most part, the above conversion to only
entries
in
the mapfile. This would exclude App IDs, and Slervice Account IDs.
Hi,
do I understand correctly that you want that SSSD only handled "real" users from AD and ignores all other accounts like App IDs?
bye, Sumit
Unfortunately, the scenario I've run across, is that I only limit
the
users
and not the Service Accounts to login via *realm permit* and
inappropriate
*su - App_ID" can create it if *getent passwd App_ID* works. I've
tried
encouraging that local accounts not have AD names, but that seems
to have
fallen on deaf ears.
I would like to create these IDs locally with UID:GID etc... that I
specify
but I'm having issues when SSSD is running. It appears that
setting up a
[domain/local] might be the key, along with sss_useradd? But I
would
like
the ID to be created in /etc/passwd as well if possible. We are
discussing
a 2500 Linux Server environment.
Thanks!
Thom
On Wed, Mar 18, 2020 at 10:01 PM Spike White <
spikewhitetx@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/htm...
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.
- 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.
- However, if there's just some item of that AD entry you wish to
override locally (like the login name or UID), but you otherwise
wish
to
use the AD entry -- then you would run the "sss_override" command
to
locally override the specified item of that AD entry.
Spike
On Wed, Mar 18, 2020 at 9:38 PM Thomas Harrison <pjcp64@gmail.com
wrote:
> You'd like a specific question... So here it is. How do I
create a
local
> user ( /etc/passwd ) so I can define UID,GID, gecos, shell )
when it
> already exists in a getent lookup? > > On Wed, Mar 18, 2020, 21:32 Thomas Harrison pjcp64@gmail.com
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-leave@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.o...
> _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o... _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...
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 sbose@redhat.com wrote:
On Thu, Mar 19, 2020 at 06:13:38AM -0500, Thomas Harrison wrote:
Certainly at first. Phase 1 is to replace Quest for the cost saving with as little change to the overall function as possible. Since pbly mapfile users authenticate via AD in Quest, only those IDs are being "realm permitted" at this time.
Hi,
ok, so assuming user joe is allowed and expected to log in. What you want to avoid is that user joe calls 'su - App_ID', enters the App_ID password stored in AD and then can run commands as App_ID user?
bye, Sumit
On Thu, Mar 19, 2020, 04:53 Sumit Bose sbose@redhat.com wrote:
On Wed, Mar 18, 2020 at 10:13:51PM -0500, Thomas Harrison wrote:
Wow Spike! You're faster and better than the support we pay for! 8)
Summary. RHEL 6 and 7. Plus AWS. I already wrote the scripts to convert user IDs to match. ( our /etc/opt/quest/vas/mapfile had jdoe mapped to jdoeXX We are limiting for the most part, the above conversion to only
entries
in
the mapfile. This would exclude App IDs, and Slervice Account IDs.
Hi,
do I understand correctly that you want that SSSD only handled "real" users from AD and ignores all other accounts like App IDs?
bye, Sumit
Unfortunately, the scenario I've run across, is that I only limit the
users
and not the Service Accounts to login via *realm permit* and
inappropriate
*su - App_ID" can create it if *getent passwd App_ID* works. I've
tried
encouraging that local accounts not have AD names, but that seems to
have
fallen on deaf ears.
I would like to create these IDs locally with UID:GID etc... that I
specify
but I'm having issues when SSSD is running. It appears that setting
up a
[domain/local] might be the key, along with sss_useradd? But I would
like
the ID to be created in /etc/passwd as well if possible. We are
discussing
a 2500 Linux Server environment.
Thanks!
Thom
On Wed, Mar 18, 2020 at 10:01 PM Spike White <spikewhitetx@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/htm...
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.
- 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.
- However, if there's just some item of that AD entry you wish to
override locally (like the login name or UID), but you otherwise
wish
to
use the AD entry -- then you would run the "sss_override" command
to
locally override the specified item of that AD entry.
Spike
On Wed, Mar 18, 2020 at 9:38 PM Thomas Harrison pjcp64@gmail.com
wrote:
> You'd like a specific question... So here it is. How do I create
a
local
> user ( /etc/passwd ) so I can define UID,GID, gecos, shell ) when
it
> already exists in a getent lookup? > > On Wed, Mar 18, 2020, 21:32 Thomas Harrison pjcp64@gmail.com
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-leave@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.o...
> _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o... _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...
On Thu, Mar 19, 2020, 06:40 Sumit Bose sbose@redhat.com wrote:
On Thu, Mar 19, 2020 at 06:13:38AM -0500, Thomas Harrison wrote:
Certainly at first. Phase 1 is to replace Quest for the cost saving with as little change to the overall function as possible. Since pbly mapfile users authenticate via AD in Quest, only those IDs are being "realm permitted" at this time.
Hi,
ok, so assuming user joe is allowed and expected to log in. What you want to avoid is that user joe calls 'su - App_ID', enters the App_ID password stored in AD and then can run commands as App_ID user?
bye, Sumit
On Thu, Mar 19, 2020, 04:53 Sumit Bose sbose@redhat.com wrote:
On Wed, Mar 18, 2020 at 10:13:51PM -0500, Thomas Harrison wrote:
Wow Spike! You're faster and better than the support we pay for! 8)
Summary. RHEL 6 and 7. Plus AWS. I already wrote the scripts to convert user IDs to match. ( our /etc/opt/quest/vas/mapfile had jdoe mapped to jdoeXX We are limiting for the most part, the above conversion to only
entries
in
the mapfile. This would exclude App IDs, and Slervice Account IDs.
Hi,
do I understand correctly that you want that SSSD only handled "real" users from AD and ignores all other accounts like App IDs?
bye, Sumit
Unfortunately, the scenario I've run across, is that I only limit the
users
and not the Service Accounts to login via *realm permit* and
inappropriate
*su - App_ID" can create it if *getent passwd App_ID* works. I've
tried
encouraging that local accounts not have AD names, but that seems to
have
fallen on deaf ears.
I would like to create these IDs locally with UID:GID etc... that I
specify
but I'm having issues when SSSD is running. It appears that setting
up a
[domain/local] might be the key, along with sss_useradd? But I would
like
the ID to be created in /etc/passwd as well if possible. We are
discussing
a 2500 Linux Server environment.
Thanks!
Thom
On Wed, Mar 18, 2020 at 10:01 PM Spike White <spikewhitetx@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/htm...
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.
- 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.
- However, if there's just some item of that AD entry you wish to
override locally (like the login name or UID), but you otherwise
wish
to
use the AD entry -- then you would run the "sss_override" command
to
locally override the specified item of that AD entry.
Spike
On Wed, Mar 18, 2020 at 9:38 PM Thomas Harrison pjcp64@gmail.com
wrote:
> You'd like a specific question... So here it is. How do I create
a
local
> user ( /etc/passwd ) so I can define UID,GID, gecos, shell ) when
it
> already exists in a getent lookup? > > On Wed, Mar 18, 2020, 21:32 Thomas Harrison pjcp64@gmail.com
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-leave@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.o...
> _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o... _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...
... 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 sbose@redhat.com 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 sbose@redhat.com wrote:
On Thu, Mar 19, 2020 at 06:13:38AM -0500, Thomas Harrison wrote:
Certainly at first. Phase 1 is to replace Quest for the cost saving
with
as little change to the overall function as possible. Since pbly
mapfile
users authenticate via AD in Quest, only those IDs are being "realm permitted" at this time.
Hi,
ok, so assuming user joe is allowed and expected to log in. What you want to avoid is that user joe calls 'su - App_ID', enters the App_ID password stored in AD and then can run commands as App_ID user?
bye, Sumit
On Thu, Mar 19, 2020, 04:53 Sumit Bose sbose@redhat.com wrote:
On Wed, Mar 18, 2020 at 10:13:51PM -0500, Thomas Harrison wrote:
Wow Spike! You're faster and better than the support we pay
for! 8)
Summary. RHEL 6 and 7. Plus AWS. I already wrote the scripts to convert user IDs to match. ( our /etc/opt/quest/vas/mapfile had jdoe mapped to jdoeXX We are limiting for the most part, the above conversion to only
entries
in
the mapfile. This would exclude App IDs, and Slervice Account
IDs.
Hi,
do I understand correctly that you want that SSSD only handled
"real"
users from AD and ignores all other accounts like App IDs?
bye, Sumit
Unfortunately, the scenario I've run across, is that I only
limit the
users
and not the Service Accounts to login via *realm permit* and
inappropriate
*su - App_ID" can create it if *getent passwd App_ID* works.
I've
tried
encouraging that local accounts not have AD names, but that
seems to
have
fallen on deaf ears.
I would like to create these IDs locally with UID:GID etc...
that I
specify
but I'm having issues when SSSD is running. It appears that
setting
up a
[domain/local] might be the key, along with sss_useradd? But I
would
like
the ID to be created in /etc/passwd as well if possible. We are
discussing
a 2500 Linux Server environment.
Thanks!
Thom
On Wed, Mar 18, 2020 at 10:01 PM Spike White <
spikewhitetx@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/htm...
> > > Focus on the "direct integration" section. > > How simple or difficult your migration journey is -- depends
on two
things:
> 1. How complex your AD forest is (multiple trusted
subdomains?
> Extensive use of GC and universal groups? Or a simple flat
one-domain
> forest?) > 2. How far back in Linux OS versions do you wish to
support?
> > If you have a simple flat forest and if you don't have to
support
anything
> earlier than RHEL7, the conversion should be relatively easy. > > With some effort, you can support cross-domain authentication
with
RHEL6
> as well. RHEL5? Forget about it! > > BTW, I'm quite familiar with the VAS commands and what are the
sssd
> analogs. (About 99% of what we did in VAS, we have figured out
how to
do
> in sssd.) > > About your specific question. There's multiple answers,
depending
on
what
> you want to do. > > 1. You can define "files" first in /etc/nsswitch.conf before
"sss". It
> will find your local /etc/passwd entry first, instead of your
AD
entry.
> That masks your AD entry. > > 2. However, if there's just some item of that AD entry you
wish to
> override locally (like the login name or UID), but you
otherwise
wish
to
> use the AD entry -- then you would run the "sss_override"
command
to
> locally override the specified item of that AD entry. > > Spike > > > On Wed, Mar 18, 2020 at 9:38 PM Thomas Harrison <
pjcp64@gmail.com>
wrote:
> >> You'd like a specific question... So here it is. How do I
create
a
local
>> user ( /etc/passwd ) so I can define UID,GID, gecos, shell )
when
it
>> already exists in a getent lookup? >> >> On Wed, Mar 18, 2020, 21:32 Thomas Harrison <pjcp64@gmail.com
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-leave@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.o...
>> > _______________________________________________ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to
sssd-users-leave@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.o...
>
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave@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.o...
On Thu, Mar 19, 2020, 06:40 Sumit Bose sbose@redhat.com wrote:
On Thu, Mar 19, 2020 at 06:13:38AM -0500, Thomas Harrison wrote:
Certainly at first. Phase 1 is to replace Quest for the cost saving
with
as little change to the overall function as possible. Since pbly
mapfile
users authenticate via AD in Quest, only those IDs are being "realm permitted" at this time.
Hi,
ok, so assuming user joe is allowed and expected to log in. What you want to avoid is that user joe calls 'su - App_ID', enters the App_ID password stored in AD and then can run commands as App_ID user?
bye, Sumit
On Thu, Mar 19, 2020, 04:53 Sumit Bose sbose@redhat.com wrote:
On Wed, Mar 18, 2020 at 10:13:51PM -0500, Thomas Harrison wrote:
Wow Spike! You're faster and better than the support we pay
for! 8)
Summary. RHEL 6 and 7. Plus AWS. I already wrote the scripts to convert user IDs to match. ( our /etc/opt/quest/vas/mapfile had jdoe mapped to jdoeXX We are limiting for the most part, the above conversion to only
entries
in
the mapfile. This would exclude App IDs, and Slervice Account
IDs.
Hi,
do I understand correctly that you want that SSSD only handled
"real"
users from AD and ignores all other accounts like App IDs?
bye, Sumit
Unfortunately, the scenario I've run across, is that I only
limit the
users
and not the Service Accounts to login via *realm permit* and
inappropriate
*su - App_ID" can create it if *getent passwd App_ID* works.
I've
tried
encouraging that local accounts not have AD names, but that
seems to
have
fallen on deaf ears.
I would like to create these IDs locally with UID:GID etc...
that I
specify
but I'm having issues when SSSD is running. It appears that
setting
up a
[domain/local] might be the key, along with sss_useradd? But I
would
like
the ID to be created in /etc/passwd as well if possible. We are
discussing
a 2500 Linux Server environment.
Thanks!
Thom
On Wed, Mar 18, 2020 at 10:01 PM Spike White <
spikewhitetx@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/htm...
> > > Focus on the "direct integration" section. > > How simple or difficult your migration journey is -- depends
on two
things:
> 1. How complex your AD forest is (multiple trusted
subdomains?
> Extensive use of GC and universal groups? Or a simple flat
one-domain
> forest?) > 2. How far back in Linux OS versions do you wish to
support?
> > If you have a simple flat forest and if you don't have to
support
anything
> earlier than RHEL7, the conversion should be relatively easy. > > With some effort, you can support cross-domain authentication
with
RHEL6
> as well. RHEL5? Forget about it! > > BTW, I'm quite familiar with the VAS commands and what are the
sssd
> analogs. (About 99% of what we did in VAS, we have figured out
how to
do
> in sssd.) > > About your specific question. There's multiple answers,
depending
on
what
> you want to do. > > 1. You can define "files" first in /etc/nsswitch.conf before
"sss". It
> will find your local /etc/passwd entry first, instead of your
AD
entry.
> That masks your AD entry. > > 2. However, if there's just some item of that AD entry you
wish to
> override locally (like the login name or UID), but you
otherwise
wish
to
> use the AD entry -- then you would run the "sss_override"
command
to
> locally override the specified item of that AD entry. > > Spike > > > On Wed, Mar 18, 2020 at 9:38 PM Thomas Harrison <
pjcp64@gmail.com>
wrote:
> >> You'd like a specific question... So here it is. How do I
create
a
local
>> user ( /etc/passwd ) so I can define UID,GID, gecos, shell )
when
it
>> already exists in a getent lookup? >> >> On Wed, Mar 18, 2020, 21:32 Thomas Harrison <pjcp64@gmail.com
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-leave@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.o...
>> > _______________________________________________ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to
sssd-users-leave@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.o...
>
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to
sssd-users-leave@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.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o... _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...
sssd-users@lists.fedorahosted.org
-
Lawrence Kearney -
Spike White -
Sumit Bose -
Thomas Harrison