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

Web Proxy funktioniert seit 9.500-9 nicht mehr bei https Traffic

Hallo zusamment,

 

seit über 2 Wochen haben wir nun unsere Web Protection abgeschaltet und warten auf den Sophos Support. Wir sind nun an einem Punkt an dem wir nicht mehr warten können, daher erhoffe ich mir Hilfe von den Profis ;-).

 

Seit dem wir auf 9.500-009 aktualisiert haben, reagiert der Web Proxy bei https Traffic nicht mehr. Http Websites funktionieren einwandfrei.

Wir setzen den Web Proxy mittels Standard Mode und AD SSO ein. Wir nutzen ein einfaches Webzugriffs Prinzip - Keine Authentifizierung über die definierte AD Gruppe - Kein Internetzugriff.

Im Web Proxy Log findet sich leider auch nichts hilfreiches da die Zugriffe als allowed geloggt werden.

 

Laut Sophos Support ist das Problem als Bug in 9.5 bekannt und wird unter Bug ID NUTM-7960  geführt. Kann mir jemand verraten wie ich zu diesem Bug Artikel komme?

Hier mein aktueller nicht zufriedenstellender Status seitens Support:

Als aktuellen Workaround kann ich Ihnen nur anbieten AD SSO temporär aus zu schalten oder falls bei Ihnen nur vereinzelt Webseiten Probleme haben eine Exception zu erstellen die die Authentifizierung überspringt.
Hierzu gibt es bereits eine Bug ID NUTM-7960 die auf critical eingestuft ist. Wir warten auf die Entwicklung bezüglich eines temporären Workarounds und einen Fix.

Wenn es doch Kerberos ist, dann muss man doch etwas seitens AD unternehmen können oder?

 

VG

Philipp



This thread was automatically locked due to age.
Parents
  • Im englischsprachigen Thread habe ich das hier gefunden:

    Zitat:

    We got told that there should be an official update via Up2Date in calender week 28.

    Mal sehen, ob der Patch dann zur Verfügung steht ... [*-)]

  • Hallo

    Sophos Support hat den RPM Fix auf unserer Anlage gemacht und diese RPM installiert, damit ist seit Samstag die Authentifizierung am AD wieder ok. Hatte aber fast 2 Wochen gedauert, bis dass man hier aktiv wurde (seit der Ankündigung dass man einen Fix per RPM einspielt)

    ep-httpproxy-9.50-396.g0618cbe.rb3

  • Hallo zusammen,

    @ Phillip:
    Ich hab das gleiche Problem..! Auch bei mir werden https Seiten geblockt seit Update auf 9.500.

    Da hiervon sicher auch noch andere betroffen sind, hier mein aktueller Stand:

    Heute morgen hatte ich eine Remot-Sitzung mit dem Sophos Support weil es dafür angeblich ein Patch gibt.
    Es wurde das ep-mdw-9.50-865.g3beb74b.i686.rpm eingespielt.

    Leider hat es das Problem auch nicht gelöst.
    Mir wurde aber gesagt das in den kommenden Tagen das Update 9.502 zur Verfügung gestellt wird.
    Ich soll dieses einspielen und dann noch einmal die Authentifizierung testen.
    Bis dahin besteht nur die Möglichkeit auf den Transparenzmodus auszuweichen oder in den Filteroptionen der Web Protection, eine Ausnahme für alle https Webseiten anzulegen.
    Diese Ausnahme sollte dann auf die Authentifizierung verzichten.

    Viele Grüße
    Bruno

  • __________________________________________________________________________________________________________________

  • Leider hat der Patch auf 9.502-4 bei uns nicht geholfen. Wir sind mit dem Support immernoch dran.

     

    Rejoin Domain wurde gemacht und Test Client wurde neu gestartet. HTTPS bleibt unerreichbar.

    Die Ausnahme finde ich nicht akzeptabel, da der meiste Traffic bereits auf https läuft und somit Anwender die garnicht ins Internet dürfen ins Internet können.

    Transparenzmodus habe ich noch nicht probiert da ich mit vielen Problemen bei Standverbindung im Serverbereich rechne.

  • Hallo,

    auch bei uns gibt es Probleme seit dem Update auf 9.502-4. Single Sign-On funktioniert im Internet Explorer nicht mehr. Zudem ist das Aufrufen von Webseiten extrem langsam. Wir nutzten außerdem intern den Teamviewer, der deit dem Sophos Update ca. 10-15 Minuten zum Verbinden benötigt.

    Die UTM haben wir bereits neu in die Domäne aufgenommen und den Webfilter deaktviert, jedoch keine Besserung.

    Hat irgendjemand Lösungsansätze von Sophos erhalten? Wir warten noch auf Antwort...

  • Hallo beckerantriebe,

     

    ich habe bei mehreren Kunden auf die 9.502-4 upgedated. Die bekannten Probleme scheinen bei allen gefixt zu sein. Wenn der Webfillter deaktiviert ist läuft der Traffic über die Firewall. Kann also nichts damit zu tun haben.

    Ich habe aber bei einem Kunden das AD SSO Problem auch bei 9.502 festgestellt. Nach intensiver Fehlersuche hat sich herausgestellt das der auf den Clients lokal installierte Kaspersky Scanner die Probleme verursacht hat. Probiere bitte mal den lokalen Virenscanner zu deaktivieren.

    vg

    mod

  • Hallo Mod,

    vielen Dank für die Anwort. Wir haben bereits auf 9.502-4 geupdated. Den Virenschutz habe ich mal deaktiviert (Sophos Endpoint Protection), jedoch tritt des dass SSO Problem weiterhin auf. Hast du noch eine Idee?

    VG Julia

  • Hallo Julia,

    das müsste man mal genauer analysieren. Was sagt der Authentifizierungslog wenn du die AD Gruppenmitgliedschaften manuell syncronisierst?

    Hier kann auch ein inkonsitentes AD oder auch eine Zeitdifferenz eine Rolle spielen. Hast du mal überprüft ob die Zeit bei allen Komponenten (DC, Client, UTM) syncron ist?

    vg

    mod

