November 2011 - sssd-devel - Fedora mailing-lists

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

Imperfection of new debug levels macros
by Pavel Březina 03 Nov '11

03 Nov '11

Hi all, while working on the sudo I've noticed some semantic issues with debug level names. The debug levels are defined as: #define SSSDBG_FATAL_FAILURE 0x0010 /* level 0 */ #define SSSDBG_CRIT_FAILURE 0x0020 /* level 1 */ #define SSSDBG_OP_FAILURE 0x0040 /* level 2 */ #define SSSDBG_MINOR_FAILURE 0x0080 /* level 3 */ #define SSSDBG_CONF_SETTINGS 0x0100 /* level 4 */ #define SSSDBG_FUNC_DATA 0x0200 /* level 5 */ #define SSSDBG_TRACE_FUNC 0x0400 /* level 6 */ #define SSSDBG_TRACE_LIBS 0x1000 /* level 7 */ #define SSSDBG_TRACE_INTERNAL 0x2000 /* level 8 */ #define SSSDBG_TRACE_ALL 0x4000 /* level 9 */ Unfortunately there are some old DEBUG call that does not correspond with these names. Look at this snippet from responder initialization: if (ret != EOK) { DEBUG(0, ("Failed to set up automatic reconnection\n")); return ret; } for (iter = sctx->rctx->be_conns; iter; iter = iter->next) { sbus_reconnect_init(iter->conn, max_retries, sudo_dp_reconnect_init, iter); } DEBUG(1, ("SUDO Initialization complete\n")); It is ok to replace the 0 with SSSDBG_FATAL_FAILURE (however I would prefer SSSDBG_CRIT_FAILURE as it does not prevent reponder from starting). But more important is - I can't use SSSDBG_CRIT_FAILURE, because it is semantically nonsense. There should be SSSDBG_TRACE_FUNC. But if I use it, it will differ from other responders and that would be just confusing. Another problem is that debug levels that are described in the man page (master) does not correspond the way it is used in the code.

4 4

Announcing SSSD 1.6.3
by Stephen Gallagher 02 Nov '11

02 Nov '11

The SSSD team is proud to announce the version 1.6.3 bugfix release of the System Security Services Daemon. As always, it can be downloaded from https://fedorahosted.org/sssd/ == Highlights == * Fixes a major cache performance issue introduced in 1.6.2 * Fixes a potential infinite-loop with certain LDAP layouts == Detailed Changelog == Jakub Hrozek (4): * Plug memory leaks in LDAP provider * RFC2307bis initgroups: fix nested groups processing * Steal result onto mem_ctx in sdap_initgr_nested_get_direct_parents * Use LDAPDerefSpec properly Jan Zeleny (1): * Handle group renaming correctly Stephen Gallagher (5): * Bumping version to 1.6.3 * RESPONDER: Fix segfault in sss_packet_send() * SYSDB: add index for nameAlias * Fix bad backport of group rename patch * Update translation files for release

1 0

Announcing SSSD 1.5.15
by Stephen Gallagher 02 Nov '11

02 Nov '11

The SSSD team is proud to announce the version 1.5.15 bugfix release of the System Security Services Daemon. As always, it can be downloaded from https://fedorahosted.org/sssd/ == Highlights == * Fixes a major cache performance issue introduced in 1.5.14 * Fixes a potential infinite-loop with certain LDAP layouts == Detailed Changelog == Jakub Hrozek (3): * Plug memory leaks in LDAP provider * RFC2307bis initgroups: fix nested groups processing * Steal result onto mem_ctx in sdap_initgr_nested_get_direct_parents Stephen Gallagher (4): * Bumping version to sssd 1.5.15 * RESPONDER: Fix segfault in sss_packet_send() * SYSDB: Update sysdb version to latest * Updating translation files for release

1 0

[PATCH] SYSDB: add index for nameAlias (master)
by Stephen Gallagher 02 Nov '11

02 Nov '11

SSSD 1.6.2 has a major performance issue due to the addition of the alias support. We added a new attribute to the lookup filter, aliasName. Unfortunately, we forgot to add an index to it and it's causing a severe bottleneck in cache lookups.

3 6

[PATCH] SYSDB: Update sysdb version to latest (1.6.x)
by Stephen Gallagher 02 Nov '11

02 Nov '11

SSSD 1.6.2 has a major performance issue due to the addition of the alias support. We added a new attribute to the lookup filter, aliasName. Unfortunately, we forgot to add an index to it and it's causing a severe bottleneck in cache lookups.

3 5

[PATCH] Handle group renaming correctly
by Jan Zelený 02 Nov '11

02 Nov '11

https://fedorahosted.org/sssd/ticket/1040 Jan

3 3

[PATCH] Add support to request canonicalization on krb AS requests
by Jan Zelený 02 Nov '11

02 Nov '11

https://fedorahosted.org/sssd/ticket/957 Jan

4 14

[PATCH] Unused declaration in ldap access provider
by Jan Zelený 02 Nov '11

02 Nov '11

Seems like it has been renamed and moved to ldap_common.h Thanks Jan

3 2

fix debug-tests.c coverity issues: NEGATIVE_RETURNS, FORWARD_NULL
by Pavel Březina 02 Nov '11

02 Nov '11

https://fedorahosted.org/sssd/ticket/1046

3 10

[PATCH] RESPONDER: Fix segfault in sss_packet_send()
by Stephen Gallagher 02 Nov '11

