sssd-devel August 2012

sssd-devel@lists.fedorahosted.org

22 participants
98 discussions

[PATCH] Add python bindings for murmurhash3
by Sumit Bose 15 Aug '12

15 Aug '12

Hi, I would like to find a range/slice for Posix IDs based on a domain SID on the IPA server the same way as sssd does. For this I need python bindings for the murmurhash3() call. The attached patch adds them and a small test. bye, Sumit

2 4

[PATCH] Failover: try all servers if name resolution doesn't work
by Jakub Hrozek 15 Aug '12

15 Aug '12

[PATCH 1/2] FO: Don't retry the same server if it's not working This is a regression (luckily in master only) caused by my earlier patch to return the same server if it's already being resolved, which is the case in IPA provider where we need to kinit as part of id lookup. I broke the case where we need to do a failover operation even between we returned the server to the backend, which is done if a server cannot be resolved and the be_fo_ layer queries failover for another. [PATCH 2/2] FO: Return EAGAIN if there are more servers to try The failover uses ENOENT to indicate that there are no more available servers and the provider needs to go offline. However, when the resolver returned ENOENT after failing to resolve a host name, we would just pass ENOENT up as-is. The net effect was that if a server could not be resolved, the whole provider went offline.

2 2

[PATCH] Duplicate detection in fail over did not work.
by Michal Židek 15 Aug '12

15 Aug '12

This should fix the duplicate detection. Patch is attached. Please review with caution, i was in hurry. https://fedorahosted.org/sssd/ticket/1472 Thanks Michal

4 13

Re: [SSSD] Default LDAP/SSSD timeouts are too slow if primary DNS is down. (Mark London)
by Mark London 14 Aug '12

14 Aug '12

Jakub Hrozek <jhrozek(a)redhat.com> wrote > On Mon, Aug 13, 2012 at 10:16:49PM -0400, Mark London wrote: > >> Mark London wrote: >> >>> Hi - When our primary DNS is unreachable, SSSD with LDAP breaks, >>> or is incredibly slow. I've traced it to the fact that several of >>> the LDAP timeout values are 6 seconds. This is not long enough, >>> because the default DNS timeout failover is 5 seconds. Incoming >>> SSH connections are impossible without increasing the LDAP timeout >>> value. I'm not sure yet which is the critical setting, but I've >>> increased the following from 6 seconds to 30: >>> >> I found the dns_resolver_timeout variable and changed it from 5 seconds 1 >> second, but that didn't help. I still see 5 second delays when >> sdap_ldap_connect_callback_add is called. It would be nice if the >> internal resolver had a cache! Any other suggestions? I'll be >> happy to hack the code, if someone could give me any idea of what >> needs to be fixed. This situation has occurred several times over >> the past few months, causing major problems. Thanks. >> > > I would recommend turning off the referral support: > ldap_referrals = false > > That should get rid of many reconnection attempts. We don't control name > resolution for referred servers and I suspect the resolution is done > internally in libldap. > > Thanks for the info! That reduces the time to login to 50 seconds. Much better! Perhaps the default for that setting should be false?

2 1

Refactoring the realmd DBus interface
by Stef Walter 14 Aug '12

14 Aug '12

