Learn more about these different git repos.
Other Git URLs
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
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>
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.13
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
rhbz: => todo
I cannot reproduce anymore. Tested with two different AD servers.
Closing
resolution: => worksforme status: new => closed
rhbz: todo => 0
Metadata Update from @lslebodn: - Issue assigned to lslebodn - Issue set to the milestone: SSSD 1.13.1
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/3731
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.