Küstennebel

Seit Kurzem haben wir auch verstärkt Mailrückläufer von 1&1 / IONOS. Eine IP Cam, die seit Jahren Alarmbilder verschickt, wird z.B. nicht mehr akzeptiert. In der Zwischenzeit habe ich mehrfach mit dem Support telefoniert. Am Ende kam heraus, dass 1&1 / IONOS seit dem 01.04.20 alle Mails konsequent auf Einhaltung von RFC 5321/5322 checkt. Und alles, was früher noch akzeptiert wurde, wird jetzt abgelehnt. Unsere Kamera (altes China Modell) sendet z.B. u.a. folgendes: ... From: "johndoe IP Cam" <ipcam1@johndoe.com> To: "name1@johndoe.com" Subject:Mail Test Date: Wed, 08 Apr 2020 08:29:21 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_25850421==_" Comment: Message-ID missing from received message, added by johndoe.com. Message-ID: <5ACBA5C7.5E8D8B62.03F4@johndoe.com> Im To: Feld steht nur ein Name in Quotation Marks, aber die E-mail Adresse selber in <> fehlt. Im Subject: fehlt ein Leerzeichen hinter dem Doppelpunkt. Im Date: Feld fehlt der TimeZone Offset. Eine Message ID fehlt auch und wird erst durch unseren Mailserver hinzugefügt. All das störte den 1&1 SMTP bis zum 01.04. überhaupt nicht. Ich weiß auch nicht konkret, ob nur einer der Fehler ausschlaggebend ist oder alles. Du solltest aber mal Deine betroffenen Mails auf RFC Konformität überprüfen.

Das macht der Zyxel SecuExtender aber leider nicht. Er weist eine IP aus dem Company LAN zu und übergibt auch den Company DNS, aber keinen Suffix. Also mit meinem begrenzten Wissen denke ich trotzdem, dass der DNS des DC sauber läuft. Hier gab es rückwirkend noch nie irgendwelche Probleme oder Fehler in der Ereignisanzeige. Die SSL VPN Verbindung gibt auch den richtigen lokalen DNS Server mit. Nach dem Verbinden sehe ich im VPN Status direkt die eigenen IP aus dem Company LAN, die Tunnel Server IP und auch die IP unseres Company DNS. Außerdem löst er ja die Namen des Server Share sauber auf, entweder, wenn man das DNS Suffix manuell in den Adaptereinstellungen einträgt oder aber das Share mit dem FQDN mapped. Also läuft für mich der DNS und ist auch erreichbar. Evtl. liegt es ja am Zyxel VPN. Der Tunnel wird dabei direkt mit der Zyxel Firewall aufgebaut und ist nicht irgendwie "domain-integriert" Für mich geht es jetzt nur noch darum, das Suffix per GPO zu verteilen, damit ich es nicht händisch überall eintagen muss. Und ich kann halt per GPO nicht nur die "disjoint clients" auswählen, weil diese halt auch ab und zu im "joint namespace", also direkt in der Firma, sind. Deshalb meine Frage, ob es irgendwelche Auswirkungen hat, das Domain Suffix einfach allen zuzuweisen. Mag vielleicht unsinnig sein, sollte aber auch kein Brot fressen, oder?

Hi Dukel, danke für die Rückmeldung. Klingt erst mal interessant. Allerdings steht in der MS Anleitung, dass diese GPO nur jenen Computern zugewiesen werden soll, welche sich im "disjoint namespace" befinden. Unsere Notebook sind aber mal in der Firma, direkt im Firmen-LAN, und mal zu Hause und nur per VPN verbunden. Hat es irgendwelche Auswirkungen, wenn ich das Domain Suffix per GPO einfach allen betreffenden Rechnern zuweise?

