cj_berlin

...aber denkt daran: Die beschriebenen Events werden nicht zum Spaß geloggt. Das sind die Applikationen, mit deren Authentifizierungsgewohnheiten ihr euch in den kommenden 6 Monaten beschäftigen müsst. ...und wenn wir schon dabei sind: https://support.microsoft.com/en-au/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1 hat auch einen Enforcement Mode, der im April 2022 aktiv wird. Allerdings kann man das Verhalten mit den neuen Flags im dsHeuristics-Attribut dauerhaft abschalten.

Dumm nur, dass in vielen Fällen, gerade bei Benamsung, "Frau Meyer möchte" als Anforderung gilt. Oder "der Betriebsrat hat beschlossen", was auf das gleiche hinausläuft.

Moin, kein Backup --> kein Mitleid wenn es SATA- oder SAS-Platten sind, sollten sie sich theoretisch alle wieder finden, die Signaturen und Konfigurationen sind ja auf den Platten selbst gespeichert. praktisch ist es besser, sie an die alten Anschlüsse zu stecken. Ein wenige Beschriftung sollte ja nicht das Problem sein. selbst wenn Storage Spaces da empfindlich reagieren sollte, Daten gehen ja erst mal nicht verloren, der Pool wird halt im Status "Platten fehlen" hochgefahren. Dann musst Du halt umstecken. Dein nächster Server sollte ein redundantes Netzteil haben und eine Kabelführung, welche das Tauschen des Netzteils ohne Abstecken von Platten ermöglicht.

Moin, Microsoft VDI ist ein sehr starres Produkt und kann euren Fall vermutlich nicht abbilden, weil es keine persistenten Desktops realisieren kann. Es ist genau für den Fall gedacht, den ihr nach Deinen Angaben nicht habt - einige wenige Images für relativ viele Sessions. Mit Microsoft-Bordmitteln seid ihr bei 1x Session Collection pro Benutzer, die jeweils eine einzige Maschine enthält. Gebt einfach jedem User eine statische VM mit einer fixen IP, dann habt ihr eure Client-Landschaft noch einmal virtuell nachgebildet, aber mehr scheint ja nicht gefordert zu sein. Der Connection Broker bringt euch dabei exakt Null, da er ja jedem User jeden Tag immer die gleiche VM zuweisen müsste. Warum ausgerechnet in eurer Firma ein Shared Desktop "nicht praktikabel" sein soll, gehört vermutlich in den Bereich des Anforderungsmanagements und nicht in den der technischen Umsetzbarkeit

Nein. Denn wenn ein Host stirbt, sterben alle Desktop-VMs darauf mit, und es sorgt der Connection Broker dafür, dass sie neu aus dem Image geklont werden, auf einem Host, der noch lebt. Anders ist es, wenn Du Terminalserver hast, die aus Sicht des Connection Brokers ja fix provisioniert sind. Unter solchen VMs möchte man in der Tat eine hochverfügbare Plattform haben - wenn man sie denn virtualisiert. Aber da steuert der Connection Broker auch nicht die Virtualisierung. Apropos: Denk daran, dass im Microsoft VDI-Szenario jeder User oder Client eine RDS CAL braucht, weil ja der Connection Broker (und evtl. RDWeb und RDG) im Spiel ist. Und ja, es ist so b***d wie es sich anhört: Microsoft VDI --> RDS CAL nötig XenDesktop oder View --> keine RDS CAL nötig. Will damit sagen: Wenn man auch das komplett fehlende Image Management in der Microsoft VDI mit ins Kalkül nimmt, ist es vermutlich auf lange Sicht billiger, ein Third Party VDI-Produkt einzusetzen, es sei denn, man hat die RDS CALs bereits. In diesem Fall sollte man aber die Möglichkeit von Terminalservern ausschöpfen, bevor man zu VDI greift, unabhängig vom Technologie-Anbieter.

Es ist Rußland, nicht Andorra - 20 Stück sind keine "größeren Mengen" Vermutlich ein Schreibbüro ausgestattet plus 3x Reserve,

Ein neu in die Bereitstellung hinzugefügter Host, ob RDSH oder RDVH, wird in der Regel immer durchgerissen. Dein Cluster ist danach aber keins mehr. VDI-Workloads und Backend-Workloads auf gleichen Hosts fahren, ist möglich, aber mit sehr viel mehr Planung verbunden. Na wenn er Hyper-V hinzufügt...

Das wollte ich damit zum Ausdruck bringen

Moin, DC = plattmachen, aus dem AD löschen, neu aufsetzen mit der gleichen IP und dem gleichen Namen, promoten, replizieren, fertig.

Moin, Family Safety bezieht sich nur auf Microsoft-Konten privater Art (ehem. LiveID). Konten aus dem lokalen AD sind in der Cloud nicht bekannt und können nicht über den Cloud-Dienst Family Safety verwaltet werden.

1. selbst Windows NT konnte schon 15 Zeichen 2. Und? Es kann zwei Michael_Mueller in eurer Umgebung geben, aber die werden trotzdem unterschiedliche sAMAccountName-Werte haben müssen. Das stimmt, nichts in der IT ist vollständig problemfrei. Aber das im Artikel beschriebene Problem lässt sich bereits dadurch drastisch reduzieren, dass man %APPDATA% nicht umleitet. In dem vom TO beschriebenen Szenario geht es ja nicht um Roaming, sondern dadurch, den Usern die Möglichkeit zu geben, ihre Dateien über eine einheitliche Vorrichtung auf einem Fileserver abzulegen.

