REGRESSION: Unable to retrieve data with wrong domain SID #3731

sssd-bot · 2020-05-02T13:15:29Z

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/2690

Created at 2015-06-24 10:32:31 by lslebodn
Closed as Invalid
Assigned to lslebodn

If there is a typo in value of the option ldap_idmap_default_domain_sid (doesn't match the AD domain sid) then sssd is not able to retrieve any information about users. It works with sssd 1.12.

sssd.conf:

    [sssd]
    config_file_version = 2
    services = nss, pam
    domains = ADTEST

    [nss]
    filter_groups = root
    filter_users = root
    default_shell = /bin/bash
    override_homedir = /home/%u

    [pam]

    [domain/ADTEST]
    debug_level = 0xFFF0
    id_provider = ldap
    ldap_uri = ldap://$AD_SERVER1
    ldap_schema = ad
    ldap_id_mapping = True
    ldap_default_bind_dn = $AD_SERVER1_BINDDN
    ldap_default_authtok = $AD_SERVER1_BINDPASS
    ldap_idmap_default_domain_sid=S-1-5-21-1111111-2222222-3333333
    ldap_idmap_default_domain=
    ldap_tls_cacert = /etc/openldap/certs/ad_cert.pem

Reproducer is to retrieve info about user from AD getent passwd aduser

Comments

Comment from lslebodn at 2015-06-24 13:10:32

It works for me after reverting patches for GPO and referrals.

commit 176244cb1e9df96ce36d36556de1fd766582b1dc
Author: Lukas Slebodnik <lslebodn@redhat.com>
Date:   Sat May 30 09:33:34 2015 -0400

    SDAP: Check return value before using output arguments
    
    ==18139== Conditional jump or move depends on uninitialised value(s)
    ==18139==    at 0x14400F1B: generic_ext_search_handler.isra.3 (sdap_async.c:1626)
    ==18139==    by 0x879D7E3: tevent_common_loop_immediate (tevent_immediate.c:135)
    ==18139==    by 0x87A20CD: epoll_event_loop_once (tevent_epoll.c:907)
    ==18139==    by 0x87A07D6: std_event_loop_once (tevent_standard.c:114)
    ==18139==    by 0x879CFBC: _tevent_loop_once (tevent.c:530)
    ==18139==    by 0x879D15A: tevent_common_loop_wait (tevent.c:634)
    ==18139==    by 0x87A0776: std_event_loop_wait (tevent_standard.c:140)
    ==18139==    by 0x5293862: server_loop (server.c:668)
    ==18139==    by 0x10EA41: main (data_provider_be.c:2909
    
    Related tickets:
    https://fedorahosted.org/sssd/ticket/2645
    https://fedorahosted.org/sssd/ticket/2662
    
    Reviewed-by: Pavel Reichl <preichl@redhat.com>

commit 31bafc0d6384a30859aa18f3bd22275aec6ee2ed
Author: Stephen Gallagher <sgallagh@redhat.com>
Date:   Fri May 1 16:26:36 2015 -0400

    AD GPO: Support processing referrals
    
    For GPOs assigned to a site, it's possible that their definition
    actually exists in another domain. To retrieve this information,
    we need to follow the referral and perform a base search on
    another domain controller.
    
    Resolves:
    https://fedorahosted.org/sssd/ticket/2645
    
    Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>

commit c9db9d3e3d1a51117a64b366ec866bbeb009c57f
Author: Stephen Gallagher <sgallagh@redhat.com>
Date:   Fri May 1 11:42:06 2015 -0400

    LDAP: Support returning referral information
    
    Some callers may be interested in the raw referral values returned from
    a lookup. This patch allows interested consumers to get these referrals
    back and process them if they wish. It does not implement a generic
    automatic following of referrals.
    
    Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>

Comment from jhrozek at 2015-06-25 15:48:24

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.13

Comment from jhrozek at 2015-07-04 16:17:48

Assigning to Lukas because he can reproduce and moving to the immediate milestone.

milestone: SSSD 1.13.2 => SSSD 1.13.1
owner: somebody => lslebodn

Comment from jhrozek at 2015-08-18 12:15:24

Fields changed

rhbz: => todo

Comment from lslebodn at 2015-09-03 15:08:52

I cannot reproduce anymore. Tested with two different AD servers.

Closing