Thanks for the tip on the sudo_provider setting. I was trying to work out how to do that but couldn't find the exact option.
I managed to find the solution to my original problem through some trial and error. Seems I needed to set "ldap_referrals = false" in my config. Put that in and it all started and worked correctly. Thanks, Mark J On 23 July 2018 at 18:20, Jakub Hrozek <[email protected]> wrote: > > > > On 23 Jul 2018, at 04:05, Mark Johnson <[email protected]> > wrote: > > > > I've been going around in circles with this for days and I'm stuck. I'm > trying to run up a new AD environment with only Samba 4.8.3 servers that > we'll authenticate user server access against via SSSD/LDAP using a simple > bind. All of our servers are either CentOS 6 or 7. > > > > I've created a test environment with a single Samba AD 4.8.3 server as > the AD server, a Windows 7 client to run RSAT and a CentOS 6 and CentOS 7 > server to test user authentication. The Samba server is up and running and > I can manage the directory via RSAT. I've set up the CentOS 6 server and > can successfully authenticate user logins on this via using SSSD/LDAP to > the AD. However, the issue I have is with the CentOS 7 server. I've > basically copied the SSSD config from the CentOS 6 server so everything is > the same. However, when I start SSSD on the CentOS 7 server, it binds > successfully and does an initial searchRequest which it gets a result from > but after doing the subsequent searchRequests on Configuration, > ForestDnsZones and DomainDnsZones I just see a RST from the server and the > whole process starts over again. Over the third failure, SSSD fails to > start and stops trying. > > > > Comparing packet captures on the AD server when starting SSSD on both > servers, the initial ROOT search request and response are identical as is > the bind request and response. However, the first wholeSubtree search > request is where things start looking different. On the CentOS 6 server, > it shows a filter in the request of: > > Filter: (&(&(cn=smtp)(ipServiceProtocol=dccp))(objectclass=ipService)) > > and there are 4 attributes in the request - objectClass, cn, > ipServicePort, ipServiceProtocol > > > > Whereas on the CentOS 7 server, the filter looks like this: > > Filter: (&(objectClass=sudoRole)(|(|(|(|(|(|(|(|(|(!(sudoHost=*))( > sudoHost=ALL))(sudoHost=ldaptest7.company.com))(sudoHost= > ldaptest7))(sudoHost=192.168.193.62))(sudoHost=192.168.192. > 0/23))(sudoHost=fe80::5054:ff:fef2:26ed))(sudoHost=fe80::/6 > > with 13 attributes - objectClass, cn, and a bunch of sudo attributes. > > > > The response from the Samba server to each of these is nearly > identical. Both servers then send searchRequests for Configuration, > ForestDnsZones and DomainDnsZones but with the same filter differences > above. This is the point of failure for the CentOS 7 server. The other > server gets a successful response from the Samba server, but the CentOS 7 > server just gets an ACK. When I up the debug level on SSSD on the CentOS 7 > server, I see a few different errors but I'm not sure which of these show > cause or effect. Examples... > > > > (Thu Jul 19 23:40:34 2018) [sssd[be[AD.COMPANY.COM]]] > [common_parse_search_base] (0x0100): Search base added: > [SUDO][dc=ad,dc=company,dc=com][SUBTREE][] > > (Thu Jul 19 23:40:34 2018) [sssd[be[AD.COMPANY.COM]]] > [common_parse_search_base] (0x0100): Search base added: > [AUTOFS][dc=ad,dc=company,dc=com][SUBTREE][] > > (Thu Jul 19 23:40:34 2018) [sssd[be[AD.COMPANY.COM]]] > [dp_client_register] (0x0100): Cancel DP ID timeout [0x55941e9a6860] > > (Thu Jul 19 23:40:34 2018) [sssd[be[AD.COMPANY.COM]]] [dp_find_method] > (0x0100): Target [subdomains] is not initialized > > (Thu Jul 19 23:40:34 2018) [sssd[be[AD.COMPANY.COM]]] > [dp_req_reply_gen_error] (0x0080): DP Request [Subdomains #0]: Finished. > Target is not supported with this configuration. > > > > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] > [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP' > > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] > [set_server_common_status] (0x0100): Marking server '192.168.192.50' as > 'resolving name' > > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] > [set_server_common_status] (0x0100): Marking server '192.168.192.50' as > 'name resolved' > > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] > [sdap_get_server_opts_from_rootdse] (0x0100): Setting AD compatibility > level to [4] > > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] > [sdap_cli_auth_step] (0x0100): expire timeout is 900 > > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] > [simple_bind_send] (0x0100): Executing simple bind as: [email protected] > > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] > [fo_set_port_status] (0x0100): Marking port 389 of server '192.168.192.50' > as 'working' > > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] > [set_server_common_status] (0x0100): Marking server '192.168.192.50' as > 'working' > > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] > [be_run_online_cb] (0x0080): Going online. Running callbacks. > > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] [be_ptask_enable] > (0x0080): Task [SUDO Smart Refresh]: already enabled > > (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] > [sdap_process_result] (0x0040): ldap_result error: [Can't contact LDAP > server] > > hmm, I don’t know why would libldap return ‘Can’t contact LDAP server > here..” > > > sssd_be: io.c:224: ber_flush2: Assertion `( (sb)->sb_opts.lbo_valid == > 0x3 )' failed. > > moreover there is some assertion in the lber code.. > > > (Thu Jul 19 23:40:44 2018) [sssd] [svc_child_info] (0x0040): Child > [1570] terminated with signal [6] > > > > ..which causes the sssd_be process to SIGABRT. > I’ve never seen this issue before.. > > > I get the feeling that the issue is around sudo somehow, but I don't > believe I have sudo enabled in my sssd. > > > > So one thing that changed between 6 and 7 is that unless you explicitly > disable the sudo provider it is always ran. So one thing to check might be > to explicitly set “sudo_provider=none” in the config file.. > > > Here's my sssd.conf from the CentOS 7 server: > > > > [sssd] > > config_file_version = 2 > > reconnection_retries = 3 > > sbus_timeout = 30 > > services = nss, pam > > domains = AD.COMPANY.COM > > > > [nss] > > filter_groups = root,bin,daemon,sys,adm,tty,disk,lp,mem,kmem,wheel,mail, > uucp,man,games,gopher,video,dip,ftp,lock,audio,nobody, > users,floppy,vcsa,utmp,utempter,rpc,cdrom,tape,dialout,rpcuser,nfsnobody, > sshd,cgred,screen,saslauth,apache,mailnull,smmsp,mysql > > filter_users = root,bin,daemon,adm,lp,sync,shutdown,halt,mail,uucp, > operator,games,gopher,ftp,nobody,vcsa,rpc,rpcuser,nfsnobody,sshd,saslauth, > apache,mailnull,smmsp,mysql,apache > > reconnection_retries = 3 > > #entry_cache_timeout = 300 > > entry_cache_nowait_percentage = 75 > > > > [domain/AD.COMPANY.COM] > > enumerate = false > > cache_credentials = true > > > > id_provider = ldap > > #auth_provider = ldap > > > > ldap_schema = rfc2307bis > > ldap_user_principal = userPrincipalName > > ldap_user_fullname = displayName > > ldap_user_name = sAMAccountName > > ldap_user_object_class = user > > ldap_user_home_directory = unixHomeDirectory > > ldap_user_shell = loginShell > > ldap_group_object_class = group > > ldap_force_upper_case_realm = True > > > > ldap_uri = ldap://192.168.192.50 > > > > ldap_search_base = dc=ad,dc=company,dc=com > > ldap_id_use_start_tls = false > > ldap_tls_reqcert = never > > ldap_tls_cacert = /etc/sssd/ca.company.com.crt > > > > access_provider = ldap > > ldap_access_filter = memberOf=cn=ServerAdmins,ou= > Groups,dc=ad,dc=company,dc=com > > > > ldap_default_authtok_type = password > > ldap_default_bind_dn = [email protected] > > ldap_default_authtok = Password1 > > > > > > [pam] > > > > > > > > I tried adding the sudo roles schema to active directory to see if it > would resolve the sssd not starting issue, but while I was able to > successfully import the schema via ldifde and create the sudoers OU in the > root, but when it came to adding the sudoRole object via ADSIEdit, I got an > Operation Failed error - "An invalid directory pathname was passed". So, > I'm not sure if adding this will resolve the issue or not. > > > > There was no sudoers entry in nsswitch.conf so I tried specifically > adding the following line to explicitly omit sss in case it has become a > default setting: > > > > sudoers: files > > > > But that made no difference. > > > > I've tried all of the above twice from scratch to be sure and I got the > same results both times. I can successfully query the directory via the > same ldapsearch command from both CentOS servers. I don't know if I'm > completely barking up the wrong tree. I'm just going around in circles now > and I can't think of anything new to try. Oh, and here's my smb.conf... > > > > # Global parameters > > [global] > > bind interfaces only = Yes > > dns forwarder = 192.168.192.1 > > interfaces = lo eth0 > > netbios name = TUG-SAMBA > > realm = AD.COMPANY.COM > > server role = active directory domain controller > > workgroup = COMPANY > > idmap_ldb:use rfc2307 = yes > > dsdb:schema update allowed = yes > > ldap server require strong auth = no > > > > [netlogon] > > path = /var/lib/samba/sysvol/ad.company.com/scripts > > read only = No > > > > [sysvol] > > path = /var/lib/samba/sysvol > > read only = No > > > > _______________________________________________ > > sssd-users mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > 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.org/message/CSI4GUUP73FBQUNSDMZPJMOAXF6RQWES/ > _______________________________________________ > sssd-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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.org/message/NDBFE7BJMQBZDT7LQJRSV2NB2Y426WWH/ >
_______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]/message/QWWGQN7ZII57WTOGORWREIKSU2JPH3K7/