Moin, für sowas gibt es mit Bordmitteln das Homedrive. Dafür kann Windows %USERNAME% abbilden und andere Dinge, für die es Umgebungsvariablen gibt. Vielleicht arbeitest Du mit dem, was out of the box vorhanden ist, und erfindest nicht das Rad neu. Besser, viel besser allerdings ist es, wenn Du es mit Laufwerkmappings sein lässt und beispielsweise mit Ordnerumleitungen arbeitest (auch da ist %USERNAME% Dein bester Freund). Dann hat der User das "Laufwerk" jederzeit im Explorer unter "Dokumente". Laufwerkmappings sind von vorvorgestern und bringen mehr Probleme mit sich als sie jemals zu lösen vermochten.

Moin, siehe Abschnitt "GSSAPI" unter https://linux.die.net/man/5/ldap.conf . Allerdings ist es in Bezug auf ein mögliches Abhören von Credentials nicht sicherer als was ihr jetzt macht, nur in Bezug auf Replay. Ihr solltet daher überlegen, ob nicht die Zeit gekommen ist, euren DCs Zertifikate zu verpassen und auf LDAPS zu wechseln. @NilsK wird gleich sagen, PKI ist böse, wenn man nicht weiß, was man tut, und er hat nicht unrecht. Andererseits, Credentials unverschlüsselt übertragen ist auch böse.

ich glaube, das meint er mit "PWS"

Genau. Also ist in Deiner Applikation irgendwo eingestellt, dass die Verschlüsselung zu verwenden ist. Ich meine, in der neusten Version der OLEDB-Komponenten ist sie es per Default. Also musst Du es im Connection String deaktivieren, sofern Du Zugriff darauf hat. Besser ist natürlich, wenn Du am Server ein Zertifikat einspielst, dem Deine Clients vertrauen, und Daten, wie Ende 2021 dringend geboten, verschlüsselt überträgst...

...aber wenn nachweislich kein Zertifikat am Server eingespielt, dürfte das scheitern.

Moin, das ist jetzt nicht auf Dein Problem bezogen, muss aber dennoch gesagt werden: Niemals *muss* sich ein Domain Admin an einer Workstation anmelden; es sei denn, es ist eine dedizierte und extrem gehärtete Privileged Access Workstation (PAW). Zu Deinem Problem aber: Ich würde vermuten, dass eher die Installation der Updates als die blosse Anmeldung als Admin das verursacht hat. Es sei denn, jemand hat die Profile so verbogen, dass jeder User auf dasselbe Profilverzeichnis zeigt. Dann hat der Admin mit seinen Rechten Besitz von der Registry und den DPAPI-Schlüsseln nehmen können, der User konnte den Besitz aber nicht wieder "zurückerobern".

...aber das Debug Logging des Windows Time Service ist eine Textdatei und wird immer sequenziell geschrieben Das solltest Du mal aktivieren, auf die höchste Stufe drehen und einen Tan lang mitlaufen lassen.

Moin, keine (mir bekannte) Lösung wird lokale Benutzer provisionieren. View und XenDesktop können beide SAML, aber die haben ja auch einen Agenten, der diese Authentifizierung empfängt. Und dennoch wird vorausgesetzt, dass es diesen User schon gibt und dass er sich da anmelden kann. Die von Dir angestrebte Lösung hat aber auch lizenzrechtliche Auswirkungen, die Du beleuchten solltest, bevor Du technisch weiter designst. Soll der Zugriff per User oder per Device lizenziert werden? Falls per Device, fallen jegliche Gateway-Lösungen vermutlich flach. Falls aber per User, wie sollen Lizenzen ausgestellt werden? Dafür muss der Server zwingend in einem AD sein, und die User aus diesem AD oder einem Forest, der diesem AD vertraut, kommen.

Achtung! Ein Ordered Dictionary ist keine Hashtable. Hier ein paar Unterschiede: OD hat keine der Methoden ContainsKey(), ContainsValue() und Clone(). Und obgleich OD keine Methode Clone() hat, ist das Zuweisungsverhalten so, dass man sie gelegentlich bräuchte. Dafür hat OD die Methoden Insert() und RemoveAt(), die für HT keinen Sinn ergeben.

Naja, zwei Spalten hast Du schon, die hat eine Hashtable immer Der Konstruktor einer Hashtable ist keine Zuweisung, daher kann man hier kein Array von Values zu einem Array von Keys gleicher Länge zuweisen. Siehe auch hier: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_hash_tables?view=powershell-7.2

Wenn das ganze wenigstens ein bisschen verschlüsselt sein soll, musst Du die Anmeldedaten so oder so in der Session des zugreifenden Users erfassen, dann kannst Du auch gleich den Windows Credential Manager nutzen und die Anmeldedaten einfach beim ersten Verbinden des Netzlaufwerks hinterlegen.

IGEL UMS: https://kb.igel.com/securitysafety/en/isn-2021-11-ums-log4j-vulnerability-54086712.html

...da sollte man sich im Nachhinein aber schon fragen, warum ein Tier 0-System etwas "nachladen" darf

Nein, weil ein Angreifer die Lücke ausnutzen könnte, indem er einem User scheinbar harmlosen Code unterschiebt, der ein anfälliges Gerät anspricht. Klar, weniger wahrscheinlich und ungleich komplexer als ein direkter Angriff aus dem Internet, aber "sicher"? Nein.