> On 23 Jul 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=*))(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: 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]
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 = 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/NDBFE7BJMQBZDT7LQJRSV2NB2Y426WWH/
