wznutzer

Guten Abend, wenn man Applocker verwendet, sollte man den Zugriff auf c:\ sperren, weil der Schutz sonst umgangen werden kann (Leerzeichen in Pfade). Die meisten hier werden das ohnehin wissen. Aber wie stelle ich das am besten an? Mit älteren OS-Versionen wurden Sicherheitsrichtlinien ausgeliefert, da war dann auch eine rootsec.inf dabei. Die konnte man importieren und per GPO verteilen. Oder halt manuell zusammenklicken oder auch als lokale Richtlinie. Das ist soweit klar. Passt diese alte Richtlinie, wie z. B. hier beschrieben: https://www.gruppenrichtlinien.de/artikel/rootsecinf-keine-ordner-auf-c-erstellen. noch auf einen W2K22? Ein W2K22 zeigt frisch nach der Installation folgendes: Ich würde jetzt die rot umrahmten Einträge entfernen, "Jeder" gibt es auf einem W2K22 nicht mehr standardmäßig auf c:\. Aber wird jetzt in der Richtlinie die Vererbung aktiviert oder nicht? Ich würde meinen ja, bin mir aber nicht sicher. Das Vererben würde ja nur neue Ordner auf c:\ treffen. Richtig? Natürlich nicht die Rechte aller Unterordner neu setzen, das ist klar. Aber das wäre per GPO, soweit ich weiß, nicht machbar. Diesen Fehler könnte man nur beim manuellen zusammenklicken machen. Grüße und einen schönen Abend

Darf ich fragen, welcher Key das ist? Gibt es da einen bestimmten Grund? Ich frage, weil ich auch bei Azure VMs mit CPUs außerhalb der 2er Potenzen mieten kann. Grüße und eine schöne Woche

Guten Abend, ein altes Thema. Lange galt die Faustregel man sollte das Pagefile auf das 1,5 fache des RAMs setzen. Man kann aber auch einfach Windows machen lassen. Mich würde interessieren wie Ihr das so macht? Einfach ein Erfahrungsaustausch. Ich meine wenn man einen Hyper-V Host mit 512GB RAM hat oder einen SQL-Server mit 128 GB RAM, macht man doch nicht das 1,5 fache, oder doch? Danke und einen schönen Abend

Ja, ich meinte den reinen KdcProxy der mit einem RDS-Gateway installiert wird. Von mache nicht über mache ich doch, wenn MS das extra dafür baut, bis jetzt wieder mache ich nicht, war so der Gedankengang. Gut, dass Du das auch so siehst. In dem verlinkten Artikel von Steve Syhfus schreibt er auch, dass man sich extern für Angriffe wie dem Kerberoasting aussetzt. Ich lasse das Loch zu. Zwar jetzt etwas OT, aber verwundert war ich, dass ich mit Domäne\Benutzername über den KdcProxy per Kerberos authentifiziert werde und per Name@Domäne üer NTLM. Das ist doch normalerweise andersrum. Ich habe das mehrfach probiert, ist einfach so. RDP zeitgt ja bei Kerberos oben das Schloss an. Danke und schönes Wochenende

Dagegen spricht nichts. Aber mir geht es darum, ob ich den Kerberos-Proxy ohne Nachteile öffnen kann. Da hilft mir ein Zertifikat ja nicht.

Ich will nichts spezielles wie SSO erreichen. Selbst das Zertifikat ist kein Problem. Die User klicken sowieso auf alles. Ich will einfach nur herausfinden was die sicherste Methode für die Veröffentlichung des Gateway ist. Nützlich wäre, wenn sich die User mittels der RDP-Anmeldung ein neues Passwort vergeben könnten. Das ist aber nur ein angenehmer Nebeneffekt. Ich bin davon abgerückt, dass die User die Passwörter oft ändern müssen. Meine erste Überlegung war zwar falsch, weil ja bei NTLM das Passwort auch nicht übertragen wird, aber es ist halt eine URL mehr die erreichbar ist. Mit der URL /KdcProxy ist das Loch größer und dafür muss es dann einen Grund geben.

Genau deswegen bin ich draufgekommen. Internet testweise abgedreht und dann mal in das Firewall-Log geschaut und gesehen was so ein W2K22 alles im Vergleich zu einem W2K12 R2 machen will. Zusammen mit der CPU-Last die ich dann noch gesehen hatte, habe ich nach der Ursache gesucht, das war dann die Telemetrie. Ich hätte das aber gerne komplett weg, auch auf den Systemen die in das Internet kommen müssen wie RDSHs. Wenn man die Telemetrie ausschaltet ist das Log wieder klein. Bei mir ist das halt GData mit deren Cloud-Erkennung. Ich weiß, kann man drüber streiten, ob das sinnvoll ist oder nicht .

