Sharing SSS cache db
by Lukas Koschmieder
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
9 years, 4 months
SSSD-1.12.2: KRB auto-renew feature not working?
by Joschi Brauchle
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
9 years, 4 months
Debug levels for SSSD
by Dmitri Pal
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.
9 years, 4 months
Adding local users to ldap groups
by Octavian Afilipoai
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
9 years, 4 months
Re: [SSSD-users] pac issue
by Roy Sigurd Karlsbakk
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
9 years, 4 months