cj_berlin

Der Einwand von @NilsK ist aber nicht von der Hand zu weisen - wenn Benutzer aus "ihren eigenen Strukturen" kommen, das heißt, nicht eurer Organisation angehören und ihre Geräte auch nicht, wird die Lizenzierung des Ganzen richtig spannend. Nächste Frage, um Dich von Network Traces als Methode zur Logon-Protokollierung abzuhalten: Könnt ihr die benötigten Daten nicht aus dem VPN ziehen? Dort lassen sie sich vielleicht sogar einem User zuordnen, denn die IP, welche der VPN-Server vergibt, ist ja vermutlich nicht für jeden User fix...

Authentifizieren tun sich die User aber trotzdem. Insofern hat der Einwurf von @daabm auch ohne AD Bestand. Oder verbinden sie sich direkt zur Datenbank auf einem Datenbark-Port und mit der dort vorhandenen internen Authentifzierung?

Moin, grundsätzlich schon, Einstieg hier: https://docs.microsoft.com/de-de/windows/win32/wmisdk/changing-access-security-on-securable-objects Besser ist jedoch

Deutlich. Ich kann die guten Erfahrungen, die @Sunny61 gemacht hat, dennoch nicht 100% bestätigen. Allerdings sehe ich als Consultant natürlich nur die Problemfälle, meine Betrachtung ist also alles andere als objektiv

Moin, ein Tip: Wenn Du Skript-Code, Configs, CSV-Dateien usw. postest, verwende bitte den Code-Button (links neben dem Smiley). Das erlaubt den Helfenden, den Text verlustfrei in den Editor ihrer Wahl zu kopieren und, wenn es eine unterstützte Sprache ist, gibt es sogar hier im Forum schon Syntax-Hervorhebung. Ansonsten: Da bei Dir HideEULAPage auf true steht, der Lizenzvertrag aber laut Deinem Post dennoch angezeigt wird, läuft da grundsätzlich irgendwas falsch. Zu den weiteren Punkten, die bei Dir noch fehlen, hier: https://docs.microsoft.com/en-us/windows-hardware/customize/desktop/unattend/microsoft-windows-shell-setup-oobe

Nö. Die Aussage war lediglich: Keines dieser Systeme muss in Besitz eines Accounts (Name + Passwort) sein, das Mitglied in DA ist. Dass ein Management-System in Tier0 auch ein Tier0-System ist, ist unbestritten.

Wenn Du auf die Konfiguration des Servers keinen Einfluss hast, kannst Du es vermutlich nicht verhindern. Du müsstest ja quasi einstellen, dass der Benutzer (der sich authentifiziert) Mails nur an eine Adresse senden darf (z.B. an seine eigene). Dann kann aber jemand, der im Besitz der Zugangsdaten ist, auch per IMAP in dieses Postfach reinschauen... Mir würden da ein paar krude Bastellösungen einfallen, aber das möchte ich hier nicht ausbreiten.

Hast Du da auch einen Beleg zu? Wenn ich mich noch richtig erinnere, fehlte die RDS-Rolle im Technical Preview. Daraufhin bloggte Ryan Mangan, dass Multisession Win10 jetzt die Zukunft von RDS wäre. Ryans Blog ist aber kein Indikator für die Strategie von Microsoft, und ein Technical Preview ist nur ein sehr grober Indikator für die zukünftigen Features. Im RTM war RDS komplett drin.

Ja, aber dieser SMTP sollte, zumindest mit den Anmeldedaten, nicht weitersenden. Denk Spamschleuder.

Moin, keines der angeführten Systeme muss Domänen-Adminrechte haben. Viele, leider auch Entwickler, haben sich daran gewöhnt, dass Domain Admins auf jedem Member lokale Admins sind. Dies ist aber nicht in Stein gemeißelt, sondern in die Group Policy und sollte, wenn man Security ernst nimmt, dort auch entfernt werden. Lokale Adminrechte auf irgendwelchen Systemen könnten durchaus benötigt werden, dann gibt man sie halt und schaut, wie die Anwendung sie technisch verwendet (d.h. man schaut zuerst und gibt dann ). Insbesondere ist zu prüfen, wie das System mit den hinterlegten Credentials umgeht. Vieles wird aber auch im SYSTEM-Kontext erledigt - Softwareverteilung (nicht jede, aber beispielsweise SCCM), Monitoring (alles, was mit Agenten arbeitet), Backup - auch da gibt es agentenbasierte Konstrukte, die kein Account mit irgendwelchen Rechten benötigen. Natürlich besteht theoretisch die Gefahr, dass jemand genau das angreift (OK, die Gefahr ist seit Solorigate nicht mehr theoretisch). Aber einen Agenten, der nur lesen kann (Monitoring) dafür missbrauchen, dass er auch was verändert, ist schon höhere Kunst.

