Archiv des Autors: weed

SSTP VPN unter Apple MacOS X nutzen

Veröffentlicht am von — 6 Kommentare ↓

Leider liefert Apple standartmäßig immer noch keinen SSTP-GUI-Client mit, daher muss man einen selber bauen oder installieren. Der SSTP-Client von sstp-client.sourceforge.net wurde ursprünglich für Linux gebaut, aufgrund des statischen Bianaries läuft es aber auch perfekt unter MacOS.

L2TP ist im Lieferumfang von zwar MacOS enthalten, aber wegen der NAT Probleme und Apple’s Beschränkungen bei der Sicherheit ist das leider nicht mehr zuverlässig. Wir Admins raten zu SSTP, denn das „geht immer und überall“. Zumindest solange man nicht OpenVPN, CyberGhost oder andere fiese PPP-Adapter-Hackereien installiert hat. Die müssen, wie bei jedem VPN-Zugang, in aller Regel erst deinstalliert werden.

  1. Terminal öffnen
  2. https://brew.sh/ Installieren:
    • /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
  3. brew install sstp-client
  4. sudo touch /etc/ppp/options
  5. sudo /usr/local/sbin/sstpc --log-stderr --cert-warn --user <[email protected]> --password <PASSWD> <SERVER-FQDN> usepeerdns require-mschap-v2 noauth noipdefault defaultroute refuse-eap noccp

Das Split-Tunneling, also die eigene Defaultroute weiter für den Netzzugang nutzen, kann man indem man den Parameter defaultroute weglässt.

Und schon steht die Verbindung 🙂

Firefox/Chrome HSTS Cache „NET::ERR\_CERT\_AUTHORITY\_INVALID“ oder „MOZIlLA_PKIX_ERROR_SELF_SIGNET_CERT“

Veröffentlicht am von — Keine Kommentare ↓

Problem

Es kommt mal vor, das Zertifikate ablaufen. Tausch der Admins das Zertifikat dann auch, anstatt ein bestehendes zu verlängern, passiert es gerne das Edge/Chrome/Firefox die Verbindung verweigern.

Lösung

HSTS (HTTP Strict Transport Security) ist ein krasser Schutz für HTTPS-Verbindungen. Dabei wird dem Browser der HTTP Response Header „Strict-Transport-Security“ vom Server gesendet. Dies veranlasst den Browser zukünftig nur verschlüsselte Verbindungen zu dieser Domain aufzubauen. An sich eine nette Erfindung die „Fallback man in the middle“ Attacken verhindert.

Die meisten Browser speichern zusätzlich zu dem Flag für die Domain(s) auch noch den Thumprint der Certifikates. Ändert sich der Fingerabdruck, läuft man in diesen unumgänglichen Fehler.

Firefox

  1. Alle Tabs und Fenster schließen, bis auf eins
  2. Bibliothek > Chronik > gesammte Chronik anzeigen
  3. Nach der betroffenen Seitenadresse suchen
  4. Rechte MT und „Gesamte Webseite vergessen“ wählen
  5. Einen Moment warten, Firefoxy neu starten, geht.

Chrome

Chrome ist leider etwas umständlicher zu bedienen:

  1. Öffne chrome://net-internals/#hsts
  2. Unter „Query HSTS/PKP domain“ nach der Domain suchen. Achtung, das ist FQDN-Sensitiv. Wenn die Domain auftaucht …
  3. Ganz unten unter „Delete domain security policies“ den FQDN eintragen
  4. „Delete“ löscht die zugehörigen Einträge
  5. Chrome neu starten, fertig

Windows Server 2019 „Set-RDWorkspace“ Fehler „Ausnahme beim Aufrufen von ‚Put‘ mit 0 Argument(en):“

Veröffentlicht am von — Keine Kommentare ↓

Das CMDlet Set-RDWorkspace ist unter Windows Server 2019 (wie so vieles andere ebenfalls) kaputt. Man sollte eigentlich den Workspace-Namen so setzen können:

Set-RDWorkspace -Name "Welt der Wunder"

Aber der Befehl produziert nur einen Fehler:

Set-RDWorkspace : Fehler beim Aktualisieren des Arbeitsbereichs für den RD-Verbindungsbrokerserver
 "FQDN.MEINESSERVERS".
 Fehler: Ausnahme beim Aufrufen von "Put" mit 0 Argument(en):  ""
 In Zeile:1 Zeichen:1
 Set-RDWorkspace -Name "Welt der Wunder"
 ~~~~~~~~~ CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
 FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Set-RDWorkspace

