sssd-users December 2014

sssd-users@lists.fedorahosted.org

17 participants
15 discussions

Sharing SSS cache db
by Lukas Koschmieder 04 Dec '14

04 Dec '14

Hi, I'd like to share a single SSS cache database between several node. Therefore, I'd like to know whether or not it's safe to simply symlink /var/lib/sss/db to a single/shared network directory? Best regards, Lukas

4 3

SSSD-1.12.2: KRB auto-renew feature not working?
by Joschi Brauchle 03 Dec '14

03 Dec '14

Hello Everyone, there seems to be a problem with the KRB TGT auto-renewal feature of SSSD in version 1.12.2. I have this config in sssd.conf: ----------------------------- krb5_renew_interval = 60 ----------------------------- We are using the AD plugin, the KRB plugin is not installed but krb-common (i.e. krb5_child, ldap_child, libsss_krb5_common.so). #Everything works fine, except auto-renewal! See the following example: ----------------------------- $ kinit -l 10m Password for ne96soh(a)ADS.MWN.DE: $ klist Ticket cache: KEYRING:persistent:3036404:krb_ccache_G0haM75 Default principal: user@REALM Valid starting Expires Service principal 12/01/2014 16:59:00 12/01/2014 17:08:58 krbtgt/REALM@REALM renew until 12/08/2014 16:59:00 $ sleep 601 $ klist klist: Credentials cache keyring 'persistent:3036404:krb_ccache_G0haM75' not found ----------------------------- => Ticket did not get renewed after >5minutes of its lifetime or at all, but expires instead. I also have this behavior with 'traditional' dir-based cache collections... it does bot work there as well. Also note that SSSD continues to set timeouts to check for renewal even after the cache is gone: ----------------------------- (Mon Dec 1 17:08:09 2014) [sssd[be[default]]] [renew_all_tgts] (0x4000): Checking [KEYRING:persistent:3036404] for renewal at [Mon Dec 1 17:08:09 2014]. ###### Ticket expired here ###### (Mon Dec 1 17:09:09 2014) [sssd[be[default]]] [renew_all_tgts] (0x4000): Checking [KEYRING:persistent:3036404] for renewal at [Mon Dec 1 17:09:09 2014]. (Mon Dec 1 17:10:09 2014) [sssd[be[default]]] [renew_all_tgts] (0x4000): Checking [KEYRING:persistent:3036404] for renewal at [Mon Dec 1 17:10:09 2014]. (Mon Dec 1 17:11:09 2014) [sssd[be[default]]] [renew_all_tgts] (0x4000): Checking [KEYRING:persistent:3036404] for renewal at [Mon Dec 1 17:11:09 2014]. (Mon Dec 1 17:12:09 2014) [sssd[be[default]]] [renew_all_tgts] (0x4000): Checking [KEYRING:persistent:3036404] for renewal at [Mon Dec 1 17:12:09 2014]. (Mon Dec 1 17:13:09 2014) [sssd[be[default]]] [renew_all_tgts] (0x4000): Checking [KEYRING:persistent:3036404] for renewal at [Mon Dec 1 17:13:09 2014] ... ----------------------------- But maybe seems to be normal as its only checking for something renewable? Best regards, J Brauchle

3 6

Debug levels for SSSD
by Dmitri Pal 03 Dec '14

03 Dec '14

HI, Do we have any place where we describe what level of output one would get with each level? It seems that we constantly ask people to put debug_level and provide logs but there is no good reference to actually see what level to put in. If there is such page why we are not pointing people to it? If there is no such page we should file a ticket and create one. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc.

4 8

Adding local users to ldap groups
by Octavian Afilipoai 02 Dec '14

02 Dec '14

Hello, I'm trying to include a user "local" defined in /etc/passwd in a ldap group called "test" by adding a memberUid in the group definition. With the getent command I see the change: >getent group test test:*:3000:local However when I run the id command for user local the group test is not shown. Only the locally defined group "local" is listed. Also accessing resources which require membership to group test fails. >id local uid=1000(local) gid=1000(local) groups=1000(local) I don't have this issue with users defined on the ldap server (the id command lists all the groups they are members of). The behavior is the same with sssd 1.11.6 on CentOS 6.6 and sssd 1.9.2 on Centos 6.5. On different machines (Centos 5.x and DebianWheezy) the local user shows up with the correct ldap groups, but those systems don't use sssd to bind to the ldap server. The version of the server is OpenLDAP 2.4.31 Is there anything in the configuration file which would enabled this behavior with sssd? Any help is appreciated. --Tavi

3 10

Re: [SSSD-users] pac issue
by Roy Sigurd Karlsbakk 02 Dec '14

02 Dec '14

On Thu, Nov 27, 2014 at 07:36:28PM +0100, Roy Sigurd Karlsbakk wrote: > Hi all. > > I just upgraded some servers to RHEL7 and saw some really, really bad performance and found ssse_pac to be the badguy. After disabling PAC, the system worked well. Before that, server had a load at 200 with only 3-400 users. This is with sssd 1.11.2. After removing pac, it was down to a calm load of 1.2 or so, similar to that of Samba 3 with winbind. Any ideas what might have cause this? Do you have any log files from the pac responder? Are you using the PAC responder with IPA or AD provider? Did you see multiple sssd_pac processes in the process list or just one? Not sure which logs to look for. I only saw one sssd_pac process, and that had used a helluva lot of time. roy

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users December 2014