SSL-Weiterleitung (SSL-Redirect) im IIS einrichten (mit URL-Rewrite)

Diese kleine Schritt-für-Schritt Anleitung zeigt, wie man seine Website(n) im IIS so konfigurieren kann, dass eingehende http:// Anfragen zur Website sicherem https:// umgeleitet werden. Das passiert automatisch im Hintergrund mit einer „301“ HTTP-Meldung (permanent redirect), damit Browser und Clients das auch speichern können.

1. Das Microsoft IIS URL-Rewrite Modul herunterladen und installieren

2. Den „Internetinformationsdienste (IIS)-Manager“ öffnen, die Site um die es geht öffnen und das „URL Rewrite“ Modul öffnen

3. Oben rechts „Regel hinzufügen“ klicken …

4. dann eine „Leere Regel“ unter „Eingehende Regeln“ auswählen …

5. Den oberen Teil der Regel („Übereinstimmung mit URL“) folgendermaßen ausfüllen:
– Name: Ein sinnvoller Name fur die Kosmetik (Pro-Tipp: Keine Umlaute oder Emojies)
– „Angeforderte URL“: Entspricht dem Muster
– „Unter Verwendung von“: Reguläre Ausdrücke
– „Muster“: (.*)

6. „Bedingungen“ ausfüllen
– Die (leider zu kleine) Auswahl von „Logische Gruppierung“: Übereinstimmung mit allen Elementen
– Dann den Button „Hinzufügen“ rechts daneben klicken


7. Die „Bedingung“ ausfüllen, danach mit „OK“ schliessen
– Bedingungseingabe: {HTTPS}
– „Überprüfen, ob die Eingabezeichenfolge“: Entspricht dem Muster
– Muster: ^OFF$
– Groß-/Kleinschriebung ignorieren: aktiviert

8. Nachdem die Regel übernommen wurde, weiter unten im IIS nun eine „Aktion“ konfigurieren und die Änderung übernehmen:
– Aktionstyp: Umleiten
– Aktionseigenschaften „URL Umleiten“: https://{HTTP_HOST}/{REQUEST_URI}
– Abfragezeichenfolge anhängen: Deaktivieren
– Umleitungstyp: Dauerhaft
Oben rechts „übernehmen“

Ergebnis (schnelle Lösung)

Das ganze manifestiert sich mit dem Klick auf „Übernhemen“ auch in der entsprechenden web.config Datei der Site. Man kann den <rules> Block natürlich auch manuell bearbeiten und/oder kopieren.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="SSL-Weiterleitung" stopProcessing="true">
                    <match url="(.*)" />
                    <conditions>
                        <add input="{HTTPS}" pattern="^OFF$" />
                    </conditions>
                    <action type="Redirect" url="https://{HTTP_HOST}/{REQUEST_URI}" appendQueryString="false" />
                </rule>
            </rules>
        </rewrite>
    </system.webServer>
</configuration>

Windows LAN Manager-Hashes für Benutzerkonten abschalten

Windows speichert Benutzerkontokennwörter („Anmeldeinformationen“) grundsätzlich als Hash. Das ist auch eine gute Idee, denn wenn Angreifer die SAM-Datenbank erbeuten hilft diese nicht beim Einbruch weiter. In der Theorie.

Normalerweise, also „by default“ werden dabei sowohl einen LAN Manager-Hash („LM-Hash“) als auch einen Windows NT-Hashwert („NT-Hash“) abgelegt. Windows speichert beide Hashes dann entwerder in der lokalen Security Accounts Manager Datenbank (SAM)-Datenbank oder im Active Directory.

Der LM-Hash ist bekanntlich eher schwach und SEHR anfällig für Angriffe, die das Plaintext-Kennwort extrahieren. Am besten verhindert man also, dass Windows den LM-Hash überhaupt speichert. Das ist seit ein paar Jahren (~2012) auch praktisch nicht mehr nötig und nur noch zur Abwärtskompatiblität da. Windows 10 hat das Flag beispielsweise schon ab der Installation gesetzt.

