cj_berlin

Naja, wenn Du im letzten Schritt des Wizards sagst "Save as SSIS package", dann kannst Du das Paket ja durch den SSIS zeitgesteuert ausführen...

Ein anderer Bereich, der mit Wahrscheinlichkeiten agiert, und zwar deutlich länger als es IT Security als Fach überhaupt gibt, ist das betriebliche Gesundheitsmanagement und die Berufsgenossenschaften. Von denen können wir durchaus auch etwas lernen. Frag mal die BG, was mit Deiner BU passiert, wenn Du auf einer Baustelle ohne Helm erwischt wirst, mit der Begründung, dass es sich ja nur um Tiefbau handelt und daher sehr unwahrscheinlich ist, dass von oben etwas herunterkommt. Wenn man den Usern einen Laptop schenken will, kann man das als Firma tun (Disclaimer; was es steuerrechtlich bedeutet, weiß ich nicht - vermutlich geldwerten Vorteil in voller Höhe). Die Konsequenz daraus ist aber, dass dieses Gerät niemals "Line Of Sight" zu den Backend-Systemen bekommen darf. Alle Unternehmensanwendungen müssen entweder webbasiert durch eine WAF geschützt oder auf Terminalservern durch einen entsprechenden Gateway geschützt bereitgestellt werden. Und dann gibst Du dem User einfach das Gerät inklusive lokaler Adminrechte, denn dann ist es Dir egal, was er damit anstellt. Du kannst das Gerät ja auch gern in Intune managen, um zu sehen, ob es überhaupt eingeschaltet wird. Aber es ist dann in der Klassifizierung kein "company owned device" mehr, oder zumindest darfst du im Conditional Access diese Geräte anders behandeln als ein Gerät "von der Straße".

Noch Lust, über Wahrscheinlichkeiten zu philosophieren?

Moin, im Sinne dieser Definition kann die private Instanz also auch Firmware-Malware usw. auf das Gerät bringen. Ob das "Wald und Wiesen" ist, wird dann davon abhängen, auf was für Wiesen der User sich privat tummelt.

Doch, die Meldung kenne ich. Und nein, "zu langes im Schrank herumliegen" ist schon bei Windows 7 kein Problem mehr gewesen. Das könnte wieder eine dieser "Maschine zu schnell anmeldebereit, aber Netzwerk noch nicht fertig verbunden" Geschichten sein. Ich würde vorsichtig die GPO-Einstellung "Beim Hochfahren und Anmelden auf Netzwerk warten" mal ausprobieren.

Moin, wie die Vorredner schon angedeutet haben: Einfach eine normale Mail-Enabled Security Group nach einer gewissen Vorschrift mit Mitgliedern bestücken. Alles, was ein Recipient Filter einer DDG abbilden kann, kannst Du auch mit PowerShell abbilden. Aber zwei Exchange-Empfänger für das gleiche haben ergibt in der Regel nicht so viel Sinn.

Hatten wir nicht neulich auch Windows 2000?

Moin, "abrufen" kann Exchange gar nichts, dafür ist das Produkt nicht gedacht. Für so etwas brauchst Du zusätzliche Software wie POPcon, P2S, POP2Exchange etc.

Moin, einen Kontakt mit der Weiterleitungsadresse in die Gruppe aufnehmen? Ansonsten nur per Transportregel.

Moin, die Kommunikation wird schon funktionieren, wenn Du den DC nicht auf dem besagten Server mit aufsetzt, sondern separat, denn alle lokalen Accounts und Berechtigungen bleiben ja trotz AD-Mitgliedschaft bestehen. Die User, die sich remote dort anmelden, müssen aber AD-User sein, denn nur für diese können Per-User-RDSCALs ausgecheckt werden.

Moin, Fazit des bisher Gesagten: Bau das mit Device RDSCALs auf - damit kommst Du um AD herum, bleibst auch EULA-konform bei Microsoft und billiger ist es auch noch, da Du eben 5x statt 20x brauchst.

Alles, was LGA1156 ist, endet bei 6.5U3. Neuere Versionen werden vermutlich auch nicht laufen. Und wenn der Installer bei dieser CPU sagt, dass sie zu alt ist, wird es bei jeder anderen CPU auf demselben Sockel genauso sein.

Definiere "VMware". Wenn Du ESXi 7 meinst, wird es vermutlich schwierig, bei 6.7 oder so würde ich mir da echte Chancen ausmalen. Da es aber für daheim ist, muss es doch nicht offiziell supported sein. Stick rein, booten, probieren - chances are, dass es darauf wunderbar laufen wird, wenn auch unsupported.