02 Nov '11

There are several places (all error-handling) where sss_cmd_done() is called with no response packet created. As a short-term solution, we need to check whether the packet is NULL and simply return EINVAL. client_send() (the consumer) will then forcibly disconnect the client (which will return PAM_SYSTEM_ERR to the client). This is a quick fix for https://bugzilla.redhat.com/show_bug.cgi?id=748924 We don't have enough information (or steps to reproduce) to trace back the processing to its origin, so the best thing we can do for the moment is to simply prevent the crash. The client will receive an error, but the SSSD will continue to function.

2 4

[PATCHES] Support for multiple LDAP search bases
by Stephen Gallagher 02 Nov '11

02 Nov '11

These patches add support for multiple search bases for users and groups in both direct-lookup and enumeration modes. Addresses https://fedorahosted.org/sssd/ticket/868 Some notes: There is no patch adding multiple search base support for group lookups in RFC2307bis because it's meaningless right now. Since the group memberships are direct DNs, we do all of our searches as base searches, ignoring group_search_base. There is a separate ticket, https://fedorahosted.org/sssd/ticket/960 that will need to address this, taking advantage of the multiple search base features. Also, while working through this, I opened https://fedorahosted.org/sssd/ticket/1006 as I noticed that we are using far too many separate transactions while processing RFC2307bis (which is likely the cause of the extreme slowdown that some of our users were reporting with AD). These patches don't really work separately, but they've been broken up to make review much easier. Patch 0001: Remove some unused options in a struct Patch 0002: Fix size return for split_on_separator() It was returning the size of the array, rather than the number of elements. (The array was NULL-terminated). This argument was only used in one place that was actually working around this odd return value. Patch 0003: Make sdap_get_id_specific_filter() more strict Just makes it take const char * instead of char *. Patch 0004: Add parser for multiple search bases As discussed on the list, this will the ldap_*_search_base options in the form of: search_base[?scope?[filter][?search_base?scope?[filter]]*] This is backwards-compatible (just use a search base) Patch 0005: Add support for multiple search bases for users Patch 0006: Add support for multiple search bases for netgroups Patch 0007: Add support for multiple search bases for RFC2307 groups Patch 0008: Add support for multiple search bases for initgroups (user portion) Patch 0009: Add support for multiple search bases for initgroups (RFC2307 group portion) Patch 0010: Add support for multiple search bases for initgroups (RFC2307 group portion) This patch I'm not 100% sure of. It may need more processing. With RFC2307, it was safe to have duplicate groups in the list, because only the group name is important (and we guarantee that the name list has only unique values before saving it). With RFC2307bis, I'm not sure if it's safe to add two groups that may have the same name. Comments welcome. Patch 0011: Update manpages with multiple search base information Patch 0012: Convert ldap_*_search_filter Instead of making this a global option for all user lookups, make it only used if the search base is passed without an explicit filter. The idea here is to deprecate the old separate ldap_user_search_filter and ldap_group_search_filter options in favor of the new representation (which is closer to the traditional nss_ldap representation). Patch 0013: Add support for multiple search bases for user enumeration Patch 0014: Add support for multiple search bases for group enumeration This changes our behavior slightly with regard to handling direct lookups that return more than one entry. In the old code, we had a bug that would cause SSSD to treat this as an enumeration (instead of a direct lookup). This was a bug and has been fixed incidentally as part of this modification.

2 10

[PATCH] Two deref fixes
by Jakub Hrozek 02 Nov '11

02 Nov '11

Simo was studying the dereference code lately and found two issues. #1 is an important bug, #2 is more of a cosmetic issue. [PATCH 1/2] Use LDAPDerefSpec properly ldap_create_deref_control_value expects an array of LDAPDerefSpec structures with LDAPDerefSpec.derefAttr == NULL as a sentinel. We were passing a single instance of a LDAPDerefSpec structure. https://fedorahosted.org/sssd/ticket/1050 [PATCH 2/2] Remove confusing do-while loop The deref processing would return a single control back. The do-while loop was harmless but confusing.

3 5

Authentication against AD
by Thomas Jagt 02 Nov '11

02 Nov '11

Hi Stephen, We are using sssd to authenticate against AD with using Kerberos and LDAP. The idea is to filter users who are allowed to login based on a LDAP filter. In the AD there are computer objects created with the same name as the hostname of the Linux client. The filter must be something like is; If the computer object is a member of the group where the user is memberOf then allow the user to login. So what we want is to authenticate linux clients based on computer objects in the AD. (We are not using winbind) When using the ldap_access_filter it's not possible to create a LDAP query neither with the ldap_group_search_filter. Is it possible with sssd to meet our requirements? The following ldapsearch gives the right output; ldapsearch -h test.local -s sub -x -b ",ou=Groups,dc=test,dc=local" "(&(member=cn=`hostname`,cn=Computers,dc=test,dc=local))" Thanx and Regards Thomas Jagt

4 6

sss_debuglevel doesn't work for LDAP logs?
by Mark London 01 Nov '11

01 Nov '11

Hi - Is the sss_debuglevel command supposed to work with the sssd_be logs? I'm using LDAP, and while the command change the debugging level for the PAM and NSS logs, it didn't change the debug level for the my sssd_be LDAP log (or at least it couldn't change it from 0). I also tried to specify a different configuration file, that had debugging enabled in the LDAP section, and that didn't seem to work either. Thanks. - Mark

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel November 2011