Stephen did a quick review of the realmd DBus interface yesterday. Thanks Stephen! One of the main things he pointed out was that the realmd interface needed to be more extensible in order to be useful for non-kerberos realms in the future, like LDAP or others. Notes about some of the changes: INTERFACE: org.freedesktop.realmd.Realm * http://people.freedesktop.org/~stefw/docs/realmd-dbus-refactor/gdbus-org.fr… * a new generic interface for realms which contains generic properties and methods relevant to any kind of realm (kerberos or not). * It has a Configured property. If this property is blank, then the realm is not configured (for example just been discovered). Otherwise it contains the string of the interface that was used to configure (ie: enroll, join) the realm. An example of such an interface is o.f.r.KerberosMembership, see below. * A realm has a generic displayable Name property. * A realm has a SupportedInterfaces property, which lists all the other interfaces that the realm supports. These include interfaces which are relevant to getting more information about the realm such as o.f.r.Kerberos and also interfaces that are relevant to configuring the realm such as o.f.r.KerberosMembership. It is possible to also get a list of SupportedInterfaces through standard DBus introspection. The SupportedInterfaces property just makes things easier for some callers. * Details, LoginFormats, LoginPolicy and PermittedLogins are properties on the new generic o.f.r.Realm interface and behave the same way they did on the old o.f.r.Kerberos interface. Ditto for ChangeLoginPolicy(). * The new Deconfigure() method allows deconfiguring a realm in a generic way. It is not possible to configure a realm in a generic way as this requires input of information, but it should be possible to deconfigure a realm without realm or method specific info like credentials. The realm specific configuration interfaces still contain more fine grained methods for deconfiguring a realm, such as: o.f.r.KerberosMembership.Leave(). And these do require realm specific input, such as credentials. INTERFACE: org.freedesktop.realmd.Kerberos * http://people.freedesktop.org/~stefw/docs/realmd-dbus-refactor/gdbus-org.fr… * This used to be the main realm interface, but most of the functionality is now elsewhere. It now only contains a few extra properties to do with kerberos realms. * Renamed the 'Domain' property to 'DomainName' so it's clearer. Ditto for 'RealmName'. * This interface is always implemented on a DBus object that also implements o.f.r.Realm. It is an extra one of the 'SupportedInterfaces' INTERFACE: org.freedesktop.realmd.KerberosMembership * http://people.freedesktop.org/~stefw/docs/realmd-dbus-refactor/gdbus-org.fr… * This is a new interface that exposes functionality to configure a kerberos realm by having the machine become a member of that realm. * The Join() and Leave() methods are the same as the Enroll() and Unenroll() methods of the old o.f.r.Kerberos interface. OTHER CHANGES * Documented which PolicyKit authorizations are required for the various realmd methods. The interface documentation for this refactor is currently here until it gets merged: http://people.freedesktop.org/~stefw/docs/realmd-dbus-refactor/index.html I've done an initial untested port of realmd to this new interface, which is found here: http://cgit.freedesktop.org/realmd/realmd/log/?h=wip/dbus-refactor Stephen, if I missed anything you pointed out, please give me a heads up :) Cheers, Stef

1 0

Default LDAP/SSSD timeouts are too slow if primary DNS is down.
by Mark London 14 Aug '12

14 Aug '12

Hi - When our primary DNS is unreachable, SSSD with LDAP breaks, or is incredibly slow. I've traced it to the fact that several of the LDAP timeout values are 6 seconds. This is not long enough, because the default DNS timeout failover is 5 seconds. Incoming SSH connections are impossible with increasing the LDAP timeout value. I'm not sure yet which is the critical setting, but I've increased the following from 6 seconds to 30: ldap_network_timeout = 30 ldap_opt_timeout = 30 ldap_search_timeout = 30 What I don't understand is, even with this increase, while it allows SSH logins to work, it still takes about 1 1/2 minutes to login to the computer. The logs show that every LDAP connection takes about 5 seconds to complete. That seems to imply to me that the code doing an DNS Lookup to the primary DNS server, rather than using the local DNS cache. See below. I've not traced the code, to see if in fact this is the case. But whatever the reason, LDAP connections are taking a long time, with the primary DNS server being down: (Mon Aug 13 15:43:46 2012) [sssd[be[PSFC]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldaps://ForestDnsZones.psfc.mit.edu/DC=ForestDnsZones,DC=psfc,DC=mit,DC=edu] with fd [32]. (Mon Aug 13 15:43:51 2012) [sssd[be[PSFC]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldaps://DomainDnsZones.psfc.mit.edu/DC=DomainDnsZones,DC=psfc,DC=mit,DC=edu] with fd [33]. (Mon Aug 13 15:43:56 2012) [sssd[be[PSFC]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldaps://psfc.mit.edu/CN=Configuration,DC=psfc,DC=mit,DC=edu] with fd [34]. (Mon Aug 13 15:43:56 2012) [sssd[be[PSFC]]] [sdap_rebind_proc] (0x1000): Successfully bind to [ldaps://DomainDnsZones.psfc.mit.edu/DC=DomainDnsZones,DC=psfc,DC=mit,DC=edu] (Mon Aug 13 15:43:56 2012) [sssd[be[PSFC]]] [sdap_rebind_proc] (0x1000): Successfully bind to [ldaps://ForestDnsZones.psfc.mit.edu/DC=ForestDnsZones,DC=psfc,DC=mit,DC=edu] This is true, even though I have enumeration turned on, with long cached timeouts: enum_cache_timeout = 86400 ldap_purge_cache_timeout = 0 ldap_enumeration_refresh_timeout = 300 I was under the impression that enumeration prevented blocking, and used cache values, rather than waiting for LDAP requests to finish. Any comments, or opinions on how to fix this problem? Thanks. - Mark

3 3

sss_client: Group lookups should work even when fastcache cannot be initialized
by Jakub Hrozek 13 Aug '12

13 Aug '12

