[PATCH] Add python bindings for murmurhash3
by Sumit Bose
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
11 years, 8 months
[PATCH] Failover: try all servers if name resolution doesn't work
by Jakub Hrozek
[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.
11 years, 8 months
Re: [SSSD] Default LDAP/SSSD timeouts are too slow if primary DNS is down. (Mark London)
by Mark London
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?
11 years, 8 months
Refactoring the realmd DBus interface
by Stef Walter
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....
* 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....
* 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....
* 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
11 years, 8 months
Default LDAP/SSSD timeouts are too slow if primary DNS is down.
by Mark London
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
11 years, 8 months
[PATCH] Add autofs-related options to configAPI
by Jakub Hrozek
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.
11 years, 8 months
- Issue with 1.8.0-32.el6 being on a different VLAN then active directory servers
by Derek Page
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
11 years, 8 months
[patch] TTL in SSSD DNS update
by James Hogarth
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
11 years, 8 months
