cj_berlin

<OT>Wissen vs. Tool </OT>

Siehe https://gist.github.com/Manouchehri/fd754e402d98430243455713efada710

Aber die TSA hat doch nichts mit CA zu tun. Ich kenne auch niemanden, der eine TSA selber betreibt, ob die CA nun von Microsoft ist oder von anderen.

https://docs.microsoft.com/en-us/windows/win32/secauthz/well-known-sids

Moin, um das ein wenig aufzuräumen: Timestamping ist wichtig und richtig, hat aber nichts damit zu tun, wo das Signierungs-Zertifikat herkommt. Letzteres kann selbstsigniert, aus eigener PKI (vermutlich meint der TO das mit "auf dem DC" ) oder gekauft sein. Das Vertrauen der Clients muss man so oder so herstellen. Wie man ein Zertifikat "testen" kann, ist relativ unklar - vermutlich bekommst Du ein Zertifikat, das zwei Wochen gültig ist. Da kannst Du auch gleich ein selbstsigniertes nehmen. Denkt daran: In Office kann man nach wie vor nicht sagen "nur Skripte mit Signatur von Anbieter X, Y und Z zulassen". D.h. wenn ihr signierte Makros generell zulasst, könnte ein Angreifer einfach ein Makro signieren, und das wäre zugelassen. aus https://support.microsoft.com/en-gb/office/macros-in-office-files-12b036fd-d140-4e74-b45e-16fed1a7e5c6

Man kann schon, es ist nur nicht supported.

Moin, was passiert denn, wenn Du auf dem Windows 10-Client den IMAP-Sync manuell initiierst, dann den Client bootest und dich danach gleich wieder dort anmeldest, ohne Schwenk auf Windows 11? Funktioniert der Sync dann automatisch? Falls ja, dann müsstest Du vermutlich die OST roamen...

Hat er ja. pfSense Router, auf dem NUT läuft. Nur kann anscheinend NUT nicht so gut mit Windows...

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.