Hi all!
As far as I can tell the option 'ldap_sasl_mech = gssapi' in sssd.conf always makes LDAP use a Kerberos keytab for LDAP searches. As far as I can tell there is no way to use the users Kerberos credentials? I think this design comes from how Windows does it with AD?
I would like to use the Kerberos credentials of the user who has just logged-in instead. Maybe I'm somewhat paranoid or missing something but I'm not really comfortable with hundreds of hosts / machines with keytabs on them which give access to LDAP. Extracting that keytab from a machine is not that hard I think. I think in most use-cases the user only needs to be able to see LDAP entries (ie. other users with privacy sensitive information like names and other GDPR problematic data) which LDAP ACI's allow them.
Is there currently a way to configure SSSD in such a way?
Kind regards,
Jasper
On Fri, Dec 06, 2019 at 10:26:13AM -0000, Jasper Siepkes wrote:
Hi all!
As far as I can tell the option 'ldap_sasl_mech = gssapi' in sssd.conf always makes LDAP use a Kerberos keytab for LDAP searches. As far as I can tell there is no way to use the users Kerberos credentials? I think this design comes from how Windows does it with AD?
I would like to use the Kerberos credentials of the user who has just logged-in instead. Maybe I'm somewhat paranoid or missing something but I'm not really comfortable with hundreds of hosts / machines with keytabs on them which give access to LDAP. Extracting that keytab from a machine is not that hard I think. I think in most use-cases the user only needs to be able to see LDAP entries (ie. other users with privacy sensitive information like names and other GDPR problematic data) which LDAP ACI's allow them.
Is there currently a way to configure SSSD in such a way?
Hi,
there was a similar question recently at https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted....
To cut it short, this is not possible because many login programs need to information about the user before the password or other credentials are available.
bye, Sumit
Kind regards,
Jasper _______________________________________________ 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...
Hi,
Thanks for the reply and sorry I missed the other question (my Google-foo is apparently a bit weak today ;-).
To cut it short, this is not possible because many login programs need to information about the user before the password or other credentials
are available.
Would you folks be open to a patch which adds a flag to use the users own Kerberos credentials for environments where hosts are less trusted (ie. desktop deployments)? The documentation could add a warning that this won't work for all deployment scenario's.
I understand this might be a problem for applications like ssh however those kind of applications are not part of a normal office desktop deployment I think. Those type of applications are usually part of server deployment scenarios where the host itself is also more trusted then some desktop sitting in an office.
Kind regards,
Jasper
On Fri, Dec 06, 2019 at 11:15:46AM -0000, Jasper Siepkes wrote:
Hi,
Thanks for the reply and sorry I missed the other question (my Google-foo is apparently a bit weak today ;-).
To cut it short, this is not possible because many login programs need to information about the user before the password or other credentials
are available.
Would you folks be open to a patch which adds a flag to use the users own Kerberos credentials for environments where hosts are less trusted (ie. desktop deployments)? The documentation could add a warning that this won't work for all deployment scenario's.
I understand this might be a problem for applications like ssh however those kind of applications are not part of a normal office desktop deployment I think. Those type of applications are usually part of server deployment scenarios where the host itself is also more trusted then some desktop sitting in an office.
Hi,
sshd was just an example, afaik all login programs currently look up the user before requesting credentials.
bye, Sumit
Kind regards,
Jasper _______________________________________________ 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 Fri, 2019-12-06 at 12:25 +0100, Sumit Bose wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
On Fri, Dec 06, 2019 at 11:15:46AM -0000, Jasper Siepkes wrote:
Hi,
Thanks for the reply and sorry I missed the other question (my Google-foo is apparently a bit weak today ;-).
To cut it short, this is not possible because many login programs need to information about the user before the password or other credentials
are available.
Would you folks be open to a patch which adds a flag to use the users own Kerberos credentials for environments where hosts are less trusted (ie. desktop deployments)? The documentation could add a warning that this won't work for all deployment scenario's.
I understand this might be a problem for applications like ssh however those kind of applications are not part of a normal office desktop deployment I think. Those type of applications are usually part of server deployment scenarios where the host itself is also more trusted then some desktop sitting in an office.
Hi,
sshd was just an example, afaik all login programs currently look up the user before requesting credentials.
I don't think so. I have had problems with just sshd only when trying do clever things just because ssh looks up the user before trying to login.
Jocke
I don't think so. I have had problems with just sshd only when trying do clever things just because ssh looks up the user before trying to login.
Same here. I don't think this should be too big of a problem. It might not work for a default PAM stack (as John points out in another message) but I think it's fairly easy to make a PAM stack for which it works.
Sure there are some things you might not be able to do but it's all a matter of trade-offs. Say you have a breach; All personal data of employees has been leaked and it has been determined this was done by gaining access via a keytab lifted of any one of the 500 desktops in your organisation. Having to explain to the authorities that every desktop has a key (which isn't tied to a unique user) and allows access to personal data of employees isn't a really good sell when your trying to make a case you did your due diligence in order to avoid a fine.
On Fri, 6 Dec 2019, Jasper Siepkes wrote:
Hi,
Thanks for the reply and sorry I missed the other question (my Google-foo is apparently a bit weak today ;-).
To cut it short, this is not possible because many login programs need to information about the user before the password or other credentials
are available.
Would you folks be open to a patch which adds a flag to use the users own Kerberos credentials for environments where hosts are less trusted (ie. desktop deployments)? The documentation could add a warning that this won't work for all deployment scenario's.
I understand this might be a problem for applications like ssh however those kind of applications are not part of a normal office desktop deployment I think. Those type of applications are usually part of server deployment scenarios where the host itself is also more trusted then some desktop sitting in an office.
I'd be interested to know how you'd make this work. A default pam stack would keel over if it didn't already know the user information, as it'd typically block access to pam_sss if the UID was < 1000.
jh
sssd-users@lists.fedorahosted.org
-
Jasper Siepkes -
Joakim Tjernlund -
John Hodrien -
Sumit Bose