cj_berlin

Ha! Diese Auslegung hatte ich noch nicht gehört, und sie würde ja total einleuchten, wenn man Microsoft vernünftiges Handeln unterstellt. ABER. Nach demselben Prinzip könnten auch Device CALs nicht getrackt werden, denn ein Computer kann 7 OS-Instanzen installiert haben, die nichts voneinander wissen

...wobei return als LETZTE Anweisung innerhalb einer Funktion vollkommen optional ist, sprich, $rueckgabeWert ist äquivalent zu return $rueckgabeWert Erst wenn return dazu verwendet wird, in einem bestimmten Zweig aus der Funktion auszusteigen, entfaltet es eine wirkliche Wirkung. In Klassen sieht es wieder anders aus Dies nur als "unnützes Wissen zum Freitag".

Ich weiß nicht, was ein "Funktionsaccount" in Deiner Welt ist Vielleicht. Aber genau das suchst Du doch, oder?

Moin, im User-Account kannst Du nur die Workstations hinterlegen, von denen aus es sich anmelden darf, und Zeiten. Wenn das DokuWiki (ich nehme an, auf Linux) damit klar kommt, ist das Problem schon gelöst. Für alles andere gibt es Policies ("loklae Anmeldung verweigern", "Anmeldung über remotedesktopdienste verweigern" usw.) womit Du den Member-Maschinen mitteilen kannst, dass dieses Acount sich NICHT dort interaktiv anmelden darf.

Das würde aber dazu führen, dass alle SMTP-Anfragen an den Server gehen würden, zu dem sich der FQDN der Domäne auflöst. Normalerweise nicht schlimm, muss man aber im Hinterkopf haben, falls doch.

Ich habe in meinen aktiven Labs nur zwei 2019er, beides Domain Controller, beide in EN-US. BEide haben zwar lange gerödelt, waren dann aber fertig. Aber natürlich VMs (ESX + Hyper-V), das ist nicht repräsentativ.

Nur hat @daabm die technologische Basis für diese Ansicht Das ist der Unterschied sowohl zum BSI als auch zu 100% der Kunden von @Nobbyaushb.

Ich glaube, der Konsens im Thread ist, dass das verwendete Attribut nicht durch "äußere Umstände" befüllt wurde, sondern gezielt zweckentfremdet wird, um die benötigte Info zu speichern...

Moin, Service, Einzahl Nur mal als Schuss ins Blaue: hat der Einzel-Server exakt den gleichen Build wie die DAG-Member? auf welchem Server wohnt das Postfach von dem Account, mit welchem Du die ECP-Webseite aufrufst?

Das ist erst mal funktional, und da stimme ich @NorbertFe zu. Allerdings, wie immer, wenn man Kryptographie einschaltet, die vorher ausgeschaltet war, wird es zu einem etwas höheren CPU-Verbrauch führen als vorher

Hier zum Beispiel ein Snippet, das das Mail-Attribut eruiert, in der Annahme, dass es nur eine Domäne im Forest gibt: $ds = New-Object System.DirectoryServices.DirectorySearcher $ds.Filter = "(&(objectClass=user)(sAMAccountName=$($env:USERNAME)))" $null = $ds.PropertiesToLoad.Add("mail") $user = $ds.FindOne() $user.Properties["mail"][0]

Dafür benutzt man System.DirectoryServices, das ist in PowerShell unter Windows immer verfügbar.

Für diejenigen, die dort arbeiten, ist 1x doch durchaus eine praxisrelevante Zahl Aber klar, natürlich gibt es nur sehr wenige. Daher finde ich die Diskussion um jahrelang nicht gerollte Passwörter immer so spannend...

Moin, Users von Shared Mailboxes sind normalerweise deaktiviert Alle anderen: Least Privilege plus entweder Group Policy oder Authentication Policy.

Also habt ihr NTLM schon abgeschaltet, so dass Pass-the-Hash nicht mehr ohne weiteres funktioniert?

Das hat in meiner Erfahrung mit "Event Log Readers" zu 100% funktioniert. Firewall?

Geht es um den Zugriff per PowerShell? Da gibt es zusätzliche Problemfelder.

Und so sieht diese Roadmap grafisch aus:

Moin, Tip #1: Die Verwendung von RODC noch einmal überlegen. Ist es *wirklich* ein Standort mit schlechter physischer Sicherheit, wo der DC physikalisch entwendet werden könnte? Falls nicht, ist RODC dort falsch. Tip #2: DNS auf einem Member-Server installieren, wenn es schon nicht in AD integriert sein soll. Oder halt sogar auf einem Workgroup-Server.

Redest Du von diesem Thread oder von dem Zustand der Welt?

imap.something ist mit Sicherheit kein Posteingangsserver, auch wenn es in Outlook so heißt Da müsste der Server hin, auf den der MX zeigte, bevor Du ihn auf Exchange umgestellt hast.

VPN outbound zu einer IPv4-Adresse: Kann ich nicht bestätigen. Ich habe einen 1&1-Anschluss mit einer DSLite-IPv4 und bisher keine Probleme gehabt. Meine Kunden und Arbeitgeber hatten sowohl SSL-VPN als auch IKEv2, beides ging.

Kommt darauf an, was für Dich die "eigentliche" Replikation ist. Das hat mit der AD-Replikation vielleicht nichts zu tun, dafür aber mit der DFS-Replikation, denn die SYSVOL-Inhalte kommen nicht "mit der Macht" auf die anderen Domain Controller. Mit welchem DC Dein GP Editor verbunden ist, kannst Du direkt im Editor sehen:

Möglich ist es schon, schön ist anders. Meinst Du nicht, dass Du 60 Postfächer auch übers Wochenende umgestellt bekommst? Um das ursprünglich Gewünschte umzusetzen, muss die Empfangsdomäne auf nicht authoritativ gesetzt werden und ein Sendeconnector für diese Domain angelegt werden, der auf Strato zeigt.

Moin, kannst Du bitte den Link am Ende des letzten Posts entfernen? Checkt mit den Herstellern euerer SQL-Anwendungen, ob sie eine Azure SQL-Datenbank supporten würden. Kommt vermutlich billiger als einen dedizierten Server anzumieten, und es ist zumindest ein bisschen mehr Security vorgeschaltet als bei einem nackten SQL-Listener. Checkt mit den Herstellern, ob ein "Offline-Replikat" mit SQL Express o.Ä. möglich ist. Das wäre vermutlich die beste Lösung, aber vermutlich werden nicht alle drei Anwendungen das können. Ansonsten, wenn es so gar nicht anders geht: TLS am SQL-Listener erzwingen wäre ein guter erster Schritt, um die Credentials und die Daten wenigstens vor dem Abhören in Transit zu schützen. Idealerweise findet ihr eine Firewall, wo ein Mitarbeiter seine IP "on demand" freischalten kann (ich gehe jetzt davon aus, dass wenigstens einige der Quell-IPs dynamisch sind). Einen Port irgendwo im oberen Bereich für den Listener verwenden, um zumindest die "dummen" Angriffe auf Port 1433 nicht abwehren zu müssen. Lange Passwörter. Sehr lange Passwörter. Auch hier könnte die Anwendung euch einen Strich durch die Rechnung machen. Eigentlich bin ich bei @testperson - VDI, welcher Art auch immer, ist immer a. sicherer und b. robuster als Remote-Zugriff auf SQL. Und CAD über WAN haben wir mit Citrix HDX 3D Pro schon vor 13 Jahren gemacht. Und auch das kann man inzwischen mieten und muss nicht eine eigene Farm für 11 Leute bauen.