sssd-devel November 2011

sssd-devel@lists.fedorahosted.org

24 participants
74 discussions

OpenSSH integration - known_hosts
by Jan Zelený 09 Nov '11

09 Nov '11

Hello everyone, there is a new effort in IPA and SSSD teams and that is SSH key integration in both parts of SSSD-IPA infrastructure. We've put together some basic plans and now we would like to know your opinion. Note that this is just shortened version to make it easier to read. It doesn't contain every bit of information about the design. For full version see https://fedorahosted.org/freeipa/wiki/SSH-FreeIPA-Integration Problems: ========= * the known_hosts file becomes outdated as machines get new host keys (e.g. re- installed systems in virtualized environment) * the user accepts any host key of the remote host without validating its authenticity Solution: ========= Instead of checking stale known_hosts file, provide a dynamic mechanism to lookup and deliver the public ssh key of the remote host to the client and use it for validation of the remote host identity. The dynamic mechanism would imply that no action is needed from the user because the source of the retrieved key is trusted. Limitations: ============ It is out of scope of this work to solve the problem in general. We propose a solution for following use case: Client host is a managed host meaning that it has SSSD installed and it is joined an IPA domain. It also has OpenSSH patched to interact with SSSD to get the information about the remote host Other UNIX machines or Windows machines as SSH clients are out of the scope of the current project. For the client hosts that can not be managed but can access IPA via the standard LDAP tools we will provide documentation on how to construct the content of the known_hosts file by querying LDAP server and saving the results. The remote host can be a managed (joined IPA domain via SSSD) or an unmanaged host. IPA server needs to provide a way to create entries for any managed and unmanaged hosts and store public keys for those hosts in that entries. What would change in IPA: ========================= * external host would have entries with the possibility of storing their public keys * new mechanism to work with keys through UI and CLI * host key fingerprints would be stored in SSHFP DNS records for each host joined in IPA domain What would change on the client: ================================ * SSSD would fetch and cache host public keys from IPA * joining to IPA domain would upload host public key * ssh client would communicate with SSSD, probably through ssh-agent, to check if the remote host is known It is still a question whether the solution is sufficient enough to address the needs and pains of the real deployments or other technologies outside the proposed should be used later (or instead). -- Thank you Jan Zeleny Red Hat Software Engineer Brno, Czech Republic

4 6

[PATCH] Fixed translation bug
by Thorsten Scherf 08 Nov '11

08 Nov '11

3 2

[PATCH] LDAP: Remove redundant groups from the lookup list
by Stephen Gallagher 08 Nov '11

08 Nov '11

There was a bug in the multiple search base patches. A section of code was duplicated in the group enumeration patches, and it was causing group lookups to become corrupted.

2 2

OpenSSH integration - authorized_keys
by Jan Zelený 08 Nov '11

08 Nov '11

Hello everyone, this is a follow-up on the email on OpenSSH integration - known_host. It describes another scenario we want to address in the process of integrating OpenSSH to SSSD-IPA infrastructure - user public keys and their central management. As in the previous email, we would also like to know your opinion. Note that this is just shortened version to make it easier to read. It doesn't contain every bit of information about the design. For full version see https://fedorahosted.org/freeipa/wiki/SSH-FreeIPA-Integration Problems: ========= * how to distribute keys for new users / regenerated keys through the domain. The authorized_keys is probably not an option, we also want to cover use case when home directories are remote and not mounted on the server. * user may want to log on to the remote server using different account. We need to determine if he is allowed to impersonate that account Solution: ========= Similarly to openssh-lpk, the solution is to centrally manage and store user public keys in the IPA server and deliver them to the host for validation when user accesses that host. In the central server provide a way to define which account can do impersonation of which other accounts. Optionally add a way to represent special service accounts that are not full user accounts but can be logged as via ssh (stretch goal). What would change on IPA: ========================= * user entry will have additional multi-valued attribute for storing public keys. Unlike in openssh-lpk, this attribute will store what keys the user has, not who can impersonate him. * user entry would also have a multi-valued attribute containg DNs of users he can impersonate * new mechanisms to work with account public keys and impersonation via UI and CLI * HBAC rules would be extended to cover impersonation * provide an LDAP control to get a list of ssh keys that correspond to accounts that can impersonate a particular account in one operation. On the client side: =================== * SSSD would fetch (and cache?) user public keys from IPA * new SSSD client would fetch user public keys from SSSD * use SSH agent feature to get user public key from an output of the SSSD client -- Thank you Jan Zeleny Red Hat Software Engineer Brno, Czech Republic

1 0

memberUID corruption handling
by Stephen Gallagher 08 Nov '11

08 Nov '11

I've noticed lately on a couple of LDAP environments (all of which having been converted at some point in the past from NIS) that there is a tendency for bad conversion scripts to sometimes leave around groups with improperly formatted memberUID values. For example: dn: cn=groupA,ou=Groups,dc=example,dc=com objectClass: posixGroup ... memberUID: user1,user2,user3 Now, the standards-compliant approach here would be to just treat 'user1,user2,user3' as a single group entry (that except on the most psychotic of systems would never match an actual username). However, it's well within our power in SSSD to handle this more gracefully, by parsing the commas ourselves. My question is, is this something we should do, or should we continue treating this as useless data and use it to encourage admins to fix their systems? This *has* caused negative behavior in the SSSD in the past (specifically, there was a bug in some older versions of LDB that caused it to be unable to perform a reindex on DNs that contained an escaped comma, thus rendering SSSD incapable of safely upgrading to newer versions).

3 3

[PATCHES] Two resource leaks discovered by coverity
by Jan Zelený 07 Nov '11

07 Nov '11

https://fedorahosted.org/sssd/ticket/1069 https://fedorahosted.org/sssd/ticket/1071 -- Jan

3 7

[PATCH] Fix two bugs in initgroups code
by Jakub Hrozek 07 Nov '11

07 Nov '11

I found two new bugs in the initgroups code. They affect master only. Patches are attached.

3 2

[PATCH] Fixed empty loginShell in proxy provider
by Jan Zelený 07 Nov '11

07 Nov '11

The ticket is: https://fedorahosted.org/sssd/ticket/892 Jan

3 2

Unable to auth using SSSD on RHEL 5
by Eric 04 Nov '11

04 Nov '11

I have been unable to auth using ssh and sssd. I have attached my sssd.conf (sanitized) and sssd_LDAP.conf (sanitized), sssd.log, sssd_pam.log, sssd_nss.log. My ldap server is OpenLDAP 2.4.23. The system is a RHEL 5.5. I am seeing the following in /var/log/secure: masterldap sshd[3299]: error: Could not get shadow information for testuser masterldap sshd[3299]: Failed password for testuser from 192.168.0.10 port 46521 ssh2 I am able to do an ldap bind using uid=testuser,ou=People,dc=mydomain,dc=org so the password hash appears to be correct. I am using the package sssd-1.5.1-37.el5 and sssd-client-1.5.1-37.el5 Any help would be greatly appreciated. I can provide more information upon request. /etc/pam.d/system-auth-ac ======================================================================== auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so use_first_pass auth required pam_deny.so account required pam_unix.so broken_shadow debug account sufficient pam_localuser.so debug account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session optional pam_sss.so session required pam_unix.so ============================================================================== -Eric

2 4

autofs support
by Ondrej Valousek 03 Nov '11

03 Nov '11

Just a captious question: anyone working on the autofs support yet? :-)

3 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel November 2011