cj_berlin

Moin, AFAIK ist das nur bei Exchange Online möglich. On-prem werden Mails, die über SMTP mit Authentifizierung eingereicht werden, nirgends gespeichert (außer beim Empfänger, wenn er intern war). Hier Flashback: Auf diese Idee sind schon einige gekommen, und ich meine, es gibt auch ein Tool, welches das macht. Wenn es nur um den Nachweis geht, kannst Du das ja per Mailflow Rule kennzeichnen und zurück an die Mailbox schicken, und dort per Mailbox Rule anhand der Kennzeichnung in Sent Items verschieben. Oder so.

Moin, nein, der Wert im Attribut verleiht dem User keine Berechtigungen am Computer-Objekt - meistens wird der User aber auch Owner sein, und daraus leiten sich die Rechte an, wenn auch nicht automatisch. Das ist aber per se ein Problem. Das Attribut ist nur dafür da, das MachineQuota überwachen zu können.

Moin, hast Du mal probiert, es zu löschen? Warum sollte das kritisch sein? So wie es jetzt ist, ist der jeweilige Admin ja vermutlich sogar Owner des Computer-Objektes - das wäre evtl. kritisch, wenn das Admin-Account kompromittiert wird. Aber die SID eines Accounts kann doch jeder lesen, also nicht "Jeder", sondern jeder Und welchen Bezug hat es zum LAPS? Wenn ein Angreifer wissen will, wer LAPS-Attribute lesen darf, fragt er auch danach und nicht nach obskuren Attributen...

...es sei denn, der Zugriff erfolgt von Terminalservern oder VDI Man sollte es dennoch lieber lassen.

Das ehrt Dich - ist aber in diesem speziellen Fall vermutlich eh egal, denn wenn ich einen Deiner User phishe (hat Adminrechte, wir erinnern uns!), komme ich an CredMan aller lokaler Benutzer auf dieser Maschine so oder so ran.

Ich glaube, dieses Forum ist der falsche Ort, um auf diese Frage eine objektive Antwort zu erwarten. Klar werden weiterhin Admins gebraucht, aber bei offiziellen Lehrgängen sind die Schulen ja nicht ganz unabhängig von den Herstellern, und die pushen ja sehr stark in die Cloud. Man findet aber durchaus gute Weiterbildungsmöglichkeiten zu den klassischen Themen, so bei https://www.it-administrator.de/trainings/ oder auch bei anderen Verlagen.

Hast Du da auch ne Quelle zu, aus der Dein Wissen stammt?

Und spätestens hier ist es dann vollkommen wurscht, welche vermeintlichen Sicherheitsmaßnahmen Du wo ergreifst. Leg einfach auf dem Master-PC gleichlautende Konten mit gleichen Kennwörtern an, sensibilisiere die User, dass sie die Kennwortänderungen 2x machen müssen, und vergiss den ganten CredMan-Kram.

So etwas wäre ja auch nur beim Versand aus Funktionspostfächern überhaupt zustimmungsfähig. Wenn eine Mail mit einem persönlichen Absender vor Verlassen der Organisation ohne Wissen des Absenders bearbeitet werden kann, müsste das die Beschäftigtenvertretung sofort auf die Barrikaden treiben. Und in der Tat ist ein solcher Workflow im DMS eher zu Hause als im Mailsystem.

Warum ist IPMI böse? (Immer vorausgesetzt, Hardware-Managrment ist vom produktiven Traffic getrennt)

Moin, Intel RMM kann zumindest IPMI. Damit kannst Du mit Start-PCSVDevice die Maschine einschalten.

Es sei denn, der Zugriff erfolgt von einer Terminalserver- oder VDI-Lösung aus. Dann ist es funktional supported, aber für die Performance übernimmt Microsoft keine Gewähr: https://docs.microsoft.com/de-de/outlook/troubleshoot/data-files/limits-using-pst-files-over-lan-wan#outlook-2010-or-later-versions-hosted-remotely-by-using-windows-server-2008-r2-or-later-rdsh-or-vdi-configuration Ist bei diesen Usern %AppData% auch umgeleitet? Ich habe bei Outlook schon alle möglichen Schweinereien erlebt, die auf eine Umleitung von %AppData% zurückzuführen waren.

...also vielleicht nicht die letzte Änderung, sondern pwdLastSet. Letzte Änderung kann sonstwas sein.

Dann musst Du die Geräte wohl erst einmal betanken - ebenfalls mit dem HPDM. Images gibt es bei HP zum Download.

Folgendes funktioniert (mit Ausnahme der Zeile 2, aber das könnte Copy-/Paste-Artefakte sein): $ledger = [xml](Get-Content C:\Temp\ledger.xml) $ledger.LedgerImport.consolidate.accountsReceivableLedger.ForEach({$_.exchangeRate='H'}) $ledger.Save("c:\temp\ledger-processed.xml") Du hast vermutlich übersehen, dass es in einem consolidate-Element mehrere accountsReceivableLedger-Elemente gibt. Und der Umweg über die HashTable ist zwar interessant. aber nach Deiner Beschreibung brauchst Du ihn nicht - es ist ja entweder Payable oder Receivable, und dann weißt Du ja, was reinkommt.

Moin, XML kann man in PowerShell objektorientiert verarbeiten: https://www.educba.com/powershell-xml/ Dann wäre exchangeRate eine Property, der Du ein 'H' oder ein 'S' zuweisen kannst.

Moin, HP DeviceManager (https://h30670.www3.hp.com/portal/swdepot/displayProductInfo.do?productNumber=HPDEVMAN) oder Client Cloud Manager. Dass die Änderungen nach Neustart wieder zurückgerollt sind, liegt am Write Filter. Den musst Du ausstellen, wenn Du Änderungen vornimmst, die permanent bleiben müssen.

Wenn die Audit-Settings am DC auch fehlgeschlagene Logons protokollieren lassen, ja.

Moin, solange in der Umgebung NTLM und/oder RC4 in Kerberos aktiv sind, ist ein Kennwortwechsel nach wie vor das einzige wirksame Mittel gegen Pass-The-Hash (nicht zur Vorbeugung, wohlgemerkt, sondern nur zur Eingrenzung).

Ja.

Versuch's zuerst mit dem KMS Client Key und dann mit der ROK. Schlägt das fehl, musst Du mit Microsoft telefonieren und schauen, was sie dann sagen. Und bei Domain Controllern ist eine Umwandlung von Eval zu Prod grundsätzlich nicht möglich.

For-Schleife, da kannst Du auf das nächste Element gucken.

Absolut.

...also in den Eigenschaften des Postfachs, nicht als Regel im Postfach? Dann ist es klar, dass Journaling nicht feuert, denn die Weiterleitung per targetAddress erfolgt ja bereits im Routing - damit kommt die Mail mit der Postfachdatenbank nie in Berührung!

Ja, weil Proxies Authentifizierung unterstützen, hier geht es aber um Firewalls. Und ja, egal, für was Du oder ich das halten, es funktioniert so - SOPHOS mit STAS, PaloAlto mit UserID, usw. usw. Alternative dazu ist ein Agent auf jedem Endpoint, wie TMG einen hatte.