Hetzner hat hierfür übrigens eine Regelung getroffen: https://docs.hetzner.com/de/robot/dedicated-server/windows-server/windows-server-2016/ Warum eigene RDS CALs nicht eingesetzt werden können, wenn Du einen eigenen Server und ein eigenes AD hast, in das die ausgecheckten Lizenzen geschrieben werden, ist mir allerdings schleierhaft.

Moin, und Du musst doch Hetzner fragen. Meines Wissens kannst Du keine Kauflizenzen auf fremder Hardware betreiben (außer in Azure, und auch da gilt es nicht für jede Lizenz). Die Server-Lizenz mietest Du ja schließlich auch bei Hetzner.

Message Tracking Logs würden mir dabei einfallen...

Es ist bei zwei Stück natürlich schwierig, zwischen "einen" und "alle bis auf einen" zu unterscheiden. Beim 1000-Meter-Wettlauf zwischen Brezhnev und Reagan sagte das Radio Moskau danach "Brezhnev ist als Zweiter ins Ziel gekommen und Reagan als Vorletzter" Und bevor man mich hier der Fake News bezichtigt: Natürlich hat dieser Lauf nie stattgefunden. Da ich Dich schon etwas länger kenne, würdest Du es nicht "einfach herausfordern, weil...", sondern eine Lösung vorschlagen. Ohne jegliche Ironie: Ich bin ganz Ohr. Mir hat bisher nur ein Kunde eine vollständige forensische Untersuchung bezahlt, um festzustellen, wer alles DNS und LDAP gegen die scheidenden DCs macht. Das war aber eine große Kombi-Maßnahme, da auch LDAP auf LDAPS umgestellt werden sollte, da hat sich's im Endeffekt gelohnt. Im nächsten Lifecycle lautete die Vorgabe explizit "das darf aber auf keinen Fall so viel kosten und so lange dauern wie letztes Mal".

...aber bevor die AD-Intelligenz greift, muss wenigstens ein DNS-Server erreicht werden, der die Resource Records für AD und die NS Records hostet. Und wenn sie sich alle ändern, hilft auch keine Intelligenz.

Doch, ist es. Auf diese Weise behältst Du IP-Adressen und Namen der DCs, ohne fertig hochgestufte DCs nachträglich verändern zu müssen. 99% meiner Kunden wissen nicht mit absoluter Sicherheit, wo welche Maschinen für DNS und LDAP mit Namen oder sogar IP-Adressen eingetragen sind. Doch selbst wenn man es wüßte - will man jede doofe Appliance, jeden Drucker usw. usw. anfassen und IP-Adressen ändern? Man kann natürlich, wenn man nur zwei DCs hat, zuerst einen dritten installieren und ihn zum Schluss wieder entfernen. Aber bereits wenn man drei DCs hat, verzichtet man auch bei reiner Rotation zu keinem Zeitpunkt auf Redundanz. Aber auch bei zwei DCs dauert der Verlust der Redundanz bei ordentlicher Vorbereitung 18 Minuten, 15 davon braucht der KCC, um die Replication Links neu auszuwürfeln.

Genau so macht man das. Denk daran, ihn auch aus Sites & Services zu entfernen und so lange zu warten, bis der KCC alle Replikationsverbindungen von alleine entfernt hat.

In einem größeren AD - nicht so, sondern Get-ADUser -LDAPFilter "(altsecurityidentities=*)" -Properties altsecurityidentities | Select-Object samaccountname,altsecurityidentities

Moin, wie äußert sich "funktioniert gar nicht" technisch? Was passiert, wenn Du einen User dort anmeldest, der dort noch nie ein Profil hatte?

Ja, aber es ist nichts für schwache Nerven. Und ein 3rd Party-Patchmanagement, mit Ausnahme von Adobe, ist auch eher dürftig ausgeprägt.

Ich habe einfach das umgesetzt, was der Hersteller an Verwendungszweck des Accounts dokumentiert, und als dann beim Start des Dienstes "Zugriff verweigert" kam, noch die Schreibrechte für das Verzeichnis nachgetragen.

Falls es jemanden Interessiert: Wir haben STAS nun ohne DA ans Laufen bekommen: Logon As a Service auf DCs Builtin\Event Log Readers Full Access auf das Programmverzeichnis von STAS Lokaler Admin auf Workstations (als Abkürzung für Remote WMI) Viel fehlt hier effektiv nicht zum DA, aber das ganze lief im Rahmen eines AD-Audits, und jeder DA, dessen Kennwort nicht abläuft, bringt Strafpunkte