Reply
  • Hallo Julia,

    das müsste man mal genauer analysieren. Was sagt der Authentifizierungslog wenn du die AD Gruppenmitgliedschaften manuell syncronisierst?

    Hier kann auch ein inkonsitentes AD oder auch eine Zeitdifferenz eine Rolle spielen. Hast du mal überprüft ob die Zeit bei allen Komponenten (DC, Client, UTM) syncron ist?

    vg

    mod

Children
  • Also ich habs eben auch mal getestet.

    Es geht jetzt wieder bei uns, mal schauen wie lange. Letztes mal hat es ziemlich genau 24 Stunden funktioniert!
    Ich habe die UTM neu in die Domäne genommen und ich habe auch meine AD Gruppen in die UTM neu hinzugefügt!

     

    Im Fallback log stand:

    [daemon:err] winbindd[25588]: cm_prepare_connection: mutex grab failed for server.domain <--diesen Server gibt es, er ist auch ein DC aber nicht in der UTM eingetragen.

    Nachdem ich die Gruppen neu hinzugefügt hatte und den Webfilter wieder aktiviert habe stand im Log:

    [daemon:err] winbindd[26586]: [2017/07/25 10:25:54.608544, 0] ../source3/winbindd/winbindd_cache.c:3171(initialize_winbindd_cache)
    [daemon:err] winbindd[26586]: initialize_winbindd_cache: clearing cache and re-creating with version number 2
    [daemon:err] winbindd[26586]: [2017/07/25 10:25:54.612439, 0] ../lib/util/become_daemon.c:124(daemon_ready)
    [daemon:err] winbindd[26586]: STATUS=daemon 'winbindd' finished starting up and ready to serve connections
     
    Also, läuft gerade alles...
     
    Model SG230
    Firmware: 9.502-4
     
    Grüße
     
     
     
  • Als hätte ich es mir nicht schon gedacht, nach ca. 5 Stunden läuft es nicht mehr!

    Log ist voll mit Status 407 und -_>

    id="0003" severity="info" sys="SecureWeb" sub="http" request="(nil)" function="plain_write_vector" file="epoll.c" line="1091" message="Write error on the epoll handler 264 (Connection refused)"
    httpproxy[23155]: id="0003" severity="info" sys="SecureWeb" sub="http" request="0x8fffe00" function="send_winbindd_request" file="auth_adir.c" line="269" message="write: Connection refused"
  • Hallo zusammen,

    kleiner Zwischenstand von mir:

    Wie vom Sophos Support vorgeschlagen habe ich gestern morgen die 9.502-4 eingespielt.
    Hat keinerlei Verbesserung gebracht. Auch bei mir sind weiterhin HTTPS-Webseiten tabu, sobald ich ein Webfilterprofil mit Standardmodus und SSO-Authentifizierung zuschalte.
    Also habe ich nun wieder den Transparenzmodus ohne Authentifizierung eingeschaltet. So können unsere Mitarbeiter wenigstens arbeiten.
    Es ist natürlich ein Sicherheitsproblem, da man den Internetzugang so weder kontrollieren, noch nachverfolgen kann.

    Das wirklich ärgerliche daran ist das mir versprochen wurde, falls das Update nichts bewirkt würde mein Fall mit erhöhter Priorität zurück in die Entwicklungsabteilung gehen.
    Das wurde nicht eingehalten.
    Seit mittlerweile 7 Wochen warte ich nun auf eine Lösung.

    Der aktuelle Vorschlag ist, das ich Kaspersky deaktiviren, und dann den Standardmodus testen soll.
    Mit etwas Glück werde ich das morgen früh schaffen - glaube aber nicht das es was bringt (wie bereits oben im Thread beschrieben)

  • Hallo Bruno,

    wie ich in dem Threat schon beschrieben habe. Ich hatte genau das gleiche Problem mit den gleichen Auswirkungen bei einem Kunden. Dort war es 100% der Kasperski Scanner auf den Clients. Das betraf aber nicht alle Clients. Sobald Kasperski deaktiviert wurde gab es kein SSO Problem mehr. Ich könnte wetten das du genau das gleiche Problem hast. Der Kunde läßt gerade seinen Kasperski Deinstleister das überprüfen.

    Ich habe dort als Workaround ein extra Webfilter Profil ohne AD SSO angelegt wo nur die betroffenen Clients hinzugefügt wurden. Das waren zum Glück bei dem Kunden nicht alzuviele.

    vg

    mod

  • Hallo mod

    gut, aber selbst wenn das irgendwie mit Kaspersky Virenschutz zusammenhängen würde, selbst dann verstehe ich nicht warum Dein Kunde das nun Kaspersky prüfen läßt?
    Das Problem liegt hier in meinen Augen ganz klar bei Sophos.
    Ich kann nur sagen das meine SG210 knappe 2 Jahre prima mit SSO gelaufen ist, bis ich die 9.500 eingespielt habe.
    Die Sophos Entwicklungsabteilung sollte sich also speziell noch einmal die Release-Änderungen ansehen, die zur 9.500 an Authentifizierung bzw SSO gemacht wurden.

    LG Bruno

  • Wir haben Kaspersky Endpoint Security 10 ServicePack 2 im Einsatz.

    Habs deaktiviert auf ein paar Clients, ebenfalls ohne erfolg...

     

    @Bruno ...hast du im Fallback log auch einträge wie diese?

    [daemon:err] winbind-check.pl[17198]:  winbindd trust secret check via RPC call failed
    [daemon:err] winbindd[17340]:  [2017/07/25 14:16:51.997979,  0] ../source3/winbindd/winbindd_cache.c:3171(initialize_winbindd_cache)
    [daemon:err] winbindd[17340]:    initialize_winbindd_cache: clearing cache and re-creating with version number 2
    [daemon:err] winbindd[17340]:  [2017/07/25 14:16:52.032606,  0] ../lib/util/become_daemon.c:124(daemon_ready)
    [daemon:err] winbindd[17340]:    STATUS=daemon 'winbindd' finished starting up and ready to serve connections
    [daemon:err] winbindd[17351]:  [2017/07/25 14:18:59.298506,  0] ../source3/libads/kerberos_util.c:74(ads_kinit_password)
    [daemon:err] winbindd[17351]:    kerberos_kinit_password SG230-XXXXX$@XXX.XXX.DE failed: Cannot contact any KDC for requested realm
    [daemon:err] winbindd[17351]:  [2017/07/25 14:18:59.301521,  0] ../source3/winbindd/winbindd_dual.c:107(child_write_response)
    [daemon:err] winbindd[17351]:    Could not write result
  • Hallo Bruno,

    AD SSO funktioniert scheinbar mit jedem anderen Virenscanner nur nicht mit dem Kasperski. Ich finde es auch seltsam und kann es nicht wirklich erklären. Fakt ist aber das AD SSO funktioniert sobald Kasperski abgeschaltet wird und es betrifft nicht alle Kaspeski Installationen. Vieleicht wurde hier zeitgleich ein Kaspeski Update ausgerollt der diese Probleme verurscht.

    Für meinen Kunden war das auf jeden Fall eindeutig. Unabhängig vom Browser war das Problem bei allen betroffenen Clients der Kasperski Scanner.

    vg

    mod

  • cannot contact any KDC for requested realm -> Sieht aus wie ein AD oder Konfigurations Problem

    vg
    mod

  • Das AD hier funktioniert fehlerfrei in 8 Standorten. Erst seit dem Update gibt's die Probleme.
    Außerdem benutze ich das AD + SSO für andere Dienste wo es ebenfalls Fehlerfrei funktioniert.

    Also denke ich nicht das es ein Problem mit dem AD oder DNS gibt!
    Ich werde die Tage den Support drauf schauen lassen und gebe dann hier Rückmeldung.

     

    Grüße

  • Hallo Marc,

    das ist wirklich seltsam. Bin gespannt was der Support dazu sagt.

    vg

    mod