Autoren-Archiv: weed

vCenter lässt plötzlich root Login nicht mehr zu „Unable to authenticate user“

Veröffentlicht am von — Keine Kommentare ↓

Vor ein paar Tagen hatten wir Probleme mit der Anmeldung beim vCenter Appliance Management Interface („VAMI“). Statt der Dienste-Gui sehen wir nur die Fehlermeldung

Unable to authenticate user

Das Passwort für den Root-Benutzer war ganz sicher war. Die Verbindung via SSH funktioniert problemlos.

Lösung

Der Dienst „applmgmt“ ist vermutlich abgestürzt. Der Dienst kann aber an der Shell neu gestartet werden und ist praktisch sofort wieder verfügbar.

  1. Als root (oder [email protected]) via SSH einloggen und mit shell die Shell starten. Sollte die Shell nicht freiwillig wollen, lässt sich diese mit shell.set --enabled true einschalten und danach starten.
  2. Den Dienst starten:
    service-control --start applmgmt

Und schon geht das GUI wieder.

Sollte das wider erwartend nicht funktionieren oder in einer Fehlermeldung enden, loht eventuell ein Blick auf https://knowledge.broadcom.com/external/article?legacyId=68149

Kennwortänderung für alle Benutzer in Microsoft 365 erzwingen

Veröffentlicht am von — Keine Kommentare ↓
„Free digital security background“/ CC0 1.0

Das Erzwingen einer „selbstständigen“ Kennwortänderung kommt schon mal vor – vor allem, wenn ein Admin mit viel Wissen ein Unternehmen verlässt. Das ist in Microsoft 365 im GUI leider nicht möglich, aber natürlich an der PowerShell.

So zwingt man einen (oder mehrere) Benutzer, das eigene Kennwort bei der nächsten Anmeldung zu ändern – ohne das Kennwort zu kennen.

Lösung

Nach dem Obligatorischen Connect-MsolService:

Set-MsolUserPassword -UserPrincipalName [email protected] -ForceChangePasswordOnly $true -ForceChangePassword $true

Das lässt sich nun weiterverarbeiten.

Zum Beispiel, um alle Microsoft 365 Benutzer „auf einmal“ zu zwingen, ihr Kennwort zu ändern:

Get-MsolUser -All | Set-MsolUserPassword -ForceChangePasswordOnly $true -ForceChangePassword $true

So filtert man (zum Beispiel) eine Gruppe von Benutzern und erzwingt die Änderung:

Get-MsolUser -All | ? { $_.Country -eq "Hessen"} | Set-MsolUserPassword -ForceChangePasswordOnly $true -ForceChangePassword $true

Wichtig: Man muss sowohl den Parameter ForceChangePassword als auch ForceChangePasswordOnly setzen. Wenn man ForceChangePasswordOnly überspringt, wird nur ein neues Kennwort für den Benutzer (automatisch) generiert und man muss selbiges manuell verteilen (Stichwort „Initialkennwort“).

Ältere HP-Switches (ProCurve) „Unable to negotiate with <DEVICE> port 22: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1“

Veröffentlicht am von — Keine Kommentare ↓

Ältere HP Switches oder andere embedded-Systeme sprechen schon mal kein aktuelles SSH und aus Sicherheitsgründen lehnt der Default SSH-Client die Verbindung ab. Es gibt eine ganze Menge Key-Exchange-Methoden, die mittlerweile veraltet sind oder als unsicher gelten.

Der entscheidende Teil ist dabei der Letzte, der Angibt, welche Verfahren der Server anbietet:

Unable to negotiate with SWITCH.EXAMPLE.COM port 22: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1

Denn man muss seinem SSH-Client nur noch beibringen, dass dieser das für diese Verbindung akzeptieren soll.

Lösung

SSH versteht mit dem Parameter -o die „optionalen“ Verfahren für die Verbindung:

ssh -o KexAlgorithms=diffe-hellman-group14-sha1 [email protected]

Je nach Switch (=SSH-Server) einfach das passende Verfahren benennen, fertig.

Passiert das häufiger, also verbindet man sich öfter mit diesem Gerät, kann (sollte) man die passende Konfiguration in seine ~/.ssh/config eintragen:

Host SWITCH.EXAMPLE.COM
    Ciphers 3des-cbc
    KexAlgorithms +diffie-hellman-group14-sha1
    User administrator

Windows Update Fehler 0x800F0986 bei Cummulativem Update

Veröffentlicht am von — Keine Kommentare ↓

Bei der Installation des aktuellen CU auf einem Windows Server 2019 weigerte sich Windows Update beharrlich, das Setup erfolgreich abzuschließen. Schuld war der hilfreich benannte Fehler „0x800F0986„.

Die Fehlernummer 0x800F0986 steht lauf MSEC für, ebenfalls wenig hilfreich, „Corrupted or missing system files“.

Lösung

In diesem Fall hat geholfen:

  1. Microsoft Edge installieren (war noch nicht vorhanden)
  2. Ausführen, „Als Administrator“ – wobei \\SERVERNAME\ eine „gesunde“, also erfolgreich gepatchte Maschine war:
    DISM.exe /Online /Cleanup-Image /RestoreHealth /Source:\\SERVERNAME.EXAMPLE.TLD\C$\Windows
  3. Reboot

Danach wurde auch KB5041578 ganz ohne Fehler installiert. Was den Effekt ausgelöst hat werden wir (hoffentlich) nie erfahren.

Wer kommt auf sowas? GDI-fix im 7-Zip Changelog

Veröffentlicht am von — Keine Kommentare ↓

Manchmal fragt man sich, wer auf sowas stößt. Und das auch noch kompetent debuggt 🤔

Frisch aus dem aktuellen 7-Zip 24.08 Changelog:

[…] there was a leak of GDI objects (internal resources in Windows) in „Confirm File Replace“ window, causing problems after 1600 displays of „Confirm File Replace“ window from same running 7-Zip process.

In meinem Kopf entsteht dazu ein Bild von einem total frustrierten Furry, dem sich die flauschigen Nackenhaare aufstellen, weil das Backup der Manga-Sammlung nicht vernünftig zippt – und bei der Eintausendsechshundertundersten Meldung das 7-Zip GUi crasht.

Schön, das das endlich gefixt ist 😀