Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 14 replies
  • Answers 1 answer
  • Subscribers 27 subscribers
  • Views 3514 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

18.0.4 MR-4: AD join issues!!

twister5800

Hi all,

Running SFOS 18.0.4 MR-4, and tried to AD join my XG as this was working before but did not use it for a long time.

i have been with this for 4 hours now, but no luck.

Seeing this in the log:

Jan 06 20:32:06.896985 [nasm] executing '/oss/winbindd'
winbindd version 4.7.4 started.
Copyright Andrew Tridgell and the Samba Team 1992-2017
initialize_winbindd_cache: clearing cache and re-creating with version number 2
STATUS=daemon 'winbindd' finished starting up and ready to serve connections
dos charset 'CP850' unavailable - using ASCII
Jan 06 20:32:07.897022 [nasm] is_ad_server_alive
Jan 06 20:32:07.897080 [nasm] is_ad_server_alive: winbindd running fine (this is what system thinks !!)
Jan 06 20:32:07.897101 [nasm] throw_request: written 2096 bytes on winbind pipe
Jan 06 20:32:07.897107 [nasm] catch_response
Jan 06 20:32:07.897111 [nasm] __read
Jan 06 20:32:08.315381 [nasm] we've 3496 bytes on winbindd pipe
Jan 06 20:32:08.315400 [nasm] received response (3496 bytes) from winbindd
Jan 06 20:32:08.315404 [nasm] catch_response
Jan 06 20:32:08.315408 [nasm] NT_STATUS_ACCESS_DENIED: {Access Denied} A process has requested access to an object but has not been granted those access rights. (0xc0000022)
Jan 06 20:32:08.315412 [nasm] is_ad_server_alive: validate_credentials failed
Jan 06 20:32:08.316271 [nasm] pre_channel (done)
Jan 06 20:32:08.316302 [nasm] throwing logs on garner
Jan 06 20:32:08.316326 [nasm] all servers traversed, but still not able to setup channel, will try again in 20 seconds
Jan 06 20:32:08.316345 [nasm] setup_channel (done)
Jan 06 20:32:08.316349 [nasm] waiting for an event on PROTOCOL fd [up to 20s]
Jan 06 20:32:15.013686 [ntlmserver] ntlm_server() ---> epoll_wait() waiting 10s for events
^C

have rejoined the XG to my AD several times, deleted the AD Computer object every time.

Also did this:

Stop the NASM service: service nasm:stop -ds nosync

Remove file /content/nasm: rm -rf /content/nasm

Start the NASM service: service nasm:start -ds nosync

Tried all of this:

NTLM and Kerberos troubleshooting (sophos.com)

Still no joy.

My domain level is 2016 and AD servers are Win 2019

When I press TEST is goes all green and I can import users from AD.

What the h... am I doing wrong?

Also tried with Plain text LDAP, same result.



This thread was automatically locked due to age.
  • FormerMember
    0 FormerMember

    Hi ,

    Thank you for reaching out to the Community! 

    Did you configure the AD admin user? 

    Was there any recent update on your server? For testing, can you try to change the port to 389 and check your server's internal certificate? Is it valid? 

    Did you put the access_server service in debug before collecting these logs?

    Can you provide packet capture from your server and the firewall? 

    Thanks,

  • 0

    I've seen similar behaviour last week (when just setting up XG and no real former experience). What I have noticed is that while AD is configured for SSL on port 636, AD SSO still tries port 389 unencrypted. Our domain doesn't accept that.

    Solution from Lucar Toni was to deselect AD SSO from all zones. See this topic.

    Managing several Sophos UTMs and Sophos XGs both at work and at some home locations, dedicated to continuously improve IT-security and feeling well helping others with their IT-security challenges.

    Sometimes I post some useful tips on my blog, see blog.pijnappels.eu/category/sophos/ for Sophos related posts.

  • 0 in reply to FormerMember
    Unknown said:

    Did you configure the AD admin user? 

    Was there any recent update on your server? For testing, can you try to change the port to 389 and check your server's internal certificate? Is it valid? 

    Did you put the access_server service in debug before collecting these logs?

    Can you provide packet capture from your server and the firewall? 

    Hi 

    1) Yes

    2) No - tried changing ports already

    3) yes

    4) Packet trace shows that XG connect with port 389 even though I have set for 636 above - not good :-(

    -----

    Best regards
    Martin

    Sophos XGS 2100 @ Home | Sophos v19 Architect

  • 0 in reply to apijnappels

    Thanks for posting this, I have the same bug (Bug ID for this: NC-66450)

    But I cannot disable AD SSO as Sync. user Id with heartbeat will stop working...

    -----

    Best regards
    Martin

    Sophos XGS 2100 @ Home | Sophos v19 Architect

  • 0

    It seems to be the case, that your account, which you select for XG, does not have the rights to create a AD computer. 

    Jan 06 20:32:08.315408 [nasm] NT_STATUS_ACCESS_DENIED: {Access Denied} A process has requested access to an object but has not been granted those access rights. (0xc0000022)

    This indicates this assumption. 

    Check the AD server log, if you see any LDAP errors. https://ldapwiki.com/wiki/LDAP%20Result%20Codes

    __________________________________________________________________________________________________________________

  • 0 in reply to twister5800

    That is actually not correct - Its not your bug ID. If you do not want to use NTLM/Kerberos, you can disable AD SSO in the Zone. Sync-Sec User ID will use Client Authentication for authentation, not AD SSO. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    But I need it also for authenticating SSLVPN users.

    -----

    Best regards
    Martin

    Sophos XGS 2100 @ Home | Sophos v19 Architect

  • 0 in reply to LuCar Toni

    The AD Computer object is created successfully every time, if I delete it, it's being recreated  as wanted.

    I use domain admin for the account. Issue is that XG connects on port 389 and not 636 as I need.

    -----

    Best regards
    Martin

    Sophos XGS 2100 @ Home | Sophos v19 Architect

  • 0 in reply to twister5800

    AD SSO is only NTLM/Kerberos. This has nothing to do with any other authentication services. AD SSO is basically the web based authentication in UTM (Also called AD SSO there), which you only use for Web Proxy. 

    __________________________________________________________________________________________________________________

  • 0 in reply to twister5800

    Thats the current bug ID, that is correct, port if you open Port 389, will it work or not? If not, you need to dump the Port389 traffic and export this tcpdump into wireshark. Then check, what is actually denying the join. 

    __________________________________________________________________________________________________________________