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@gmail.com wrote:
On Wed, Feb 28, 2018 at 4:27 PM, Jakub Hrozek jhrozek@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@gmail.com wrote:
On Tue, Feb 27, 2018 at 1:12 PM, Asif Iqbal vadud3@gmail.com wrote:
On Tue, Feb 27, 2018 at 3:37 AM, Sumit Bose sbose@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 80974I 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@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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On Sun, Mar 11, 2018 at 10:25:24AM -0400, Asif Iqbal wrote:
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.
You might want to try local overrides, see man sss_override for details.
As an alternative you might want to try to enable enumeration. After the initial enumeration run is done all users and groups are already in SSSD's cache and lookups by id should work. But I'm not sure if enumeration can handle you setup where user and groups are defined by the same LDAP object.
Finally, if it is possible to remove the leading '0's from mnetid it should work as well because then '(mnetid=4311)' would match as string as well.
bye, Sumit
Appreciate any help
On Mar 8, 2018 11:29 PM, "Asif Iqbal" vadud3@gmail.com wrote:
On Wed, Feb 28, 2018 at 4:27 PM, Jakub Hrozek jhrozek@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@gmail.com wrote:
On Tue, Feb 27, 2018 at 1:12 PM, Asif Iqbal vadud3@gmail.com wrote:
On Tue, Feb 27, 2018 at 3:37 AM, Sumit Bose sbose@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 80974I 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@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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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?
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On Mon, Mar 12, 2018 at 5:59 AM, Sumit Bose sbose@redhat.com wrote:
On Sun, Mar 11, 2018 at 10:25:24AM -0400, Asif Iqbal wrote:
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.
You might want to try local overrides, see man sss_override for details.
Let me read up on it real quick and explore that. What should I be looking for? How to override mnetid attribute value type from string to integer?
As an alternative you might want to try to enable enumeration. After the initial enumeration run is done all users and groups are already in SSSD's cache and lookups by id should work. But I'm not sure if enumeration can handle you setup where user and groups are defined by the same LDAP object.
During initial setup, before this server was in production, I tried enumeration on and I think login were failing and it was doing ldap query for 2500 users and almost was not responding. So kind of risky to go that path, since most users' mnetd id do not have leading `0' and I might add more problem than solution :-)
Finally, if it is possible to remove the leading '0's from mnetid it should work as well because then '(mnetid=4311)' would match as string as well.
I think I have the worst IT LDAP team. They will not change there schema and remove any leading 0s from mnetid.
Might be little off-topic, but I am not sure if we could have a ldap sync all attributes to a local ldap server minus the mnetid and we populate that with numbers. Probably also add more work to address few user accounts with leading 0s
bye,
Sumit
Appreciate any help
On Mar 8, 2018 11:29 PM, "Asif Iqbal" vadud3@gmail.com wrote:
On Wed, Feb 28, 2018 at 4:27 PM, Jakub Hrozek jhrozek@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@gmail.com wrote:
On Tue, Feb 27, 2018 at 1:12 PM, Asif Iqbal vadud3@gmail.com
wrote:
On Tue, Feb 27, 2018 at 3:37 AM, Sumit Bose sbose@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 80974I 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@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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.
fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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?
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On Mon, Mar 12, 2018 at 11:04 AM, Asif Iqbal vadud3@gmail.com wrote:
On Mon, Mar 12, 2018 at 5:59 AM, Sumit Bose sbose@redhat.com wrote:
On Sun, Mar 11, 2018 at 10:25:24AM -0400, Asif Iqbal wrote:
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.
You might want to try local overrides, see man sss_override for details.
Let me read up on it real quick and explore that. What should I be looking for? How to override mnetid attribute value type from string to integer?
So I see 5% of current users have mnetid with leading 0.
So I never used sss_override. How do I use sss_override to make mnetid 004311 to work with sss when ldap id mapping tries to map 4311 instead?
Appreciate your help!
As an alternative you might want to try to enable enumeration. After the initial enumeration run is done all users and groups are already in SSSD's cache and lookups by id should work. But I'm not sure if enumeration can handle you setup where user and groups are defined by the same LDAP object.
During initial setup, before this server was in production, I tried enumeration on and I think login were failing and it was doing ldap query for 2500 users and almost was not responding. So kind of risky to go that path, since most users' mnetd id do not have leading `0' and I might add more problem than solution :-)
Finally, if it is possible to remove the leading '0's from mnetid it should work as well because then '(mnetid=4311)' would match as string as well.
I think I have the worst IT LDAP team. They will not change there schema and remove any leading 0s from mnetid.
Might be little off-topic, but I am not sure if we could have a ldap sync all attributes to a local ldap server minus the mnetid and we populate that with numbers. Probably also add more work to address few user accounts with leading 0s
bye,
Sumit
Appreciate any help
On Mar 8, 2018 11:29 PM, "Asif Iqbal" vadud3@gmail.com wrote:
On Wed, Feb 28, 2018 at 4:27 PM, Jakub Hrozek jhrozek@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@gmail.com wrote:
On Tue, Feb 27, 2018 at 1:12 PM, Asif Iqbal vadud3@gmail.com
wrote:
On Tue, Feb 27, 2018 at 3:37 AM, Sumit Bose sbose@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 80974I 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@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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorah
osted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorah
osted.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?
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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?
On Mon, Mar 12, 2018 at 03:05:43PM -0400, Asif Iqbal wrote:
On Mon, Mar 12, 2018 at 11:04 AM, Asif Iqbal vadud3@gmail.com wrote:
On Mon, Mar 12, 2018 at 5:59 AM, Sumit Bose sbose@redhat.com wrote:
On Sun, Mar 11, 2018 at 10:25:24AM -0400, Asif Iqbal wrote:
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.
You might want to try local overrides, see man sss_override for details.
Let me read up on it real quick and explore that. What should I be looking for? How to override mnetid attribute value type from string to integer?
So I see 5% of current users have mnetid with leading 0.
So I never used sss_override. How do I use sss_override to make mnetid 004311 to work with sss when ldap id mapping tries to map 4311 instead?
Appreciate your help!
I haven't tested it with your setup but
sss_override user_add mwvande --uid 4311 --gid 4311 sss_override group_add mwvande --gid 4311
should create the needed override data so that user and group mwvande can be looked up with the ID 4311.
HTH
bye, Sumit
As an alternative you might want to try to enable enumeration. After the initial enumeration run is done all users and groups are already in SSSD's cache and lookups by id should work. But I'm not sure if enumeration can handle you setup where user and groups are defined by the same LDAP object.
During initial setup, before this server was in production, I tried enumeration on and I think login were failing and it was doing ldap query for 2500 users and almost was not responding. So kind of risky to go that path, since most users' mnetd id do not have leading `0' and I might add more problem than solution :-)
Finally, if it is possible to remove the leading '0's from mnetid it should work as well because then '(mnetid=4311)' would match as string as well.
I think I have the worst IT LDAP team. They will not change there schema and remove any leading 0s from mnetid.
Might be little off-topic, but I am not sure if we could have a ldap sync all attributes to a local ldap server minus the mnetid and we populate that with numbers. Probably also add more work to address few user accounts with leading 0s
bye,
Sumit
Appreciate any help
On Mar 8, 2018 11:29 PM, "Asif Iqbal" vadud3@gmail.com wrote:
On Wed, Feb 28, 2018 at 4:27 PM, Jakub Hrozek jhrozek@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@gmail.com wrote:
On Tue, Feb 27, 2018 at 1:12 PM, Asif Iqbal vadud3@gmail.com
wrote:
On Tue, Feb 27, 2018 at 3:37 AM, Sumit Bose sbose@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@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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorah
osted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorah
osted.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?
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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?
-- 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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On Tue, Mar 13, 2018 at 3:24 AM, Sumit Bose sbose@redhat.com wrote:
On Mon, Mar 12, 2018 at 03:05:43PM -0400, Asif Iqbal wrote:
On Mon, Mar 12, 2018 at 11:04 AM, Asif Iqbal vadud3@gmail.com wrote:
On Mon, Mar 12, 2018 at 5:59 AM, Sumit Bose sbose@redhat.com wrote:
On Sun, Mar 11, 2018 at 10:25:24AM -0400, Asif Iqbal wrote:
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.
You might want to try local overrides, see man sss_override for
details.
Let me read up on it real quick and explore that. What should I be
looking
for? How to override mnetid attribute value type from string to integer?
So I see 5% of current users have mnetid with leading 0.
So I never used sss_override. How do I use sss_override to make mnetid 004311 to work with sss when ldap id mapping tries to map 4311 instead?
Appreciate your help!
I haven't tested it with your setup but
sss_override user_add mwvande --uid 4311 --gid 4311 sss_override group_add mwvande --gid 4311should create the needed override data so that user and group mwvande can be looked up with the ID 4311.
So I can lookup by 4311 after this. Very nice!
Do I need to restart sssd after these two commands?
HTH
bye, Sumit
As an alternative you might want to try to enable enumeration. After
the
initial enumeration run is done all users and groups are already in SSSD's cache and lookups by id should work. But I'm not sure if enumeration can handle you setup where user and groups are defined by the same LDAP object.
During initial setup, before this server was in production, I tried enumeration on and I think login were failing and it was doing ldap query for 2500
users
and almost was not responding. So kind of risky to go that path, since most users' mnetd id do not have leading `0' and I might add more problem than solution :-)
Finally, if it is possible to remove the leading '0's from mnetid it should work as well because then '(mnetid=4311)' would match as string as well.
I think I have the worst IT LDAP team. They will not change there
schema
and remove any leading 0s from mnetid.
Might be little off-topic, but I am not sure if we could have a ldap
sync
all attributes to a local ldap server minus the mnetid and we populate that with
numbers.
Probably also add more work to address few user accounts with leading 0s
bye,
Sumit
Appreciate any help
On Mar 8, 2018 11:29 PM, "Asif Iqbal" vadud3@gmail.com wrote:
On Wed, Feb 28, 2018 at 4:27 PM, Jakub Hrozek jhrozek@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@gmail.com wrote: > > > > On Tue, Feb 27, 2018 at 1:12 PM, Asif Iqbal vadud3@gmail.com
wrote:
> > > On Tue, Feb 27, 2018 at 3:37 AM, Sumit Bose sbose@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@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@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-leave@lists.fedorah
osted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorah
osted.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?
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.
fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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?
-- 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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On Wed, Mar 14, 2018 at 03:42:28PM -0400, Asif Iqbal wrote:
On Tue, Mar 13, 2018 at 3:24 AM, Sumit Bose sbose@redhat.com wrote:
On Mon, Mar 12, 2018 at 03:05:43PM -0400, Asif Iqbal wrote:
On Mon, Mar 12, 2018 at 11:04 AM, Asif Iqbal vadud3@gmail.com wrote:
On Mon, Mar 12, 2018 at 5:59 AM, Sumit Bose sbose@redhat.com wrote:
On Sun, Mar 11, 2018 at 10:25:24AM -0400, Asif Iqbal wrote:
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.
You might want to try local overrides, see man sss_override for
details.
Let me read up on it real quick and explore that. What should I be
looking
for? How to override mnetid attribute value type from string to integer?
So I see 5% of current users have mnetid with leading 0.
So I never used sss_override. How do I use sss_override to make mnetid 004311 to work with sss when ldap id mapping tries to map 4311 instead?
Appreciate your help!
I haven't tested it with your setup but
sss_override user_add mwvande --uid 4311 --gid 4311 sss_override group_add mwvande --gid 4311should create the needed override data so that user and group mwvande can be looked up with the ID 4311.
So I can lookup by 4311 after this. Very nice!
Do I need to restart sssd after these two commands?
You have to restart SSSD after adding the first overrides to switch on the override handling. If you add additional override later on you do not have to restart SSSD, but you might need to wait until some cache timeouts are passed before the overridden values are shown.
bye, Sumit
HTH
bye, Sumit
As an alternative you might want to try to enable enumeration. After
the
initial enumeration run is done all users and groups are already in SSSD's cache and lookups by id should work. But I'm not sure if enumeration can handle you setup where user and groups are defined by the same LDAP object.
During initial setup, before this server was in production, I tried enumeration on and I think login were failing and it was doing ldap query for 2500
users
and almost was not responding. So kind of risky to go that path, since most users' mnetd id do not have leading `0' and I might add more problem than solution :-)
Finally, if it is possible to remove the leading '0's from mnetid it should work as well because then '(mnetid=4311)' would match as string as well.
I think I have the worst IT LDAP team. They will not change there
schema
and remove any leading 0s from mnetid.
Might be little off-topic, but I am not sure if we could have a ldap
sync
all attributes to a local ldap server minus the mnetid and we populate that with
numbers.
Probably also add more work to address few user accounts with leading 0s
bye,
Sumit
Appreciate any help
On Mar 8, 2018 11:29 PM, "Asif Iqbal" vadud3@gmail.com wrote:
On Wed, Feb 28, 2018 at 4:27 PM, Jakub Hrozek jhrozek@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@gmail.com wrote: > > > > > > > > On Tue, Feb 27, 2018 at 1:12 PM, Asif Iqbal vadud3@gmail.com
wrote:
> > > > > > On Tue, Feb 27, 2018 at 3:37 AM, Sumit Bose sbose@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@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@lists.fedorahosted.org > > To unsubscribe send an email to sssd-users-leave@lists.fedorah
osted.org
> _______________________________________________ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-leave@lists.fedorah
osted.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?
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.
fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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?
-- 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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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?
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On Thu, Mar 15, 2018 at 4:42 AM, Sumit Bose sbose@redhat.com wrote:
On Wed, Mar 14, 2018 at 03:42:28PM -0400, Asif Iqbal wrote:
On Tue, Mar 13, 2018 at 3:24 AM, Sumit Bose sbose@redhat.com wrote:
On Mon, Mar 12, 2018 at 03:05:43PM -0400, Asif Iqbal wrote:
On Mon, Mar 12, 2018 at 11:04 AM, Asif Iqbal vadud3@gmail.com
wrote:
On Mon, Mar 12, 2018 at 5:59 AM, Sumit Bose sbose@redhat.com
wrote:
On Sun, Mar 11, 2018 at 10:25:24AM -0400, Asif Iqbal wrote: > 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.
You might want to try local overrides, see man sss_override for
details.
Let me read up on it real quick and explore that. What should I be
looking
for? How to override mnetid attribute value type from string to integer?
So I see 5% of current users have mnetid with leading 0.
So I never used sss_override. How do I use sss_override to make
mnetid
004311 to work with sss when ldap id mapping tries to map 4311 instead?
Appreciate your help!
I haven't tested it with your setup but
sss_override user_add mwvande --uid 4311 --gid 4311 sss_override group_add mwvande --gid 4311should create the needed override data so that user and group mwvande can be looked up with the ID 4311.
So I can lookup by 4311 after this. Very nice!
Do I need to restart sssd after these two commands?
You have to restart SSSD after adding the first overrides to switch on the override handling. If you add additional override later on you do not have to restart SSSD, but you might need to wait until some cache timeouts are passed before the overridden values are shown.
I have a user today complained whose mnetid has leading 0s
[mwvande@example:]$ ssh sgx2-brdr-01
No user exists for uid 4311
I already have the sss_override ran last week for 100 users last week and sssd was restarted.
bye, Sumit
HTH
bye, Sumit
As an alternative you might want to try to enable enumeration.
After
the
initial enumeration run is done all users and groups are already
in
SSSD's cache and lookups by id should work. But I'm not sure if enumeration can handle you setup where user and groups are
defined by
the same LDAP object.
During initial setup, before this server was in production, I tried enumeration on and I think login were failing and it was doing ldap query for 2500
users
and almost was not responding. So kind of risky to go that path, since
most
users' mnetd id do not have leading `0' and I might add more problem than solution :-)
Finally, if it is possible to remove the leading '0's from mnetid
it
should work as well because then '(mnetid=4311)' would match as
string
as well.
I think I have the worst IT LDAP team. They will not change there
schema
and remove any leading 0s from mnetid.
Might be little off-topic, but I am not sure if we could have a
ldap
sync
all attributes to a local ldap server minus the mnetid and we populate that with
numbers.
Probably also add more work to address few user accounts with leading 0s
bye,
Sumit
> > Appreciate any help > > > > > On Mar 8, 2018 11:29 PM, "Asif Iqbal" vadud3@gmail.com wrote: > > > > On Wed, Feb 28, 2018 at 4:27 PM, Jakub Hrozek <
jhrozek@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@gmail.com
wrote:
> > > > > > > > > > > > On Tue, Feb 27, 2018 at 1:12 PM, Asif Iqbal <
vadud3@gmail.com>
wrote: > > > > > > > > > On Tue, Feb 27, 2018 at 3:37 AM, Sumit Bose <
sbose@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@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@lists.fedorahosted.
org
> > > To unsubscribe send an email to
sssd-users-leave@lists.fedorah
osted.org > > _______________________________________________ > > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > > To unsubscribe send an email to sssd-users-leave@lists.fedorah osted.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?
> _______________________________________________ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-leave@lists.
fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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?
-- 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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.
fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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?
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On Wed, Mar 21, 2018 at 4:09 PM, Asif Iqbal vadud3@gmail.com wrote:
On Thu, Mar 15, 2018 at 4:42 AM, Sumit Bose sbose@redhat.com wrote:
On Wed, Mar 14, 2018 at 03:42:28PM -0400, Asif Iqbal wrote:
On Tue, Mar 13, 2018 at 3:24 AM, Sumit Bose sbose@redhat.com wrote:
On Mon, Mar 12, 2018 at 03:05:43PM -0400, Asif Iqbal wrote:
On Mon, Mar 12, 2018 at 11:04 AM, Asif Iqbal vadud3@gmail.com
wrote:
On Mon, Mar 12, 2018 at 5:59 AM, Sumit Bose sbose@redhat.com
wrote:
> On Sun, Mar 11, 2018 at 10:25:24AM -0400, Asif Iqbal wrote: > > 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. > > You might want to try local overrides, see man sss_override for
details.
>
Let me read up on it real quick and explore that. What should I be
looking
for? How to override mnetid attribute value type from string to
integer?
So I see 5% of current users have mnetid with leading 0.
So I never used sss_override. How do I use sss_override to make
mnetid
004311 to work with sss when ldap id mapping tries to map 4311 instead?
Appreciate your help!
I haven't tested it with your setup but
sss_override user_add mwvande --uid 4311 --gid 4311 sss_override group_add mwvande --gid 4311should create the needed override data so that user and group mwvande can be looked up with the ID 4311.
So I can lookup by 4311 after this. Very nice!
Do I need to restart sssd after these two commands?
You have to restart SSSD after adding the first overrides to switch on the override handling. If you add additional override later on you do not have to restart SSSD, but you might need to wait until some cache timeouts are passed before the overridden values are shown.
I have a user today complained whose mnetid has leading 0s
[mwvande@example:]$ ssh sgx2-brdr-01
No user exists for uid 4311
I already have the sss_override ran last week for 100 users last week and sssd was restarted.
I am still wondering if there is a gap in my using sss_override
I have ran this, example commands, for all users with leading 0s in mnetid
sss_override user-add mwvande --uid 4311--gid 4311 sss_override group-add mwvande --gid 4311
Then I ran the systemctl restart sssd
Is there a step I am missing?
On Thu, Mar 22, 2018 at 2:51 PM, Asif Iqbal vadud3@gmail.com wrote:
[..stripped for brevity..]
So I see 5% of current users have mnetid with leading 0.
So I never used sss_override. How do I use sss_override to make
mnetid
004311 to work with sss when ldap id mapping tries to map 4311 instead?
Appreciate your help!
I haven't tested it with your setup but
sss_override user_add mwvande --uid 4311 --gid 4311 sss_override group_add mwvande --gid 4311should create the needed override data so that user and group mwvande can be looked up with the ID 4311.
So I can lookup by 4311 after this. Very nice!
Do I need to restart sssd after these two commands?
You have to restart SSSD after adding the first overrides to switch on the override handling. If you add additional override later on you do not have to restart SSSD, but you might need to wait until some cache timeouts are passed before the overridden values are shown.
I have a user today complained whose mnetid has leading 0s
[mwvande@example:]$ ssh sgx2-brdr-01
No user exists for uid 4311
I already have the sss_override ran last week for 100 users last week and sssd was restarted.
I am still wondering if there is a gap in my using sss_override
I have ran this, example commands, for all users with leading 0s in mnetid
sss_override user-add mwvande --uid 4311--gid 4311 sss_override group-add mwvande --gid 4311
Then I ran the systemctl restart sssd
Is there a step I am missing?
I have another user having the same issue with mnetid 027505 and username ac09446
As a workaround he ran `getent passwd ac09446` and `getent group ac09446` and that fixed it
Please advise
-- 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?
On Fri, Mar 23, 2018 at 06:13:39PM -0400, Asif Iqbal wrote:
On Thu, Mar 22, 2018 at 2:51 PM, Asif Iqbal vadud3@gmail.com wrote:
[..stripped for brevity..]
> So I see 5% of current users have mnetid with leading 0. > > So I never used sss_override. How do I use sss_override to make
mnetid
> 004311 > to work with sss when ldap id mapping tries to map 4311 instead? > > Appreciate your help!
I haven't tested it with your setup but
sss_override user_add mwvande --uid 4311 --gid 4311 sss_override group_add mwvande --gid 4311should create the needed override data so that user and group mwvande can be looked up with the ID 4311.
So I can lookup by 4311 after this. Very nice!
Do I need to restart sssd after these two commands?
You have to restart SSSD after adding the first overrides to switch on the override handling. If you add additional override later on you do not have to restart SSSD, but you might need to wait until some cache timeouts are passed before the overridden values are shown.
I have a user today complained whose mnetid has leading 0s
[mwvande@example:]$ ssh sgx2-brdr-01
No user exists for uid 4311
I already have the sss_override ran last week for 100 users last week and sssd was restarted.
I am still wondering if there is a gap in my using sss_override
I have ran this, example commands, for all users with leading 0s in mnetid
sss_override user-add mwvande --uid 4311--gid 4311 sss_override group-add mwvande --gid 4311
Then I ran the systemctl restart sssd
As said earlier I haven't tested overrides with your type of setup, so I'm not sure if they work as expected. After adding the overrides and restarting SSSD with debug_level=9 in the [nss] and [domain/...] sections of sssd.conf, can you call 'sss_cache -E' and 'getent passwd 4311' and send me the related logs.
bye, Sumit
Is there a step I am missing?
I have another user having the same issue with mnetid 027505 and username ac09446
As a workaround he ran `getent passwd ac09446` and `getent group ac09446` and that fixed it
Please advise
-- 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?
-- 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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On Tue, Mar 27, 2018 at 4:43 AM, Sumit Bose sbose@redhat.com wrote:
On Fri, Mar 23, 2018 at 06:13:39PM -0400, Asif Iqbal wrote:
On Thu, Mar 22, 2018 at 2:51 PM, Asif Iqbal vadud3@gmail.com wrote:
[..stripped for brevity..]
> > So I see 5% of current users have mnetid with leading 0. > > > > So I never used sss_override. How do I use sss_override to make
mnetid
> > 004311 > > to work with sss when ldap id mapping tries to map 4311
instead?
> > > > Appreciate your help! > > I haven't tested it with your setup but > > sss_override user_add mwvande --uid 4311 --gid 4311 > sss_override group_add mwvande --gid 4311 > > should create the needed override data so that user and group
mwvande
> can be looked up with the ID 4311. >
So I can lookup by 4311 after this. Very nice!
Do I need to restart sssd after these two commands?
You have to restart SSSD after adding the first overrides to switch
on
the override handling. If you add additional override later on you do not have to restart SSSD, but you might need to wait until some cache timeouts are passed before the overridden values are shown.
I have a user today complained whose mnetid has leading 0s
[mwvande@example:]$ ssh sgx2-brdr-01
No user exists for uid 4311
I already have the sss_override ran last week for 100 users last week
and
sssd was restarted.
I am still wondering if there is a gap in my using sss_override
I have ran this, example commands, for all users with leading 0s in
mnetid
sss_override user-add mwvande --uid 4311--gid 4311 sss_override group-add mwvande --gid 4311
Then I ran the systemctl restart sssd
As said earlier I haven't tested overrides with your type of setup, so I'm not sure if they work as expected. After adding the overrides and restarting SSSD with debug_level=9 in the [nss] and [domain/...] sections of sssd.conf, can you call 'sss_cache -E' and 'getent passwd 4311' and send me the related logs.
bye, Sumit
# sss_cache -E # getent passwd 4311 (no output)
sssd_LDAP.log https://gist.github.com/7170405abc3c7b8a2fac0211f4452aab
sssd_nss.log https://gist.github.com/cd1a4a1323c94d0284d4001fe364bf71
Appreciate your help!
On Mon, Apr 2, 2018 at 12:20 PM, Asif Iqbal vadud3@gmail.com wrote:
On Tue, Mar 27, 2018 at 4:43 AM, Sumit Bose sbose@redhat.com wrote:
On Fri, Mar 23, 2018 at 06:13:39PM -0400, Asif Iqbal wrote:
On Thu, Mar 22, 2018 at 2:51 PM, Asif Iqbal vadud3@gmail.com wrote:
[..stripped for brevity..]
> > > So I see 5% of current users have mnetid with leading 0. > > > > > > So I never used sss_override. How do I use sss_override to
make
mnetid > > > 004311 > > > to work with sss when ldap id mapping tries to map 4311
instead?
> > > > > > Appreciate your help! > > > > I haven't tested it with your setup but > > > > sss_override user_add mwvande --uid 4311 --gid 4311 > > sss_override group_add mwvande --gid 4311 > > > > should create the needed override data so that user and group
mwvande
> > can be looked up with the ID 4311. > > > > > So I can lookup by 4311 after this. Very nice! > > Do I need to restart sssd after these two commands?
You have to restart SSSD after adding the first overrides to switch
on
the override handling. If you add additional override later on you
do
not have to restart SSSD, but you might need to wait until some
cache
timeouts are passed before the overridden values are shown.
I have a user today complained whose mnetid has leading 0s
[mwvande@example:]$ ssh sgx2-brdr-01
No user exists for uid 4311
I already have the sss_override ran last week for 100 users last
week and
sssd was restarted.
I am still wondering if there is a gap in my using sss_override
I have ran this, example commands, for all users with leading 0s in
mnetid
sss_override user-add mwvande --uid 4311--gid 4311 sss_override group-add mwvande --gid 4311
Then I ran the systemctl restart sssd
As said earlier I haven't tested overrides with your type of setup, so I'm not sure if they work as expected. After adding the overrides and restarting SSSD with debug_level=9 in the [nss] and [domain/...] sections of sssd.conf, can you call 'sss_cache -E' and 'getent passwd 4311' and send me the related logs.
bye, Sumit
# sss_cache -E # getent passwd 4311 (no output)
sssd_LDAP.log https://gist.github.com/7170405abc3c7b8a2fac0211f4452aab
sssd_nss.log https://gist.github.com/cd1a4a1323c94d0284d4001fe364bf71
Appreciate your help!
Hi Sumit et al.,
Still like some help to resolve 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?
On Mon, Apr 09, 2018 at 10:53:51AM -0400, Asif Iqbal wrote:
On Mon, Apr 2, 2018 at 12:20 PM, Asif Iqbal vadud3@gmail.com wrote:
On Tue, Mar 27, 2018 at 4:43 AM, Sumit Bose sbose@redhat.com wrote:
On Fri, Mar 23, 2018 at 06:13:39PM -0400, Asif Iqbal wrote:
On Thu, Mar 22, 2018 at 2:51 PM, Asif Iqbal vadud3@gmail.com wrote:
[..stripped for brevity..] > > > > So I see 5% of current users have mnetid with leading 0. > > > > > > > > So I never used sss_override. How do I use sss_override to
make
> mnetid > > > > 004311 > > > > to work with sss when ldap id mapping tries to map 4311
instead?
> > > > > > > > Appreciate your help! > > > > > > I haven't tested it with your setup but > > > > > > sss_override user_add mwvande --uid 4311 --gid 4311 > > > sss_override group_add mwvande --gid 4311 > > > > > > should create the needed override data so that user and group
mwvande
> > > can be looked up with the ID 4311. > > > > > > > > > So I can lookup by 4311 after this. Very nice! > > > > Do I need to restart sssd after these two commands? > > You have to restart SSSD after adding the first overrides to switch
on
> the override handling. If you add additional override later on you
do
> not have to restart SSSD, but you might need to wait until some
cache
> timeouts are passed before the overridden values are shown. >
I have a user today complained whose mnetid has leading 0s
[mwvande@example:]$ ssh sgx2-brdr-01
No user exists for uid 4311
I already have the sss_override ran last week for 100 users last
week and
sssd was restarted.
I am still wondering if there is a gap in my using sss_override
I have ran this, example commands, for all users with leading 0s in
mnetid
sss_override user-add mwvande --uid 4311--gid 4311 sss_override group-add mwvande --gid 4311
Then I ran the systemctl restart sssd
As said earlier I haven't tested overrides with your type of setup, so I'm not sure if they work as expected. After adding the overrides and restarting SSSD with debug_level=9 in the [nss] and [domain/...] sections of sssd.conf, can you call 'sss_cache -E' and 'getent passwd 4311' and send me the related logs.
bye, Sumit
# sss_cache -E # getent passwd 4311 (no output)
sssd_LDAP.log https://gist.github.com/7170405abc3c7b8a2fac0211f4452aab
sssd_nss.log https://gist.github.com/cd1a4a1323c94d0284d4001fe364bf71
Appreciate your help!
Hi Sumit et al.,
Still like some help to resolve this.
Thank you for the logs. Unfortunately I cannot see the reason in the logs why it does not work. I'll have to replicate your setup and try to reproduce the issue and will send my findings in a few days.
bye, Sumit
-- 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?
-- 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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On Tue, Apr 10, 2018 at 01:30:44PM +0200, Sumit Bose wrote:
On Mon, Apr 09, 2018 at 10:53:51AM -0400, Asif Iqbal wrote:
On Mon, Apr 2, 2018 at 12:20 PM, Asif Iqbal vadud3@gmail.com wrote:
On Tue, Mar 27, 2018 at 4:43 AM, Sumit Bose sbose@redhat.com wrote:
On Fri, Mar 23, 2018 at 06:13:39PM -0400, Asif Iqbal wrote:
On Thu, Mar 22, 2018 at 2:51 PM, Asif Iqbal vadud3@gmail.com wrote:
> [..stripped for brevity..] >> > > > So I see 5% of current users have mnetid with leading 0. >> > > > >> > > > So I never used sss_override. How do I use sss_override to
make
>> mnetid >> > > > 004311 >> > > > to work with sss when ldap id mapping tries to map 4311
instead?
>> > > > >> > > > Appreciate your help! >> > > >> > > I haven't tested it with your setup but >> > > >> > > sss_override user_add mwvande --uid 4311 --gid 4311 >> > > sss_override group_add mwvande --gid 4311 >> > > >> > > should create the needed override data so that user and group
mwvande
>> > > can be looked up with the ID 4311. >> > > >> > >> > >> > So I can lookup by 4311 after this. Very nice! >> > >> > Do I need to restart sssd after these two commands? >> >> You have to restart SSSD after adding the first overrides to switch
on
>> the override handling. If you add additional override later on you
do
>> not have to restart SSSD, but you might need to wait until some
cache
>> timeouts are passed before the overridden values are shown. >> > > > I have a user today complained whose mnetid has leading 0s > > [mwvande@example:]$ ssh sgx2-brdr-01 > > No user exists for uid 4311 > > I already have the sss_override ran last week for 100 users last
week and
> sssd was restarted. > > > > I am still wondering if there is a gap in my using sss_override
I have ran this, example commands, for all users with leading 0s in
mnetid
sss_override user-add mwvande --uid 4311--gid 4311 sss_override group-add mwvande --gid 4311
Then I ran the systemctl restart sssd
As said earlier I haven't tested overrides with your type of setup, so I'm not sure if they work as expected. After adding the overrides and restarting SSSD with debug_level=9 in the [nss] and [domain/...] sections of sssd.conf, can you call 'sss_cache -E' and 'getent passwd 4311' and send me the related logs.
bye, Sumit
# sss_cache -E # getent passwd 4311 (no output)
sssd_LDAP.log https://gist.github.com/7170405abc3c7b8a2fac0211f4452aab
sssd_nss.log https://gist.github.com/cd1a4a1323c94d0284d4001fe364bf71
Appreciate your help!
Hi Sumit et al.,
Still like some help to resolve this.
Thank you for the logs. Unfortunately I cannot see the reason in the logs why it does not work. I'll have to replicate your setup and try to reproduce the issue and will send my findings in a few days.
I was able to reproduce the issue if I use a string attribute with a leading white-space as UID attribute. I have to think a bit about how this can be fixed in a general way.
bye, Sumit
bye, Sumit
-- 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?
-- 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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On Wed, Apr 18, 2018 at 10:49 AM, Sumit Bose sbose@redhat.com wrote:
On Tue, Apr 10, 2018 at 01:30:44PM +0200, Sumit Bose wrote:
On Mon, Apr 09, 2018 at 10:53:51AM -0400, Asif Iqbal wrote:
On Mon, Apr 2, 2018 at 12:20 PM, Asif Iqbal vadud3@gmail.com wrote:
On Tue, Mar 27, 2018 at 4:43 AM, Sumit Bose sbose@redhat.com
wrote:
On Fri, Mar 23, 2018 at 06:13:39PM -0400, Asif Iqbal wrote:
On Thu, Mar 22, 2018 at 2:51 PM, Asif Iqbal vadud3@gmail.com
wrote:
> > [..stripped for brevity..] >>> > > > So I see 5% of current users have mnetid with leading 0. >>> > > > >>> > > > So I never used sss_override. How do I use sss_override
to
make
>>> mnetid >>> > > > 004311 >>> > > > to work with sss when ldap id mapping tries to map 4311
instead?
>>> > > > >>> > > > Appreciate your help! >>> > > >>> > > I haven't tested it with your setup but >>> > > >>> > > sss_override user_add mwvande --uid 4311 --gid 4311 >>> > > sss_override group_add mwvande --gid 4311 >>> > > >>> > > should create the needed override data so that user and
group
mwvande
>>> > > can be looked up with the ID 4311. >>> > > >>> > >>> > >>> > So I can lookup by 4311 after this. Very nice! >>> > >>> > Do I need to restart sssd after these two commands? >>> >>> You have to restart SSSD after adding the first overrides to
switch
on
>>> the override handling. If you add additional override later
on you
do
>>> not have to restart SSSD, but you might need to wait until
some
cache
>>> timeouts are passed before the overridden values are shown. >>> >> >> >> I have a user today complained whose mnetid has leading 0s >> >> [mwvande@example:]$ ssh sgx2-brdr-01 >> >> No user exists for uid 4311 >> >> I already have the sss_override ran last week for 100 users
last
week and
>> sssd was restarted. >> >> >> >> > I am still wondering if there is a gap in my using sss_override > > I have ran this, example commands, for all users with leading
0s in
mnetid
> > sss_override user-add mwvande --uid 4311--gid 4311 > sss_override group-add mwvande --gid 4311 > > Then I ran the systemctl restart sssd
As said earlier I haven't tested overrides with your type of setup,
so
I'm not sure if they work as expected. After adding the overrides
and
restarting SSSD with debug_level=9 in the [nss] and [domain/...] sections of sssd.conf, can you call 'sss_cache -E' and 'getent
passwd
4311' and send me the related logs.
bye, Sumit
# sss_cache -E # getent passwd 4311 (no output)
sssd_LDAP.log https://gist.github.com/
7170405abc3c7b8a2fac0211f4452aab
sssd_nss.log https://gist.github.com/cd1a4a1323c94d0284d4001fe364bf
71
Appreciate your help!
Hi Sumit et al.,
Still like some help to resolve this.
Thank you for the logs. Unfortunately I cannot see the reason in the logs why it does not work. I'll have to replicate your setup and try to reproduce the issue and will send my findings in a few days.
I was able to reproduce the issue if I use a string attribute with a leading white-space as UID attribute. I have to think a bit about how this can be fixed in a general way.
I am glad(?) you saw same issue. Appreciate your help!
bye, Sumit
On Wed, Apr 18, 2018 at 10:49 AM, Sumit Bose sbose@redhat.com wrote:
[.. stripped for brevity ..]
Hi Sumit et al.,
Still like some help to resolve this.
Thank you for the logs. Unfortunately I cannot see the reason in the logs why it does not work. I'll have to replicate your setup and try to reproduce the issue and will send my findings in a few days.
I was able to reproduce the issue if I use a string attribute with a leading white-space as UID attribute. I have to think a bit about how this can be fixed in a general way.
bye, Sumit
Hi Sumit,
Let me know if you need something for me. I am still looking for a workaround
Appreciate your help!
bye, Sumit
On Tue, Apr 24, 2018 at 1:35 PM, Asif Iqbal vadud3@gmail.com wrote:
On Wed, Apr 18, 2018 at 10:49 AM, Sumit Bose sbose@redhat.com wrote:
[.. stripped for brevity ..]
Hi Sumit et al.,
Still like some help to resolve this.
Thank you for the logs. Unfortunately I cannot see the reason in the logs why it does not work. I'll have to replicate your setup and try to reproduce the issue and will send my findings in a few days.
I was able to reproduce the issue if I use a string attribute with a leading white-space as UID attribute. I have to think a bit about how this can be fixed in a general way.
bye, Sumit
Hi Sumit,
Let me know if you need something for me. I am still looking for a workaround
Appreciate your help!
Hi Sumit,
Were you able to find a workaround for this?
Appreciate your help
On Wed, May 2, 2018 at 3:02 PM, Asif Iqbal vadud3@gmail.com wrote:
On Tue, Apr 24, 2018 at 1:35 PM, Asif Iqbal vadud3@gmail.com wrote:
On Wed, Apr 18, 2018 at 10:49 AM, Sumit Bose sbose@redhat.com wrote:
[.. stripped for brevity ..]
Hi Sumit et al.,
Still like some help to resolve this.
Thank you for the logs. Unfortunately I cannot see the reason in the logs why it does not work. I'll have to replicate your setup and try to reproduce the issue and will send my findings in a few days.
I was able to reproduce the issue if I use a string attribute with a leading white-space as UID attribute. I have to think a bit about how this can be fixed in a general way.
bye, Sumit
Hi Sumit,
Let me know if you need something for me. I am still looking for a workaround
Appreciate your help!
Hi Sumit,
Were you able to find a workaround for this?
Appreciate your help
Hi Sumit,
Do you know if there might be a workaround where may be we setup a ldap replica and make change on the some of the attributes on the local copy instead?
May be that would be a possible solution?
-- 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?
On Wed, May 23, 2018 at 02:03:11PM -0400, Asif Iqbal wrote:
On Wed, May 2, 2018 at 3:02 PM, Asif Iqbal vadud3@gmail.com wrote:
On Tue, Apr 24, 2018 at 1:35 PM, Asif Iqbal vadud3@gmail.com wrote:
On Wed, Apr 18, 2018 at 10:49 AM, Sumit Bose sbose@redhat.com wrote:
[.. stripped for brevity ..]
> Hi Sumit et al.,
Still like some help to resolve this.
Thank you for the logs. Unfortunately I cannot see the reason in the logs why it does not work. I'll have to replicate your setup and try to reproduce the issue and will send my findings in a few days.
I was able to reproduce the issue if I use a string attribute with a leading white-space as UID attribute. I have to think a bit about how this can be fixed in a general way.
bye, Sumit
Hi Sumit,
Let me know if you need something for me. I am still looking for a workaround
Appreciate your help!
Hi Sumit,
Were you able to find a workaround for this?
Appreciate your help
Hi Sumit,
Do you know if there might be a workaround where may be we setup a ldap replica and make change on the some of the attributes on the local copy instead?
May be that would be a possible solution?
yes, as long as the UID and GID attributes are real numerical values it should work.
bye, Sumit
-- 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?
-- 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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted....
On Fri, May 25, 2018 at 3:04 PM, Sumit Bose sbose@redhat.com wrote:
Hi Sumit,
Do you know if there might be a workaround where may be we setup a ldap replica and make change on the some of the attributes on the local copy instead?
May be that would be a possible solution?
yes, as long as the UID and GID attributes are real numerical values it should work.
Yes, I have not done ldap replication. Trying to see how to keep a live replication where mnetid attribute is string and how to overwrite a local copy of mnetid as numeric
Let me know if you have any hint. I probably will ping openldap mailing list.
bye, Sumit
On Mon, Mar 12, 2018 at 5:59 AM, Sumit Bose sbose@redhat.com wrote:
On Sun, Mar 11, 2018 at 10:25:24AM -0400, Asif Iqbal wrote:
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.
You might want to try local overrides, see man sss_override for details.
As an alternative you might want to try to enable enumeration. After the initial enumeration run is done all users and groups are already in SSSD's cache and lookups by id should work. But I'm not sure if enumeration can handle you setup where user and groups are defined by the same LDAP object.
Finally, if it is possible to remove the leading '0's from mnetid it should work as well because then '(mnetid=4311)' would match as string as well.
So on a tangent from my original question I got a response from IT saying "It seems like you are trying to use a value for something it was never meant to be used for"
They are referring to mnetid. As you can see there is huge reluctance in helping. to fix this issue.
bye, Sumit
Appreciate any help
On Mar 8, 2018 11:29 PM, "Asif Iqbal" vadud3@gmail.com wrote:
On Wed, Feb 28, 2018 at 4:27 PM, Jakub Hrozek jhrozek@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@gmail.com wrote:
On Tue, Feb 27, 2018 at 1:12 PM, Asif Iqbal vadud3@gmail.com
wrote:
On Tue, Feb 27, 2018 at 3:37 AM, Sumit Bose sbose@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 80974I 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@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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.
fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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?
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users@lists.fedorahosted.org
-
Asif Iqbal -
Sumit Bose