sssd performance on large domains
by zfnoctis＠gmail.com
Hi,
I'm wondering if there are any plans to improve sssd performance on large active directory domains (100k+ users, 40k+ groups), or if there are settings I am not aware of that can greatly improve performance, specifically for workstation use cases.
Currently if I do not set "ignore_group_members = True" in sssd.conf, logins can take upwards of 6 minutes and "sssd_be" will max the CPU for up to 20 minutes after logon, which makes it a non-starter. The reason I want to allow group members to be seen is that I want certain domain groups to be able to perform elevated actions using polkit. If I ignore group members, polkit reports that the group is empty and so no one can elevate in the graphical environment.
Ultimately this means that Linux workstations are at a severe disadvantage since they cannot be bound to the domain and have the normal set of access features users and IT expect from macOS or Windows.
Distributions used: Ubuntu 16.04 (sssd 1.13.4-1ubuntu1.1), Ubuntu 16.10 (sssd 1.13.4-3) and Fedora 24 (sssd-1.13.4-3.fc24). All exhibit the same problems.
I've also tried "ldap_group_nesting_level = 1" without seeing any noticeable improvement with respect to performance. Putting the database on /tmp isn't viable as these are workstations that will reboot semi-frequently, and I don't believe this is an I/O bound performance issue anyways.
Thanks for your time.
7 months, 4 weeks
Enumerate users from external group from AD trust
by Bolke de Bruin
Hello,
I have sssd 1.13.00 working against FreeIPA 4.2 domain. This domain has a trust relationship with a active directory domain.
One of the systems we are using requires to enumerate all users in groups by (unfortunate) design (Apache Ranger). This is done by using
“getent group”. During this enumeration the full user list for a group that has a nested external member group* is not always returned so we thought to
add “getent group mygroup” in order to get more details. Unfortunately this does not seem to work consistently: sometimes this gives information sometimes it does not:
[root@master centos]# getent group ad_users
ad_users:*:1950000004:
[root@master centos]# id bolke(a)ad.local
UID=1796201107(bolke(a)ad.local) GID=1796201107(bolke(a)ad.local) groepen=1796201107(bolke(a)ad.local),1796200513(domain users@ad.local),1796201108(test(a)ad.local)
[root@master centos]# getent group ad_users
ad_users:*:1950000004:bolke@ad.local <mailto:bolke@ad.local>
If I clear the cache (sss_cache -E) the entry is gone again:
[root@master centos]# getent group ad_users
ad_users:*:1950000004:
My question is how do I get sssd to enumerate *all users* in a group consistently?
Thanks!
Bolke
* https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/trust-g...
2 years, 10 months
SSSD strangeness
by simonc99＠hotmail.com
Hi All
We've got SSSD 1.13.0 installed as part of a Centos 7.2.1511 installation.
We've used realmd to join the host concerned to our 2008R2 AD system. This went really well, and consequently we've been using SSSD to provide login services and kerberos integration for our fairly large hadoop system.
The authconfig that's implicitly run as part of realmd produces the following sssd.conf:
[sssd]
domains = <joined domain>
config_file_version = 2
services = nss, pam
[pam]
debug_level = 0x0080
[nss]
timeout = 20
force_timeout = 600
debug_level = 0x0080
[domain/<joined domain>]
ad_domain = <joined domain>
krb5_realm = <JOINED DOMAIN>
realmd_tags = manages-system joined-with-samba
cache_credentials = true
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/%u@%d
access_provider = simple
simple_allow_groups = <AD group allowing logins>
krb5_use_kdc_info = False
entry_cache_timeout = 300
debug_level = 0x0080
ad_server = <active directory server>
As I've said - this works really well. We did have some stability issues initially, but they've been fixed by defining the 'ad_server' rather than using autodiscovery.
Logins work fine, kerberos TGTs are issued on login, and password changes are honoured correctly.
However, in general day to day use, we have noticed a few anomalies, that we just can't track down.
Firstly (this has happened a few times), a user will change their AD password (via a Windows PC).
Subsequent logins - sometimes with specific client software - fail with
pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<remote PC name> user=<username>
pam_sss(sshd:auth): received for user <username>: 17 (failure setting user credentials)
So in this example, the person concerned has changed their AD password. Further attempts to access this system via SSH work fine. However, using SFTP doesn't work (the above is output into /var/log/secure).
There are no local controls on sftp logins, and the user concerned was working fine (using both sftp and ssh) until they updated their password.
There is no separate sftp daemon running, and it only affects one individual currently (but we have seen some very similar instances before)
The second issue we have is around phantom groups in AD.
Hadoop uses an id -Gn command to see group membership for authorisation.
With some users - we've seen 6 currently - we see certain groups failing to be looked up:
id -Gn <username>
id: cannot find name for group ID xxxxyyyyy
<group name> <group name> <group name> <group name> <etc...>
The xxxxyyyyy indicates:
xxxx = hashed realm name
yyyyy = RID from group in AD
We can't find any group with that number on the AD side!
We can work around this by adding a local group (into /etc/group) for the GIDs affected. This means the id -Gn runs correctly, and the hadoop namenode can function correctly - but this is a workaround and we'd like to get to the bottom of the issue.
Rather than flooding this post now with logfiles, just thought I'd see if this looked familiar to anyone. Happy to upload any logs, amend logging levels, etc.
Many thanks
Simon
2 years, 10 months
Multiple GPOs and order processing issue
by Max DiOrio
Hi!
So it seems that I’m having an issue with GPO processing. I have an OU (Servers/Infrastructure) that contains a few servers. In this OU, I have a few GPO’s applied.
Once is “generic” that should applied to every server in this OU - which allows Remote Interactive Login and Logon Locally to Domain Admins.
I also have a GPO that applies to a specific server in this out that grants access to a service account to log on to terminal services and log on as a service. For this GPO, I have a security filter to the specific computer object it is supposed to apply to - and I think this is the root of my issue.
The GPOs are listed
1) Infrastructure servers Access Control (that should apply to them all)
2) Single Computer policy for service account
When looking at the sssd_domain logs, I can see that it’s processing both GPO’s, but only adding the account from policy 2 to the ad_gpo_access_check, meaning domain admins can’t log in to either server, only the service account can to both of them.
So we have multiple issues:
1) It’s not combining the GPO access policies, but only taking the last one found
2) It’s not abiding by the Security Filtering on the GPO
So in my case - how would I go about making this work? Would I need a separate GPO for each server I want to apply individual rights to and explicitly include the domain admins group in it, then using delegation allow the single computer read and deny read of every other computer?
Seems like this also means you can’t do GPO inheritance if it only takes the last found GPO and ignores the settings configured in previous GPO’s it checked.
Any ideas?
Thanks!
Max
4 years, 3 months
Nested LDAP groups and filtering
by Christian Svensson
Hi sssd-users,
My LDAP setup contains two bases:
dc=office1,dc=company,dc=tld
dc=office2,dc=company,dc=tld
Groups can cross-reference other groups in the two bases, like this:
cn=printer-access,ou=groups,dc=office1,dc=company,dc=tld
- member: cn=everybody,ou=groups,dc=office1,dc=company,dc=tld
- member: cn=everybody,ou=groups,dc=office2,dc=company,dc=tld
cn=printer-access,ou=groups,dc=office2,dc=company,dc=tld
- member: cn=everybody,ou=groups,dc=office2,dc=company,dc=tld
What I'm trying achieve is to have a server belonging to office1 being able
to expand all groups, even if the references are across office boundary,
but only see the leaf groups that are in its own base.
What I've tried is something like this:
[domain/office1]
debug_level = 9
enumerate = true
cache_credentials = true
entry_cache_timeout = 600
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_search_base = dc=company,dc=tld
ldap_group_search_base = dc=office1,dc=company,dc=tld
# Also tried with:
# ldap_group_search_base = dc=company,dc=tld?subtree?(dc:dn:=office1)
ldap_schema = rfc2307bis
ldap_group_member = member
ldap_group_nesting_level = 5
ldap_uri = ldaps://xxx
ldap_tls_reqcert = hard
ldap_tls_cacert = /etc/ssl/ldap-ca.crt
Sadly this does not work, which I'm not that surprised over. The lookup
logic reports:
(Sun May 20 14:00:29 2018) [sssd[be[ office1]]] [sdap_save_grpmem]
(0x0400): Adding member users to group [printer-access@office1]
(Sun May 20 14:00:29 2018) [sssd[be[ office1]]] [sdap_find_entry_by_origDN]
(0x4000): Searching cache for [
cn=everybody,ou=groups,dc=office2,dc=company,dc=tld].
(Sun May 20 14:00:29 2018) [sssd[be[ office1]]] [sdap_fill_memberships]
(0x0080): Member [ cn=everybody,ou=groups,dc=office2,dc=company,dc=tld] was
not found in cache. Is it out of scope?
Looking at the way things are executed in code and logs it seems like there
is no "post processing" to drop groups based on LDAP attributes, nor is
there any way for me to add attributes to the full name of the resource to
disambiguate them. Those are the two ways I've been attacking this, and
both seems to not be supported.
Are my observations correct? Is there a workaround other than making sure
groups have unique names across the whole company?
When groups are not colliding in name everything works just fine if I
put " ldap_group_search_base
= dc=company,dc=tld", but I'd prefer if I could avoid having to resort to
globally unique group names.
Thanks,
P.S. My groups are named differently and have been renamed in the log
messages. Let me know if something doesn't make sense and I might have
typo'd a replacement.
4 years, 3 months
Server not found in Kerberos database and debug level 11
by JOHE (John Hearns)
I would appreciate some pointers.
I have a sandbox setup running on VMs. There is an AD controller using the VM image which Microsoft has available for testing.
I have created a domain called ad.test
On my client machine I am continually getting this error:
[sssd[be[adtest.private]]] [ad_sasl_log] (0x0040): SASL: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)
On the client klist-k | uniq returns
KVNO Principal
---- --------------------------------------------------------------------------
3 CLIENT1$(a)ADTEST.PRIVATE
3 host/CLIENT1(a)ADTEST.PRIVATE
3 host/client1(a)ADTEST.PRIVATE
3 RestrictedKrbHost/CLIENT1(a)ADTEST.PRIVATE
3 RestrictedKrbHost/client1(a)ADTEST.PRIVATE
The funny thing is ONLY kinit -k CLIENT1$\(a)ADTEST.PRIVATE will work.
I do get a tgt:
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: CLIENT1$(a)ADTEST.PRIVATE
Just in the sandbox I am also setting:
ldap_auth_disable_tls_never_use_in_production = true
Any pointers please? I have cranked debug up to 8 and this error message seems to be the crucial one.
By the way, why does the debug level not go up to 11?
4 years, 4 months
Long groups resolution time
by JOHE (John Hearns)
I am still having a lot of problems with group resolution in sssd.
User logins can take anything up to two minutes, or longer.
When I time the command groups username for a selected username thish can take two or more minutes to return.
I have this set:
ldap_schema = ad
ldap_group_nesting_level = 0
ldap_groups_use_matching_rule_in_chain = True
ldap_initgroups_use_matching_rule_in_chain = True
How can one tell what the appropriate ldap_schema is for our AD controllers?
Also the information is not cached for long enough. I set
enum_cache_timeout = 1200
entry_cache_timeout = 5400
entry_cache_user_timeout = 5400
entry_cache_group_timeput = 5400
I really do not see groups information being cached for 90 minutes
4 years, 4 months
Re: Experiencing a bug on users' name and ID
by Asif Iqbal
I still like some help with any workaround in dealing with string.
IT LDAP team do not have any attribute value with real number. Is it
possible to create a local DB to map the mnetid to a real number and then
use that table as a reference for ID mapping? I am not sure if this
discussion should be in developer mailing list.
Appreciate any help
On Mar 8, 2018 11:29 PM, "Asif Iqbal" <vadud3(a)gmail.com> wrote:
On Wed, Feb 28, 2018 at 4:27 PM, Jakub Hrozek <jhrozek(a)redhat.com> wrote:
> I think the next good step would be to show the LDIF and logs of a
> resolution of a single faulty entry, e.g. 80974 which you used earlier as
> an example of an entry that doesn’t work.
>
Here are some logs for this account
dn: uid=mwvande,ou=People,dc=mnet,dc=qintra,dc=com
mnetid: 004311
(Thu Mar 8 22:10:22 2018) [sssd[be[LDAP]]] [dp_get_account_info_handler]
(0x0200): Got request for [0x1][BE_REQ_USER][idnumber=4311]
(Thu Mar 8 22:10:22 2018) [sssd[be[LDAP]]] [sdap_get_generic_ext_step]
(0x0400): calling ldap_search_ext with [(&(mnetid=4311)(objectclass=
mnetPerson)(uid=*)(&(mnetid=*)(!(mnetid=0))))][ou=People,dc=
mnet,dc=qintra,dc=com].
(Thu Mar 8 22:10:22 2018) [sssd[be[LDAP]]] [dp_table_value_destructor]
(0x0400): Removing [0:1:0x0001:1::LDAP:idnumber=4311] from reply table
(Thu Mar 8 22:10:29 2018) [sssd[be[LDAP]]] [dp_get_account_info_handler]
(0x0200): Got request for [0x2][BE_REQ_GROUP][idnumber=4311]
(Thu Mar 8 22:10:29 2018) [sssd[be[LDAP]]] [sdap_get_generic_ext_step]
(0x0400): calling ldap_search_ext with [(&(mnetid=4311)(objectClass=
inetOrgPerson)(uid=*)(&(mnetid=*)(!(mnetid=0))))][ou=
People,dc=mnet,dc=qintra,dc=com].
(Thu Mar 8 22:10:29 2018) [sssd[be[LDAP]]] [dp_table_value_destructor]
(0x0400): Removing [0:1:0x0001:2::LDAP:idnumber=4311] from reply table
(Thu Mar 8 22:11:14 2018) [sssd[be[LDAP]]] [dp_get_account_info_handler]
(0x0200): Got request for [0x1][BE_REQ_USER][name=4311@ldap]
(Thu Mar 8 22:11:14 2018) [sssd[be[LDAP]]] [sdap_get_generic_ext_step]
(0x0400): calling ldap_search_ext with [(&(uid=4311)(objectclass=
mnetPerson)(uid=*)(&(mnetid=*)(!(mnetid=0))))][ou=People,dc=
mnet,dc=qintra,dc=com].
(Thu Mar 8 22:11:14 2018) [sssd[be[LDAP]]] [dp_table_value_destructor]
(0x0400): Removing [0:1:0x0001:1::LDAP:name=4311@ldap] from reply table
(Thu Mar 8 22:11:14 2018) [sssd[be[LDAP]]] [dp_get_account_info_handler]
(0x0200): Got request for [0x1][BE_REQ_USER][idnumber=4311]
(Thu Mar 8 22:11:14 2018) [sssd[be[LDAP]]] [sdap_get_generic_ext_step]
(0x0400): calling ldap_search_ext with [(&(mnetid=4311)(objectclass=
mnetPerson)(uid=*)(&(mnetid=*)(!(mnetid=0))))][ou=People,dc=
mnet,dc=qintra,dc=com].
(Thu Mar 8 22:11:14 2018) [sssd[be[LDAP]]] [dp_table_value_destructor]
(0x0400): Removing [0:1:0x0001:1::LDAP:idnumber=4311] from reply table
(Thu Mar 8 22:11:38 2018) [sssd[be[LDAP]]] [dp_get_account_info_handler]
(0x0200): Got request for [0x2][BE_REQ_GROUP][idnumber=4311]
(Thu Mar 8 22:11:38 2018) [sssd[be[LDAP]]] [sdap_get_generic_ext_step]
(0x0400): calling ldap_search_ext with [(&(mnetid=4311)(objectClass=
inetOrgPerson)(uid=*)(&(mnetid=*)(!(mnetid=0))))][ou=
People,dc=mnet,dc=qintra,dc=com].
(Thu Mar 8 22:11:38 2018) [sssd[be[LDAP]]] [dp_table_value_destructor]
(0x0400): Removing [0:1:0x0001:2::LDAP:idnumber=4311] from reply table
(Thu Mar 8 22:12:00 2018) [sssd[be[LDAP]]] [dp_get_account_info_handler]
(0x0200): Got request for [0x2][BE_REQ_GROUP][idnumber=4311]
(Thu Mar 8 22:12:00 2018) [sssd[be[LDAP]]] [sdap_get_generic_ext_step]
(0x0400): calling ldap_search_ext with [(&(mnetid=4311)(objectClass=
inetOrgPerson)(uid=*)(&(mnetid=*)(!(mnetid=0))))][ou=
People,dc=mnet,dc=qintra,dc=com].
(Thu Mar 8 22:12:00 2018) [sssd[be[LDAP]]] [dp_table_value_destructor]
(0x0400): Removing [0:1:0x0001:2::LDAP:idnumber=4311] from reply table
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [nss_getby_id] (0x0400): Input ID:
4311
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR
#913574: Looking up UID:4311@LDAP
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913574: Checking negative cache for [UID:4311@LDAP]
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913574: [UID:4311@LDAP] is not present in negative cache
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913574: Looking up [UID:4311@LDAP] in cache
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913574: Object [UID:4311@LDAP] was not found in cache
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR
#913574: Looking up [UID:4311@LDAP] in data provider
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [sss_dp_issue_request] (0x0400):
Issuing request for [0x5641be284b10:1:4311@LDAP]
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400):
Creating request for [LDAP][0x1][BE_REQ_USER][idnumber=4311:-]
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400):
Entering request [0x5641be284b10:1:4311@LDAP]
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913574: Looking up [UID:4311@LDAP] in cache
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913574: Object [UID:4311@LDAP] was not found in cache
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [cache_req_global_ncache_add]
(0x0400): CR #913574: Adding [UID:4311@LDAP] to global negative cache
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [sss_ncache_set_str] (0x0400):
Adding [NCE/UID/4311] to negative cache
(Thu Mar 8 22:10:22 2018) [sssd[nss]] [sss_dp_req_destructor] (0x0400):
Deleting request: [0x5641be284b10:1:4311@LDAP]
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [nss_getby_id] (0x0400): Input ID:
4311
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR
#913598: Looking up GID:4311@LDAP
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913598: Checking negative cache for [GID:4311@LDAP]
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913598: [GID:4311@LDAP] is not present in negative cache
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913598: Looking up [GID:4311@LDAP] in cache
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913598: Object [GID:4311@LDAP] was not found in cache
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR
#913598: Looking up [GID:4311@LDAP] in data provider
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [sss_dp_issue_request] (0x0400):
Issuing request for [0x5641be284b10:2:4311@LDAP]
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400):
Creating request for [LDAP][0x2][BE_REQ_GROUP][idnumber=4311:-]
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400):
Entering request [0x5641be284b10:2:4311@LDAP]
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913598: Looking up [GID:4311@LDAP] in cache
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913598: Object [GID:4311@LDAP] was not found in cache
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [cache_req_global_ncache_add]
(0x0400): CR #913598: Adding [GID:4311@LDAP] to global negative cache
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [sss_ncache_set_str] (0x0400):
Adding [NCE/GID/4311] to negative cache
(Thu Mar 8 22:10:29 2018) [sssd[nss]] [sss_dp_req_destructor] (0x0400):
Deleting request: [0x5641be284b10:2:4311@LDAP]
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [nss_getby_name] (0x0400): Input
name: 4311
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_process_input] (0x0400):
CR #913740: Parsing input name [4311]
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_parse_name_for_domains]
(0x0200): name '4311' matched without domain, user is 4311
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_set_name] (0x0400): CR
#913740: Setting name [4311]
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR
#913740: Looking up 4311@ldap
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913740: Checking negative cache for [4311@ldap]
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913740: [4311@ldap] is not present in negative cache
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913740: Looking up [4311@ldap] in cache
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913740: Object [4311@ldap] was not found in cache
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR
#913740: Looking up [4311@ldap] in data provider
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_dp_issue_request] (0x0400):
Issuing request for [0x5641be284b10:1:4311@ldap@LDAP]
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400):
Creating request for [LDAP][0x1][BE_REQ_USER][name=4311@ldap:-]
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400):
Entering request [0x5641be284b10:1:4311@ldap@LDAP]
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913740: Looking up [4311@ldap] in cache
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913740: Object [4311@ldap] was not found in cache
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_ncache_add]
(0x0400): CR #913740: Adding [4311@ldap] to negative cache
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_ncache_set_str] (0x0400):
Adding [NCE/USER/LDAP/4311@ldap] to negative cache
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_dp_req_destructor] (0x0400):
Deleting request: [0x5641be284b10:1:4311@ldap@LDAP]
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [nss_getby_id] (0x0400): Input ID:
4311
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR
#913741: Looking up UID:4311@LDAP
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913741: Checking negative cache for [UID:4311@LDAP]
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913741: [UID:4311@LDAP] is not present in negative cache
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913741: Looking up [UID:4311@LDAP] in cache
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913741: Object [UID:4311@LDAP] was not found in cache
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR
#913741: Looking up [UID:4311@LDAP] in data provider
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_dp_issue_request] (0x0400):
Issuing request for [0x5641be284b10:1:4311@LDAP]
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400):
Creating request for [LDAP][0x1][BE_REQ_USER][idnumber=4311:-]
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400):
Entering request [0x5641be284b10:1:4311@LDAP]
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913741: Looking up [UID:4311@LDAP] in cache
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913741: Object [UID:4311@LDAP] was not found in cache
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_global_ncache_add]
(0x0400): CR #913741: Adding [UID:4311@LDAP] to global negative cache
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_ncache_set_str] (0x0400):
Adding [NCE/UID/4311] to negative cache
(Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_dp_req_destructor] (0x0400):
Deleting request: [0x5641be284b10:1:4311@LDAP]
(Thu Mar 8 22:11:15 2018) [sssd[nss]] [nss_getby_name] (0x0400): Input
name: 4311
(Thu Mar 8 22:11:15 2018) [sssd[nss]] [cache_req_process_input] (0x0400):
CR #913742: Parsing input name [4311]
(Thu Mar 8 22:11:15 2018) [sssd[nss]] [sss_parse_name_for_domains]
(0x0200): name '4311' matched without domain, user is 4311
(Thu Mar 8 22:11:15 2018) [sssd[nss]] [cache_req_set_name] (0x0400): CR
#913742: Setting name [4311]
(Thu Mar 8 22:11:15 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR
#913742: Looking up 4311@ldap
(Thu Mar 8 22:11:15 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913742: Checking negative cache for [4311@ldap]
(Thu Mar 8 22:11:15 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913742: [4311@ldap] does not exist (negative cache)
(Thu Mar 8 22:11:15 2018) [sssd[nss]] [nss_getby_id] (0x0400): Input ID:
4311
(Thu Mar 8 22:11:15 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR
#913743: Looking up UID:4311@LDAP
(Thu Mar 8 22:11:15 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913743: Checking negative cache for [UID:4311@LDAP]
(Thu Mar 8 22:11:15 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913743: [UID:4311@LDAP] does not exist (negative cache)
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [nss_getby_id] (0x0400): Input ID:
4311
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR
#913764: Looking up GID:4311@LDAP
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913764: Checking negative cache for [GID:4311@LDAP]
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913764: [GID:4311@LDAP] is not present in negative cache
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913764: Looking up [GID:4311@LDAP] in cache
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913764: Object [GID:4311@LDAP] was not found in cache
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR
#913764: Looking up [GID:4311@LDAP] in data provider
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [sss_dp_issue_request] (0x0400):
Issuing request for [0x5641be284b10:2:4311@LDAP]
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400):
Creating request for [LDAP][0x2][BE_REQ_GROUP][idnumber=4311:-]
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400):
Entering request [0x5641be284b10:2:4311@LDAP]
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913764: Looking up [GID:4311@LDAP] in cache
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913764: Object [GID:4311@LDAP] was not found in cache
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [cache_req_global_ncache_add]
(0x0400): CR #913764: Adding [GID:4311@LDAP] to global negative cache
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [sss_ncache_set_str] (0x0400):
Adding [NCE/GID/4311] to negative cache
(Thu Mar 8 22:11:38 2018) [sssd[nss]] [sss_dp_req_destructor] (0x0400):
Deleting request: [0x5641be284b10:2:4311@LDAP]
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [nss_getby_id] (0x0400): Input ID:
4311
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR
#913765: Looking up GID:4311@LDAP
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913765: Checking negative cache for [GID:4311@LDAP]
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #913765: [GID:4311@LDAP] is not present in negative cache
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913765: Looking up [GID:4311@LDAP] in cache
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913765: Object [GID:4311@LDAP] was not found in cache
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR
#913765: Looking up [GID:4311@LDAP] in data provider
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [sss_dp_issue_request] (0x0400):
Issuing request for [0x5641be284b10:2:4311@LDAP]
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400):
Creating request for [LDAP][0x2][BE_REQ_GROUP][idnumber=4311:-]
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400):
Entering request [0x5641be284b10:2:4311@LDAP]
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913765: Looking up [GID:4311@LDAP] in cache
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #913765: Object [GID:4311@LDAP] was not found in cache
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [cache_req_global_ncache_add]
(0x0400): CR #913765: Adding [GID:4311@LDAP] to global negative cache
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [sss_ncache_set_str] (0x0400):
Adding [NCE/GID/4311] to negative cache
(Thu Mar 8 22:12:00 2018) [sssd[nss]] [sss_dp_req_destructor] (0x0400):
Deleting request: [0x5641be284b10:2:4311@LDAP]
>
> > On 28 Feb 2018, at 01:30, Asif Iqbal <vadud3(a)gmail.com> wrote:
> >
> >
> >
> > On Tue, Feb 27, 2018 at 1:12 PM, Asif Iqbal <vadud3(a)gmail.com> wrote:
> >
> >
> > On Tue, Feb 27, 2018 at 3:37 AM, Sumit Bose <sbose(a)redhat.com> wrote:
> > On Mon, Feb 26, 2018 at 10:21:14PM -0500, Asif Iqbal wrote:
> > > I have 300 out of 3000 users whose /home/<username> dir shows uid and
> gid
> > > instead of username and groupname.
> > >
> > > It seems to be behaving like a bug
> > >
> > > As soon I become a user with `sudo su - username' the uid of the home
> dir
> > > changes to username but gid still does not change to groupname.
> > >
> > > I also get an error message, but still successfully become that user
> > >
> > > $ ls -ld /home/mbniels
> > > drwx------. 3 80974 80974 4096 Feb 27 02:15 /home/mbniels
> > >
> > > $ su - mbniels
> > > Last login: Tue Feb 27 02:34:04 UTC 2018 on pts/39
> > > /usr/bin/id: cannot find name for group ID 80974
> > > groups: cannot find name for group ID 80974
> > >
> > > $ ls -ld /home/mbniels
> > > drwx------. 3 mbniels 80974 4096 Feb 27 02:15 /home/mbniels
> > >
> > > Then to check the groups of username I get another error which then
> gets
> > > cleared by next command.
> > >
> > > $ groups mbniels
> > > mbniels : groups: cannot find name for group ID 80974
> > > 80974 users
> > >
> > > $ getent group mbniels
> > > mbniels:*:80974
> > >
> > > $ groups mbniels
> > > mbniels : mbniels users
> > >
> > > It also fixes the gid to groupname
> > >
> > > $ ls -ld /home/mbniels/
> > > drwx------. 3 mbniels mbniels 4096 Feb 27 02:15 /home/mbniels/
> > >
> > > I noticed it reverts after may be within half an hour, not exact sure
> when.
> > > Almost behaves like `quantum entanglement'.
> > > As soon as I try to check by trying to become that user the issue
> > > disappears.
> > >
> > > This is not just cosmetic issue, when the home dir shows ownership with
> > > uid, instead of username, the user fails some commands.
> > >
> > > We just started noticing today, since we just built this box and only
> few
> > > months ago and users are being invited to start using this server
> > >
> > > Some annoying error it is showing like below and user then fails to ssh
> > >
> > > $ ssh remote
> > > No user exists for uid 80974
> > >
> > > I am using centos 7 and sssd 1.15.2
> > >
> > > $ cat /etc/redhat-release
> > > CentOS Linux release 7.4.1708 (Core)
> > >
> > > $ sssd --version
> > > 1.15.2
> > >
> > > Here are some relevant logs
> > > https://paste.fedoraproject.org/paste/gBaZ-Vr8Urh-M5ABpaRNuA
> >
> > It looks like you are not using a plain RFC2307bis LDAP schema. Can you
> > send you sssd.conf and a typical LDAP user and group object?
> >
> > bye,
> > Sumit
> >
> >
> > Here is an ldap user and I using same info as group (sanitized)
> >
> > dn: uid=mbniels,ou=People,dc=example,dc=com
> > roomNumber: 123456
> > departmentNumber: 3.11.3
> > tier1: Technology
> > joblevel: 6
> > legacycompany: G
> > mobile: +11234567890
> > manager: uid=managerid,ou=People,dc=example,dc=com
> > departmentname: TESTING & INTEG
> > costcenter: S0019751
> > companynumber: S001
> > companyname: EXAMPLE COMPANY
> > displayName: FOO, BAR
> > preferredname: Mark
> > docshareaccess: TRUE
> > sAMAccountName: mbniels
> > l: XX
> > street: 123 example ave
> > saploginid: foobar
> > title: LEAD ARCHITECT
> > postalCode: 123456
> > employeeNumber: 00112233
> > mail: foo.bar(a)example.com
> > objectClass: top
> > objectClass: person
> > objectClass: organizationalPerson
> > objectClass: inetOrgPerson
> > objectClass: mnetPerson
> > mnetid: 080974
> > uid: mbniels
> > givenName: Mark
> > st: XX
> > cn: Foo Bar
> > sn: Bar
> > employeeType: Management
> > initials: X
> > nationnumber: USA
> > nationname: United States
> >
> >
> >
> > I am still looking for some help on this.
> >
> >
> >
> > --
> > Asif Iqbal
> > PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
> > A: Because it messes up the order in which people normally read text.
> > Q: Why is top-posting such a bad thing?
> >
> > _______________________________________________
> > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>
--
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
4 years, 4 months
Cacheing of group entries
by JOHE (John Hearns)
Another thing which is driving me batty....
I log in via ssh. there is a long pause while the 'groups' utility is run.
When I get a prompt I can type 'id myusername' and get an instant response.
Five minutes later I open a new terminal on my desktop, and it hangs, again in the groups utility
I have set enum_cache_timeout to be 1200. Should I be looking at other cacehing parameters please?
From my nss stanza:
[nss]
filter_users = root, postfix, lightdm
filter_groups = root
enum_cache_timeout = 1200
entry_negative_timeout = 600
4 years, 4 months