Lösung

Den Workspace-Namen und die Beschreibung („Description“) setzt man am besten direkt in der Registry in dem Schlüssel HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralizedPublishing

Windows Registry Editor Version 5.00

 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralizedPublishing]
 "WorkspaceName"="Welt der Wunder"

Windows 10 Offlinedateien zurücksetzen (reset)

Veröffentlicht am von — 8 Kommentare ↓

Problem

Manchmal macht der (prinzipiell gutmeinende) Windows 10 Offline-Cache, namentlich „Offlinedateien“ oder auch „CSC“ für Client-Side Caching, absurde Sachen. Gerne lässt sich diese fiese kleine Mimose auch durch Serverumzüge verwirren und präsentiert unlösbare Konflike im Synccenter. Es „entstehen“ auch manchmal unlöschbare Ordner, neue Dokumente kommen auf Dateiservern nicht mehr (zuverlässig) an und generell ist das was der Explorer zeigt nicht mehr das selbe was der Explorer auf dem Fileserver auflistet.

Lösung

In den meisten Fällen hilft ein Zurücksetzen des Caches. Achtung, dabei wird sämtlicher zwischengespeicherter Inhalt entfernt, man sollte also von den betroffenen Daten eine Sicherung haben.

Möglichkeit 1: Cache neu erstellen lassen (liebevolle Variante)

Einen neuen DWORD-Wert (32bit) “ FormatDatabase“ mit dem Wert „1“ erstellen:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CSC\Parameters]
"FormatDatabase"=dword:00000001

Danach rebooten.

Die meisten Synchronisationsfehler sind damit schon behoben. Als hätten die Programmierer des CSC geahnt das dieses transparente Caching-Konzept … „anfällig“ sein könnte.

Möglichkeit 2: Cache komplett löschen (krasse Variante)

Der Offline-Cache wohnt in %windir%\CSC. Dieser Inhalt muss komplett entsorgt werden.

  1. Als ein anderer Benutzer anmelden (man kann seinen „eigenen“ Cache nicht wärend man aangemeldet ist löschen)
  2. Besitz von „C:\Windows\CSC“ als Benutzer (keine Gruppe!) übernehmen (mit Unterordnern und Dateien)
  3. Rechte in „C:\Windows\CSC“ für den Vollzugriff vererben
  4. Ordnerinhalt komplett löschen
  5. Registry-Eintrag (siehe oben) erstellen
  6. Rebooten
takeown /r /f C:\Windows\CSC
rd /s C:\Windows\CSC
reg add HKLM\SYSTEM\CurrentControlSet\Services\CSC\Parameters /v FormatDatabase /t REG_DWORD /d 1
shutdown -r -f -t 0

AADConnect Kennwort eines Benutzers neu in das Azure AD synchronisieren

Veröffentlicht am von — Keine Kommentare ↓

Problem

Nach der „Kennwort zurücksetzen“ Aktion der Administrators einer lokalen Domäne wird das neue Kennwort eines Benutzes nicht automatisch in das Azure AD (Office 365) synchronisiert.

Der Benutzer kann sich zwar in dem lokalen AD mit seinem neuen Kennwort anmelden, in Office 365 aber weiterhin nur mit dem alten.

Ändert ein Benutzer selbser sein Kennwort (STRG+ALT+ENTF), wird das neue Kennwort sofort (max 120 Sekunden) synchronisiert.

Lösung

Von manuellen Datenbank-Änderungen an der Client-API „vorbei“ bekommt AADConnect (ADsync) nichts mit. Da es (ohne weiteres) nicht möglich ist, Kennworthashes aus dem AzureAD für einen Vergleich zu exportieren, bleiben die Kennwörter bis zur nächsten Änderung unterschiedlich.

Das Kennwort kann aber einfach manuell (nachträglich) neu synchronisiert werden.

  • PowerShell auf der AADConnect Maschine öffnen („Als Administrator“, mit ExecutionPolicy auf mindestens „RemoteSigned“)
  • Distinguished Name (DN) des Benutzers besorgen:
    • Get-ADUser NAME | select D*
  • Assistenten zur Synchronisation des Kennworthashes des DNs starten:
    • Invoke-ADSyncDiagnostics
  • Dem Assistenten folgen (2 > 3 …)

Schon fertig 🙂