Proxmox aufgefundene vDisk

Wollte Storage einer VM von einem LVM Store auf einen anderen verschieben und bin nach Start draufgekommen dass ich nicht das Hakerl bei „delete on source“ gemacht habe – abgebrochen in der Annahme dass er die unfertige Kopie am Ziel dann entfernt.

Natürlich hat er die Zieldisk nicht gelöscht und man konnte sie auch nicht manuell löschen weil er meinte es gibt eine VM dazu.

Lösung: qm disk rescan, das erkennt die in der Luft hängende Disk und fügt sie als „unused0“ der VM hinzu wo man sie dann kontrolliert löschen kann.

Quelle: https://forum.proxmox.com/threads/orphaned-vm-disk-removal.144637/

TP-Link Switches, Omada und die VLANs

Obwohl TP-Link seit mehreren Jahren in diversen Supportforen angefleht wird das zu ändern sind neuere Omadataugliche TP-Link Switches ausschließlich über VLAN 1 adoptierbar.

Mein Lösungsansatz (für mich weil ichs bis zum nächsten Mal garantiert erfolgreich vergessen hab):

  • Port auf der Kiste wo Omada läuft freihalten
  • Bei Bedarf diesen Port auf 192.168.0.irgendwas (<> 1) konfigurieren, kein VLAN
  • Switch anstecken (am besten auf einem Port der auch in der Zielkonfiguration Default VLAN (1) hat) und mit Strom versorgen
  • Warten bis der Switch in Omada auftaucht
  • Adopten
  • [falls noch nicht erledigt VLANs in Omada unter Settings/LAN erzeugen]
  • Bei den Ports die Zielkonfiguration der Ports herstellen (VLANs/Trunks) herstellen.
  • In der Config unter VLAN Interface das gewünschten Management VLAN hinzufügen enablen und editieren
  • „Management VLAN“ enablen und Adresse vergeben (oder für die mutigen halt mit DHCP am Managementinterface arbeiten)

Wenn man den Switch jetzt an dem Port in Richtung eine Switches dessen Zielport mit dem Management VLAN tagged ist anbindet sollte man normal weiter administrieren können.

Falls der Konfigurationsport nicht VLAN 1 behalten soll entsprechend konfigurieren.

HP LTE Modem und der Linuxschlaf

Problem: Linux, HP EliteBook 850 G5 mit HP LTE Modem. Nach 1-12x zuklappen und Sleep erwacht das Modem nicht mehr aus dem Schlaf und man muss alles mögliche und unmögliche restarten (am besten aber rebooten) um Dornröschen wachzuküssen.

Ursache: Würde mal annehmen HP?

Lösung/Workaround: Es gibt ein Tool mit dem man bestimmte USB Geräte zurücksetzen kann: usb_modeswitch, man braucht „nur“ Vendor- und Product-ID von dem Gerät welche man mit lsusb rausfinden kann:

Danach einfach das Gerät resetieren und es sollte zurück ins Leben kommen:

sudo usb_modeswitch -v 03f0 -p a31d --reset-usb

Proxmox Host Firewall macht dicht

Problem: Single Host Proxmox Installation. 3 Linux Bridges – vmbr0 für den Host selbst, vmbr1 für die CorpNet Simulation, vmbr2 für die Internetsimulation. Keine bessere Möglichkeit als Host Firewall gefunden um vmbr1 und vmbr2 voneinander abzuschotten (also das Internetsimulation nicht die VMs in der CorpNetsimulation sieht) und folgende Regel eingetragen (123 ist Internet, 122 ist CorpNet):

Hat super funktioniert, auch über Reboots hinweg bis ich angefangen habe pve8to9 für Upgrade auf PVE 9.0 auszuführen und paar Warnings weggemacht habe (nix was eigentlich Firewall ändern sollte) – auf einmal ging nix mehr rein aber alles raus (VM und Host selber kamen überall hin).

Ursache: Unbekannt, irgendwas hat die Regel die vorher einwandfrei auch ohne Zusatzregeln funktioniert hat geändert.

Lösung (vermutlich grauslicher Hack aber für mich reichts): Da man ja remote nicht mehr drauf kommt lokal oder über KVM oder IPMI in /etc/pve/nodes/<hostname>/host.fw IN und OUT Regeln eintragen:

[OPTIONS]

nftables: 1

[RULES]

FORWARD DROP -source 192.168.123.0/24 -dest 192.168.122.0/24 -log nolog
OUT ACCEPT -log nolog
IN ACCEPT -log nolog

Und schon gehts wieder 😀

Global Secure Access: on-prem SSO mit PIN

Problem: Entra Joined Client mit Global Secure Access (Entra Private Access), Anmeldung des vom AD gesyncten Entra-Accounts erfolgt über PIN (=Windows Hello for Business). Zugriff auf on-prem Resourcen via SSO funktioniert nicht (es wird nach PIN gefragt um dann fehlenden Zugriff auf Domain Controller zu melden). Es gibt eine Enterprise Application mit den notwendingen Ports für den Domain Controller, Private DNS ist enabled – Zugriff wenn mit Passwort angemeldet funktioniert einwandfrei.

Ursache: Für SSO bei Anmeldung via WHfB muss was Zertifikat am Domain Controller angeht mehrere Punkte erfüllt sein:

  • Zertifikat am DC muss „KDC Authentication“ als EKU haben
  • Aktuelles Template dafür ist „Kerberos Authentication“, Domain Controller enrolled es aber nicht vollelektrisch
  • Client muss Root CA des DC Zertifikats in den Trusted Root CAs haben
  • CRL im CDP und AIA dürfen nicht (zuerst) auf LDAP liegen weil Client zum Zeitpunkt des Zugriffs zwar CRL prüfen muss aber noch kein Ticket hat um im AD den LDAP Zugriff machen zu dürfen

Lösung: Die Vorraussetzungen schaffen 😀

  • Auf der CA die CDP und AIA Extensions um LDAP erleichtern und HTTP enablen – je nach Geschmack auch gleich die Delta CRLs disablen.
  • Altes Zertifikat am DC löschen.
  • Alte Templates für Domain Controller von CA entfernen: Domain Controller, Domain Controller Authentication, Directory Email Replication.
  • Eine Group Policy erstellen oder bestehende die (auch) auf Domain Controller wirkt ändern sodass AutoEnrollment enabled ist (Template Kerberos Authentication hat schon AutoEnroll für DCs).
  • gpupdate/certutil -pulse/Reboot – was auch immer Autoenrollment heute triggert.
  • In der GSA Enterprise App für Domain Controller Access (oder in einer neuen App) ein Segment hinzufügen damit der Client durch den Tunnel auf den HTTP Ort wo die CRL liegt kommt – bei mir hats nur mit FQDN funktioniert.
  • Am Client das Root CA Zertifikat in die Trusted Root CAs importieren (Machine Store).

Quellen:

Global Secure Access: Breakglass mode

Problem: Global Secure Access Client (bei mir Entra Private Access) startet im Breakglass Modus, keine Verbindung.

Ursache: Im Eventlog zu GSA (Windows Komponente!) findet man beim Start Warnings der Art
ErrorMessage=AADSTS9002341: User is required to permit SSO, Microsoft hat offenbar aufgrund des EU DMA für bestimmte Aktionen andere Verhaltensweisen eingebaut wenn der Client in der EU steht – u.a. eben auch dass für jedes Mal SSO extra nachgefragt werden muss, schaut dann so aus:

Offenbar kann der Global Secure Access Client das nicht anzeigen und scheitert damit mit der Anmeldung und kann sich keine Policies holen.

Lösung/Workaround: Die Ausnahmebehandlung für die EU ist sehr lowtech – in C:\Windows\System32\IntegratedServicesRegionPolicySet.json sind Aktionen und die Ausnahmeregionen hinterlegt, das File ist natürlich mit TrustedInstaller geschützt also entweder händisch übernehmen und das Land der Wahl für die Policy mit der GUID 1d290cdb-499c-4d42-938a-9b8dceffe998 entfernen oder das Script im unten verlinkten Reddit-Beitrag verwenden (Achtung, löscht nur Region NL und versagt auf einem deutschen Windows weil die Administrators natürlich dort Administratoren heißen…) und rebooten.

Quellen:

Intune Portal auf Linux (Arch): Something happened [4u3ga]

Weil ich auf Schmerzen stehe hab ich versucht Intune Portal auf Arch Linux zum Laufen zu bringen, Anleitungen:

