VPN mit Zertifikaten von iOS zu Windows RRAS mit Endpoint Manager (Intune) konfigurieren

Veröffentlicht am von — Keine Kommentare ↓

Wir möchten erfolgreich eine VPN-Verbindung auf iOS-Endgeräte verteilen. Das „OnDemand“ VPN soll verwendet werden und daher muss der Nutzer mit Zertifikaten authentifiziert werden. die Authentifizierung am NPS (Radius) ist noch eine andere Sache, dieser Beitrag konzentriert sich auf das IKEv2 zwischen iOS und Windows Server RRAS.

Unsere iOS-VPN-Intune Checkliste

  • Microsoft Endpoint Manager (ehemals Intune) soll die VPN-Verbindung via Konfigurationsprofil verteilen
    • Die Devices sind schon im EPM angekommen und synchronisieren fröhlich Richtlinien
  • Microsoft Endpoint Manager soll den Nutzern (auf den Geräten) automatisch ein Zertifikat ausstellen (via „Certificate Connector“)
    • Funktioniert perfekt mit einer Microsoft CA
    • Die CA und NPS sind nicht Teil dieses Beitrages, aber mit Anleitung durchaus machbar
  • Die iPhone/iPads Geräte haben iOS 14.2 oder neuer (!)
  • Es wird IKEv2 verwendet
    • Denn das ist die einzige Möglichkeit, iOS mit RRAS unter der Verwendung von Zertifikaten zu verbinden
  • Der RRAS Server ist ein Windows Server 2019
  • RRAS ist korrekt konfiguriert (Ports, Erreichbarkeit, Radius …)
  • NPS ist korrekt konfiguriert (Verbindungsanforderungs- und die Verbindungsrichtlinie …)

Im Prinzip folgen wir dem brauchbaren „Deploy Always On VPN“ Guide von Microsoft unter https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/always-on-vpn-deploy-deployment

Der Trick ist eine funktionierende Kombination aus iOS IKEv2-Parametern und den zugehörigen Phase1/2 Parametern auf der RRAS-Gegenstelle zu erstellen. Denn das ist nicht Default und leider auch praktisch nirgends dokumentiert.

RRAS-Server

Um erfolgreich eine IKEv2 Verbindung von iOS zum RRAS Server herzustellen, ist dem RRAS-Server (und iOS) die richtige Kombination der Ciphersuits vorzugeben. Das geht am RRAS via CustomPolicy. Natürlich exklusiv an der PowerShell.

Viele Kombinationen funktionieren nicht. Diese hier funktioniert:

Set-VpnServerConfiguration -CustomPolicy -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES256 -DHGroup Group14 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -PfsGroup PFS2048 -SALifeTimeSeconds 28800 -MMSALifeTimeSeconds 86400 -SADataSizeForRenegotiationKilobytes 1024000

Dann muss man dem RRAS-Server in aller Regel erklären, das er auch fragmentierte IKE Pakete annehmen soll. Bei einer Schlüsselgröße von 2048bit mit Zertifikaten und einer MTU von 1492 oder 1500byte wird es oft knapp und Pakete fragmentieren:

New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\Ikev2\" -Name EnableServerFragmentation -PropertyType DWORD -Value 1 -Force

Wenn beides geschehen ist, muss der RRAS neu starten:

Restart-Service RemoteAccess

Microsoft Endpoint Manager

Innerhalb der VPN-Richtlinie kommt es auf die IKEv2 Parameter an. Die sind in einer bestehenden Richtlinie erreichbar unter Devices > Richtlinie (Name) > Properties > Configuration settings > IKEv2 Settings. Dort gibt es ab etwa der Mitte die „wichtigen“ (und nicht offensichtlichen) Einstellungen:

Perfect forward secrecy: Enable

Certificate revocation check: Disable

Use IPv4/IPv6 internal subnet attributes: Disable

Mobility and multihoming (MOBIKE): Enable

Redirect: Enable

Security Association Parameters

Encryption algorithm: AES-256

Integrity algorithm: SHA2-256

Diffie-Hellman group: 14

Lifetime (minutes): 1440

