Domain (joining) problems after up2date to 9.713-19

Hi chronowerx ,

Thanks for reaching out to Sophos Community and hope you are well

In addition to the DNS requirements on your checklist that has been tested, any chance you checked the time and date configured on the UTM and the AD server as well?

use 'date' command for date and time - for UTM

net ads info -I <IPofAD> - For AD 

You could also check more details on this KB: https://support.sophos.com/support/s/article/KB-000035211?language=en_US

Thanks for your time and patience and Thank you for choosing Sophos

Regards,

Hi Raphael,

thank you very much for your answer and the suggestions. Yes, I have checked the time and date settings and they're OK.

Thank you also for the link you provided. At this point I believe it has something to to with the NTLM version being used. I temporarily set it to the required value and it still doesn't work; but I might have made an error there.

Three questions:

1.Where in the UTM logs can I find a full error message about the UTM not being able to join a domain? "Failed to join the domain" is not helpfull.

2. Are the required NTLM settings only required for joining and can be set to the default values afterwards?

3. What does the original error message mean/why did it appear only after the UTM update?

Thanks & kind regards
Ken

You are using a FQDN aren't you?  If that is truncated or incorrect, it can cause that error.  Could be a DNS issue as well.  Are you joining it using an account that has domain admin access?

Hi chronowerx ,

Good day and hope all is well

Thanks for the provided details. Kindly create a support ticket for this to be further checked, also kindly let us know of the would be generated case number through DM or by replying to this thread so we can follow progress and make notes internally accordingly.

Many thanks

Cheers,

Hi,

I was wondering if there were any further updates to this thread. I was going to update our SG330 UTM and came across this discussion. We have our UTM connected to our local AD, so wondered if this was a common problem, or how it would affect us if I performed the update.

Thanks,

Pat.

Hi chronowerx ,

I found a solution for me with this problem (I hope, which helps on your end too).

I strictly followed the AD-Guide (KBA000035211 @ sophos.support) with the NTLM rights.
Those were already disabled, because I hardened my domain by MS best-practices.
These "Best-Practices" also changed Session-Security-Settings (force 128-Bit Session-Security & force NTLMv2-Sec).
Those Settings also had to be reverted! (create Reverse-GPO for those 3!!! settings) & temporarily disable the seperate "Hardening-GPO".
If you've changed those settings in the "default DC-Policy" I'd recommend to only set those switches to "non defined" and create a Reverse-GPO for those 3 settings only.

BUT

I also had to make sure, that the domain-user for my "Firewall-SSO" has a Password no longer than 12-digits (Capitals, Lowers, Numbers & Special).
I'm from Germany, so i also made sure that i only use Special-Characters, that i know are on the same key on an american key-layout (which effectively reduces them to "!" and "$".

Created the SSO-User in AD ran a gpupdate on the modified DC, replicated everything to the second DC with gpupdate and also rebooted both of them.

Then I was able to join the firewall to SSO-Domain.

Funny fact.

I changed the GPO-Settings back and ...

Till now it keeps working *fingers-crossed*

Have a great one

Franz

EDIT:
Also have a look at those INBOUND Windows-Firewall-Settings "Remote Scheduled Tasks Management (RPC)", "Remote Scheduled Tasks Management (RPC-EPMAP)" & "Windows Management Instrumentation (WMI-In)".
Here might also be a hickup there. This helped on another customers setup (right now).
For most consistent result use GPO here aswell. Just fixing up another "lost-SSO" :-)