3:18 a.m.
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.
1:41 p.m.
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(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
2:11 p.m.
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.
10:04 a.m.
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.
10:20 a.m.
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(a)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(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
1:05 p.m.
On Mon, Oct 16, 2017 at 03:04:22PM +0000, hedrick(a)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(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
2384
days inactive
2632
days old
sssd-users@lists.fedorahosted.org
5 comments
3 participants
participants (3)
-
hedrick＠rutgers.edu -
Jakub Hrozek -
Mario Rossi