FSLogix automatisch aktualisieren (FSLogix autp Update) [UPDATE]

Update: Im FSLogix-Paket haben sich Pfade geändert, die unnötige Fehlermeldung zu Beginn ist entfernt und die Pfade sind angepasst.

Leider ist FSLogix nicht in Windows-Update(s) enthalten. Der Admin einer RDS-Farm muss also selbstständig für seine Updates sorgen.

Da es aber in der Tat häufiger mal Updates für FSLogix gibt (Siehe Hotfix-Liste), die beispielsweise Fehler mit der Microsoft Office 365 Aktivierung beheben, lohnt es sich diese auch wirklich zu installieren. Man kann das Setup in derselben Version auch mehrfach ausführen, es wird nur installiert, wenn wirklich etwas Neues dabei ist.

Der Vorgang ist prinzipiell einfach: Neue Version herunterladen, ZIP-Datei auspacken, App-Installer ausführen und Server neu starten. Wäre das nicht toll, wenn das auch automatisch geht?

Lösung

Bei dem letzten Einsatz, der das Problem „Leeres Microsoft 365 Anmeldefenster“ behebt, ist ein PowerShell Script das selbiges tut entstanden. Einsatz auf eigene Gefahr ☺️

# Update FSLogix to "latest"
# [email protected]
#
# Achtung: BOOTET bei Erfolg den Server neu, ohne Rueckfrage!

# Aktuelle FSLogix-Version liegt hier
$FslogixUrl= "https://aka.ms/fslogix_download"

# Download landet hier
if ( Test-Path "C:\Windows\Temp\fslogix\install" ) { Remove-Item "C:\Windows\Temp\fslogix\install" -Force -Recurse }
mkdir "C:\Windows\Temp\fslogix\install" -Force | Out-Null
Write-Host "Download von" $FslogixUrl "... (180Mbyte)"
# Ausblenden der ProgressBar macht den Download 5x schneller
$ProgressPreference = 'SilentlyContinue'
Invoke-WebRequest -Uri $FslogixUrl -OutFile "C:\Windows\Temp\fslogix\install\FSLogixAppsSetup.zip" -UseBasicParsing

# Auspacken
Write-Host "Auspacken von C:\Windows\Temp\fslogix\install\FSLogixAppsSetup.zip ..."
Expand-Archive -LiteralPath "C:\Windows\Temp\fslogix\install\FSLogixAppsSetup.zip" -DestinationPath "C:\Windows\Temp\fslogix\install" -Force -Verbose
Set-Location "C:\Windows\Temp\fslogix\install\x64\release"

# Installieren + Neustart
Start-Process "FSLogixAppsSetup.exe" -ArgumentList "/install /quiet" -Wait -Passthru

IIS ARR (Reverse Proxy) Fehler 400 (Keycloak, Camunda, Visi …) weil „Ein möglicherweise gefährlicher Request.Path-Wert wurde vom Client (:) entdeckt.“

In einem IIS mit ARR der andere Web-Services hinter sich schützt, tritt (gehäuft in letzter Zeit) schon mal ein „unerwarteter“ Fehler 400 auf. Im Ereignisprotokoll gibt es auch einen (ernsthaft) hilfreichen Hinweis. Der Fehler tritt gehäuft bei Sites auf, die das Angular Framework verwenden.

Eventlog Anwendung, Quelle ASP.NET 4.0.<build>, Ereignis-ID (EventID) 1309,

Event code: 3005 
Event message: Es ist eine unbehandelte Ausnahme aufgetreten. 
 
Application information:
    Trust level: Full 
    Application Virtual Path: / 
    Application Path: C:\inetpub\<PATH> 
 
Exception information: 
    Exception type: HttpException 
    Exception message: Ein möglicherweise gefährlicher Request.Path-Wert wurde vom Client (:) entdeckt.
   bei System.Web.HttpRequest.ValidateInputIfRequiredByConfig()
   bei System.Web.HttpApplication.PipelineStepManager.ValidateHelper(HttpContext context)

Die Request URL enthält einen Doppelpunkt. Einen „gefährlichen“ Doppelpunkt!!1elf

Dass der Doppelpunkt „gefährlich“ ist, liegt grundsätzlich nicht am IIS, sondern an der RFC1738, die genau definiert, wie eine URL aussehen darf („Uniform Resource Locators“). Darin ist nämlich festgelegt, dass …

…only alphanumerics, the special characters „$-_.+!‘(), and reserved characters used for their *reserved purposes* may be used unencoded within a URL

Der Doppelpunkt („colon“) „:“ ist so ein reserviertes Zeichen. Die RFC wird sogar noch deutlicher: „it’s used after the protocol (http, https) and after the domain to specify a port.“

Natürlich lässt sich das Verhalten des IIS anpassen, um solche „illegalen“ Requests zu erlauben. Das sollte man aber zumindest mit seinen Security-Leuten absprechen, die Änderung ist nicht ganz ohne. Die „Lösung“ hier lädt nur die Waffe, wenn sich der Admin damit selber ins Knie schießt, ist das sein Problem 😉

Lösung

Die „richtige“ Lösung ist natürlich, in der Webseite (Web App, Service, was auch immer) korrekt zu serialisieren. Angular nutzt dazu den UrlSerializer router; richtig eingesetzt tritt der Fehler nicht auf.

Oft hat man als Admin „am anderen Ende“ aber keinen Einfluss auf die Entwicklung so einer App. Man kann daher in der Site-Konfiguration (web.config) auf dem IIS die Request-Filterung konfigurieren.

Das hier ist eine Beispiel-Konfiguration, die mehrere solcher „Eigenheiten“ umgeht.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.web>

    <!-- Off=Debugausgaben in HTTP-Fehlern
         On=Gekuerzte Ausgavben (Produktivumgebung)
    -->
	<customErrors mode="Off" />

    <!--
        maxUrlLength: Lange Request URIs erlauben
        maxQueryStringLength: Lange Query-String (nach dem '?') erlauben
        relaxedUrlToFileSystemMapping: Dateisystemspfade (Doppelpunkte, \\?\) in URIs erlauben
        requestPathInvalidCharacters: Bestimmte Zeichen erlauben
    -->
	<httpRuntime
		maxUrlLength="10999"
		maxQueryStringLength="2097151"
		relaxedUrlToFileSystemMapping="true"
		requestPathInvalidCharacters="*,%,?,\,&amp;,&lt;,&gt;"
	/>
    </system.web>

    <system.webServer>
        <security>
            <!-- allowDoubleEscaping: \\ vor ? erlauben
             -->
            <requestFiltering allowDoubleEscaping="true">
                <requestLimits maxUrl="10999" maxQueryString="2097151" />
            </requestFiltering>
        </security>

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

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

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“

Ä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