Hi sssd users,
sssd creates many ccache-files under /var/lib/sss/db/. They become so much, that the maximum number of inodes (default: 32768) for the partition is reached. This results in several other problems (failed logins, processes can't create sockets, etc).
Why are so many files created? Is there a way to limit the maximum number of created files?
Right now I'm running a daily Cronjob that deletes the sssd-cache (sss_cache -E).
I'm running RHEL6.6 and sssd 1.11.6 with AD as backend.
Linux 2.6.32-504.el6.x86_64 #1 SMP Tue Sep 16 01:56:35 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux
Not too long back, we noticed a mention in a RHEL6 release note that
sssd supported autofs now. We currently run autofs directly against
ldap, but just for fun we thought we'd see how well it played with sssd,
which is using the same ldap system for users/groups.
Unfortunately, our initial try was unsuccessful. Based on reviewing the
code, it looks like sssd wants to download the *entire* autofs map,
including all entries, from ldap in order it serve it to autofs? We have
something like 120000 users/groups, so that's not really feasible or
Am I understanding the operation correctly? Or is there some way to get
it to look up map entries as necessary like it does for users/groups? It
doesn't try to suck all of the users or all of the groups out of ldap at
initialization, I'm not sure why it wants to do so for autofs maps.
Is it possible to use SASL/EXTERNAL when connecting to a LDAP server with
StartTLS or LDAPS using client certs?
In a project they have certs in all systems anyway (because of using puppet)
and I'd like to let the sssd instances on all the systems authenticate to the
LDAP server to restrict visibility of LDAP entries by ACL. I'd like to avoid
having to set/configure passwords for each system's sssd.
> -----Original Message-----
> From: Domenico Viggiani [mailto:email@example.com]
> > -----Original Message-----
> > Then I'm 100% sure we have a bug. The group shouldn't have the non-
> > posix flag after it was updated.
> > Can you tell us anything about this group:
> > (Mon Mar 16 16:57:52 2015) [sssd[be[MYDOMAIN.COM]]] [sdap_save_group]
> > (0x1000): Mapping group [Organigramma] objectSID [S-1-5-21-
> > 2151176789-1472819363-28039] to unix ID
> > Is it from the same domain? What type does the group have?
> Searching for name "Organigramma", I get three results:
> dn: OU=Organigramma,OU=Liste di Distribuzione,DC=mydomain,DC=COM
sorry for disturbance: had you a chance to review this problem?
We are currently forced to allow login to all users on Red Hat 7 boxes.
Do you suggest to open a 'parallel' ticket with Red Hat?
i want to run different automounts for users on workstations or laptops
vs users logging into servers. also, i would like certain processes to
have different automounts.
say i have a user, and the user automounts server:/directory
under /home/user/localdir when logged into their daily-driver device.
when that user logs into a server, i dont want that user to get the
automount. how are people differentiating automounts for a given
i figure i could create different automountMaps and point the particular
devices to specific maps, but is there a way to have all configs be the
same and have the differentiation done in LDAP?
say all devices point to one auto.master and get direct and/or indirect
mappings from one place. is there a way to add criteria for which
mappings are returned? you only get these keys if you are in this ip
range or you only get those keys if the DNS name of the client machine
is it just easier to have different auto.masters for the different
devices or audience i want to manage?
I'm having an issue with IPA/sssd (RHEL 7.1) when accessing resources through an AD trust. The following is logged in ldap_child.log (debug_level=10):
(Tue Mar 10 12:31:12 2015) [sssd[be[unix.domain.com]]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC has no support for encryption type)]
This error seems to occur randomly. We have over 40+ DC's in our HUB site for active directory forest/domain. All of these DC's are running either Windows 2008 R2/Windows 2012/Windows 2012 R2. The domain/forest level is still Windows 2003. The trust is established between IPA (unix.domain.com) and the forest root AD domain (domain.com). The AD users actually exist in a child domain (ad.domain.com).
I conducted a test where I deleted the sssd server cache (in /var/lib/sss/db/), restarted sssd, and then did a 'getent passwd user(a)domain.com.' There were several instances where sssd was successfully using one of the AD DC's, and then after clearing the cache and restarting failed on the same AD DC with the "KDC has no support for encryption type" error. Nothing is being logged to /var/log/sssd/krb5_child.log.
We are running the following versions:
Does anyone have an idea of what may be happening here?
We are using sssd available on RHEL 7 and have a query on purging sssd
cache incase domain goes offline.
We are using just the UID/GID and group membership for users. And netgroups
(both LDAP and NIS proxy) in some cases
As I understand, sss_cache utility only invalidates the records, which
marks them expired. Whenever the domain is online, these will be refreshed.
But if the domain is offline, those expired records will still be returned
- Please reconfirm if this understanding is correct
- And if this is correct, then is there a way to purge the records to
return users/group queries invalid if domain is offline
Thanx & Regards,
We have setup FreeIPA (VERSION: 4.1.2, API_VERSION: 2.109) in our realm (IPA.DOMAIN1.COM), with trust to an AD forest (DOMAIN2.NET, which itself has trust to AD.DOMAIN2.NET, where the corporate users are). Everything works fine when using Kerberos, we can obtain tickets from AD.DOMAIN2.NET and authenticate to services in IPA.DOMAIN1.COM. We can also do "getent passwd user(a)ad.domain2.net" on a host enrolled in FreeIPA and quickly get a result.
But we have some legacy applications that perform authentication with simple LDAP binds, so we have the compat tree enabled, and while trying to authenticate users in the AD.DOMAIN2.NET realm this way eventually succeeds, it takes an awfully long time (30 seconds or so, sometimes more), with a lot going on between the AD and FreeIPA. We've attached the log file of SSSD (version 1.12.4, we've upgraded based on advice from IRC #sssd, but the problem didn't go away) from the FreeIPA server while running "ldapwhoami -D uid=user(a)ad.domain2.net,cn=users,cn=compat,dc=ipa,dc=domain1,dc=com -W" from a client machine. The debug level was set to 0x07f0.
On (rare) occasions, authentication is very fast while running the exact same command on the client machine. We've also attached the SSSD log file when that happens, for comparison. The log files have been sanitized and the slow log output was bit simplified, we removed 25 repeated events where sssd was trying to resolve unknown SIDs, it would have taken too much time to sanitize so we left 5 caching events only (we made a remark on the log file where we removed those lines.)
Any advice is more than welcome.
Thanks for your help.
Senior System Administrator - R&D and ops Infrastructure
Kudelski Security - Kudelski Group
rte de Genève 22-24, 1033 Cheseaux, SWITZERLAND
+41 21 732 03 79