Child Security Association Parameters

Encryption algorithm: AES-256

Integrity algorithm: SHA2-256

Diffie-Hellman group: 14

Lifetime (minutes): 480

… und schon geht’s. Also schon ging es bisher bei unseren Systemen 🙂

Vielleicht schreiben wir irgendwann noch einen großen Artikel mit allen Schritten, also von der Zertifizierungsstelle bis zum Endgerät … oder jemand anderes tut das. Oder, wenn ihr sowas braucht, ruft ihr uns an 😋

Windows Hello PIN entfernen/zurücksetzen (PIN entfernen ausgegraut)

Veröffentlicht am von — Keine Kommentare ↓

Bei dem Versuch eine vergessene Windows Hello PIN innerhalb eines Domänen-Netzwerkes zu löschen, ist mir aufgefallen, dass der „entfernen“ Knopf ausgegraut war.

Um diese PIN trotzdem entfernen zu können, müssen nur die Inhalte von: %windir%\ServiceProfiles\LocalService\AppData\Local\Microsoft\NGC gelöscht werden.

Lösung

Eingabeaufforderung als Administrator ausführen

(um den Besitz an dem Ordner zu übernehmen)

takeown /f %windir%\ServiceProfiles\LocalService\AppData\Local\Microsoft\NGC /r /d j

(garantiert die Administratorberechtigung für diesen Ordner)

icacls %windir%\ServiceProfiles\LocalService\AppData\Local\Microsoft\NGC /grant administratoren:F /t

(den Inhalt des Ordner löschen)

del /f /q C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\NGC\*.*

Anschließend neu starten

Achtung! Alle Zugangsmöglichkeiten von Windows Hello, wie Fingerabdruck, Gesichtserkennung und sonstige sind nicht mehr verfügbar und müssen neu eingerichtet werden.

PrintNightmare: Drucker hinzufügen Fehler 0x0000011b

Veröffentlicht am von — Keine Kommentare ↓

Nach der Installation von KB5005033 (und den folgenden Patches) kann es dazu kommen, dass Clients im Netzwerk nicht mehr zuverlässig drucken können. Die Druckerliste ist leer, es passiert nach dem Auftrag nichts mehr oder alle Drucker (außerf den lokalen) sind einfach verschwunden.

Verbindet man einen so „verschwundenen“ Drucker von einem gepatchten Windows-Druckserver neu, erhält man statt eines neu verbundenen Druvkers die Fehlermeldung 0x0000011b. Das betrifft in der Regel nur Maschinen, die eine alte Version des zugehörigen Druckertreibers installiert hatten.

Nutzt man auch noch Drucker(treiber) die einen einem eigenen Porttyp mitbringen, bleibt sogar die Liste der „Anschlüsse“ plötzlich leer.

Lösung

In die Registry importieren:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Print]
"RestrictDriverInstallationToAdministrators"=dword:00000000

Nach einem Neustart des Druckerspooler geht’s sofort wieder.

VMware ESXi CDP/LLDP mit standard vSwitch

Veröffentlicht am von — Keine Kommentare ↓

Da ich ständig vergesse, wie man auf einem VMware standard vSwitch CDP bzw. LLDP konfiguriert um Uplinks von/zu physischen Switches schnell und einfach nachvollziehen zu können:

Per SSH auf den ESXi verbinden und folgenden esxcli Befehl ausführen:

esxcli network vswitch standard set --cdp-status=both -v vSwitch0

--cdp-status=both konfiguriert den vSwitch sowohl für’s empfangen, als auch senden von CDP/LLDP Paketen.

Mit dem Parameter -v <vSwitch> wird der Name des zu konfigurierenden vSwitch angegeben.

Alternativ geht das auch per esxcfg:

esxcfg-vswitch -B both vSwitch0

Das war schon alles, nun kann man ganz einfach auf den physischen Switches die CDP/LLDP Infos abrufen.

Z.B. auf HPE (Aruba) Switches:

show cdp neighbors
show lldp info remote-device