Ergänzung: Wenn man sich bei einem RDS-Gateway mit domäne\Benutzername anmeldet, wird Kerberos verwendet, wenn ich den UPN verwende nicht. Unter der Voraussetzung, dass /KdcProxy erreichbar ist. Da bei Kerberos das Passwort nicht über die Leitung geht und der Kerberos Proxy von Microsoft explizit für das RDS-Gateway und Direct-Access gemacht ist, wird das wohl in Ordnung sein das freizugeben.

Nur ein wenig Erfahrungsaustausch und ob irgendein Nebeneffekt, den man nicht gerne haben will, bekannt ist. Ich werde das in Zukunft auf jeden Fall konsequent abdrehen, jedenfalls soweit es die Möglichkeiten zulassen.

Nachtrag: https://www.gruppenrichtlinien.de/artikel/windows-10-telemetrie-und-diagnosedaten-richtig-abschalten

Guten Abend, RDP lässt sich ja prima per RDS Gateway freigeben, wenn man eine passende Lizenz hat funktioniert das auch sehr gut mit der Azure MFA. Ich mache das z. B. mit einem Reverse-Proxy. Da hat man dann die Möglichkeit die URL /KdcProxy freizugeben oder auch nicht. Funktionieren tut beides. Mit Freigabe von /KdcProxy: Kerberos-Authentifizierung Keine Zertifikatsabfrage (RDP-Zertifikat) auch wenn der Client nicht Mitglied der Domäne ist. Passwortänderung geht von einem Client aus der nicht Mitglied der Domäne ist (STRG + ALT + ENTF) Ohne Freigabe von /KdcProxy: NTLM Zertifikatsabfrage des RDP-Zertifikats wenn das nicht zuvor irgendwie verteilt wurde. Passwortänderung nicht möglich, wenn der Client nicht Mitglied der Domäne ist. Ein paar Infos z. B. hier: https://syfuhs.net/kdc-proxy-for-remote-access Da das von Microsoft ja explizit für das RDS-Gateway vorgesehen ist, müsste das kein Problem sein. Aber ist es tatsächlich auch sicher? Ich meine, macht das Freigeben ein Loch auf, das ich ohne diese Freigabe nicht habe? Vielen Dank

Guten Morgen, teilweise verursacht die Telemetrie, auch auf einem Windows Server 2022, doch eine hohe CPU-Last. Auch wenn es nicht unbedingt schlimm ist, hätte ich das gerne weg. Telemetrie ausschalten 1) Taskplaner, Microsoft, Windows, Application Experience ==> Microsoft Compatibility Appraiser -> deaktivieren 2) sc config DiagTrack start= disabled In sconfig steht die Telemetrie dann noch immer auf "Erforderlich" aber auch da kann man das ausschalten. Ob das aber irgendwas zusätzlich bewirkt konnte ich nicht rausfinden. Fragen Sind Nebeneffekte bekannt wenn man das macht? Ich konnte bisher nichts feststellen. Macht Ihr das oder lasst Ihr das? Grüße und Danke

Für alle die hier auch noch am lernen sind, Veeam hat das in gewohnter Qualität beschrieben. https://www.veeam.com/blog/hyperv-set-management-using-powershell.html Lt. meinen Tests ist die Kommunikation der VMs untereinander schneller, wenn diese an so einem vSwitch hängen, als bei einzelnen vSwitchen, somit alles prima. Nach „außen“, also nicht die VMs am vSwitch untereinander“, bleibt einen Ticken langsamer als ohne Teaming 🤷‍♂️.

Es ist nie zu spät etwas nicht zu wissen .

Die meisten hier werden es ohnehin wissen, aber evtl. nicht alle die auf diesen Thread stoßen. Deswegen folgender Hinweis: Wenn bei einer RDP-Bereitstellung Zertifikate einer eigenen Zertifizierungsstelle verwendet werden muss auf die Einhaltung von RFC2818 geachtet werden. Das Zertifikat wird sonst "nur" noch vom Internet-Explorer akzeptiert (lt. meinen Tests jedenfalls). Fehler: ERR_CERT_COMMON_NAME_INVALID Die RFC fordert, dass die Identität nicht mehr durch den CN festgestellt wird, sondern durch einen oder mehrere DNS-Einträge im SAN. https://tools.ietf.org/html/rfc2818 Das HTML5-Control funktioniert mit einem so ausgestellten Zertifikat auch nicht. Grüße