Moin, ich benötige mal etwas Nachhilfe von den Spezialisten hier. Innerhalb unserer Firmendomain (1x Server 2016 Standard DC/ 18x W10 Pro Clients) verbinden wir bestimmte Server Shares als Netzlaufwerke auf jedem Client via Profil Batch für jeden User (net use ... \\server1\share). Das läuft soweit seit Jahren. In Corona Zeiten mussten wir jetzt auf Home Office umstellen. Dabei verbinden sich die Home Office User per Zyxel SSL VPN Client mit der Zyxel Firewall und bekommen Zugriff auf's Firmen LAN. Auch das läuft zufriedenstellend. Allerdings, und obwohl der Firmen DNS per DHCP mit an den Tunnelclient übertragen wird, konnten die Clients zu Hause nicht das Server Share auflösen. Kurzfristig haben wir uns damit beholfen, dass wir das Server Share per IP Adresse des Servers mappen (\\192.168.21.230\share). Damit kamen dann alle, sowohl in der Firma als auch von zu Hause auf das Laufwerk. Später merkten wir dann aber, dass unsere Office Serienbriefe nicht mehr funktionierten. MS Word wollte die, mit dem Serienbrief verknüpften Datendateien einfach nicht mehr öffnen. Auch sämtliche Änderungsversuche am Word Trust Center halfen nichts. Nach Internetrecherche mussten wir dann lernen, dass Office wohl keine IP Adressen für diesen Zweck akzeptiert und dass beim Nutzen von IP Adressen auch Keberos nicht mehr genutzt wird. Also keine so gute Idee. Als Nächstes hatten wir dann den FQDN des Server Shares zum Mappen genutzt (\\server1.firma.local\share). Das lief eigentlich auch gut und das Share konnte vom Home Office aus aufgelöst werden. Allerdings wollte MS Word auch hier unsere Serienbriefe nicht mehr ordnungsgemäß öffnen. Ging also auch nicht. Am Ende blieb nur händisch das DNS Suffix "firma.local" in den erweiterten DNS Einstellungen des Netzwerkadapters des VPN Clients einzutragen. Dann konnte sowohl das Server Share von zu Hause aufgelöst werden als auch die Serienbriefe funktionieren wieder. Allerdings müssten jetzt auf 18 Client Rechnern die DNS Suffixe händisch eingetragen werden. Gibt es dafür einen eleganteren Weg oder fällt Euch etwas ganz anderes ein? Vielen Dank Jörg

Moin Norbert, nach kurzer Inventur haben wir derzeit im Einsatz: 1x MS Office 2010 Home & Business 10x MS Office 2013 Home & Business 10x MS Office 2016 Home & Business Ich teste zwischen den Jahren mal weiter. Dann sind meine User alle im Weihnachtsurlaub. Gruß Jörg

Funktioniert hatte es auf jeden Fall bei Office 2010 unter W10, dagegen bei Office 2007 unter W7 nicht und bei Office 2013 unter W7 auch nicht. Ich check morgen erst mal meine Installations- und Lizenzübersicht. Gruß Jörg

... ach Du Sch..., wenn ich Deine Links so lese, war ja meine ganze Office Makro GPO Erstellung von heute für den A... Das hätte ich mir ja nicht träumen lassen, dass die neueren Office Versionen nicht über GPOs angepasst werden können. Ich habe den halben Tag dazu recherchiert und in keiner Anleitung stand auch nur ein Wort darüber. Jetzt muss ich erst mal 'ne Weile drüber schlafen, ob ich mir die Mühe mache, die einzelnen Registry Key herauszubekommen, um diese dann direkt per GPO zu setzen. Aber dies für alle Office Versionen und/oder sogar einzeln für alle Excel, Word, Powerpoint durchzuführen, ist wohl nicht die Mühe wert, da der User diese auch wieder zurückstellen kann. Ich werde wohl eher unsere 20 Rechner zu Fuß abklappern und die Makrosicherheit manuell hochsetzen bzw. disablen. Wenigstens etwas. Danke Dir, Norbert, für die Hilfe und Aufklärung. Gruß Jörg

Wir haben hier eine bunt gemischte Umgebung aus Office 2007, 2010, 2013 und 2016. Alle Lizenzen sind über Dell beim Rechnerkauf bezogen worden. Die älteren mussten noch separat installiert und aktiviert werden, die Neueren sind alle vorinstalliert und aktiviert. Sind meistens Home & Office Varianten. Von "Klick2Run" habe ich noch nie gehört.

ich komme hier tagsüber schlecht an die Userrechner ... Wie es scheint, haben die W7 Rechner nur diese Probleme, obwohl gpresult auch hier auch alles ok anzeigt. Trotzdem sind die Makroeinstellungen in Word nicht disabled und die komische Infomeldung kommt, die besagt, dass es abgestellt ist. Bei den W10 Clients scheint alles richtig zu laufen. Die Makroeinstellung ist disabled und es kommt auch keine andere Warnmeldung. Hier kann ich mich auch mit verschiedenen Usern anmelden, bleibt alles, wie es soll. Ich muss morgen mal weiterprobieren. Jetzt geh' ich nach Hause. Schönen Feierabend.

Auf den User Also gpresult zeigt mir eine erfolgreiche Anwendung des GPO. Allerdings steht im Report weiter unten bei "Zusätzliche Registryeinstellungen": "Für einige Einstellungen konnten keine Anzeigenamen gefunden werden. Eine Aktualisierung der von der Gruppenrichtlinienverwaltung verwendeten ADM-Dateien behebt möglicherweise das Problem. " Darunter sind dann die verschiedenen Office Policies mit diversen Statusnummern (entweder 1 oder 4) aufgelistet.

