cj_berlin

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

vor 4 Minuten schrieb CoolBlue:

 

da man MS365 auf Server 2022 nicht mehr installieren kann, selbst dann nicht, wenn keine RDS Rolle aktiv ist, 

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...

vor 28 Minuten schrieb Nobbyaushb:

Eventuell einen Micro-PC oder ggf. einen Raspberry seriell oder per USB anschließen und ein Stück Software drauf.

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

vor 1 Minute schrieb mwiederkehr:

obwohl sie jetzt bestimmt zuverlässiger funktionieren als vor 20 Jahren.

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

vor 2 Minuten schrieb daabm:

 

As usual: "It depends" Fürs Monitoring gebe ich Dir Recht. Aber Patchverteilung sollte lokale Adminrechte haben (oder als SYSTEM laufen), und auf DCs heißt das "Domain Admin equiv". Oder hab ich was übersehen?

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.

vor 1 Minute schrieb RealUnreal:

Ok. Aber ich weiß noch nicht genau wie ich das verhindern kann.

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.

vor 17 Minuten schrieb Edvvde:

 

wenn es nach Microsoft geht, ist der Terminalserver ja eigentlich ein weiteres Mal (war ja schon bei 2019 angekündigt, wurde aber ja zurückgerudert) als Totgeburt auf den Markt geworfen.

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.

vor 6 Minuten schrieb RealUnreal:

hhmm...Da bin ich nicht sicher ob ich das verstehe. Der Sinn des SMTP Server ist doch, dass er senden kann oder was meinst du?

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

vor 10 Minuten schrieb Marco31:

Noch mal eine Frage dazu; es gibt ja leider einiges an Software (Monitoring, SW-Verteilung, Backup) die gerne Adminrechte oder sogar Domänen-Admin-Rechte haben möchte. Würde diese nicht das ganze Konstrukt torpedieren? 

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 

vor 8 Minuten schrieb Nobbyaushb:

Exchange 2016 ist max auf Server 2016 Supportet

Hat er doch auch gemacht???

vor 18 Minuten schrieb ir0nstrik3:

 

ich konnte ab den punkt mich nicht mehr bei Outlook anmelden usw

gibt es da irgendeinen leitfaden.

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.

vor 1 Minute schrieb MurdocX:

• Stufe den DC auf dem Exchange 2016 herunter (ob das einwandfrei klappt, kann ich dir nicht sagen.)

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.

vor einer Stunde schrieb kiffajoe:

 

Was kann man hier den Kunden/Partnern kommunizieren?

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.

Gerade eben schrieb NorbertFe:

Nö, also ich habs genauso verstanden. ;)

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.