Archiv der Kategorie: Remote Web Access

We lost remotewebaccess.com again …

Veröffentlicht am von
7

Seit dem letztem Samstag (12.11.2022) häufen sich die Berichte, dass ein Zugriff auf https://<hostname>.remotewebaccess.com nicht mehr möglich ist.

Update 19.11.2022.
Seit dem 19.11. ist der Service wieder funktional. Damit hatten wir eine Woche Ausfall, wie man sowas bewerten muss bleibt jedem selber überlassen. Die Konfiguration eines DynDns-Service mit eigenem Zertifikat würde das Problem lösen, bis der SBE außer Dienst geht.

Das Problem hatten wir schon einmal und zwar im Mai in diesem Jahr, damals wurde es nach knapp 14 Tagen !!! behoben.

image

Im Vergleich zur Situation im Mai, habe ich zum Glück nicht mehr den hohen Druck das Problem analysieren zu müssen. Inzwischen sind nur noch zwei meiner vielen (ehemals 11) Windows SBE Server aktiv und einer davon läuft mit eigenem Zertifikat und Domain, beim anderen ist der Zugriff über remotewebaccess.com zwar konfiguriert, wird aber nicht genutzt.

Ich schau trotzdem ob ich hier nochmals hilfreiche Informationen zusammentragen kann. Für Erkenntnisse aus dem Feld bin ich jederzeit dankbar, schreibt es einfach unten in die Kommentare rein.

Enjoy it, b!

(enjoy = auch wenn einem manchmal nicht danach ist)

We lost remotewebaccess.com …

Veröffentlicht am von
13

Update 14.05.2022:
Seit dem letzten Samstag (14.05.2022) ist remotewebaccess.com wieder funktional. Wer während des „Offline“ sein RWA auf dem SBE nicht kaputt konfiguriert hat, sollte wieder eine korrekte Aktualisierung der Domain sehen und Zugriff darauf haben.

Eigentlicher Blog
Seit dem 01. Mai 2022 funktioniert remotewebaccess.com nicht mehr zuverlässig. Alle die nicht wissen, was https://<hostname>.remotewebaccess.com ist oder war, brauchen hier nicht weiterzulesen.

Der Windows Server SBE (Small Business Essentials) bietet ein Feature mit dem der Zugriff auf den Arbeitsplatz innerhalb der Firma über eine Webseite, wie z.B. https://sbsland.remotewebaccess.com/remote möglich ist. Damit das Mapping von aktueller IP-Adresse des Internet-Zugangs und remotewebaccess.com funktioniert, steckt dahinter ein DynDns-Mechanismus, der über ein Zertifikat abgesichert ist, was wiederum den Zugriff mit HTTPS und damit ohne Fehlermeldungen im Browser ermöglicht.

Das Problem wird durch die folgenden Meldungen protokolliert:

image

Windows Logs / Application and Services Logs / Microsoft / Windows / ServerEssentials / Admin

image

Da zumindest auf meinen SBE-Servern alle Zertifikate in Ordnung sind, vermute ich das der Server selbst ein Problem hat den Dienst der hinter remotewebaccess.com steht zu erreichen.

Betroffen sind von dem Problem alle, die diesen Dienst nutzen. Die Auswirkungen sind aber nur im Fall einer Änderung der IP-Adresse spürbar. Kunden mit einer festen IP vom Provider sehen dieses Problem nicht. Es sei denn, sie bekommen einen neuen Internet-Tarif und in diesem Zusammenhang auch eine neue feste IP. Dann versucht der SBE die neue IP zu aktualisieren, was ebenfalls fehlschlägt.

Ich gehe mal davon aus, dass die meisten Nutzer des SBE diesen noch auf Basis des Windows Server 2012 R2 betreiben, was zumindest bei mir die Mehrheit ist. Wenig sind noch mit dem Windows Server 2016 unterwegs. Beide Produkte sind inzwischen aus dem Mainstreamsupport draußen und besitzen nur noch den erweiterten Support. Darum sollten wir uns auch über einen Call bei Microsoft bzw. dem OEM keine Hoffnung machen, sondern müssen über Alternativen nachdenken. Was der Aufbau von VPN-Zugängen sein kann.

Bisher habe ich meine VPN-Zugänge ausschließlich mit Lancom oder dem Synology VPN-Server realisiert und muss sagen, dass beides sehr gut und zuverlässig funktioniert.

Wie sehen den bei Euch die Alternativen aus?

Enjoy it, b!

Windows SBE remotewebaccess.com Update schlägt fehlt

Veröffentlicht am von
40

Mit dem Beginn dieser Woche (KW11/2021) waren einige meiner auf Windows Server 2012R2 basierenden Small Business Essential Server nicht mehr in der Lage ihre für den Anywhere-Access notwendige Sub-Domain unter remotewebaccess.com zu aktualisieren. Genau genommen betrifft das Problem alle SBE, aber manche haben eine statische IP-Adresse und was sich nicht ändert, muss man auch nicht aktualisieren. Die Problem-Kandidaten waren also Kunden (Telekom- und 1&1 ) die täglich eine neue dynamische IPv4-Adresse vom Provider bekommen.
image

