cj_berlin

Domain Controller. Fileserver, Datenbankserver und sowas sind nicht Tier 0. In der ursprünglichen Microsoft-Denke wäre das Tier 1, und Clients + Terminalserver sind Tier 2. Du kannst beschließen, nicht päpstlicher zu sein als der Papst und nur den Tier 0 vom Rest zu isolieren.

Wieso denn? Du musst ja nicht 20 Tier bauen, sondern - weil die Umgebung so klein ist - nur einen Eine Policy, die verbietet, dass Tier 0-Accounts sich an Nicht-Tier 0-Maschinen anmelden, ein zweites Admin-Account für jeden der beiden Admins plus das Kennwort für bestehende Accounts rollen, that's it.

Moin, die Idee ist gut, der Gedanke ist aber andersherum und nicht weit genug. Wenn Dein AD gekapert wird, sind Member-Server sowieso dahin. Das beginnt aber in den seltensten Fällen beim AD selbst, meistens ist ein Member-System das Einstiegstor. Das heißt, Deine oberste Prämisse ist es nicht, die Member vor AD zu schützen, but eher die Admins vor den Membern zu schützen. Sprich: Es ist nicht wirklich schlimm, ein AD-Account als lokalen Admin auf den Member-Systemen zu haben, Du willst aber verhindern, dass AD-Admins sich an Membern überhaupt anmelden, egal ob sie dort Adminrechte haben oder nicht. Manche kennen das Konzept als "Tiering".

Moin, im IIS herumfummeln ist bei Exchange fast nie die (nachhaltige) Lösung. Vermutlich wird dies beim Einspielen des nächsten CU wieder wegfliegen. Vielleicht ist es aber auch wirklich etwas, das durch das Windows- und damit IIS-Update versaubeutelt wurde. Markiere diesen Thread für den Abend, an dem Du das nächste CU einspielst

"nimm das Remote-Zert" --> Den Dienst "IIS" in den Eigenschaften des Zertifikats zuweisen. "In allen virtuellen Verzeichnissen blah..." --> Autodiscover URI siehst Du mit Get-ClientAccessServer

Da gibt es diesen "View Certificate..." Button, der Dir die Antwort liefern würde Aber tatsächlich "sucht" Autodiscover kein Zertifikat. Es kontaktiert den Webservice, und dieser präsentiert ein Zertifikat. Die kontaktierte URL siehst Du in der Fehlermeldung. Das Zertifikat hinter dem Button, s.o. Warum es nicht matcht, siehst Du dann.

Doch, wenn Du das interaktiv auf einem DC ausführst, muss das elevated ausgeführt werden.

Zeig doch mal den Code, der diese Ausgabe erzeugt.

Ich weiß nicht ob es das Problem ist, aber in Deinem allerersten Code-Snippet selektierst Du "sKriptPath" anstelle von "sCriptPath". Damit bleibt die Property "scriptPath" immer leer.

96 GB ist 6*16. Früher waren 6 DIMMs per Socket Gang und Gäbe, keine Ahnung wie exotisch das jetzt ist. Es geht ja dabei nicht um die Performance, sondern.um die Minimierung der Auswirkungen bei Ausfall einer Komponente. Und @Scotx: bei all der Virtualisierungsorgie das Backup nicht vergessen 😊

Wenn Du es ohne AD, nur mit Entra ID, lösen kannst, dann brauchst Du auch keine hybride Identität um ihrer selbst Willen.

...oder Du machst es mit der formatierten Ausgabe: $LinkName = 'BlaKeks' 'Es gab einen Fehler beim Anlegen des Links "{0}". Bitte manuell nacharbeiten.' -f $LinkName

Moin, ist die VM denn schon gelaufen und nach welchem Ereignis hat sich der jetzige Zustand eingestellt?

Hi, das sollte nach wie vor funktionieren: https://lizardsystems.com/terminal-services-manager/articles/how-to-grant-shadow-access-rights-for-users-without-grant-full-admins-rights-in-rds-servers/

Siehst Du, und für Windows-Menschen ist ein Service-Account einer, unter dem ein Dienst ausgeführt wird 😊 Drum frage ich ja.

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