XG fails to join domain 18.5.5

Question

Hi all 
 
 We are having trouble with a test instance of XG 18.5.5 in which we can not get it to join our domain. We are running some 18.5.1 devices which did not have any issues with joining a domain but 18.5.5 just does not play ball. 
 
 We get the following in the NASM logs: 
 Feb 06 13:45:23.454494Z [nasm] Log level set to INFO Feb 06 13:45:23.454570Z [nasm] init_nasm: launch in "non-auxiliary" mode [tid=f7584bc0] Feb 06 13:45:23.454637Z [nasm] protocol initialized successfully Feb 06 13:45:23.454667Z [nasm] NASM initialized successfully, driving towards endless loop Feb 06 13:45:23.454724Z [nasm] create_ntlmserver_thread(): AD SSO server thread created successfully (tid=f6981b40) Feb 06 13:45:23.459009Z [ntlmserver] initialize_fasm(): initialized successfully Feb 06 13:45:23.460179Z [ntlmserver] initialize_inmemorydb(): /tmp/ntlm_users.db opened successfully. Feb 06 13:45:23.460214Z [ntlmserver] initialize_local_socket(): initialized successfully Feb 06 13:45:23.460223Z [ntlmserver] ntlm_server() requesting status of AD channel Feb 06 13:45:23.462628Z [ntlmserver] client_request_processor(): new local client connected on fd=11, informing channel status to client Feb 06 13:45:23.462645Z [ntlmserver] inform_channel_status(): sumit DATA to proxy='0 0 0 0 0 0 0 0 5 0 0 0 ' Feb 06 13:45:23.462652Z [ntlmserver] inform_channel_status(): informing channel status to http proxy, channel status=0 Feb 06 13:45:23.918527Z [nasm] is_ad_join_required() AD join required due to detected change in smb.conf Feb 06 13:45:24.565643Z [nasm] connection closed, verify baby's health :) dos charset 'CP850' unavailable - using ASCII kinit succeeded but ads_sasl_spnego_gensec_bind(KRB5) failed for ldap/xxx with user[yyy] realm[zzz]: Invalid credentials 
 
 The credentials and server name are correct and test fine in the Authentication Server page. We have checked the usual things like DNS, Time, Server name and Device name etc and all seem fine. 
 
 The account we are using has all the required permission. 
 
 Checked all the logs and used the debug mode but nothing shouts at us. At a loss at the moment as to why this is happening and need to get this sorted ASAP as we have a load of devices that need upgrading. 
 
 Anybody have any ideas what we may be missing or anything else to look at?

Michael Dunn · Accepted Answer

Originally 17.5 and earlier did not allow you to select Connection Security, and all connections were plaintext/389. 
 18.0 (and 17.5 MR?) introduced configuration for Connection Security (SSL/TLS and StartTLS) and port. Only access_server used this, AD SSO still used plaintext on 389. 
 18.5 MR4 and later, AD SSO follows the Connection Security in that if either SSL/TLS or StartTLS are selected it will use StartTLS on 389 (which is the standard way of doing LDAPS on 389). It will also do certificate validation, if selected. 
 XG AD SSO uses winbindd underneath to talk to the AD Server. We have had a lot of trouble getting winbindd to do LDAPS with SSL/TLS over 636, so we only support STARTTLS on 389. We are also limited by winbindd in the error codes that we get back. Any failure is reported as Invalid Credentials even though it may or may not be. support.sophos.com/.../KB-000043818 
 As the Original Poster has said, they had no problems with 18.5 MR1 (where AD SSO always used plaintext/389) and now has problems with 18.5 MR5 (where AD SSO will try to use the configured settings - most likely being StartTLS/389). Access_server (which is used for User Portal, Captive Portal, Test Connection, and other things) also use the configured settings, but can do so more exactly. 
 If you are having problems in 18.5 MR5, first try changing the configuration to 389/plaintext and see if that works. Then your desired setting, with "Validate Server Certificate" off. If the Server Certificate is the problem, make sure that the AD server hostname that you are connecting to (in the Authentication Server settings) matches the certificate that the AD server is providing. Connecting by IP address not supported if you are verifying certificates. Make sure that the AD's certificate is signed by a CA that is installed on the XG. 
 If you want to use security, make sure that the AD SSO server supports StartTLS over 389. In doing a quick google for information, this is enabled by default. More searching gives a lot of information on how to disable unencrypted, but not how to enable encrypted. For example https://kurtroggen.wordpress.com/2018/08/03/are-you-using-ldap-over-ssl-tls/ https://platformadmin.com/blogs/paul/2019/06/reviewing-ssl-tls-certificate-chain-for-active-directory-server/ 
 You may want to check the AD server logs at the time that the XG is connecting. Note: There is no difference between 18.5 MR5 and later releases in terms of AD SSO connecting to AD servers. That being said, if you are going through an upgrade it is recommend to upgrade to a recent version. Sophos maintains security releases for the "the last two releases" which means 19.5 and 19.0. 19.0 MR2 was recently released and is what I would recommend for someone who does not want to be on the leading edge. 19.5 MR1 is expected to be released soon, with the latest and greatest.

XG fails to join domain 18.5.5

Top Replies