Hi,
are there any SSSD users who actively use a configuration with: id_provider=local ? If so, what is your use-case?
We're considering deprecating and eventually removing this provider upstream. The replacemant for id_provider=local would be id_provider=files: https://fedorahosted.org/sssd/wiki/DesignDocs/FilesProvider which is already under review and later extension of the SSSD's D-Bus interface to allow manipulating custom user attributes.
My current plan for deprecating the local provider is to only build the provider and the tools around it if a configure-time flag is provided. This flag would be disabled by default. Then, if noone complains, eventually just remove the code.
Jakub,
For my production servers I enabled local provider on the customer facing servers. I have configured an emergency user that will not be shown in /etc/passwd . In a hosting environment anyone can get a a domain for a just a few $$ and this exposes passwd file. If I add the account to /etc/passwd it could be bruteforced as most brute-forcing scripts will reference the file. However if I add it via sss_* tools , the account is invisible to them.
I've read the wiki page and I understood the need for replacing it. If id_provider=local will be removed I can live without it :)
Thanks Mario
On 02/10/2017 04:18 AM, Jakub Hrozek wrote:
Hi,
are there any SSSD users who actively use a configuration with: id_provider=local ? If so, what is your use-case?
We're considering deprecating and eventually removing this provider upstream. The replacemant for id_provider=local would be id_provider=files: https://fedorahosted.org/sssd/wiki/DesignDocs/FilesProvider which is already under review and later extension of the SSSD's D-Bus interface to allow manipulating custom user attributes.
My current plan for deprecating the local provider is to only build the provider and the tools around it if a configure-time flag is provided. This flag would be disabled by default. Then, if noone complains, eventually just remove the code. _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On Sat, Feb 11, 2017 at 02:41:12PM -0500, Mario Rossi wrote:
Jakub,
For my production servers I enabled local provider on the customer facing servers. I have configured an emergency user that will not be shown in /etc/passwd . In a hosting environment anyone can get a a domain for a just a few $$ and this exposes passwd file. If I add the account to /etc/passwd it could be bruteforced as most brute-forcing scripts will reference the file. However if I add it via sss_* tools , the account is invisible to them.
I've read the wiki page and I understood the need for replacing it. If id_provider=local will be removed I can live without it :)
Interesting use-case. By the way, I've received some other feedback from users who configure the id_provider=local, so I'm no longer sure we can remove it. And, as Sumit noted to me off-list, the local provider is sufficiently tested by Red Hat's QA team, so we are usually reminded quite quickly if something goes south.
Thanks for the response.
On certain servers I want IPA authentication but the local user/group database. With sssd 1.14, I could specify pam as the only service and put files in /etc/nsswitch.conf. With sssd 1.15, I get extra groups with that setting. I had to set id_provider=none, which is undocumented. I'd be happy to see id_provider=files for this situation, though id_provider=none with nsswitch seems to do what I need.
I do have a user with a static password, for cases where services are down. That can be done in pam, by having pam_unix as well as pam_sss. It would be interesting to have sssd handle this kind of mixed case, but it seems like this is what pam is for.
In our environment, regular users authenticate via sssd/ldap, and emergency user(s) via PAM if/when sssd + RSA securid fails. Still running sssd 1.14.2 on el6.
Thanks
On 10/16/2017 11:04 AM, hedrick@rutgers.edu wrote:
On certain servers I want IPA authentication but the local user/group database. With sssd 1.14, I could specify pam as the only service and put files in /etc/nsswitch.conf. With sssd 1.15, I get extra groups with that setting. I had to set id_provider=none, which is undocumented. I'd be happy to see id_provider=files for this situation, though id_provider=none with nsswitch seems to do what I need.
I do have a user with a static password, for cases where services are down. That can be done in pam, by having pam_unix as well as pam_sss. It would be interesting to have sssd handle this kind of mixed case, but it seems like this is what pam is for. _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On Mon, Oct 16, 2017 at 03:04:22PM +0000, hedrick@rutgers.edu wrote:
On certain servers I want IPA authentication but the local user/group database. With sssd 1.14, I could specify pam as the only service and put files in /etc/nsswitch.conf. With sssd 1.15, I get extra groups with that setting. I had to set id_provider=none, which is undocumented. I'd be happy to see id_provider=files for this situation, though id_provider=none with nsswitch seems to do what I need.
On what distribution and with what nsswitch.conf contents do you get the extra groups?
I would also say that id_provider=files is what you could use here..
I do have a user with a static password, for cases where services are down. That can be done in pam, by having pam_unix as well as pam_sss. It would be interesting to have sssd handle this kind of mixed case, but it seems like this is what pam is for. _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users@lists.fedorahosted.org