Moin, grundsätzlich hat ja SMTP erst mal nichts mit dem Zugriff auf die Postfächer zu tun. Je nachdem, wie Du das baust, muss die verwendete SMTP-Anmeldung theoretisch gar keinen Zugriff auf irgendwelche Postfächer ermöglichen. Die viel realere Gefahr wäre die einer DoS-Attacke, wobei jemand Deinen Mailserver vollmüllt. Und natürlich darf der verwendete SMTP-Server nicht auch noch senden können, jedenfalls nicht mit der Anmeldung, die Du bei Kunden hinterlegst.

Normalerweise, wenn der User ein bestimmtes Land eingestellt hat, würde Outlook das erben, inklusive des ersten Tages der Woche. Aber Du kannst ja schauen, ob der entsprechende Registry Key - entweder im Policy-Zweig oder im Settings-Zweig bei diesen Usern gesetzt ist. Vielleicht war ja jemand clever?

https://admx.help/?Category=Office2016&Policy=outlk16.Office.Microsoft.Policies.Windows::L_Firstdayoftheweek

Hat er doch auch gemacht??? Korrektes Zertifikat einspielen und URLs auf allen vDirs korrekt setzen - als erste Amtshandlung. Leitfaden: https://docs.microsoft.com/en-us/exchange/exchange-deployment-assistant?view=exchserver-2016 und dort "Upgrade from 2013" wählen, Vorgehensweise sollte identisch sein.

In früheren Versionen hätte das nicht geklappt, zumindest Exchange wäre danach nicht mehr derselbe

Hätte aber im vorliegenden Fall nur bedingt geholfen, da die Absender ja nicht aus der alten Domain stammen. Würden sie das tun, müsste die Zustellung ja schon am SPF scheitern.

Wenn in euren Mail-Verläufen personenbezogene Daten enthalten sind (die Daten der eigenen Mitarbeiter eingeschlossen), müsst ihr das der zuständigen Datenschutzbehörde melden.

Der TO hat aber, wie wir jetzt wissen, etwas anderes gemeint.

Man hat Dich missverstanden. Bei Exchange möchte man http://owa.firma.de automatisch auf https://owa.firma.de umleiten, und das ist bei KEMP in den Exchange Templates mit dabei,

Moin, noch nie beNUTzt - was kann das Teil denn? Kann es PowerShell ausführen? Dann kannst Du den Raspberry per SSH Remoting die Windows-Maschinen herunterfahren lassen.

Moin, das muss mit der Installation von TeamViewer auf dem Server zu tun haben, denn ich kenne mindestens ein Dutzend Server verschiedenster Versionen, wo das, was Du beschrieben hast, einwandfrei funktioniert. Um auf den Server bereits vor der Anmeldung einer Sitzung zuzugreifen, brauchst Du den "unattended access".

Das war nicht die Frage. Was wird verhindern, dass das VPN genau so gehämmert wird wie zuvor RDP? Wenn Du irgendwas Authentifizierungspflichtiges ins Internet öffnen stellen willst, musst Du entweder damit rechnen, dass es gehämmert wird, oder einen zweiten Faktor vorschalten (Achtung! nicht NACHschalten, das ist wichtig). Es ist sehr unwahrscheinlich, dass es dafür eine elegante One-Box-Lösung geben wird.

Achso. Und das VPN wird authentifiziert werden... wodurch?

Dann musst Du die Suffixe (sowohl die eigenen als auch die Suchliste) per GPO verteilen und nicht von DHCP zuweisen lassen:

Ich denke, es geht dabei weniger um z.B. Bilder und mehr um Dokumente, die wahlweise im Browser - ohne Bearbeitungsmöglichkeit - angezeigt werden können. In OWA haben wir die Option ja schon seit einigen Jahren (zu faul nachzuschauen, ob nicht "seit vielen Jahren" angebracht wäre). Wobei auch bei Bildern könnte man bei Web Preview die Auflösung beschränken.