Häufig liest man online, dass es nicht möglich ist (oder zumindest nicht supported) auf standard vSwitches CDP/LLDP zu aktivieren. Über den vSphere Client oder den ESXi Host client geht das auch (soweit ich weiß) tatsächlich nicht. Dort heißt es dann bei den vmnics auch „CDP/LLDP steht auf diesem physischen Netzwerkadapter nicht zur Verfügung.“

Dieser KB-Artikel beschreibt das vorgehen aber auch ganz offiziell.

Linux Kernel I/O Scheduler für SSDs mit hoher Last ändern

Veröffentlicht am von — Keine Kommentare ↓

Im Linux Kernel sind seit 2.6.3irgendwas drei verschiedene I/O Scheduler enthalten. Der Klassiker NOOP, Deadline und der „moderne“ CFQ. So ein I/O Scheduler besitzt immer einen eigenen Algorithmus, um Lese- und Schreibrequests zu verarbeiten und an das Device für die physische Abarbeitung zu übergeben.

Mit „cat /sys/block/sda/queue/scheduler“ lässt sich der aktuelle Scheduler anzeigen

NOOP

Der NOOP-Scheduler ist ein vergleichsweise einfaches Ablaufmodell, das einfach alle I/O Requests in einer einzigen FIFO-Queue verwaltet und weitergibt. Es gibt in dieser Queue Request Merging, um und Seek-Times zu vermeiden, aber z.B. eine Sortierung findet nicht statt.

Deadline

Der Deadline-Scheduler ist gebaut um die „Starvation“ von Requests zu verhindern, also App-Timeouts durch *_WAIT zu vermeiden. Dazu werden in einer komplizierten Struktur Request mit einer Expiration Time versehen und in verschiedene Queues abgearbeitet. Dabei wird versucht, die Antwortzeiten für jeden Eintrag einzuhalten.

CFQ

Der „Completely fair queuing“ Scheduler ist zugleich der komplexeste, mächtigste und Standard-Scheduler des Kernels. Der Algorithmus versucht eine faire Aufteilung der vorhandenen I/Os auf alle Prozesse gleicher Priorität. Die „Fairness“ bezieht sich dabei auf die zeitliche Länge der Time-Slots und nicht auf die verwendete Bandbreite. Sequentielle Anfragen werden im gleichen Slot als immer eine höheren Durchsatz erzielen als ein Prozess mit random-Writes (welche durch Seek-times verlangsamt wird).

Dafür hat CFQ als einziger Scheduler die Möglichkeit, Prozesse in Prioritätsklassen einzuteilen. Von RT (RealTime) bis I (Idle) sind verschiedene abstufingen möglich.

Welchen nehme ich?

Wie immer in der IT gibt es hierauf keine eindeutige Antwort. In aller Regel ist der von der jeweligen Distribution ausgelieferte (und getestete) Modus eine gute Wahl.

In speziellen Szenarien, wie zum Beispiel extrem hoher random I/O Last bei vielen CPU-Kernen, kann die Umstellung auf einen anderen Scheduler aber etwas mehr Durchsatz (meint: mehr I/Ops) bewirken.

Wir empfehlen oft den Deadline Scheduler für Storages mit vielen SSDs, weil dieser nicht so viel Rechenzeit für das Mergen benötigt. SSDs sind oft schneller mit der Antwort fertig, als viele hunderte Merge-Operationen brauchen um abgesetzt zu werden. Noch schneller wäre NOOP, aber da ist die Gefahr groß, das ein Prozess mit exessiver I/O Nutzung alls anderen Operationen blockiert.

Wie stellt man den Kernel um?

Nachsehen welcher Scheduler [aktiv] ist:

[email protected]:~# cat /sys/block/sda/queue/scheduler
noop deadline [cfq]

Kernel Scheduler ändern:

[email protected]:~# echo deadline > /sys/block/sda/queue/scheduler

Die Änderung ist sofort aktiv, aber nicht persistent. Um die Umstellung über den nächsten Reboot zu retten, muss man dem Kernel den Startparameter elevator= mitgeben.

Unter Debian (beispielweise) passiert das in der /etc/default/grub in der Zeile

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash elevator=deadline"