zahni

Hi, da ist (mal wieder) mit der Syntax von SetACL gekämpft habe, hier das Ergebniss: setacl -on . -ot file -actn list -lst "f:tab;w:d,s,o,g;i:y;s:b"

Ich bin der Meinung, dass TLS-Inspection UNBEDINGT notwendig ist. Wichtiger ist aber ein funktionierender Inhaltsfilter um wirklich jeden ausführbaren Code herauszufiltern, auch weil mittlerweile jede Website SSL benutzt. Der Virenscanner am Proxy soll zusätzlich in der Lage sein, als HTML kodierte Viren zu erkennen. Das ist die 1. Bastion gegen Malware. Die letzte Bastion ist dann der Applocker auf dem Windows-Client. Man kommt dann leider nicht darum herum, kleinteilig Ausnahmen zu definieren, sei es für Anwendungen, die das Zertifikat vom Proxy nicht akzeptieren oder man tatsächlich einen Binär-Download braucht. Das Ganze kann man dann noch mit einem Proxy-SSO ergänzen, um bestimmten Benutzern andere Richtlinien zuzuweisen. Und natürlich kann man den Abfluss von Daten eindämmen, wenn man sog. "Online-Festplatten" verbietet. Ok, dazu braucht man kein TLS Inspection.

Danke, ich schaue es mir gerade an.

Ich will nur stichprobenartig prüfen. Das Problem ist, dass in beiden Domänen die Gruppen den gleichen Namen haben und die SID wechselseitig in der SID-History steht und im Trust der SID-Filer aus ist. Das dient insgesamt der Vorbereitung den Trust auszulösen. PS: Am Besten per Shell: NTFS-Rechte, UPN UND SID. Windows zeigt hier immer den UPN der aktuellen Domäne an, wo man angemeldet ist. Und der Filer ist eine Netapp.

Hi, wir müssen unserer MDM neu aufsetzen und die Lösung wechseln. Wir erlauben den Usern ihre persönliche Apple ID zu benutzen und "verbannen" unsere Daten in den Unternehmens-Container. Frage: Unser DL meint, dass die die Apple Mail-App in dem Unternehmens-Container nicht funktionier Kennt sich jemand damit aus? Wir wollen ungern Outlook für IOS einsetzen, da gibt es gewisse Bedenken hinsichtlich des Umgangs mit Kennwörtern.

Hi, kennt zufällig jemand eine Möglichkeit bei den NTFS-Rechten bei einem Objekt die SIDs statt der UPN anzuzeigen? Das geht zwar mit der Save-Option von Icacls, ist aber sehr umständlich. Hintergrund: Migration in eine neue Domäne, SID-History, DL schreibt NTFS-Rechte neu und ich muss das abnehmen. Leider zeigt Windows in diesem Konstrukt immer den UPN der neuen Domäne...

Hilfreich ist es u.U. den DNS-Eintrag (oder WINS?) des alten Servers zu löschen. Dann wird kein TCP-Connect versucht. Office wird dann versuchen Verknüpfungen zu anderen Dokumenten über relative Pfade aufzulösen.

Nur ein kleiner Fingerzeig: Was immer mehr Anbieter auch (leider) für On-Prem nutzen, ist Entra SSO. Dazu braucht man aber natürlich das ganz "Gedöns" von Microsoft. Allerdings sind natürlich auch SAML-Implementierungen potenziell angreifbar, besonders die von Citrix .

Hi, nur zur Warnung: wir haben an viele unseren dienstlichen Mailadressen merkwürdige Phishing-Mails erhalten. Die enthalten einen Link zu Google Drive. Dieser Link ruft dann diesen Link auf: https://login.kleinanzeigen.de.miakay.online /identifier-state/?_r=57f5dcbc6a984999aff85b69ef1fb858 Hier wird eine gefälschte Anmeldeseite präsentiert. Ich habe mal versucht ungültige Daten einzugeben die dann auch als ungültig erkannt wurden. Ob da eine Lücke bei Kleinanzeigen ausgenutzt wird? Die IP-Adresse 178.16.55.194 verweist in die USA, DNS nach Russland. https://www.google.com/share.google ?q=ZPoCPFlXInzUftP72

Das sollte unser DL auf dem SMTP-GW auch machen.

Ich wohl mal wieder mit unserem Mail-DL sprechen. Wir bekommen aktuell sehr viele SPAM-Mails über Google-Groups Listen. Die Anwender beschweren sich schon... Und sogar Phishing-Mails werden über Google-SMTP-Server verwendet (allerdings nicht über Google Groups).

Ich tippe auf ACLs in der Registry...

Danke. Ich schicke denen einfach mal den Link. PS: Das Problem mit den überflüssigem Abfragen konnte geklärt werden, da war eine überflüssige Funktion in der PAC-Datei. Allerdings schreit der Client weiter in einer Endlosschleife nach irgendwelchen MS-S und Symantec-Servern. Natürlich immer mit den 4s Timeout.

Danke, aber kann man das irgendwo nachlesen? Wenn ich ihm das sage, reicht es nicht.

Hi, ich streite mich mal wieder mit unserem DL rum. Lt. dem DL wäre es so, dass bei der Deaktivierung der Recursion auch keine conditional forwarder funktionieren. Das Problem: In unserer noch existierenden Alt-Umgebung funktioniert es genau so. Das Problem hier: Aus irgendwelchen mir nicht bekannten Gründen macht der Edge zuerst lokale DNS-Abfragen und geht dann erst zum konfigurierten Proxy (per PAC-Datei) Der DNS braucht nun 4 Sekunden um mir zu sagen, dass es die Adresse bei ihm nicht gibt (Server Error, Timeout). Ohne Recursion geht es wesentlich flotter, weil der mit "Query refused" antwortet. Frage: Kann man irgendwo "offiziell" nachlesen, das die Einstellung zur Recursion nicht auf conditional forwarder wirkt? Ich werde leider bei Google nicht ganz schlau draus.