sssd-devel April 2015

sssd-devel@lists.fedorahosted.org

16 participants
59 discussions

[PATCHES] Fix GPO processing for users from subdomains
by Stephen Gallagher 15 Apr '15

15 Apr '15

Patch 0001: AD: Clean up ad_access_gpo Just a minor cleanup to ad_gpo_access_send to adhere to our tevent conventions. This is purely for aesthetic and maintainability reasons; it has no functional effect. Patch 0002: AD: Always get domain-specific ID connection This one is a little tricky. It turns out that in some circumstances, ad_ctx->ldap_ctx may actually be pointing at a subdomain rather than the enrolled domain. I don't know the reasons for this (and it appears to be a race-condition, because I could only get it to happen if I was quick to test logins right after restarting SSSD). However, the fix is fairly straightforward: sdap_domain_get()->pvt->ldap_ctx always provides the real ldap_ctx for the requested domain (either the enrolled domain or any of the trusted domains). The IS_SUBDOMAIN() check and shortcut to ad_ctx->ldap_ctx was unnecessary and (thanks to the odd race) incorrect. This patch removes this conditional shortcut and forces us to get the correct ldap_ctx. This proved to be the last piece necessary to get Patch 0003 to work. Patch 0003: AD GPO: Always look up GPOs from machine domain When dealing with users from a child domain, SSSD was attempting to use the subdomain for lookups. However, all GPOs applicable to this machine are stored in the primary domain (the domain the host directly joined). This patch has the GPO processing use the primary domain instead of the user domain. Resolves: https://fedorahosted.org/sssd/ticket/2606

2 2

sss_ssh_authorizedkeys: add a flag for ppolicy ?
by Olivier 15 Apr '15

15 Apr '15

Hi everyone, I saw couple of discussion around in this list as well as others about how to exploit ppolicy with ssh : here are some thought. Currently, I am in a situation where I have inserted my users public ssh keys in ldap (openssh-ldappubkey shema) and instructed sshd to consult ldap for ssh public keys, adding in ssh_config : AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys I also have authorized password authentication , in ssh_config: PasswordAuthentication yes My current policy is the following : - All my users must have a password in ldap (that is used by applications other than ssh) - not all my users may have an ssh key (some never use ssh) Everything works as I want. I now want to introduce ppolicy overlay and would like to enforce rules for password management even for users that mainly use ssh keys. Practically and basically : when a user with valid ssh key ask for an ssh connexion, I would like ssh to behave exactly as if this user had typed a correct "loging/password" and therefore check for ppolicy situation before granting access. aka : - if the account is 'ppolicy desactivated', ssh would refuse to provide the session - if the password is "ppolicy oudated", then ssh would warn to change it (and decrease 'pwdGraceAuthnLimit*'*?) ... and so on. I thought about two options/alternatives to do that : * try to tune pam (may be there would be a way to tell pam to check for user ppolicy fields once authentication has been done before granting access ?) * add some sort of flag (aka: --ppolicy) to sss_ssh_authorizedkeys to instruct sss_ssh_authorizedkeys to check for user ppolicy (use 'ldap_default_bind_dn' as a binding user) and if there is an issue return a "ppolicy error message" rather than the user ssh key ? These are just some thoughts. I'm currently exploring the first option (but I'm not a 'pam' expert and I'm even not sure that the ssh authentication process goes through pam if a valid key is found, even with 'UsePAM yes'). I would appreciate any guidance, advices or experiences from you on that particular issue. Thank you, -- Olivier

3 5

[PATCH] Don't call semanage transaction unless the context has changed
by Jakub Hrozek 14 Apr '15

14 Apr '15

Hi, the attached patches fix ticket https://fedorahosted.org/sssd/ticket/2624 It turns out that calling libsemanage transactions is a fairly intensive operation that involves copying multiple files under the /etc/selinux hierarchy to a temporary subtree and then back. With the patches, the context from IPA is checked against the local database first and only applied if it differs.

2 4

[PATCH] sssd_sudo always asks for sudo rules of filter_users
by Adam Tkac 14 Apr '15

14 Apr '15

Hello, sssd_sudo always asks for sudo rules for users specified in filter_users directive and creates large amount of traffic to LDAP servers. Proposed patch for this is attached (tested on RHEL 6.6, rebuilt sssd-1.11.6-30.el6_6.4). With this patch sssd_sudo no longer queries LDAP for sudo rules of filter_users users. Regards, Adam

3 4

[PATCHES] sysdb-tests: Add missing assertions
by Lukas Slebodnik 14 Apr '15

14 Apr '15

ehlo, simple patches attached. LS

2 2

[PATCH] simple_access-tests: Simplify assertion
by Lukas Slebodnik 14 Apr '15

14 Apr '15

ehlo, simple patch is attached. LS

2 2

[PATCHES] SDAP: Filter ad groups in initgroups
by Lukas Slebodnik 14 Apr '15

14 Apr '15

ehlo, the problem is that with current master and 1.12 the domain local groups from subdomain are not filtered. The 1st patch partially fixes the problem. The name of group is not visible after "id user", but there is a GID which does not have a name. BTW without this patch "Distributions groups" needn't be filtered with disabled tokengroups. It might explain some cases where groups were missing with disabled tokengroups. Users might use this bug as a workaround. The last patch filter domain local groups from subdomains while doing initgroups. So there will not be GIDs without name. Please try to review patches very soon. So we can fix regression with domain local groups caused by recent optimalisation of initgroups. LS

2 2

[PATCH] Improve nsupdate error logging
by Jakub Hrozek 14 Apr '15

14 Apr '15

Hi, the attached simple patches add more debugging to nsupdate runs and capture nsupdate stderr to the sssd debug logs. I used them to get more data in case where nsupdate was failing without more data.

2 2

[PATCH] sudo: sanitize filter values
by Pavel Březina 13 Apr '15

13 Apr '15

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

3 6

RFC - disable the cleanup task by default
by Jakub Hrozek 13 Apr '15

13 Apr '15

Hi, I would like to propose disabling the cleanup task by default. It causes problems and is not really useful in my opinion. The cleanup task was designed to keep the cache size within certain limits. This is how it roughly works now: - find users who have never logged in by default. If account_cache_expiration is set, find users who loggged in later than account_cache_expiration - delete the matching set of users - find groups that have no members - delete the matching set of groups So unless account_cache_expiration is set to something sensible, only empty groups are removed and that's quite a corner case. The above effectivelly walks the whole database, especially the groups step is quite slow with a huge database. The whole cleanup task also runs in a single sysdb transaction, which means all other transactions are blocked while the cleanup task crunches the database. Just today I've seen two users/customers for which disabling the cleanup helped performance. The alternative would be to fix the cleanup task. So far I only checked that indexed attributes are used -- they are. But I don't see much value in the cleanup task to be honest. If an entry is explicitly requested, then the back end removes the cached entry when evaluating the negative result.. Therefore, I think we should disable the cleanup task completely unless account_cache_expiration is set to a non-default value. If account_cache_expiration was set, then the cleanup task would run as it does now. Opinions?

4 9

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel April 2015