https://fedorahosted.org/sssd/ticket/1415 I tripped over this bug again when I was testing the threading issue, so I decided to just fix it.

2 2

[PATCH] Add autofs-related options to configAPI
by Jakub Hrozek 13 Aug '12

13 Aug '12

https://fedorahosted.org/sssd/ticket/1478 I've tested that the following Python code now works fine: from SSSDConfig import SSSDConfig sssdconfig = SSSDConfig() sssdconfig.import_config('/etc/sssd/sssd.conf') ldap_domain = sssdconfig.new_domain('autofstest') ldap_domain.add_provider('ldap', 'autofs') ldap_domain.set_option('ldap_autofs_map_object_class', 'nisMap') works fine.

2 3

- Issue with 1.8.0-32.el6 being on a different VLAN then active directory servers
by Derek Page 13 Aug '12

13 Aug '12

Hi Devs, I am seeing an issue with sssd-1.8.0-32.el6.x86_64 Issue description. When system is on a different VLAN as the Active directory servers logins are really slow or timeout and I see these errors. I see this in the syslog Aug 13 10:27:32 m4deploy01 sssd_be: GSSAPI Error: An invalid name was supplied (Unknown error) I see this in the sssd log (Mon Aug 13 10:30:06 2012) [sssd[be[my.domain.com]]] [sdap_parse_entry] (0x4000): OriginalDN: [CN=Derek Page,OU=Concord,DC=my,DC=domain,DC=com]. (Mon Aug 13 10:30:06 2012) [sssd[be[my.domain.com]]] [sdap_process_result] (0x2000): Trace: sh[0x21a99c0], connected[1], ops[0x2194c10], ldap[0x31ae7b0] (Mon Aug 13 10:30:06 2012) [sssd[be[my.domain.com]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://DomainDnsZones.my.domain.com/DC=DomainDnsZones,DC=my,DC=domain,DC=com] with fd [35]. (Mon Aug 13 10:30:06 2012) [sssd[be[my.domain.com]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://ForestDnsZones.my.domain.com/DC=ForestDnsZones,DC=my,DC=domain,DC=com] with fd [36]. (Mon Aug 13 10:30:06 2012) [sssd[be[my.domain.com]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://my.domain.com/CN=Configuration,DC=my,DC=domain,DC=com] with fd [37]. (Mon Aug 13 10:30:06 2012) [sssd[be[my.domain.com]]] [sdap_rebind_proc] (0x0020): ldap_sasl_interactive_bind_s failed (-2)[Local error] (Mon Aug 13 10:30:06 2012) [sssd[be[my.domain.com]]] [sdap_rebind_proc] (0x1000): Failed to bind to [ldap://my.domain.com/CN=Configuration,DC=my,DC=domain,DC=com] (Mon Aug 13 10:30:06 2012) [sssd[be[my.domain.com]]] [sdap_ldap_connect_callback_del] (0x4000): Closing LDAP connection with fd [37]. (Mon Aug 13 10:30:06 2012) [sssd[be[my.domain.com]]] [sdap_rebind_proc] (0x0020): ldap_sasl_interactive_bind_s failed (-2)[Local error] (Mon Aug 13 10:30:06 2012) [sssd[be[my.domain.com]]] [sdap_rebind_proc] (0x1000): Failed to bind to [ldap://ForestDnsZones.my.domain.com/DC=ForestDnsZones,DC=my,DC=domain,DC=com] (Mon Aug 13 10:30:06 2012) [sssd[be[my.domain.com]]] [sdap_ldap_connect_callback_del] (0x4000): Closing LDAP connection with fd [36]. (Mon Aug 13 10:30:06 2012) [sssd[be[my.domain.com]]] [sdap_rebind_proc] (0x0020): ldap_sasl_interactive_bind_s failed (-2)[Local error] (Mon Aug 13 10:30:06 2012) [sssd[be[my.domain.com]]] [sdap_rebind_proc] (0x1000): Failed to bind to [ldap://DomainDnsZones.my.domain.com/DC=DomainDnsZones,DC=my,DC=domain,DC=com] (Mon Aug 13 10:30:06 2012) [sssd[be[my.domain.com]]] [sdap_ldap_connect_callback_del] (0x4000): Closing LDAP connection with fd [35]. (Mon Aug 13 10:30:06 2012) [sssd[be[my.domain.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE] (Mon Aug 13 10:30:06 2012) [sssd[be[my.domain.com]]] [sdap_process_result] (0x2000): Trace: sh[0x21a99c0], connected[1], ops[0x2194c10], ldap[0x31ae7b0] (Mon Aug 13 10:30:06 2012) [sssd[be[my.domain.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE] (Mon Aug 13 10:30:06 2012) [sssd[be[my.domain.com]]] [sdap_process_result] (0x2000): Trace: sh[0x21a99c0], connected[1], ops[0x2194c10], ldap[0x31ae7b0] (Mon Aug 13 10:30:06 2012) [sssd[be[my.domain.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE] (Mon Aug 13 10:30:06 2012) [sssd[be[my.domain.com]]] [sdap_process_result] (0x2000): Trace: sh[0x21a99c0], connected[1], ops[0x2194c10], ldap[0x31ae7b0] (Mon Aug 13 10:30:06 2012) [sssd[be[my.domain.com]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Mon Aug 13 10:30:09 2012) [sssd[be[my.domain.com]]] [sbus_dispatch] (0x4000): dbus conn: 2163580 If I moved the system to the same VLAN as the Active Directory servers and these errors go away and everything works great. Other systems running sssd-1.5.1-49.el5_8.1 on a different VLAN then my Active Directory servers also work great. Is this an issue with 1.8.0-32? Any suggestions? Here are my configs. #/etc/krb5.conf [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = MYDOMAIN.COM dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 24h renew_lifetime = 7d forwardable = true default_tgs_enctypes = rc4-hmac aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 default_tkt_enctypes = rc4-hmac aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 permitted_enctypes = rc4-hmac aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 [realms] MY.DOMAIN.COM = { kdc = ad.my.domain.com:88 admin_server = ad.my.domain.com default_domain = my.domain.com } [domain_realm] .my.domain.com = MY.DOMAIN.COM my.domain.com = MY.DOMAIN.COM #/etc/sssd/sssd.conf [domain/default] cache_credentials = fasle [sssd] config_file_version = 2 domains = my.domain.com reconnection_retries = 3 sbus_timeout = 30 services = nss, pam [nss] filter_groups = root filter_users = root reconnection_retries = 3 [pam] reconnection_retries = 3 [domain/my.domain.com] cache_credentials = false enumerate = false min_id = 80 max_id = 30000 id_provider = ldap auth_provider = krb5 ldap_uri = ldap://ad3.my.domain.com/ ldap_schema = rfc2307bis ldap_user_search_base = dc=my,dc=domain,dc=com ldap_user_object_class = person ldap_user_modify_timestamp = whenChanged ldap_user_home_directory = unixHomeDirectory ldap_user_shell = loginShell ldap_user_principal = userPrincipalName ldap_group_search_base = dc=my,dc=domain,dc=com ldap_group_object_class = group ldap_group_modify_timestamp = whenChanged ldap_group_nesting_level = 5 ldap_account_expire_policy = ad ldap_sasl_authid = M4DEPLOY01$(a)MY.DOMAIN.COM ldap_krb5_init_creds = true ldap_pwd_policy = mit_kerberos chpass_provider = krb5 ldap_sasl_mech = GSSAPI krb5_realm = MY.DOMAIN.COM krb5_validate = true ldap_user_name = sAMAccountName ldap_user_uid_number = uidNumber ldap_user_gid_number = gidNumber ldap_user_home_directory = unixHomeDirectory ldap_user_shell = loginShell ldap_user_principal = userPrincipalName ldap_group_object_class = group ldap_group_name = sAMAccountName ldap_group_gid_number = gidNumber ldap_force_upper_case_realm = true #ldap_referrals = false # User Group and Account Access access_provider = simple #simple_allow_users = simple_allow_groups = m4_login debug_level = 10

3 3

[patch] TTL in SSSD DNS update
by James Hogarth 13 Aug '12

13 Aug '12

Hi, As discussed in #SSSD on Friday the TTL used in the nsupdate when SSSD carries out a needed update is set quite high (86400 seconds) and is not in line with the TTL originally by an IPA client install (1200 seconds). I've filed bug #1476 for this on the SSSD fedorahosted trac instance and attached the proposed patch file there too... There are two patches - one against master (a git diff) and one suitable to adding to the current SRPM provided for SSSD in the centos 6.3 repository (so hopefully fine for RHEL in theory).... I've tested the one for the SRPM as working so hopefully the same will be fine on master... it's just the change of the integer after all... This is an initial patch to bring the SSSD nsupdate TTL in line with the IPA client install one... (since it's a quick and simple change). Over the course of the next couple of weeks I plan to refine this and submit a future update to have the value configurable in sssd.conf - along with a similar one the freeipa-devel lists for changes that end to expose TTL in the IPA UI and have the initial client install with a configurable TTL as well... Regards, James

2 1

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel August 2012