Jump to content

wznutzer

Members
  • Gesamte Inhalte

    510
  • Registriert seit

  • Letzter Besuch

Profile Fields

  • Member Title
    Newbie

Letzte Besucher des Profils

Der "Letzte Profil-Besucher"-Block ist deaktiviert und wird anderen Benutzern nicht angezeit.

Fortschritt von wznutzer

Experienced

Experienced (11/14)

  • Immens engagiert Rare
  • 15 Jahre dabei!
  • Positiver Einfluss Rare
  • Passioniert Rare
  • Erste Antwort

Neueste Abzeichen

37

Reputation in der Community

2

Beste Lösungen

  1. Das habe ich mal in einer VM installiert und ein Client angebunden. Hat funktioniert, aber ich habe keinen Einstieg gefunden die Logik der Konfiguration zu verstehen. Wenn ich da ein gutes Tutorial fände, würde ich mir das nochmals anschauen. Bei Graylog scheint mir das brauchbar: https://woshub.com/central-windows-event-logs-collector-graylog/ https://woshub.com/graylog-centralized-log-collection-analysis/
  2. Hallo und guten Tag, mit zunehmendem Wachstum hätte ich gerne ein anderes Monitoring. Das Windows Eventlog Forwarding ist ganz nett und man kann sich so natürlich auch hier und da mal eine Mail schicken lassen, aber schön und übersichtlich ist es nicht. Mich würde interessieren was Ihr da so verwendet. Derzeit überlege ich ob ich das Event Forwarding lasse und dann die zentralen Logs irgendwie besser auswerte, z. B. mit Graylog, habe das aber noch nicht probiert. Gespannt auf Eure Meinungen.
  3. Ich weiß nicht, ob das üblich ist, was ich da mache, aber die verwendeten Zugangsdaten sind speziell nur für diesen Server. Ich habe quasi ein Tier-Modell, das aber auch noch auf Funktionen aufgeteilt ist. Beispiel: Tier 0 userad.admin (Verwaltung Domäne) userex.admin (Verwaltung Exchange) Tier 1 userdb01.admin (Verwaltung Datenbankserver 01) userdb02.admin (Verwaltung Datenbankserver 02) usw... Ergänzung: Mir geht es tatsächlich nur darum, meine PAW nicht zu gefährden. Z. B. für eine Verbindung zu einem Server der gar nicht zu meinem lokalen Netzwerk gehört. Also im Prinzip will ich das verhindern was man "lateral movement" nennt.
  4. Hallo, ich weiß, es ist schon eine Weile her. Ich würde das Thema nochmals gerne aufgreifen, weil ich da irgendwie noch keine Klarheit im Kopf habe. Ich denke darüber nach, ob es in Ordnung ist von einer PAW aus direkt RDP-Verbindungen zu Servern herzustellen (ausgehend), die nicht zu 100% unter meiner Kontrolle sind. Betrachtet unter der Voraussetzung, dass keinerlei lokale Ressourcen in die Verbindung mitgenommen werden (auch keine Zwischenablage). Bisher habe ich da eine Wegwerf-VM in einem VLAN dazwischen, also PAW --> Wegwerf-VM --> Ziel. Das erscheint mir immer mehr übertrieben, weil ich die Kette ja beliebig lange bauen könnte, aber am Ende ja immer meine PAW steht. Über ein paar Meinungen würde ich mich freuen. Danke
  5. Das passt. Bei der Installation sind die Rechte nötig, dann nicht mehr. Wenn unbedingt nötig kann man die Rechte ja wieder vergeben. Dann noch die User in die Gruppe "Procted User". Vielleicht gibt es noch mehr, aber so ist das wieder ein Schritt hin zu einem kleineren Risiko.
  6. Die Ablaufverfolgung der Tabelle mit den User-Connections in der RDCms-DB war abgeschaltet. Vermutlich ein selbst verursachter Fehler, weil die DB mal repariert werden musste (Schattenkopie konnte nicht mehr erstellt werden). Der Zusammenhang war nur nicht gleich erkennbar.
  7. Hallo und guten Tag, mir ist aufgefallen, dass die Verbindungen zu der RDS-Farm nicht mehr im Servermanager angezeigt werden. Das ist wohl schon eine Weile so und ein Zusammenhang mit einer Änderung ist mir nicht bekannt. Im Eventlog gibt es folgenden Fehler, der damit zusammenhängen könnte: Alles in der Farm ist komplett funktionsfähig, nur sehe ich halt die Verbindungen nicht. Ich kann mich zu der genutzten WID (Windows Internal Database) verbinden. Sonst gibt es nichts auffälliges in den Logs. Der Fehler erscheint, sobald ein Sessionhost einer Sammlung zugeordnet wird. dbcc checkdb auf der DB RDCms sagt keine Fehler Danke und Grüße
  8. Ich weiß nicht, ob der Restricted Admin Mode passend ist. Ich habe z. B. eine PAW. Die Rechner auf die ich mich verbinde folgen einem Tier-Modell, d. h. je nach Sicherheitsstufe und Funktion gibt es unterschiedliche User zur Verwaltung. Mit dem Restricted Admin Mode würde ich nun meinem regulären User mit dem ich mich auf der PAW anmelde überall Adminrechte geben, weil das auf SSO basiert. Ist das wirklich gut? Den Verwaltungsuser für die RDS-Bereitstellung in die Gruppe Protected Users zu schieben macht scheinbar keine Probleme. b***d, dass das bisher an mir durch ist. Ist das Standard für RDS Bereitstellungen?
  9. Denkfehler meinerseits. Die User sind tatsächlich auch bei mir über AD-Gruppen. Dann mache ich da tatsächlich kaum etwas an der Konfig.
  10. Danke, der Inhalt vom Link scheint genau das Richtige zu sein. Schaue ich mir genauer an. Vielen Dank
  11. Habe ich noch nicht darüber nachgedacht. Im laufenden Betrieb tatsächlich nur die Sammlungen (User hinzufügen, entfernen) und das so 2 - 3 x im Monat. D. h. Deine Überlegung wäre in die Richtung, dass ich evtl. zwei OUs habe, in einer werden die User als Admins hinzugefügt und in einer anderen entfernt und ich verschiebe die VMs dann je nach Bedarf hin und her?
  12. Hallo und guten Morgen, ich bin mir unsicher, wie ich folgendes Szenario beurteilen soll: Es gibt eine RDS-Bereitstellung mit Broker, Gateway und Session-Hosts. Auf dem Server mit dem Broker wird die Bereitstellung verwaltet. D. h. da sind im Servermanager alle Server der Bereitstellung hinzugefügt. Das Gateway ist in einem separaten Netzwerksegment. Ein Session-Host ist ebenfalls in einem separaten VLAN, weil dieser von den Nutzern her einem besonderen Kompromittierungsrisiko ausgesetzt ist. Das alles funktioniert, die Firewall-Regeln sind entsprechend gesetzt. Um die Bereitstellung zu verwalten gibt es einen User, der auf allen beteiligten Servern Adminrechte haben muss. Und genau da bin ich mir nun nicht sicher, ob das ein Risiko ist, weil es so einen Benutzer gibt, der über die VLANs hinweg Adminrechte hat und die Anmeldung auch über die VLANs hinweg genutzt wird. Damit eine solche Bereitstellung funktioniert müssen folgende Freigaben konfiguriert werden: WinRM: Broker -> Gateway, Session-Hosts RPC: Broker -> Gateway, Session-Hosts RPC: Session-Hosts -> Broker RDP: Gateway -> Session-Hosts, Broker Port 5504: Gateway -> Broker (WebAccess) Also, sollte das Gateway kompromittiert werden und die Zugangsdaten herausgefunden werden, kann man sich vom Gateway aus per RDP mit dem Broker und allen Session-Hosts verbinden und die meisten Session-Hosts stehen im allgemeinen LAN und sind nicht separiert. Habe ich einen Denkfehler oder gibt es da eine Art "best practices"? Ergänzung Lt. früheren Tests, kann man das Passwort im Klartext mit Mimikatz auslesen, wenn man sich interaktiv (per RDP) an einem Server anmeldet. Erfolgt die Anmeldung per WinRM sollte (Theorie) nur das Ticket/Hash ausgelesen werden können. D. h. ich müsste dann nur dafür sorgen, dass der Verwaltungsuser zwar Adminrechte überall hat, aber mich mit diesem niemals per RDP anmelden? Liege ich da falsch? Vielen Dank
  13. Falls es für irgendjemand von Interesse ist. Es gibt eine neue Version vom RDCman.exe. Das scheint die Skalierung mit 4K Monitoren besser zu sein.
  14. Meinst Du tatsächlich deaktivieren oder priorisieren? Ich habe mir angewöhnt zu priorisieren. https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-ipv6-in-windows
  15. Das ist mein subjektiver Eindruck, der sich aus dem Lesen von vielen Kommentaren/Posts über die Zeit ergeben hat. Hier eher nicht, aber in anderen Foren. Ja
×
×
  • Neu erstellen...