Microsoft 365 Exchange online: SMTP-Relay sendet nicht mehr „SendAsDenied“ und „not allowed to send as“

„Auf einmal“ sendet ein SMTP-Relay Server nicht mehr alle E-Mails raus. Im (IIS-SMTP-) Log findet sich dieser Fehler:

SendAsDenied; <NAME> not allowed to send as <NAME>; STOREDRV.Submission.Exception:SendAsDeniedException.MapiExceptionSendAsDenied; Failed to process message due to a permanent exception with message [BeginDiagnosticData]Cannot submit message.

Wobei <NAME> ein Alias des Relay-Benutzers ist. Der Benutzer darf also nicht mehr als er selbst senden.

Lösung

Microsoft hat, natürlich ohne große Ankündigung, die implizite „Senden-Als“ Berechtigung für Aliase einer Mailbox entfernt. Man muss diese im Exchange Admin-Center einfach wieder aktivieren.

Das geht unter Einstellungen > Nachrichtenfluss > „Senden von Aliasnamen aktivieren“

… und schon kann der Nutzer wieder mit einem beliebigen Alias E-Mails (via SMTP) versenden.

Phishing per Fax🤦‍♂️

Dieser Beitrag kommt „aus gegeben Anlass“.

Phishing von Microsoft 365 Nutzern oder Google Business-Accounts sind schon länger Teil der normalen Tagesordnung. Herumschlagen mit erfolgreichem Phishing ist für die IT leider ebenfalls normal. Nicht weil die Admins ihr Opsec nicht beherrschen, sondern fast immer wegen stumpfer Benutzer. Zuhr Ehrenrettung: Angriffe werden wirklich immer besser. Angreifer nutzen echte gestohlenen E-Mails, echte Postfächer und hervorragend geschriebene (KI-Unterstütze) Texte.

Es gibt aber auch noch die absolute und totalresistente Stumpfheit. 🦍

Kein Witz. Das ist das (nicht ausgefüllte) Fax.

Die Geschichte mit dem Fax

Story as usual: Account wurde „gehackt“, vollumfänglich mißbraucht. Viele neue Phishing-Mails wurden verschickt (nach ~200 Mails schritt der Defender ein), OneDrive-Links mit Malware versendet, OneNote-Pages mit Phishing-Formularen veröffentlich, Office-Forms erstellt, also das „übliche“.

Weil der Nutzer einer E-Mail gefolgt war. Im Anhang der Mail ein PDF-Dokument mit einem schwarz-weiss-Screenshot (!) des Microsoft 365 Logins. Er druckte die Mail aus (wie angegeben), füllte diese mit Kugelschreiber aus (wie angegeben) und faxte (!) das Dokument mit seinen Zugangsdaten an eine US-Telefonnummer (wie angegeben) zurück.

Keine 12 Stunden später wurde der Account „gehackt“.

Wir dachten bisher, schon vieles gesehen zu haben. DAS war aber auch uns auch neu 😂

vSphere ESXi Host „(vim.fault.InvalidState)“ und/oder „The operation is not allowed in the current state.“

Eine Meldung wie diese kann auf einem ESXi so aussehen:

(vim.fault.InvalidState) {
   faultCause = (vmodl.MethodFault) null,
   faultMessage = <unset>
   msg = "Received SOAP response fault from [<<io_obj p:0x000000899beea2b8, h:5, <TCP '127.0.0.1 : 37600'>, <TCP '127.0.0.1 : 8307                                       '>>, /sdk>]: restoreConfiguration
The operation is not allowed in the current state."
}

Lösung

Meistens versucht der Admin da grade etwas, das im aktuellen Zustand wirklich nicht erlaubt ist. Zum Beipiel ein Backup der Konfiguration wiederherzustellen.

Es reicht in der Regel aus, den Host in den Wartungsmodus zu versetzen. An der Shell geht das mit:

vim-cmd hostsvc/maintenance_mode_enter

vmWare vSphere ESXi Host Konfiguration Backup/Restore/Migrate

In letzter Zeit müssen wir einige ESXi Hosts von USB-Sticks oder SD-Karten auf eine lokale boot-SSD (oder HDD, je nach Kundenwun$ch) umziehen. Das geht natürlich weder im laufenden Betrieb noch automatisch – man braucht eine Neuinstallation. Am einfachsten sichert man also die Konfiguration des vSphere ESXi Hosts, installiert schnell „sauber“ neu und stellt selbige Konfiguration wieder her.

ESXi von USB/SD Migration

  1. Backup der Konfiguration
  2. Host neu installieren
    • ⚠️ Die gleiche Version verwenden! ein Umzug von 7.x zu 8.x geht meistens schief, vor allem wenn man mehrere Netzwerke und/oder Storagedapter hat. Im Zweifel erst migrieren, dann updaten. vmWare empfiehlt zwar auch noch den gleichen Build, aber mit (leicht) unterschiedlichen Buildnummern hatten wir bisher noch keine Schwierigkeiten.
  3. Restore der Konfiguration

ESXi Konfiguration sichern (Backup)

SSH auf dem Host einschalten. Je nachdem via vSphere Host Client (Verwalten > Dienste > TSM-SSH > Starten) oder im vCenter (Host > Konfiguration > Dienste > SSH).

Als nächstes als root via SSH auf dem Hosts anmelden und diese beiden Zeilen ausführen:

# Volatile Konfiguration synchronisieren
vim-cmd hostsvc/firmware/sync_config

# Backup erstellen, Download-URL erhalten
vim-cmd hostsvc/firmware/backup_config

Die Backup-Datei dann herunterladen (configBundle-HOSTNAME.tgz). Von der angegebenen URL einfach direkt via HTTP(s) herunterladen. Das Sternchen (*) in der URL ist der Hostname oder die IP des Hosts.

ESXi Konfiguration widerherstellen (Restore)

Ein Restore-Vorgang klappt nur wenn:

  • Der Host die selbe Version hat, wie das Backup (z.B. v7.0.3)
  • Der Host im Wartungsmodus ist
  • Das Management-Network erreichbar ist

Dann geht das schnell und einfach:

  1. SSH einschalten
  2. Via SCP die Konfigurationdatei (configBundle-HOSTNAME.tgz) auf den Host nach /tmp/ hochladen
  3. Die Konfigurationdatei umbenennen zu configBundle.tgz
  4. Konfiguration widerherstellen
# Restore der Konfiguration starten
vim-cmd hostsvc/firmware/restore_config 0

Der Host bootet nach dem Restore SOFORT neu. Aber nach dem Neustart ist fdann auch schon alles sofort wieder „wie vorher“.

Keine Panik: Der Host startet ungefragt neu

Abhängigkeiten zu Windows-Diensten hinzufügen oder entfernen

Manchmal muss man Abhängikeiten von Windows-Diensten untereinander bearbeiten. Die Abhängigkeiten machen auch genau das was sie sagen: Dienste starten damit erst, wenn ein Anderer fertig ist.

Sinnvoll ist das zum Beispiel bei Lizenzdiensten die erst nach dem USB-Link starten sollen oder Middleware-Services erst nach einer Datenbank.

Lösung

An der guten alten CMD-Shell (als Administrator) lassen sich Abhängigkeiten schnell hinzufügen:

sc config <DIENST> depend=<ABHAENGIG VON ANDEREM DIENST>

Alle Abhängikeiten entfernen:

sc config <DIENST> depend= /