mwiederkehr

Mir fällt da die Outlook-App ein. Die ist kostenlos, aber für den geschäftlichen Einsatz braucht man Microsoft 365. Sie darf nicht verwendet werden für den Zugriff auf Exchange-Server.

Das ist aus der Ferne schwierig zu sagen. Ich vermute, da bekommt man Zugriff auf einen virtuellen Server, welcher Mitglied einer Domäne vom Provider ist. Man hat nur lokale Adminrechte. So hätten sie die Lizenzierung im Griff. Bei den grösseren Angeboten ist noch 2X dabei, das ist eine Erweiterung der Terminaldienste (vergleichbar mit Citrix). Damit kann man über ein Gateway auf den Server zugreifen (und muss RDP nicht offen haben).

Cloud Server bei Hetzner geht schon, Du brauchst einfach mehrere Server: 1x Domänencontroller, 1x Terminalserver, 1x Firewall (zB. OPNsense). Die Server kannst Du dann in ein gemeinsames Netzwerk stecken und nur die Firewall von aussen zugänglich machen. Die Benutzer können sich dann per VPN einwählen. Aber: Hetzner bietet für die Cloud Server kein Windows an, sondern sagt lediglich, dass man es selbst installieren könne. Kauflizenzen auf geteilter Hardware sind lizenzrechtlich etwas schwierig... Besser wäre ein physischer Server, aber dann bist Du für die Virtualisierung zuständig und musst bei Ausfällen die Sicherung wieder einspielen etc. Von daher würde ich mir einen Anbieter suchen, der Terminalserver anbietet. Eine Suche nach "Terminalserver as a Service", "Desktop as a Service" oder "Cloud Arbeitsplatz" sollten genügend Resultate liefern.

Ja, ein AD brauchst Du für Benutzerlizenzen, aber das installierst Du besser nicht auf dem gleichen Server.

Du könntest die wuapilib.dll anzapfen. Hier Code von jemandem, der das gemacht hat: https://github.com/avogelba/GetUpdates Oder Du schaust in den Code von PSWindowsUpdate, die machen das über COM: https://github.com/joeypiccola/PSWindowsUpdate Die PowerShell lässt sich übrigens aus C# auch recht gut bedienen, das könnte auch ein Lösungsweg sein.

Server 2019 und Windows 10 sind sich zwar ähnlich, aber es lassen sich bei Server 2019 nicht alle (GUI-)Features von Windows 10 nachinstallieren. (Bei früheren Versionen war das die „Desktop Experience“, bei 2019 ist das die GUI.) Bevor ich Server 2019 zum Client-OS umrüste, würde ich prüfen, ob es wirklich VDI sein muss. In den meisten Fällen reicht ein „normaler“ RDS-Server aus. Und unbedingt abklären, ob die Software auf einem Server läuft. Technisch wird es kaum Probleme geben, aber bei der Lizenzierung unterscheiden viele Hersteller zwischen Server- und Client-OS. Während sich eine Software auf einem Client online aktivieren lässt, benötigt sie auf einem Server unter Umständen einen Lizenzserver, was zusätzliche Kosten verursachen kann.

Ja, das geht: https://docs.microsoft.com/en-us/azure/storage/files/storage-how-to-use-files-windows Das Gerät muss jedoch SMB 3.0 unterstützen. Da habe ich bei vielen Multifunktionsgeräten meine Zweifel.

Hast Du das Array und die logische Disk erweitert?

10 Cores und 32 GB RAM für 10 Benutzer tönt vernünftig. Wenn die Leute nur mit Office und einer schlanken Branchenanwendung arbeiten, rechne ich mit 0.5 Cores und 2 GB RAM pro Benutzer. Es ist aber leider so, dass Browser die letzten Jahre nicht sparen beim RAM, das sie sich genehmigen. Ein paar Tabs offen und man kommt auf über 1 GB pro Benutzer, nur für den Browser... Es kann deshalb nicht schaden, die Benutzer etwas zu sensibilisieren. Der Browser muss nicht gleich fünf Tabs mit allen Zeitungen aufmachen, die man dann doch nicht liest und auch Internetradio lässt man lieber lokal laufen. Das Surfen auf normalen geschäftlichen Seiten ist jedoch kein Problem.