Da eine lebendige Domäne aber selten aus den aktuellensten PCs und Betriebssystemen besteht, lautet unsere aktuelle Empfehlung „auf Nummer sicehr“ zu gehen.

Lösung

Man kann Windows die Speicherung der LM-Hashes per GPO verbieten. Achtung, selbige muss auch auf DCs angewendet werden. Die „Default Domain Policy“ ist zum Beispiel ein guter Ort für eine solche Änderung.

Computerkonfiguration > Windows-Einstellungen > Sicherheitsrichtlinien > Lokale Richtlinien > Sicherheitsoptionen > „Netzwerksicherheit: Keine LAN Manager-Hashwerte für nächste Kennwortänderung speichern“

⚠️ Achtung: Bereits bestehende Hashes werden dadurch nicht sofort entfernt. Das passiert erst bei der nächsten Kennwortänderung.

Dynamische DNS Updates in einer Zone erlauben mit „dnscmd“

Den Haken „Dynamische Udpates“ in den Eigentschaften einer Zone haben vermutlich viele Admins gesetzt. Wenn man die Einstellungen zu DNS-Updates ändern will, kann man das in den Eigenschaften auch komfortabel tun.

Wenn es aber um sehr viel Zonen und dere Einstellunge geht, ist die Kommandozeile hilfreich …

Lösung

Das geht mit dem tool dnscmd mit diesen Parametern:

dnscmd /config <ZONE> /AllowUpdate 1

Genauso funktioniert das natürlich auch bei Reversen Lookupzonen. Wenn man, wie ich, zu faul ist diese abzutippen, bietet sich die Auflistung aller Zonen an:

dnscmd /enumzones

In der Textausgaben (ist auch noch filterbar, zum Beispiel mit /primay) kann man dann beliebig mit einer for Schleife herumaktualisieren, eine bearbeitbare Liste erstellen oder nach bestimmten Namen suchen (find/grep).

Wie man FSLogix automatisch aktualisiert (FSLogix Update)

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 der selben 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", 20231115
# [email protected] mit input von @j_vanneuville
#
# Achtung: Startet bei Erfolg den Server neu!

# URL zur aktuellen Version
$FslogixUrl= "https://aka.ms/fslogix_download"

# Download hierher
# Die literalen Pfade sind Absicht, anders waere RDS auch nicht supported
Remove-Item "C:\Windows\Temp\fslogix\install" -Force -Recurse
mkdir "C:\Windows\Temp\fslogix\install" -Force | Out-Null
Set-Location "C:\Windows\Temp\fslogix\install"
Write-Host "Download von" $FslogixUrl "... (180Mbyte)"
# Ausblenden der ProgressBar macht den Download 50x schneller m(
$ProgressPreference = 'SilentlyContinue'
Invoke-WebRequest -Uri $FslogixUrl -OutFile "C:\Windows\Temp\fslogix\install\FSLogixAppsSetup.zip" -UseBasicParsing

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

# Installieren + Neustart
Set-Location "C:\Windows\Temp\fslogix\install\FSLogix_Apps_*\x64\release"
Start-Process "FSLogixAppsSetup.exe" -ArgumentList "/install /quiet" -Wait -Passthru

Windows Installer uninstall, (MSI) Datei Fehler 2503 bei der Deinstallation

Manchmal möchte der Windows-Installer Programme die via MSI Datei auf das System gelangt sind nicht freiwillig deinstallieren. Der Installer zeigt stattdessen den Fehler „2503“ an.

Lösung um Fehler 2503 zu beheben

MSI-Dateien brauchen bei der Installation (meist Remote) andere Berechtigungen, als wenn man Sie lokal deinstalliert.

Die Lösung ist, in Verzeichnis %SystemRoot%\Temp der Gruppe „Benutzer“ („Users“) Vollzugriff zu gewähren:

icacls "%systemroot%\Temp" /grant Benutzer:F

Sobald man das getan hat, läuft der Deinstallter (Uninstall) sofort fehlerfrei durch.