9:05 p.m.
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: sssd(a)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,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 = sssd(a)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
2:54 a.m.
New subject: SSSD on CentOS 7 failing to start when connecting to Samba 4.8.3 AD via LDAP
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.iovox(a)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: sssd(a)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 = sssd(a)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(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)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/
3:20 a.m.
New subject: SSSD on CentOS 7 failing to start when connecting to Samba 4.8.3 AD via LDAP
On 23 Jul 2018, at 04:05, Mark Johnson
<mark.johnson.iovox(a)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: sssd(a)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 = sssd(a)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(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)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.fedorahost...
8:38 p.m.
New subject: SSSD on CentOS 7 failing to start when connecting to Samba 4.8.3 AD via LDAP
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 <jhrozek(a)redhat.com> wrote:
> On 23 Jul 2018, at 04:05, Mark Johnson <mark.johnson.iovox(a)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: sssd(a)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 = sssd(a)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(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)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(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)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/
2100
days inactive
2102
days old
sssd-users@lists.fedorahosted.org
3 comments
3 participants
participants (3)
-
Jakub Hrozek -
John Hearns -
Mark Johnson