Das sieht mir nach einem IPv6-Problem aus. Die Fritzbox bietet sich als DNS-Server an, was der Client gerne annimmt. Danach fragt er die Fritzbox statt den DC, welcher als DNS bei IPv4 eingetragen ist. Zeigt "ipconfig /all" IPv6-Adressen bei den DNS-Servern? Bei Windows 10 reicht "prefer IPv4 over IPv6" nicht mehr, man muss IPv6 deaktivieren. Würde es über die Registry machen und nicht einfach den Haken beim Protokoll rausnehmen bei der Netzwerkkarte: https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-ipv6-in-windows.

Das stimmt, aber den HTML5-Client gibt es noch nicht so lange. Warum RDG separat? Ich suche schon länger eine Lösung, um mehrere Server am gleichen Standort, aber in verschiedenen, getrennten Domänen bzw. Workgroups, anzubinden (Hoster). Das RDG ist ja auf eine Domäne limitiert. Für Adminzwecke läuft aktuell alles über einen "Jump-Host" mit RDG und 2FA und von dort aus dann intern weiter über RDP. Die Kunden selbst arbeiten per VPN. Es wäre schön, eine saubere Gateway-Lösung zu haben, ohne für jeden Kunden ein komplettes RD-Setup zu machen. Aktuell haben die kleinen Kunden nur einen Server (ohne Domäne).

Ja, aber es gab auch eine Lücke, die erst durch das Gateway ermöglicht wurde. Aber schon klar, habe ich verstanden. Oder mit den Ressourcen arbeiten, was ja quasi per Feed aktualisierte RDP-Dateien sind. Funktioniert auch ganz gut. Gutes Argument, das hatte ich so noch nicht bedacht, danke! Krass, das hätte ich so nicht vermutet. Noch eine letzte Frage: euch ist auch keine Firewall oder virtuelle Appliance bekannt, die ein RDP-Gateway integriert hat? Kemp macht nur TCP-Load-Balancing auf RD-Gateways, bei Citrix soll es gehen, aber nur in den teuren Versionen. Sonst habe ich nichts gefunden. Ausser Guacamole, aber das packt RDP dann gleich in HTML5. (Was für privat übrigens eine coole Lösung ist, falls ihr etwas Basteln wollt über die Feiertage.)

Danke für eure Antworten! Ja, es gab leider mehrere Lücken, wobei die soweit mir bekannt bei neueren Betriebssystemen nicht ausgenutzt werden konnten, wenn NLA aktiviert war. Deshalb hatte ich die Hoffnung, dass NLA die Komplexität des am Internet hängenden Codes soweit reduziert hat, dass er sicherheitstechnisch überschaubar ist. Der Webserver spricht ja auch mit dem Internet und wird nicht dauernd gehackt. Bei Farmen ist klar, dass alles über einen Gateway läuft. Der NetScaler kann die Anmeldungen direkt gegen das AD prüfen, noch bevor der potentielle Angreifer zu den Servern durchgelassen wird. Es ging mir mehr um kleine Umgebungen. Bei RDWeb mäkeln die Benutzer über fehlenden Komfort und VPN ist auch keine Freude, wenn die Leute von privaten Rechnern aus arbeiten sollen.

Hallo zusammen In der letzten Zeit hatte ich einige Diskussionen bezüglich "RDP über Internet" (für Terminalserver, nicht für Administrationszwecke). Die Bandbreite der Meinungen reicht von "geht gar nicht, nur über VPN oder man nimmt Citrix" bis "kein Problem bei neuen und aktuell gehaltenen Servern". Ich sehe folgende Risiken: 1. Passwort von Benutzer wird herausgefunden 2. Server wird durch Lücke in RDP "gehackt" 3. Kommunikation wird abgehört Punkt 1 ist sicher richtig, lässt sich aber durch starke Passwörter und allenfalls 2FA verhindern. Bezüglich Punkt 2 gab es in der Vergangenheit leider einige Vorfälle. Seit NLA kommt aber der komplexe und potentiell anfällige RDP-Code erst nach erfolgter Authentifizierung zum Einsatz. Punkt 3 sollte dank TLS kein Problem mehr sein. Wie seht ihr das? Ist RDP trotz aktiviertem NLA immer noch zu gefährlich, um es ins Internet geöffnet zu haben? Oder ist diese fixe Meinung überholt? Irgendwie wäre es eine Bankrotterklärung, wenn wichtige Dienste eines aktuellen Betriebssystems zu unsicher wären für den Zugriff über Internet. Selbst SMB macht man mitterlweile über Internet, siehe Azure. Vielen Dank für eure Meinungen!

