cj_berlin

Wenn Du das "Administrator"-Kennwort weißt, müsstest Du dich damit dennoch anmelden können. Wenn Du das DSRM-Kennwort weißt, in DSRM booten und mit NET GROUP oder so die Admins as den Protected Users entfernen. Anschließend in den normalen Modus booten und das KLennwort rollen.

Moin, Deine beste Chance ist der Administrator "Administrator", also der mit der RID 500, denn diesen kann man effektiv nicht aussperren. Das mit Protected Users wäre dann plausibel, wenn sich das Kennwort des Users, den Du nutzt, schon lange nicht geändert hat - so lange, dass keine AES-Hashes dafür gespeichert wurden, Im Regelfall würde es bedeuten, dass dieser User auf Server 2000-2008 angelegt wurde und immer noch das Kennwort von damals hat. Deine zweitbeste Chance ist das DSRM-Kennwort, das Du hoffentlich doklumentiert hast. Deine drittbeste Chance ist Dien PingCastle-Report - eventuell sind da noch mehr Anfälligkeiten drin, die noch nicht gefixt wurden Deine viertbeste Chance ist, dass die Boot-Festplatte des Servers nicht verschlüsselt ist, Dann kannst Du den DC mit allen möglichen Mitteln, beispielsweise mit Utilman, hacken. P.S. Aber der Einwand von @testperson ist nicht von der Hand zu weisen - wenn Du RDP versuchst und NLA erzwungen ist, brauchst Du den FQDN, wenn der User in der Protected Users-Gruppe drin ist.

"die es im Idealfall nicht gibt" ist das Stichwort. Ein Securty-Konzept, das von dem Idealfall ausgeht, ist nicht sehr nachhaltig Hafnium und Log4j lassen grüßen.

Wenn Pass-the-Hash in der Umgebung möglich ist, vielleicht lieber nicht darüber nachdenken. Diese Guidance, der sich inzwischen auch NIST angeschlossen hat, scheint nur eine Welt zu kennen, wo ein potentieller Angreifer vor einer Maske sitzt und da Passwörter im Klartext eingibt... Da würde ich sogar mitgehen

Moin, "geht nicht" ist keine Fehlermeldung von Windows. Welche bekommst Du denn?

...und, natürlich, wer schon vor Jahren das Feature ausgerollt hat, dessen Name mir nicht einfällt (wenn nicht bereits im Request ein passendes Client-Zertifikat enthalten ist, gar nicht antworten), kann sich jetzt entspannt auf die Schulter klopfen

Moin, wenn die Idee ist, die Umgebung nach dem Kauf weiter zu benutzen, würde ich allerdings - das habe ich jetzt nicht gesagt - eher mit nicht aktivierten Prod-Installationen arbeiten statt mit Eval, denn Eval musst Du nach dem Kauf explizit konvertieren, und das gelingt zwar immer öfter, aber halt nicht immer

Hallo zusammen, mir ist neulich durch Zufall aufgefallen, dass mein Server 2025 Hyper-V Host (die Hardware ist von ca. 2019, 2x XEON E5) bei allen VMs die CPU-Auslastung mit konstant 0% anzeigt. Mein anderer Server 2025 Hyper-V Host (relativ frischer i7-Prozessor) zeigt Werte, die in etwa den Erwartungen entsprechen. Heute meinen privaten Rechner (i7-Notebook von 2019) auf 24H2 upgedatet, selbes Bild - egal, wieviel die VMs zu tun haben, auf dem Host ist die CPU-Last bei 0%. Hyper-V PowerShell-cmdlets zeigen das gleiche Verhalten. Kann das jemand bestätigen? Stimmt mein Eindruck, dass das Phänomen sich bei älteren CPUs zeigt? Oder habt ihr andere Erfahrungen? Danke und einen schönen Sonntag allen!

Server 2025 könnte SMB über QUIC auf verschiedenen Ports per Share... Muss der Client aber auch erst mal können. Ansonsten kannst Du dir vielleicht Dynamic Access Control anschauen, das ist aber ein Rabbit Hole, wenn man damit anfängt.

Das ist wo man sich dann hinfassen darf, wenn das ganze nicht performt.

Naja, ein "NAS" ist ja nicht zwingend eine kleine Syno. Ich habe sehr gute Erfahrungen mit Hyper-V und SQL auf SMB3-Freigaben, sowohl von Windows als auch von einer "enterprise grade third party" bereitgestellt.

Ja, so würde es gehen, aber ich würd's trotzdem nicht machen In Ruhe ein Cluster bilden und Failover testen können ist Gold wert.

Moin, um den zweiten Teil der Frage zu beantworten: Downtime musst Du schon einplanen. Besonders wenn - und das ist meistens zu bevorzugen - der Shared Storage tatsächlich als Block und nicht als File betrieben wird. Denn dann werden die LUNs als Cluster Shared Volumes betrieben, und die gibt es erst, wenn das Cluster gebildet wurde. SMB-Storage von einem Feld- und Wiesen-NAS würde ich persönlich nicht riskieren wollen, funktioniert aber, wenn das NAS einen SMB3-Dialekt spricht.

Moin, erstens, bei all seinen Verdiensten für die PowerShell-Community, ist nicht alles, was Adam Bertram sich überlegt hat, als "best practice" zu bezeichnen. Zweitens, es gibt sehr viele Entwickler, die zu PowerShell nicht von CMD/VBS/bash, sondern von C++/C#/etc. gekommen sind, wo starke Typdefinitionen vorgeschrieben sind. Diese Leute versuchen, das Bekannte auch in PowerShell durchzusetzen, meistens mit mäßigem Erfolg, weil PowerShell sich strikt weigert, ein "strongly typed language" zu werden. WENN Deine Funktion immer denselben Typ zurückgibt, kann es IntelliSense verbessern, wie Du auch bemerkt hast, wenn Du diesen auch in der Definition der Funktion angibst. Wer funktionale Programmierung lange und in großem Stil betrieben hat, wird vermutlich zustimmen, dass es an sich eine sehr gute Idee ist, wenn jede Funktion immer den gleichen Ergebnistyp zurückgibt. Das schreibt auch Uncle Bob irgendwo in "Clean Code", wenn ich mich recht erinnere. Nur ist es in Skriptsprachen in der Regel eher hinderlich, solche Restriktionen aufzuerlegen. Aber wenn Dein Skript- oder Moduldesign das hergibt, gibt es Dir ein zusätzliches Quentchen Sicherheit, wenn Du weißt, was Du von welcher Funktion zurück bekommst.

Wenn Du Windows Server-Workloads fährst, musst Du diese Lizenzen betrachten. Sollte es sich um so viele VMs handeln, dass Datacenter-Lizenzen bereits wirtschaftlicher sind als eine Anhäufung von Standard, kostet Dich das Windows-Cluster selbst mit S2D an Software nichts (zusätzlich). Wenn das oben aufgeführte NAS als Shared Storage für das Proxmox-Cluster fungieren soll, hast Du zwar Hochverfügbarkeit im Compute geschaffen, aber nicht im Storage. Das kannst Du mit einem Windows-Cluster auch genau so abbilden, selbst mit Standard-Lizenzen (die Du für die VMs eh brauchst). Kostet also an Software wieder nichts (zusätzlich).

Moin, auf dem DC listen diese Widgets, und auch NET USER, und auch Get-LocalUser, die Domain User auf. Das bedeutet nicht, dass sie auf dem DC ein Userprofil haben oder sich dort anmelden dürften. Insofern hast Du security-technisch vermutlich kein Problem, oder zumindest ist es nicht dadurch ersichtlich, dass diese User auf der Liste auftauchen. Mach GPRESULT /H auf dem DC und such nach der Einstellung "Diese Systemsteuerungssymbole einblenden" oder so ähnlich. Findest Du sie, dann wird daneben stehen, aus welcher Policy sie kommt.

OK, das sind zwei Fragen. 1. sind die User wirklich lokal oder sind das Domain-User? Falls es Domain-User sind, hast Du kein Problem. 2. warum ist das Control Panel-Widget aufrufbar? Da ist scheinbar wirklich eine Policy, die für DCs nicht gedacht war, auf diese angewendet worden. GPRESULT liefert Dir den Namen der Policy. Falls die User *wirklich* nicht Domain User sind, müsste man das troubleshooten.

Moin, da musst Du mal zeigen, wie das bei Dir aussieht, denn... wenn ein DC als DC ohne Einschränkungen funktioniert, ist die lokale SAM-Datenbank in der Tat nicht geladen

Moin, vielleicht übersehe ich etwas, aber wenn Höchstleistung eingestellt ist, wie kommt der Server dann in den Ruhezustand?

Nö, das geht in Richtung OSI-Modell und auf welcher Schicht eine Verbindung besteht.

OK, von WLAN hast Du nichts erwähnt. Bei einem Switch mit drahtgebundenem Ethernet wäre der Router egal, denn da spielen IP-Adressen keine Rolle. Mit WLAN könnte es aber im Bridged Mode eigentlich auch funktionieren.

Kannst ihnen ja IP-Adressen geben, die nicht um Subnet Deines Routers liegen

Innerhalb eines Forests ist UPN ein frei beschreibbares Feld (nur nicht mit ADUC/ADAC). Nur wenn Suffix Routing ein Thema wird, muss es in die Konfig. Natürlich packen wir es immer in die Konfig, wenn möglich, aber Kerberos innerhalb des Forests funktioniert auch ohne.

Moin, ketzerische Frage: braucht ihr die UPN-Suffixe der Kunden wirklich in der Forest-Konfiguration? So lange keine Cross-Forest-Authentifizierung im Spiel ist, kannst Du den userPrincipalName frei setzen, und innerhalb des eigenen Forests wird die Authentifizierung damit auch funktionieren.

Du meinst, Putzfrau stöpselt Server aus und Staubsauger ein?