cj_berlin

Audit hochdrehen und auf den DCs genug Platz für die dann deutlich größeren Eventlogs vorsehen.

Das muss aber genau andersherum sein???

Nein, wird er nicht, denn Du wirst diesen Maschinen gar keine Route ins Internet mitgeben, sondern nur bis zum Proxy. Da Du immer noch nicht verraten hast, was denn einen "nicht internet-Berechtigten" daran hindern wird, sich an einen internetfähigen PC zu setzen, müssen wir das wohl als Lösung hinnehmen Und dann kommt ein Student mit einem USB-WLAN-Adapter...

Dann kannst Du doch einfach die LAN-Stecker rausziehen Gleicher Effekt, und geht schneller. Dann würde ich sagen (wenn ich euer Konstrukt richtig verstehe, natürlich): Proxy mit Authentifizierung, unterbinden, dass die Authentifizierung gespeichert werden kann, und der Proxy authentifiziert sich gegen RADIUS.

Moin, Deine Variable ist ein Array. Um nach Elementen zu suchen, die einen bestimmten Text beinhalten, brauchst Du also Where-Object mit -like oder -match. Und -contains macht was ganz anderes, musst Du nachlesen.

Googlen? Dich belesen? Damit Du weißt, was Du eigentlich (technisch) fragst, und die Antworten interpretieren kannst?

Ich find's auch immer furchtbar, wenn eine einfache Google-Suche wie https://www.google.de/search?q=gruppenrichtlinien+logging keinerlei Ergebnisse liefert

Ja. Ich schrieb: Das ist was völlig anderes als euer Connector, der Mails von Druckern akzeptiert.

Klar. GPRESULT, Logs, Debug Logs usw. usw.

Huch? Accepted Domains haben mit dem Senden wenig zu tun.

Moin, Du kannst auch in O365 eine Accepted Domain vom Typ "internal Relay" anlegen. Partner-Connector anlegen und fertig. MX muss auf O365 zeigen.

Beim RecipientContainer muss die OU stehen, wo die Mitglieder drunter sind.

Das steht aber nirgends Hier nicht: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-client-access-license Und wenn man in den Product Terms nach VDA sucht, kommen ausschließlich Dokumente für Desktop-OS raus:

Nicht falsch. In einem Netzwerk, das ausschließlich aus zwei Windows 10-Maschinen besteht, benötigt man für den Zugriff von Maschine A auf Maschine B keine CALs. Es gibt auch gar keine "Windows Client CALs". Das CAL-Erfordernis kommt beim Zugriff auf ein Client-OS nicht aus diesem Zugriff, sondern aus der vorhandenen Infrastruktur, und hätte vermutlich bereits in dem Moment bestanden, wo der Thin Client bootet und von einem Windows-DHCP seine IP-Konfiguration erhält.

Moin, VDA ist doch nur der Tatsache geschuldet, dass es keine valide Lizenzierung für virtualisierte Desktop-OS "per se" gibt. Das Server-OS hingegen musst Du zwingend via Blech lizenzieren, und dann ist es lizenziert, braucht also nichts zusätzlich. Zugriff auf den Server --> CAL, Zugriff auf den Server per Remoting (RDP, ICA, Blast, you name it) --> RDSCAL. Und das ist völlig unabhängig davon, ob der Server virtuell, physisch, imaginär ist oder sonst wie ist. Und auch unabhängig davon, was auf dem Client läuft. Beim Zugriff auf ein Client-OS brauchst Du schon mal keine CALs, denn CALs sind ein Server-"Feature". RDSCALs brauchst Du nur, wenn Du irgendeine RDS-Serverrolle für den Zugriff verwendest - Connection Broker, RD Gateway, RDWeb oder was weiß ich. Und wenn der zugreifende Client ein nicht qualifiziertes OS fährt, brauchst Du noch die VDA, um das angesprochene OS zu lizenzieren. Das ist auch von der Art des Zugriffs unabhängig - selbst wenn Du die VMRC dafür nutzt, brauchst Du die VDA. Bei Microsoft waren die Antworten schon immer davon abhängig, mit wem Du sprichst, vielleicht hast Du "früher" einfach mehr Glück gehabt.

Moin, Server-OS braucht kein VDA, nur RDS-CAL.

Dafür, wie ich bereits schrub, brauchst Du die Data Definitions.

Moin, stimmt denn der Recipient Container? Filter ist ja nur die halbe Miete

Moin, Desk Sharing in O365 --> Workspaces: https://learn.microsoft.com/en-us/exchange/troubleshoot/outlook-issues/create-book-workspace-outlook Ansonsten hilft nur Demos anfordern und testen - für Hunderttausende Organisationen ist Outlook für diese Aufgaben übersichtlich genug, daher ist es in einem Forum schwer zu beurteilen, was denn bei euch in dieser Hinsicht besonders ist.

...oder so (innerhalb der Schleife): if($l -imatch '^\s*\<cfg:node.*mNumber=\"(?<mNumber>\d+)\".*\>\s*$'){ $mNumber = $Matches['mNumber'] break } break hilft mit der Ausführungszeit, wenn es wirklich gesichert ist, dass der Pattern nur einmal vorkommt bzw. dass das erste Vorkommen ausreicht. Jede präzise Verarbeitung dieser XML erfordert die Data Definitions, die Du nicht mitgeliefert hast.

Du hast Deine Frage bereits selbst beantwortet. Kopiere den Kram, den Du in der Vorlage brauchst, in den .DEFAULT auf jeder Workstation (kannst per GPO tun, wenn es dann wieder geht, oder per Software-Verteilung), und fertig ist.

Das kommt darauf, an, was Du unter "auf die Adresse zugreifen" verstehst.

OK, es sind ZWEI Vulnerabilities in einem Blog-Beitrag Die zweite könnte tatsächlich den normalen PowerShell-Endpoint nutzen - hier liegen im Moment noch keine Details vor. Andererseits sollte das WinRM-basierte Remoting ja erst recht nur für andere Exchange-Server oder Management-Workstations erreichbar sein, hier ist der Angriffsvektor in wohlgemanagten Systemen tatsächlich eher beschränkt.

Das ist ein Trugschluss. Remote PowerShell zu *Exchange* geht über einen Web-Endpoint, somit 443 oder sogar 80.

...und das Konto danach möglichst nicht mehr zu benutzen, außer im Notfall. ...und genau deswegen sollte man es auch lassen. Im Troubleshooting-Fall behindert es den dazugerufenen Externen mehr als im Angriffsfall den Angreifer.