Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 6 replies
  • Subscribers 9 subscribers
  • Views 1829 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

Domain (joining) problems after up2date to 9.713-19

chronowerx

Hi everybody,

yesterday I updated our UTM to 9.713-19 via up2date. After that, every two hours I got a message

[WARN-531] Directory Services synchronization: There was an error synchronizing subscribed groups. The Sophos UTM will continue to operate with a locally cached copy of the data but will be unable to update from Directory Services until the issue is resolved.
Error was:
failed to get base dn of domain myfoo.bardomain.tld

Authentication Services -> Servers -> (my AD connection): both tests of the "bind dn" as well as the "base dn" were successful.

I then tried to re-join our domain via Authentication Services -> Single Sign On -> Active Directory SSO and now I always get "joining the domain failed"

I went through the domain joining checklist (DNS forwarders, request routing etc.), did internal and external DNS tests via the Sophos UTM support tools, checked the hostname DNS settings in our AD DNS and even deleted the old computer object created by the last successful domain join years ago.

I reapplied the latest up2date and rebooted the UTM.

No luck. I'm not able to join our UTM to our domain anymore.

Any pointers?

Kind regards



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

    Hi  ,

    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" :-)

    Sophos Certified Architect - UTM
    using Sophos UTM since Astaro ASG v7 ;-)

    PDV-Systeme GmbH est. 1985 is
    Gold Solution Partner since 2009

Reply
  • +1

    Hi  ,

    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" :-)

    Sophos Certified Architect - UTM
    using Sophos UTM since Astaro ASG v7 ;-)

    PDV-Systeme GmbH est. 1985 is
    Gold Solution Partner since 2009

Children
No Data
Unfiltered HTML