https://aur.archlinux.org/packages/intune-portal-bin

https://blog.strits.dk/how-to-enroll-arch-linux-in-microsoft-intune

https://wiki.archlinux.org/title/KDE_Wallet#Unlocking_KWallet_automatically_in_a_window_manager

(die Geschichte mit OpenSSL 3.3.2 unbedingt auch machen)

Ich bin wollte es aber superklug lösen und hab beim ersten Logon versucht mit FIDO2 Stick zu arbeiten was natürlich grandios in die Hose gegangen ist und danach bin ich ohne Angabe von Kennwort immer sofort hier gelandet:

Something went wrong. [4u3ga]

Auch tausend mal reinstallieren und alle bekannten Caches zu dem Produkt löschen hat nix gebracht.

Im Endeffekt wars aber der IdentityCache vom Edge den das Zeug offenbar tatsächlich benutzt (in den Fehlermeldungen von intune-portal stand auch immer was von oneauth…):

~/.cache/Microsoft/Edge/IdentityCache/OneAuth

Das gelöscht (und natürlich verliert dann der „normale“ Edge seine Identities) und schon gings….

OpenWrt 24.10.x NAT66 Performance

Weil ich mir jedes Mal wieder den Wolf suche hier mal verewigt: Mit Linux Kernel 6.6.x in OpenWrt 24.10 bricht die NAT66 Performance auf 10 MBit/s ein.

Mit einem beherzten Update auf 24.10.1 oder setup von ethtool in OpenWrt und einem ethtool -K wan rx-gro-list off kann man das auf 150 MBit/s heben.

Um auf einem MT7621 basierten Gerät (wie dem MikroTik RouterBoard 750Gr3) zur vollen Leistung zu kommen kann man in LuCI unter Network/Firewall das HW Offloading einschalten:

Entra Logoff bei Citrix StoreFront Logoff

Situation:

  • Edge im Kiosk Modus
  • StoreFront als Startseite
  • SAML Authentication gegen Entra (in weiterer Folge Logon am VDA via FAS)
  • Sehr kurzer Session Timeout wegen Kiosk
  • Kleinster Edge Kiosk Idle Zeitraum ist eine Minute
  • Citrix StoreFront Logoff macht KEIN Entra Logoff
    • man kann einfach auf „Anmelden“ klicken ist sofort wieder mit dem letzten SAML User drin weil die Cookies alle noch da sind

Lösung:

  • am StoreFront unter C:\Inetpub\wwwroot\Citrix\{Store}Web\Custom in script.js:
    CTXS.Extensions.afterWebLogoffComplete = function() {
    window.location.replace("https://login.microsoftonline.com/mytenant.onmicrosoft.com/oauth2/logout?post_logout_redirect_uri="+encodeURIComponent(window.location));
    callback();
    }

„Citrix Workspace-App ermitteln“ umgehen

Situation:

  • Edge im Kiosk Modus
  • StoreFront als Startseite
  • Desktop Auto Launch wird benötigt
    • benötigt protocolHandler=true in web.config
    • heißt CWA Detection muss laufen
  • Wir wollen aber direkt zur Anmeldung gelangen

Lösung:

  • am Kiosk Rechner
    • HKLM/SOFTWARE/Microsoft/Windows/AssignedAccessConfiguration/Profiles/{GUID}/AllowedApps/App0 beim Wert „Arguments“ hinten dran „--disable-features=Translate
  • beim Kiosk User (HKEY_USERS/{SID vom User}/SOFTWARE/Policies/Microsoft/Edge):
    • AutoOpenAllowedForURLs: 1 = „https://url.vom.storefront“
    • AutoOpenFileTypes: 1 = „ica“
    • AutoLaunchProtocolFromOrigins = „[{„allowed_origins“: [„https://url.vom.storefront“], „protocol“: „receiver“}]
  • am StoreFront unter C:\Inetpub\wwwroot\Citrix\{Store}Web\Custom in script.js:
    CTXS.Extensions.preInitialize = function() {
    CTXS.setCookie("CtxsClientDetectionDone","true");
    CTXS.setCookie("CtxsClientVersion","24.9.10.28"); //whatever
    CTXS.setCookie("CtxsHasUpgradeBeenShown","true");
    CTXS.setCookie("CtxsIsPassThrough","false");
    callback();
    }