#3544 pysss_nss_idmap.getsidbyid() does not work with POSIX attributes if the attributes are not replicated to GC
Closed: duplicate 6 years ago Opened 6 years ago by jhrozek.

This might not be a big deal since so far nobody noticed, but let's track the issue anyway.

If a domain does not use ID mapping, but regular POSIX attributes and at the same time the POSIX attributes are not replicated to the Global Catalog, the getsidbyid() function does not work.

This is because the internal BE_REQ_USER_AND_GROUP request first searches the main domain by ID. This triggers the check for POSIX IDs, which doesn't find anything (not because the ID is not present, but only because it's not replicated to the global catalog) and terminates the search in the first domain. The caller doesn't restart the whole request, but the request just moves to the next domain, which is searched, this time using the LDAP connection, but we never search the LDAP port of the first domain again.

The root cause is probably not handling the POSIX check well, because the logs say:

(Mon Oct  9 18:50:24 2017) [sssd[be[win.trust.test]]] [fo_set_port_status] (0x0100): Marking port 3268 of server 'childdc.child.win.trust.test' as 'working'                                                                                 
(Mon Oct  9 18:50:24 2017) [sssd[be[win.trust.test]]] [set_server_common_status] (0x0100): Marking server 'childdc.child.win.trust.test' as 'working'                                                                                        
(Mon Oct  9 18:50:24 2017) [sssd[be[win.trust.test]]] [fo_set_port_status] (0x0400): Marking port 3268 of duplicate server 'childdc.child.win.trust.test' as 'working'                                                                       
(Mon Oct  9 18:50:34 2017) [sssd[be[win.trust.test]]] [sdap_posix_check_next] (0x0400): Searching for POSIX attributes with base [DC=win,DC=trust,DC=test]
(Mon Oct  9 18:50:34 2017) [sssd[be[win.trust.test]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(|(&(uidNumber=*)(objectclass=user))(&(gidNumber=*)(objectclass=group)))][DC=win,DC=trust,DC=test].                
(Mon Oct  9 18:50:34 2017) [sssd[be[win.trust.test]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectclass]                
(Mon Oct  9 18:50:34 2017) [sssd[be[win.trust.test]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber]                          
(Mon Oct  9 18:50:34 2017) [sssd[be[win.trust.test]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber]                      
(Mon Oct  9 18:50:39 2017) [sssd[be[win.trust.test]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set                                                                                                      
(Mon Oct  9 18:50:39 2017) [sssd[be[win.trust.test]]] [sdap_posix_check_done] (0x1000): Cycled through all bases                                
(Mon Oct  9 18:50:44 2017) [sssd[nss]] [setup_client_idle_timer] (0x4000): Idle timer re-set for client [0x1681630][20]       
(Mon Oct  9 18:50:48 2017) [sssd[be[win.trust.test]]] [dp_req_done] (0x0400): DP Request [Account #4]: Request handler finished [0]: Success                 
(Mon Oct  9 18:50:48 2017) [sssd[be[win.trust.test]]] [_dp_req_recv] (0x0400): DP Request [Account #4]: Receiving request data.                                                                                                              
(Mon Oct  9 18:50:48 2017) [sssd[be[win.trust.test]]] [dp_req_reply_list_success] (0x0400): DP Request [Account #4]: Finished. Success.                                                                                                      
(Mon Oct  9 18:50:48 2017) [sssd[be[win.trust.test]]] [dp_req_reply_std] (0x1000): DP Request [Account #4]: Returning [Internal Error]: 3,5,Lookup by SID failed

Note the search just checks the presence of the uidNumber or the gidNumber, that's the POSIX presence check. The next search cycles to the next domain already

(Mon Oct  9 18:51:13 2017) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x41e7b4:7:20000@child.win.trust.test]                                                                                                           
(Mon Oct  9 18:51:13 2017) [sssd[be[win.trust.test]]] [dp_table_value_destructor] (0x0400): Removing [0:1:0x0001:18::child.win.trust.test:idnumber=20000] from reply table                                                                   
(Mon Oct  9 18:51:13 2017) [sssd[be[win.trust.test]]] [dp_req_destructor] (0x0400): DP Request [Account #5]: Request removed.                                                                                                                
(Mon Oct  9 18:51:13 2017) [sssd[be[win.trust.test]]] [dp_req_destructor] (0x0400): Number of active DP request: 0                                                                                                                           
(Mon Oct  9 18:51:14 2017) [sssd[nss]] [setup_client_idle_timer] (0x4000): Idle timer re-set for client [0x1681630][20]                                                                                                                      
(Mon Oct  9 18:51:24 2017) [sssd[nss]] [setup_client_idle_timer] (0x4000): Idle timer re-set for client [0x16880c0][21]                                                                                                                      
(Mon Oct  9 18:51:44 2017) [sssd[nss]] [client_idle_handler] (0x2000): Terminating idle client [0x1681630][20]                                                                                                                               
(Mon Oct  9 18:51:44 2017) [sssd[nss]] [client_close_fn] (0x2000): Terminated client [0x1681630][20]                  
(Mon Oct  9 18:51:54 2017) [sssd[nss]] [setup_client_idle_timer] (0x4000): Idle timer re-set for client [0x16880c0][21]                                                                                                                      
(Mon Oct  9 18:52:24 2017) [sssd[nss]] [client_idle_handler] (0x2000): Terminating idle client [0x16880c0][21]                                                                                                                               
(Mon Oct  9 18:52:24 2017) [sssd[nss]] [client_close_fn] (0x2000): Terminated client [0x16880c0][21]                                                                                                                                         
(Mon Oct  9 18:54:45 2017) [sssd[nss]] [get_client_cred] (0x4000): Client creds: euid[0] egid[0] pid[25918].          
(Mon Oct  9 18:54:45 2017) [sssd[nss]] [setup_client_idle_timer] (0x4000): Idle timer re-set for client [0x16880c0][20]                                                                                                                      
(Mon Oct  9 18:54:45 2017) [sssd[nss]] [accept_fd_handler] (0x0400): Client connected!                                

Does 'ad_enable_gc = False' fix this? If yes I would like to suggest to close this ticket as dublicate of https://pagure.io/SSSD/sssd/issue/3538.

Yes ad_enable_gc=false does and feel free to close this ticket.

I mostly opened a new ticket because I wasn't sure if what is proposed in #3538 would cover this case -- because #3538 talks explicitly about finding a DN in the GC, but that won't work here, because we search by ID which is not replicated to GC. In my mind, #3538 is more about finding the DN by name and then searching the LDAP entry to make sure we have all the attributes.

But I'm also fine with adding a note to #3538, just as long as we don't forget to cover the case described here. And the fewer tickets, the better :-)

If the POSIX IDs are replicated to the GC #3538 would speed up the lookups by ID because we do not have to check all domains in the forest. And imo #3538 should include a fallback strategy for searches where the attributes are not replicated to the GC by default.

Metadata Update from @jhrozek:
- Issue close_status updated to: duplicate
- Issue status updated to: Closed (was: Open)

6 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4570

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata