Beiträge von Megachip

    jap, er hat Recht. ich hatte es daraufhin direkt überprüft damals und konnte den Einwand KB19 damit bestätigen.


    ps: hab extra bis nach 19:xx Uhr mit diesem Beitrag gewartet. ;) :P

    Ja, stelle ich auch grad fest. Wenn ich nur wüsste, wie ich damals den cron gestrickt hatte. Bin mir sicher damals nicht mit Verkettungen gearbeitet zu haben. Leider hat netcup alle meine crons gelöscht und ich Depp hat sie leider nirgends dokumentiert ;(


    Ich glaube

    Code
    57 11 1-7 * */7

    war die Lösung ... werde es wohl nächsten Monat erfahren ^^

    DOM und DOW kann man (leider) nicht kombinieren. Es wird dann an den Tagen 1-7 und an jedem Sonntag ausgeführt.

    sicher?


    Hatte jedenfalls super ein halbes Jahr lang funktioniert ... bis Plesk weggeflogen ist und nat. hatte ich mir kein Backup/Screenshot meiner Tasks gemacht ;)

    Aber noch mal allen vielen Dank für die Tips.

    dann würde ich die ports mal mit openssl s_client -host blabla -port bla -showcerts testen.

    da müsste ja was zu sehen sein.

    Beide Ports sind offen, auf 389 wird allerdings kein Zertifikat oder ähnliches ausgeliefert. Beide anfragen beenden allerdings nicht. Vom Webspace aus kann ich nat. nicht testen, da ich dort kein Zugriff auf openssl hab. Das würde das debugging nat. ungemein Vereinfachen. Aktuell bleiben mir halt nur php skripte zum testen, da die eigentliche Appliance in diesem Bereich kein (kostenfreies) debugging zulässt.

    im august gab's ja auch wieder diverse anpassungen bei google.

    reicht denn dein g-suite/workspace-tarif noch?


    ansonsten, was steht denn in Berichterstellung - Audit und Prüfung - Secure LDAP-Protokollereignisse?

    Hallo Olivetti,


    danke fürs schnelle Feedback. Tarif reicht noch. Das Protokoll ist einfach leer (also seit dem 04.08) ... was ja durchaus Sinn macht, wenn php meldet, dass es keine Verbindung aufbauen kann ;)


    Mit Zertifikat schlägt TLS fehl, ohne nimmt der Server logischerweise meine Anfragen nicht entgegen. Ich tippe mal auf ein Maleformed Zertifikat, welches ggf durch ein update der root CAs oder ka wodurch erst zu diesem wurde... aber neue erzeugen bringt auch keinen Erfolg. Der Google Support sitzt jetzt seit 3 Monaten dran und langsam reicht es mir, dachte ich, ich frag mal in einer Kompetenten Community ;)


    Vllt haben sich auch einfach den 389 Dicht gemacht und wollen es nur nicht zugeben ;)


    Beste Grüße,

    Meg

    Hallo liebe Community,


    ich habe das Problem dass ich seit (oder nach) dem 04.08.22 keine (verschlüsselte) Verbindung mehr zum google LDAP Server (ldap.google.com) via php bekomme. Weiß irgendjemand, woran das liegen kann? An den Zertifikaten, config usw wurde nichts geändert. Bis dahin ging is via 389 und start_tls, ssl/636 hatte glaube noch nie funktioniert.


    Bin für jegliche Vorschläge, Ideen und hinweise dankbar.


    Viele liebe Grüße,

    Meg