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

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.
  • Has this device been joined before? Or another with the same name?

    Search the ADS for a duplicate computer account and delete that old entry. Wait some minutes to replicate this to all AD controllers, then try again.

    Mit freundlichem Gruß, best regards from Germany,

    Philipp Rusch

    New Vision GmbH, Germany
    Sophos Silver-Partner

    If a post solves your question please use the 'Verify Answer' button.

  • Hi Phlipp

    We have already tried this and can not find a duplicate.

    We have also checked the the smb.conf file to see what it had originally called the device to check for that.

    Vielen Danke

  • Can you change the used PW of the account? Also reenter the PW of this account. 

    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

    This indicates, the account itself has a problem, maybe something with the encode mode. 


  • Hi

    I will try a different account as that account is live on a production system running 18.5.1 that has no issues.

  • Ok.

    I crated a new account with a simplistic password as we use quite complex ones.  Same issue.  I have enabled Debug mode and this is what was returned.

    Feb 07 09:25:36.865882Z [nasm] ads_config
    Feb 07 09:25:36.865890Z [nasm] Popped Server-wwwww
    Username: 'zzzzz'
    Password: 'XXX'
    Address: 'vvvvv'
    Realm: 'yyyyy'
    Feb 07 09:25:36.865897Z [nasm] pre_channel
    Feb 07 09:25:36.865907Z [nasm] is_ad_join_required() check smb.conf [ /cfs/smb.conf.3 ]
    Feb 07 09:25:36.865924Z [ntlmserver] ntlm_server() ---> epoll_wait() waiting 10s for events

    Feb 07 09:25:37.760088Z [nasm] calculate_md5sum() calculated md5sum of "/cfs/smb.conf.3" [line=6] = 655a84af7e03fa486580682d8f93031f
    Feb 07 09:25:37.760134Z [nasm] calculate_md5sum() calculated md5sum of "/tmp/smb.conf" [line=6] = bdc44fddfa10a4021149910516b93e36
    Feb 07 09:25:37.760141Z [nasm] is_ad_join_required() AD join required due to detected change in smb.conf
    Feb 07 09:25:37.760149Z [nasm] remove_previous_footprint: execute '/bin/ zzzzz XXX wwwww'
    Feb 07 09:25:37.760156Z [nasm] execute_command
    Feb 07 09:25:37.760164Z [nasm] imaginary_baby
    Feb 07 09:25:37.760309Z [nasm] waiting for '/bin/' to complete its job
    Feb 07 09:25:37.771437Z [nasm] hi_i_m_child
    Feb 07 09:25:37.771475Z [nasm] executing '/bin/'
    Feb 07 09:25:37.772205Z [nasm] execute_command (done)
    Feb 07 09:25:37.772219Z [nasm] execute_command
    Feb 07 09:25:37.772225Z [nasm] parsing arguments for '/bin/'
    Feb 07 09:25:37.772234Z [nasm] argument '/bin/' processed
    Feb 07 09:25:37.772241Z [nasm] transferring over to imaginary_baby to execute '/bin/'
    Feb 07 09:25:37.772247Z [nasm] imaginary_baby
    Feb 07 09:25:37.772346Z [nasm] waiting for '/bin/' to complete its job
    Feb 07 09:25:37.774300Z [nasm] hi_i_m_child
    Feb 07 09:25:37.774335Z [nasm] executing '/bin/'
    Feb 07 09:25:37.793765Z [nasm] execute_command (done)
    Feb 07 09:25:37.793786Z [nasm] execute_command
    Feb 07 09:25:37.793793Z [nasm] parsing arguments for 'cp -f /cfs/smb.conf.3 /tmp/smb.conf'
    Feb 07 09:25:37.793801Z [nasm] argument 'cp' processed
    Feb 07 09:25:37.793808Z [nasm] argument '-f' processed
    Feb 07 09:25:37.793814Z [nasm] argument '/cfs/smb.conf.3' processed
    Feb 07 09:25:37.793834Z [nasm] argument '/tmp/smb.conf' processed
    Feb 07 09:25:37.793841Z [nasm] transferring over to imaginary_baby to execute 'cp -f /cfs/smb.conf.3 /tmp/smb.conf'
    Feb 07 09:25:37.793847Z [nasm] imaginary_baby
    Feb 07 09:25:37.793973Z [nasm] waiting for 'cp' to complete its job
    Feb 07 09:25:37.797172Z [nasm] hi_i_m_child
    Feb 07 09:25:37.797236Z [nasm] executing 'cp'
    Got signal 12
    Feb 07 09:25:38.575299Z [nasm] execute_command (done)
    Feb 07 09:25:38.575326Z [nasm] execute_command
    Feb 07 09:25:38.575333Z [nasm] parsing arguments for 'cp -f /cfs/ldap.conf.3 /tmp/ldap.conf'
    Feb 07 09:25:38.575341Z [nasm] argument 'cp' processed
    Feb 07 09:25:38.575348Z [nasm] argument '-f' processed
    Feb 07 09:25:38.575354Z [nasm] argument '/cfs/ldap.conf.3' processed
    Feb 07 09:25:38.575360Z [nasm] argument '/tmp/ldap.conf' processed
    Feb 07 09:25:38.575367Z [nasm] transferring over to imaginary_baby to execute 'cp -f /cfs/ldap.conf.3 /tmp/ldap.conf'
    Feb 07 09:25:38.575373Z [nasm] imaginary_baby
    Feb 07 09:25:38.575520Z [nasm] waiting for 'cp' to complete its job
    Feb 07 09:25:38.580002Z [nasm] hi_i_m_child
    Feb 07 09:25:38.580044Z [nasm] executing 'cp'
    Feb 07 09:25:39.170582Z [nasm] execute_command (done)
    Feb 07 09:25:39.170602Z [nasm] net_ads_info
    Feb 07 09:25:39.170611Z [nasm] over to real_baby to get info regarding AD DC
    Feb 07 09:25:39.170617Z [nasm] real_baby
    Feb 07 09:25:39.170771Z [nasm] __parent
    Feb 07 09:25:39.173261Z [nasm] __child
    Feb 07 09:25:39.173323Z [nasm] executing '/oss/net'
    Feb 07 09:25:39.371872Z [nasm] read event on STDOUT_FILENO for '/oss/net'
    Feb 07 09:25:39.371904Z [nasm] connection closed, verify baby's health :)
    Feb 07 09:25:39.371931Z [nasm] __parent
    Feb 07 09:25:39.371939Z [nasm] real_baby
    Feb 07 09:25:39.371945Z [nasm] real_baby done, let's verify baby's exit status
    Feb 07 09:25:39.371952Z [nasm] /oss/net exited successfully, does it left anything for us ??
    Feb 07 09:25:39.371958Z [nasm] Looking out for DC name from net ads info result
    Feb 07 09:25:39.371964Z [nasm] we have 'LDAP server:' from net ads info
    Feb 07 09:25:39.371971Z [nasm] Comparing 'LDAP server:'
    Feb 07 09:25:39.371977Z [nasm] unable to locate DC name
    Feb 07 09:25:39.371984Z [nasm] Looking out for DC name from net ads info result
    Feb 07 09:25:39.371990Z [nasm] we have 'LDAP server name: wwwww' from net ads info
    Feb 07 09:25:39.371996Z [nasm] Comparing 'LDAP server name: wwwww'
    Feb 07 09:25:39.372002Z [nasm] V to locate DC name
    Feb 07 09:25:39.372009Z [nasm] DC hostname for server->yyyyy is 'wwwww'
    Feb 07 09:25:39.372027Z [nasm] net_ads_info
    Feb 07 09:25:39.372034Z [nasm] we've DC hostname 'wwwww' for server-yyyyy
    Feb 07 09:25:39.372057Z [nasm] throw
    Feb 07 09:25:39.372075Z [nasm] throw
    Feb 07 09:25:39.372083Z [nasm] /etc/hosts generated successfully with ' localhost
    wwwww wwwww
    ' contents
    Feb 07 09:25:39.372311Z [nasm] parse_address() returned [1] for [wwwww]
    Feb 07 09:25:39.372338Z [nasm] throw
    Feb 07 09:25:39.372354Z [nasm] throw
    Feb 07 09:25:39.372362Z [nasm] lmhosts generated successfully with ' ATLAS
    ' contents
    Feb 07 09:25:39.372371Z [nasm] execute_command
    Feb 07 09:25:39.372377Z [nasm] parsing arguments for 'rm -f /tmp/krb5.conf'
    Feb 07 09:25:39.372385Z [nasm] argument 'rm' processed
    Feb 07 09:25:39.372391Z [nasm] argument '-f' processed
    Feb 07 09:25:39.372398Z [nasm] argument '/tmp/krb5.conf' processed
    Feb 07 09:25:39.372412Z [nasm] transferring over to imaginary_baby to execute 'rm -f /tmp/krb5.conf'
    Feb 07 09:25:39.372419Z [nasm] imaginary_baby
    Feb 07 09:25:39.372548Z [nasm] waiting for 'rm' to complete its job
    Feb 07 09:25:39.374719Z [nasm] hi_i_m_child
    Feb 07 09:25:39.374762Z [nasm] executing 'rm'
    Feb 07 09:25:39.375345Z [nasm] execute_command (done)
    Feb 07 09:25:39.375358Z [nasm] execute_command
    Feb 07 09:25:39.375365Z [nasm] parsing arguments for '/bin/cp /cfs/krb5.conf.3 /tmp/krb5.conf'
    Feb 07 09:25:39.375386Z [nasm] argument '/bin/cp' processed
    Feb 07 09:25:39.375394Z [nasm] argument '/cfs/krb5.conf.3' processed
    Feb 07 09:25:39.375400Z [nasm] argument '/tmp/krb5.conf' processed
    Feb 07 09:25:39.375406Z [nasm] transferring over to imaginary_baby to execute '/bin/cp /cfs/krb5.conf.3 /tmp/krb5.conf'
    Feb 07 09:25:39.375412Z [nasm] imaginary_baby
    Feb 07 09:25:39.375499Z [nasm] waiting for '/bin/cp' to complete its job
    Feb 07 09:25:39.378852Z [nasm] hi_i_m_child
    Feb 07 09:25:39.378888Z [nasm] executing '/bin/cp'
    Feb 07 09:25:39.622988Z [nasm] execute_command (done)
    Feb 07 09:25:39.623008Z [nasm] net_ads_join
    Feb 07 09:25:39.623017Z [nasm] over to imaginary_baby to JOIN with AD
    Feb 07 09:25:39.623023Z [nasm] imaginary_baby
    Feb 07 09:25:39.623154Z [nasm] waiting for '/oss/net' to complete its job
    Feb 07 09:25:39.626216Z [nasm] hi_i_m_child
    Feb 07 09:25:39.626252Z [nasm] executing '/oss/net'
    dos charset 'CP850' unavailable - using ASCII
    kinit succeeded but ads_sasl_spnego_gensec_bind(KRB5) failed for ldap/snh-dc2.atlas.local with user[zzzzz] realm[yyyyy]: Invalid credentials
    Failed to join domain: failed to connect to AD: Invalid credentials
    Feb 07 09:25:39.822389Z [nasm] '/oss/net' exited with invalid status '255'
    Feb 07 09:25:39.822411Z [nasm] net_ads_join (done)
    Feb 07 09:25:39.822419Z [nasm] net_ads_join failed to join with server->yyyyy
    Feb 07 09:25:39.822426Z [nasm] pre_channel (done)
    Feb 07 09:25:39.822447Z [nasm] throwing logs on garner
    Feb 07 09:25:39.822474Z [nasm] all servers traversed, but still not able to setup channel, will try again in 20 seconds
    Feb 07 09:25:39.822482Z [nasm] setup_channel (done)
    Feb 07 09:25:39.822489Z [nasm] reload_channel (done)
    Feb 07 09:25:39.822495Z [nasm] process_tlv_reconfig (done)
    Feb 07 09:25:39.822533Z [nasm] process_tlv_channel_status
    Feb 07 09:25:39.822542Z [nasm] sending channel down to ntlm server
    Feb 07 09:25:39.822548Z [nasm] sendto_ntlmserver: TLV [type=DOWN]
    Feb 07 09:25:39.822563Z [nasm] sendto_ntlmserver: [bytes sent=8]
    Feb 07 09:25:39.822570Z [nasm] process_tlv_channel_status (done)
    Feb 07 09:25:39.822578Z [nasm] process_protocol_event (done)
    Feb 07 09:25:39.822584Z [nasm] waiting for an event on PROTOCOL fd [up to 20s]
    Feb 07 09:25:39.822755Z [ntlmserver] fasm_processor(): processing nasm-to-server TLV [type=DOWN] message
    Feb 07 09:25:39.823502Z [ntlmserver] ntlm_server() ---> epoll_wait() waiting 10s for events
    Feb 07 09:25:49.828875Z [ntlmserver] ntlm_server() ---> looping through employ'd [elasped=18s]
    Feb 07 09:25:49.828931Z [ntlmserver] ntlm_server() ---> epoll_wait() waiting 10s for events

  • Looks still the same. 
    Could you do the following: Move to AD LDAP 389 (without TLS).

    Then tcpdump -ni any port 389 -b -w /tmp/ldap.pcap 

    Press Save on the AD Server and stop the dump.

    Download the dump via SCP and check in Wireshark the data, which is transferred. Check the LDAP codes. 


  • Hi

    I changed to AD LDAP rather than TLS and the device registered fine.  Just getting the pcap to have a look at.

    This to me points to something wrong with the TLS side of things.  As far as I am aware we have all the certs configured correctly, a cert on the XG with the device's full name, all of our root and intermediate CA certs are installed on the XG, we are using FQDN for setting up the Auth Server on the XG.

    I switched teh Auth Server back to TLS and t has started to fail again.

    Is there anything we have missed or is there a good guide for this?  The ones I have found on teh Sophos site are a bit too higher level.

  • You could look into this:  Sophos Firewall: A Quick Guide for LDAPS/AD Integration With Windows Server 2022/2019/2012… 

    But to be honest, V18.5.5 is quite rare installed in the field. It is not a public deployed release. So maybe you could not upgrade to 18.5.5, instead V19.0/5 would be a better path. 


  • Thanks for the info. I will have a look through it.

    We will consider 19.0.  We have a lot of devices running 17.5.16 to upgrade so will need to confirm the process for this.  When we tried to upgrade the last time, 18.5.5 was the recommended version but we hit the issue of the device not registering with AD so had to roll back.

  • Hi

    We have ran through that guide and all is correct as it is in there.

    One strange thing I have noticed is that when set to AD LDAPS it tries to connect to a server that was once defined as an Auth Server but isnt anymore.

    Will need to do some more digging.