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, 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.
1 year, 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?
1 year, 3 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, 3 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, 3 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, 4 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, 4 months
managing RHEL5 sssd clients without functional ldap_id_mapping?
by James Ralston
We have a small development Active Directory domain where we have
several RHEL7 hosts.
We never extended our AD schema with the RFC2307 attributes
(uidNumber, gidNumber, et. al.). Instead, we just configured sssd
with ldap_id_mapping = true. It works fantastically well!
BUT: now we need to add several RHEL5 hosts to the domain.
The problem is that the RHEL5 version of sssd is 1.5.1, which is too
old to support ldap_id_mapping.
We looked briefly at what would be required to backport a more recent
version of sssd to RHEL5, and quickly abandoned that idea: we would
have to update multiple core system libraries to more recent versions
as well.
But we don't want to have to manually manage all accounts on the RHEL5
hosts. That would be extraordinarily tedious and error-prone.
We've kicked around a few ideas:
1. Add the RFC2307 attributes to Active Directory. Set the
(uidNumber, gidNumber) attributes by logging in to one of the RHEL7
hosts and observing what values sssd has mapped.
2. On one of our RHEL7 hosts, create a list of passwd/group entries
for users/groups we care about, and then distribute that list of
users/groups to the RHEL5 hosts.
We're leaning towards #1, because while it adds an additional step for
user/group creations in AD, it keeps all account management in AD, and
seems like the solution with the least amount of overhead. (Only a
handful of people need to be able to login to the RHEL5 systems, so we
could probably get away with only creating the (uidNumber, gidNumber)
attributes for the users/groups which need to be visible on those
systems.
Does anyone have any other suggestions on how to wrangle both RHEL5
and RHEL7 hosts with sssd?
1 year, 4 months
Samba + sssd + Active Directory integration approach
by Vincenzo De Sanctis
I have been doing research on the internet for several days but I have not
yet found the best way to proceed to meet these specific needs:
I work in a company with about 1000 employees where my predecessor unix
system administrator had configured samba 3 in the best way to meet the
needs of the company at that time without Active Directory, but now
unfortunately or fortunately , the management of the network is on my
hands, alone. I never managed Active Directory, samba was enough at that
time.
The current installed Samba 3 uses the simple smbpasswd as passwd backend,
nis (without openldap and without kerberos), automount (to mount homes and
folder group from other linux) and to manage the users and group folders it
uses the simple standard posix managed by chmod behind samba (not ACL
through setfacl).
But recently we have to connect to a AD root domain in a forest and it's
mandatory by company policy, so I have to introduce Active Directory too.
Straight up, the ideal target is to add AD as a single sign-on, users will
join to the AD domain and mount the shared linux resources from samba 4
keeping the actual directory structure shared (home users, directory
groups), this is because we want to migrate to the two domains gradually
and not in one shot. I know users have to be recreated on AD :(
The online documentations that I found say howto join from linux to AD
using winbind and sssd, but it's not clear how to map gid to the existing
uid on linux (keeping the linux current users), and even if possible how to
override the access posix behind samba (I mean chmod/chown on files not on
smb.conf)?
My idea is to install a new linux server like centos 7.2, setup samba4 and
mount through autofs the resources, join samba4 to AD, remap folders from
gpo and continue to use samba 3 for the old domain and samba4+AD for the
new domain on the two but same samba's shared resources....is it possible!?
Users save on the same map network folder keeping the same data. What is
the best way to combine samba to AD keeping the same shared resources
structure managed on samba3?
I would appreciate your advice on approach! Thank you.
--
Vincenzo De Sanctis
1 year, 4 months
