Kategorie-Archiv: Allgemein

Windows VPN Fehler „Ein interner Authentifizierungsfehler ist aufgetreten“

Veröffentlicht am von — Keine Kommentare ↓

Heute habe ich (viel zu lange) an einem interessanten Fehler herumgesucht.

Eine benutzende Person konnte sich nach einem (korrekten) Kennwortwechsel nicht mehr per VPN einwählen. Die Domänen-Anmeldung funktioniert aber, PC-Zugriff kein Problem, Dateiserver, Microsoft 365, ERP … alles mit dem neuen Kennwort kein Problem. Einzig die VPN-Einwahl funktioniert nicht mehr:

Im Ereignisprotokoll des Clients (der Server protokolliert gar nichts – auch im IASLog nicht) tauch diese Meldung „645“ von RasClient (Ereignis-ID: 20227) auf:

CoID={EE17AD36-00AF-4D2E-B293-A43EFD0E0DBA}: Der Benutzer "<NAME>" hat eine Verbindung mit dem Namen "<VERBINDUNG>" gewählt, die Verbindung konnte jedoch nicht hergestellt werden. Der durch den Fehler zurückgegebene Ursachencode lautet: 645.

Lösung

Das neue Kennwort enthielt ein ganz bestimmtes Sonderzeichen: € (Euro-Zeichen)

Windows NT4 ist schuld. Das konnte noch kein € (Euro-Zeichen). Ersetzt man das Zeichen geht’s sofort.

Details

In diesem VPN wird SSTP genutzt, also PPTP-over-TLS. Schnell, einfach, sicher, flexibel und sehr gut zu verwalten. Das bedeutet aber, dass die Authentifizierung CHAP (MSCHAPv2) nach RFC2759 nutzt. Und da gibt es schlichtweg nur ASCII im „Password“ Feld. Etwas anderes gab es 1999 unter NT4 noch nicht so richtig 🤪

Der Windows Client, NICHT der Server, prüft also die Kompatibilität mit der RFC und bricht bei der Nutzung von High-Characters sofort ab. Daher auch der interne Authentifizierungsfehler am Client.

vCenter Update 8.0.3 schlägt fehl „Pre-Install failed for vmidentity:Expand“

Veröffentlicht am von — Keine Kommentare ↓

Das Upgrade auf den neuen vCenter Server 8.0.3 („U3“) bleibt gerne mal mit diesem Fehler stehen:

Pre-install failed for vmidentity:Expand

Das Logfile in /var/log/vmware/applmgmt/Patchrunner.log verrät auch ein paar mehr Details:

vmidentity:Expand INFO vmidentity Found ssoserver cert in TRUSTED_ROOTS, This will be deleted from store
vmidentity:Expand INFO vmidentity.utils Deleting cert from TRUSTED_ROOTS VECS store
vmidentity:Expand ERROR vmidentity.utils Failed to execute command '['/usr/lib/vmware-vmafd/bin/dir-cli', 'trustedcert', 'unpublish', '--cert', '/storage/seat/software-updateub8jty50/stage/scripts/patches/payload/components-script/vmidentity/<Cert_filename.pem>', '--login', '<VC FQDN>']'
vmidentity:Expand ERROR vmidentity.utils dir-cli failed. Error 1168: Operation failed with error ERROR_NOT_FOUND (1168)

Lösung

Es gibt da noch eine Bug im Update-Setup, das das Zertifikat „ssoserver“ nicht aus dem Certificate-Store gelöscht bekommt. Aber man kann das einfach manuell machen und das Setup danach fortsetzen.

  1. Alias des „ssoserver“ Zertifikates besorgen (Die Zahlenkette hinter der Bezeichnung „Alias“)
    /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store TRUSTED_ROOTS --text | egrep 'Alias|ssoserver|Key Usage' -A 1 | egrep -v 'Entry type|--'
  2. Das falsche Zertifikat löschen („<ALIAS>“ durch die Zeichenkette von 1. ersetzen)
    /usr/lib/vmware-vmafd/bin/vecs-cli entry delete --store TRUSTED_ROOTS --alias <ALIAS> -y

Danach kann man das Setup mit einem Klick auf „resume“ fortsetzen.

Excel/Word „Die Datei kann nicht geöffnet werden, da der Dateipfad größer als 259 Zeichen. Kürzen Sie den Pfad oder den Dateinamen“

Veröffentlicht am von — 2 Kommentare ↓

Es kommt vor, dass Benutzer beim Öffnen von Dateien aus tief verschachtelten Ordnern (oder sehr langen Pfadnamen) diese Fehlermeldung von Office-Apps wie Excel, Word oder PowerPoint erhalten:

Die Datei kann nicht geöffnet werden, da der Dateipfad größer als 259 Zeichen. Kürzen Sie den Pfad oder den Dateinamen

Abgesehen von dem grammatikalischen Fehler, dass im ersten Satz das abschließende Verb fehlt (vermutlich „ist“), stimmt diese Meldung.

Lösung

Es gibt keine Lösung, aber einen Workaround.

Microsoft Office-Apps, allen voran Excel, unterstützen keine Pfade mit mehr als 259 Zeichen. Das hat mit der heiligen Abwärtskompatibilität zu tun, denn es könnte ja sein das noch ein Unternehmen auf VB-Macros aus den 90ern baut. Und mit „ein“ sind hier „100% der Fortune 500“ gemeint 😉

  • Windows local and UNC files: 260 characters
  • OneDrive / SharePoint files synced to the local drive: 260 characters
  • Online OneDrive / Online SharePoint files (opened directly in the WebApp) 400 characters

Der Workaround ist einfach: Die Excel-Web-App nutzen und die Datei direkt auf dem Sharepoint (Online) bearbeiten,

Debian apt-get Fehler „Die folgenden Signaturen waren ungültig: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key“

Veröffentlicht am von — Keine Kommentare ↓

Auch der Schlüssel von sury.org (oft genutztes PHP Repository) ist abgelaufen.

Die folgenden Signaturen waren ungültig: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key

Lösung

Das Debian-Paket-Repository sury.org hat seinen Paketsignaturschlüssel geändert. Um den Fehler zu beheben, holt man sich einfach den neuen Schlüssel mit:

apt-key adv --fetch-keys https://packages.sury.org/php/apt.gpg

Dann tut es auch sofort ein apt-get update wieder.

Debian apt-get Fehler „Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY B7B3B788A8D3785C“

Veröffentlicht am von — Keine Kommentare ↓

Hat man das MySQL Repository zu seiner /etc/apt/sources.list hinzugefügt, tritt nach einer Weile bei einem apt-get update der Fehler auf:

Fehler:1 http://repo.mysql.com/apt/debian bullseye InRelease
  Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY B7B3B788A8D3785C

Lösung

Die fehlenden GPG-Keys müssen nur schnell hinzugefügt werden:

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys B7B3B788A8D3785C

Der strenge Syntax mit den Protokoll-Header („hkp://“) und dem Port (:80) ist dabei erst seit Bullseye (11) Pflicht.