Probiert da jemand Passwörter durch? Dann kann es vorkommen, dass man sich zeitweise nicht anmelden kann und die "interner Fehler"-Meldung erscheint.

Es gibt auch ein Tool für .NET, falls Dir das in eurer Umgebung lieber ist: https://unosquare.github.io/passcore/ Habe allerdings keine Erfahrung damit.

Dass bei MySQL der ganze Dienst abstürzt, hatte ich bisher nur bei korrupten Datenbanken. Was sagt denn die Logdatei? Die liegt im Data-Verzeichnis und heisst "%hostname%.err".

Schade. Es wurde ja schon länger eine Lösung versprochen und ich hatte die Hoffnung, etwas verpasst zu haben. Auf jeden Fall vielen Dank!

Doch, aber die lokalen Benutzer hätten keine Exchange-Attribute. Das Azure AD könnte also die Hoheit über diese Attribute haben, da es sie lokal im Schema gar nicht gibt. Deshalb dachte ich, es könnte evtl. anders gehen. Aber für ADSIEdit müsste das lokale Schema die Exchange-Attribute doch kennen? Also müsste ich im Minimum "/preparead" ausführen?

1.) Geschäftliche Sachen über den Browser auf dem TS, damit die Benutzer nicht immer zwischen lokal und TS umschalten müssen. Private Sachen wie Webradio, Stream von Tennismatch etc. lokal, um den TS zu schonen. 2.) Wenn Du keine richtige Farm willst, kannst Du evtl. pro Nutzerkreis einen TS erstellen. Wenn die Verwaltung eine Anwendung braucht, mit der sonst niemand arbeitet, kannst Du denen einen eigenen TS zur Verfügung stellen etc. Mehr als maximal drei solcher "Einzel-TS" würde ich aber nicht machen, dann lieber gleich eine richtige Umgebung.

Hallo zusammen Dass man einen lokalen Exchange zur Verwaltung braucht, wenn man bestehende Benutzer mittels Azure AD Connect synchronisiert, ist ja bekannt. Nirgends gefunden habe ich allerdings den Fall, dass man bei einer Neugründung auf der grünen Wiese anfängt und die Benutzer synchronisieren will. (Oder ich sehe den Wald vor lauter Bäumen bzw. Doku nicht mehr...) Also wie folgt: Firma mit ca. 100 Benutzern, welche (da das Unternehmen nur kleine Filialen und keinen Hauptsitz hat) auf einer gemieteten Terminalserver-Infrastruktur arbeiten werden. Es soll Office 365 eingesetzt werden und der Einfachheit halber sollen die Benutzerkonten aus der lokalen Domäne synchronisiert werden. Single Sign-On ist Pflicht, Password Writeback wäre schön, muss aber nicht sein. Braucht es da wirklich einen lokalen Exchange? Es wäre auch vorstellbar, die Benutzer in Azure AD getrennt anzulegen und einfach über ein gemeinsames Attribut zu "verknüpfen", so dass SSO geht. Welche der vielen Möglichkeiten würdet ihr empfehlen?

Ich habe nur einen ganz einfachen Tester, der nur auf Durchgängigkeit und Kurzschlüsse prüft (dieser ist es: https://www.conrad.de/de/p/kabeltester-laserliner-lan-check-netzwerk-1697325.html). Gebraucht habe ich den nur in den seltenen Fällen, in denen ich Dosen selbst montiert habe. Das war hauptsächlich privat. Den Durchsatz messe ich "praxisnah" mit iperf. Wenn es mal ein Problem gab, das der Durchgangstester nicht angezeigt hat, habe ich den Elektriker angrufen und der kam mit dem Fluke-Gerät. Kam aber noch nicht oft vor.

Ergänzend zu Jan: Mal mit einem anderen Browser getestet? Error 1006 wäre nämlich eigentlich ein clientseitiger Verbindungsabbruch.

Je länger der Key, desto länger dauert der Handshake für den Schlüsselaustausch. Der Unterschied zwischen 2048 und 4096 Bit ist messbar, aber nicht spürbar: https://expeditedsecurity.com/blog/measuring-ssl-rsa-keys/ Wenn Du nicht gerade den Load Balancer für google.com oder facebook.com betreibst, ist die Schlüssellänge bezüglich Performance nicht relevant.

Wenn Du im Browser die Developer Tools aufmachst, wie sieht der Fehler denn genau aus? wss ist WebSockets, irgendwo dort hat er ein Problem. Auf welchen Port versucht er zu verbinden? Ist der vom Client erreichbar?