cj_berlin

vor 6 Minuten schrieb daabm:

 

Asche auf mein Haupt - ich bin Ü50, bitte hilf mir über die Straße

 

Das gilt nur für Domain Controller - der PDC ist der einzige DC, der PW-Policies verarbeitet. Für alle "normalen" Member in der Domäne gilt das ganz normale Vererbungsprinzip bis hoch zur Domäne. Keine Ahnung, welchen mentalen Aussetzer ich da hatte 

Ich hatte mich schon gewundert - es gibt sicher Dinge, die ich über AD noch nicht weiß, aber dass mir solche Basics über all die Jahre entgangen wären, das hat mir schon Angst gemacht. Aber wenn Martin das sagt, dachte ich mir...

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

vor 18 Minuten schrieb Dutch_OnE:

Das Cluster Objekt hat auf den beiden Knoten sogar Vollzugriff.

Das muss aber genau andersherum sein???

Gerade eben schrieb TimS:

Dann kommt ein Student, steckt einen USB-Stick mit portablem Webbrowser rein und umgeht den Proxy.

Nein, wird er nicht, denn Du wirst diesen Maschinen gar keine Route ins Internet mitgeben, sondern nur bis zum Proxy.

vor 1 Minute schrieb TimS:

Ich werde wirklich für diese Anwendung ein paar extra PCs aufstellen und gut ist.

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 

vor 4 Minuten schrieb peterg:

Bei uns am Exchange ist ein "internes Relay" zum Versenden von Meldungen von Druckern, etc. eingerichtet. Das ist aber kein Postfach. Verstehe ich was falsch?

Ja. Ich schrieb:

Zitat

 eine Accepted Domain vom Typ "internal Relay"

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

vor 13 Minuten schrieb Quirk18231:

 

gibt es eine Möglichkeit GPOs zu kontrollieren - Fehler zu finden??

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

vor 16 Minuten schrieb peterg:

Bei dem "internal" Relay kann ich ja nur senden.

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.

vor 3 Minuten schrieb Weingeist:

Aber angeblich darf die RDS-CAL nur zusammen mit einem qualifizierten OS genutzt werden.

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:

vor einer Stunde schrieb SPLA:

Falsch,

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.

vor 1 Stunde schrieb dSteph:

Ich wollte die ganze Zeit die XML als solches auswerten, aber auf String-Ebene funktioniert natürlich auch.

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.

vor 7 Minuten schrieb edv-it:

 

Aktuell wird der Default-Benutzer am Computer als "Vorlage" geladen. 

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. 

vor einer Stunde schrieb Ebenezer:

 

Ergänzung: insofern die Ports 5985 und 5986 (remote PowerShell) nicht nach außen offen sind, kann das wohl wenn überhaupt nur von intern ausgenutzt werden ... somit ist der Angriffsvektor deutlich eingeschränkt

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