Mark, for information you can increase the mumber of retries by reconnection_retries = N
However that does not help you with your problem! On 23 July 2018 at 04:05, Mark Johnson <mark.johnson.io...@gmail.com> 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=*))(su > doHost=ALL))(sudoHost=ldaptest7.company.com))(sudoHost=ldapt > est7))(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: s...@ad.company.com > (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] > sssd_be: io.c:224: ber_flush2: Assertion `( (sb)->sb_opts.lbo_valid == 0x3 > )' failed. > (Thu Jul 19 23:40:44 2018) [sssd] [svc_child_info] (0x0040): Child [1570] > terminated with signal [6] > > I get the feeling that the issue is around sudo somehow, but I don't > believe I have sudo enabled in my sssd. > > 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,di > sk,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,sh > utdown,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=Gr > oups,dc=ad,dc=company,dc=com > > ldap_default_authtok_type = password > ldap_default_bind_dn = s...@ad.company.com > 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 -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@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.org/message/CSI4GUUP73FBQUNSDMZPJMOAXF6RQWES/ > >
_______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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.org/message/3FY6XORJUWHFJUSXAON5CUTVBPP3UQTV/
