Autoren-Archiv: weed

PrintNightmare: Drucker hinzufügen Fehler 0x0000011b (Update)

Veröffentlicht am von — 12 Kommentare ↓

Nach der Installation von KB5005033 (und den folgenden Patches) kann es dazu kommen, dass Clients im Netzwerk nicht mehr zuverlässig drucken können:

  • Die Druckerliste ist (und bleibt) leer
  • Es passiert nach einem Druckauftrag nichts mehr
  • Alle Netzwerkdrucker sind verschwunden

Verbindet man einen so „verschwundenen“ Drucker von einem gepatchten Windows-Druckserver neu, erhält man statt eines neu verbundenen Druckers die Fehlermeldung 0x0000011b. Das betrifft in der Regel Maschinen, die eine ältere Version des zugehörigen Druckertreibers installiert hatten.

Nutzt man auch noch Drucker(treiber) die einen einem eigenen Porttyp mitbringen, bleibt auch die Liste der „Anschlüsse“ plötzlich leer.

Lösung

In die Registry importieren:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Print]
"RestrictDriverInstallationToAdministrators"=dword:00000000

Nach einem Neustart des Druckerspoolers geht alles wieder.

In einigen Fällen kann auch dieser Registry Key auf dem Printserver die Lösung sein:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Print]  "RpcAuthnLevelPrivacyEnabled"=dword:00000000

Hiernach ist ebenfalls ein Neustart des Spoolers (auf dem Printserver) erforderlich.

Update

Damit Benutzer auch weiterhin Drucker installieren können und nicht nach dem „Administrator“ gefrat werden, muss zusätzlich zur PointAndPrint Richtlinie dieser Schlüssel gesetzt werden

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Printers\PointAndPrint]
"RestrictDriverInstallationToAdministrators"=dword:00000000

Aruba „Error connecting to the activation server: Activate TLS connection error.“

Veröffentlicht am von — Keine Kommentare ↓

Im Log eines Aruba Switches finden sich oft „zahlreiche“ Warnungen. In diesem Fall alle fünf Minuten, so dass der Rest des Protokoll kaum lesbar ist. Diese Meldung sagt, das „Activation Server“ von Aruba nicht aufgelöst werden kann. Wir wissen auch nicht was das soll, lasst unsere Switches doch einfach in Ruhe.

Lösung: „Aruba Activation“ abschalten

Zeigt den Zustand der „Activation“:

# show activate provision
Configuration and Status - Activate Provision Service

Activate Provision Service : Enabled
Activate Server Address : device.arubanetworks.com
Activation Key : Not Available

Zum Deaktivieren in den Config Modus wechseln

# config
(config)# activate provision disable
(config)# activate software-update disable
(config)# wr mem

Und schon hat man Ruhe.

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

Veröffentlicht am von — 1 Kommentar ↓

„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🤦‍♂️

Veröffentlicht am von — Keine Kommentare ↓

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

Veröffentlicht am von — Keine Kommentare ↓

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