Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 14 replies
  • Subscribers 40 subscribers
  • Views 3171 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

XG fails to join domain 18.5.5

NTW Infrastructure

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?



This thread was automatically locked due to age.
Parents
  • +1

    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.

Reply
  • +1

    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.

Children
  • 0 in reply to Michael Dunn

    Hi

    Thanks for the reply.  Quite a good explanation.  Testing yesterday did proved that plain text over 389 worked fine.  It was just TLS over 636 side that didnt.

    I will look to try STARTTLS over 389 and see if that works for us.

  • 0 in reply to Michael Dunn

    Hi

    We have done a load of testing.  Tested TLS and STARTTLS from a non Sophos device and it all seems fine, just can not get it to work from the XG.

    One thought we did have was we use an internal Root CA and a couple of Intermediate CA's.  Normally we would put all three Certs onto the Sophos but one of my colleagues has had an issue with another Linux based security device where we needed to roll the cert chain into a single file.  Does Sophos require this or does it support this?

    We have tried but still getting the errors.

    My feeling is it is down to the Certs but trying to narrow it down is hard.

Unfiltered HTML