Damit klappte natürlich auch der Zugang auf https://sbe.remotewebaccess.com/remote nicht mehr. Da hinter dem Zugang über remotewebaccess.com ein Zertifikat steckt, hat auch ein Zugang über “nur” die IP nicht gut funktioniert.

Das Fehlerbild war dubios, bis ich die Idee hatte das möglicher Weise der auf dem SBE laufende Update Client ein Problem mit der Verschlüsselung haben könnte. Stichwort TLS 1.0, TLS 1.1 Deaktivierung durch Microsoft.

Wenn man einen Blick auf die Release Documentation for Windows Server Essentials wirft, findet man zum eine Aktualisierung von 10.03.2021 …

image

… und dazu den folgenden Absatz.

image

Auch der Windows Server Essentials soll TLS 1.2 nutzen, Nach diesem Absatz dachte ich, OK – das ist es nicht, der Windows Server 2012R2 und neuer verwenden automatisch TLS.

image

Diese Aussage trifft zwar auf den Windows Server selbst zu, aber für das .Net Framework war dennoch ein wenig Nacharbeit notwendig und damit war ich auch auf die Lösung des Problems gestoßen.

Für beide auf dem Server installierten .Net Versionen (v2.0.50727 und v4.0.30319) mussten die folgenden Einträge in die Registry zusätzlich eingetragen werden.

# 64-bit OS
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001
# 32-bit Applications running on 64-bit OS
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001

Mit PowerShell geht das sehr einfach die Befehle müssen als Administrator in PowerShell (elevated Session) ausgeführt werden.

# PowerShell
New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727" -Name "SystemDefaultTlsVersions" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727" -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SystemDefaultTlsVersions" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWORD -Force

New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" -Name "SystemDefaultTlsVersions" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SystemDefaultTlsVersions" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWORD -Force

Danach noch den Server neu starten (Restart-Computer).

Update 20.03.2021
Für den Windows Server 2012 (OHNE R2) sind neben den oben beschriebenen Einträgen noch die folgenden Keys in der Registry zu setzen

# PowerShell
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" -Name "DefaultSecureProtocols" -Value '0xAA0' -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" -Name "DefaultSecureProtocols" -Value '0xAA0' -PropertyType DWORD -Force

Microsoft bietet hier auch ein eigene Lösung an um den Fix zu installieren. Dazu gibt es weitere Infos hier.

Update 22.03.2021
Das Problem tritt natürlich auch auf dem Windows Server 2016 SBE auf, und kann mit den gleichen Einträgen in der Registry wie für Windows Server 2012R2 behoben werden.

image

Die Abbildung oben zeigt den Fehler des Update-Mechanismus auch im Windows Eventlog unter Microsoft-Windows-ServerEssentials/Admin.

Enjoy it, b!

SBE, Erneuerung des Zertifikats für den Remotewebaccess

Veröffentlicht am von
Antwort

Der Windows Small Business Server ab 2011 und neuer ermöglicht den Zugriff von extern, also aus dem Internet durch eine Remote Access Webseite. Dieser wurde im Verlauf der Konfiguration des SBE ein Zertifikat auf Basis von sha1 ausgestellt, welches inzwischen (da sha1 als nicht mehr sicher gilt) von den meisten Webbrowsern mit einem Zertifikatfehler angemahnt wird.

image

Ein Klick auf den Zertifikatsfehler im Webbrowser liefert hier auch die entsprechenden Details.

Unbenannt-2

Um für die Anwender einen sicheren und vor allem vertrauenswürdigen Zugang zu ermöglichen, muss also das Zertifikat auf Basis von sha1 gegen ein neues Zertifikat ausgetauscht werden, was problemlos über den Set Up Your Domain Wizard im SBE erfolgen kann.

Die folgenden Schritte basieren auf dem Wizard welcher im Windows Small Business Server 2011 Essentials durchlaufen werden müssen.

Start des Windows Small Business Server 2011 Dashboard und Auswahl von Server Settings / Remote Web Access / Domain name / Set up

image

Nun erscheint der Set Up Your Domain Wizard (Assistant) und mit Next geht es weiter zum Dialog um den Domain name (Domänen Name) zu ändern. Hier ist es wichtig die Option Use another domain name or domain name service provider aus zu wählen und dann auf Next zu klicken. Im nun folgenden Dialog wird wieder der alte Name der Domain eingetragen, z.B. sbsland.remotewebaccess.com und mit Next bestätigt

image

Danach müssen erneut die Daten des Windows Live Accounts (Microsoft Account / Microsoft Konto) eingegeben …

image

und mit Next bestätigt werden. Danach startet der Prozess um durch eine Verbindung zu den Windows Live Services ein neues Zertifikat mit sha2 zu erstellen, damit sind wir wieder im wahrsten Sinne im grünen Bereich …

Unbenannt-7

… und haben auch ein neues Zertifikat mit sha2 als Hashalgorithmus.

Unbenannt-8

So, dass war’s!

Anmerkung

Unter Windows Server 2012 Essential, findet sich der Wizard ebenfalls im Dashboard unter Anywhere Access / Click to configure Anywhere Access / Domain name / … danach startet der Wizard mit den gleichen, wie oben beschriebenen Dialogen.

Enjoy it, b!