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...
6 days, 11 hours
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
1 month
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
1 year, 5 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.
1 year, 6 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?
1 year, 6 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
1 year, 6 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?
1 year, 6 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
1 year, 6 months
Lightdm and the fail whale
by JOHE (John Hearns)
Is anyone else using lighdm with sssd?
Specifically on Ubuntu Xenial. I have sssd working, as I can ssh into the workstation using an account and password.
The display manager is very flaky indeed, and takes a lot to get it to open a desktop session.
I see this in the lightdm logs:
[+296.15s] DEBUG: Authenticate result for user johe: Success
[+296.15s] DEBUG: User johe authorized, but no account of that name exists
I have seen one report of this problem, and the only fix seems to be a restart of the lightdm service. Or a reboot.
Also in the syslog I see
May 23 11:08:31 ibis lightdm[7408]: ** (process:7673): WARNING **: Failed to open CK session: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.ConsoleKit was not provided by any .service files
May 23 11:08:31 ibis lightdm[7408]: Failed to write utmpx: No such file or directory
May 23 11:08:36 ibis gnome-session-binary[8547]: CRITICAL: We failed, but the fail whale is dead. Sorry....
May 23 11:08:37 ibis lightdm[7408]: Failed to write utmpx: No such file or directory
Has anyone seen similar output?
1 year, 6 months