Moin, heute haben wir uns auch dazu durchgerungen, die Ausführung von Makros erst mal komplett zu unterbinden. Dazu haben wir nach Anleitung von Matthias-Staud.de eine GPO erstellt. Die Anwendung der GPO wurde auf eine AD Sicherheitsgruppe eingeschränkt. Diese funktionierte zuerst wegen MS 16-072 nicht. Nachdem wir dann aber die Gruppe der "Domänen-Computer" bei Delegierungen eingetragen hatten, kam die GPO auf den Clients zur Anwendung. Allerdings habe ich zur Zeit etliche Rechner (W7, Office 2010), die trotz "Abschaltung der Makros ohne Warnhinweis" bei jedem Word Dokument (auch Dokumente ohne Makros), eine Makro Hinweis-Meldung ausgeben: "Sie versuchen eine Funktion auszuführen, die Makrounterstützung erfordert. Bei der Installation dieses Programms haben Sie (oder Ihr Admin) entschieden, die Unterstützung für Makros oder Steuerelemente nicht zu installieren...". Bisher haben wir schon mal eine Office Reparaturinstallation durchgeführt - ohne Erfolg. Fällt Euch noch ein Ansatzpunkt ein? Gruß Jörg

Wen's interessiert, hier die Rückmeldung zur Lösung, welche zumindest bei uns Wirkung zeigt. Teile davon habe ich z.B. hier gefunden: für die Sperrung des Computers nach zeitlicher Inaktivität: GPO an eine User OU geknüpft: Benutzerkonfiguration > Richtlinien > Administrative Vorlagen > Systemsteuerung > Anpassung: Bildschirmschoner aktivieren Kennwortschutz für den Bildschirmschoner verwenden Zeitlimit für Bildschirmschoner setzen Bestimmten Bildschirmschoner erzwingen (sofortiger Lock Screen mit „rundll32.exe user32.dll,LockWorkStation“) für die erzwungene Domänenanmeldung (kein Durchstarten des Rechners bis zum Desktop bei gespeicherten Anmeldedaten) GPO an eine Computer OU geknüpft: Computerkonfiguration > Einstellungen > Windows-Einstellungen > Registrierung: Hier muss dann folgender Registrywert angelegt und auf "Aktualisieren" gesetzt werden: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\WinLogon > AutoAdminLogon auf „0“ Falls also ein User ein AutoLogon in seinem Windows aktviert hat (AutoAdminLogon auf „1“), wird dieser Wert überschrieben und wieder auf „0“ gesetzt.

In diesem Zusammenhang haben wir eben auch mal die GPO "Interaktive Anmeldung: Inaktivitätsgrenze des Computers" getestet. Hier wollten wir gerne erreichen, dass nach 30 Minuten Inaktivität der Rechner gesperrt wird. Doch die genannte GPO funktioniert nicht bei normaler Domänenanmeldung. Hier müssen wir wohl jetzt doch über den erzwungenen Bildschrimschoner gehen.

Moin und Dank für die zahlreichen Rückmeldungen. Hätte gedacht, da gibt's mittlerweile 'ne GPO für. Aber dann setze ich per GPO einfach den Registrywert "AutoAdminLogon" wieder auf "0" und die automatische Anmeldung müsste gegessen sein. Das Löschen des Schlüssels "DefaultPassword" kann ich mir dann schenken. (Bei uns sind einige User auch Lokale Admins auf Ihren Maschinen. Die Softwareentwickler müssen halt ständig Sachen installieren und testen. Und einige haben halt das AutoLogon aktiviert. Und wenn sie das dann später wieder auf "1" setzen, .... mal sehen, wann sie aufgeben. ) Gruß Jörg

Moin Forum, gibt es eine GPO für das Erzwingen des Anmeldebildschirms bei Rechnerstart? Bei uns haben einige User ihren Rechner auf "Durchstarten bis zum Desktop" eingestellt, ohne das die Anmeldeinformationen erneut eingegeben werden müssen. Nun, im Zuge der Einführung der EU-DSGV wollen wir hier mal einige Schwachstellen ausmertzen. Eine GPO für das Locken des Computers nach bestimmter Inaktivität habe ich gefunden, aber einen erzwungenen Anmeldebildschirm bei Rechnerstart leider nicht. Könnt Ihr mir da auf die Sprünge helfen? Gruß Jörg (DC Server 2016 / Windows 7 Clients)