cj_berlin

Moin, der Sinn eines Support-Forums im Internet ist es NICHT NUR, dass viele Helfer sich Dein Problem angucken, SONDERN AUCH, dass viele Mitleser von der Lösung und von der Findung des Lösungsweges profitieren.

Moin, und da wir innerhalb weniger Wochen diese Anfrage zweimal hier sehen, die Frage an @goat82 und @Angua: Was ist der Use Case? Ich kann mich nicht erinnern, innerhalb der letzten 20 Jahre auf \\domain.fqdn ohne Folder oder Namespace dahinter zugegriffen zu haben, und ich mach ja schon ab und zu mit AD rum... Es wäre also spannend zu wissen, welche Situation euch oder eure User dazu veranlasst Danke im vorab!

Es ist nicht so, dass single label-names automatisch zum NTLM-Fallback führen, denn SPNs können durchaus Hostnamen beinhalten und seit Server 2016 sogar IPs (außer bei Domain Controllern). Schau Dir das Attribut servicePrincipalName bei einem DC an, da findest Du einiges. In der Umgebung, wo ich gerade herumspiele, fällt der Client sowohl für \\DOMAIN als auch für \\domain.fqdn auf NTLM zurück. Es gibt einen Trick (keine Empfehlung!), der funktioniert aber nur, wenn Du weißt, auf welchem DC Du mit dieser Anfrage landen wirst (also entweder gibt es nur einen, oder es gibt in der Site, wo diese Funktionalität benötigt wird, nur einen ). In diesem Fall kannst Du den Domänennamen zu dem Attribut 'msDS-AdditionalDnsHostName' des betroffenen DC hinzufügen. Das wird dazu führen, dass er den SPN 'HOST/domain.fqdn' für sich einträgt. Wie bei Highlander, kann es auch hier nur einen geben... Es ist sicherlich ein Bug, denn per Spezifikation muss auch der SPN 'HOST/DCNAME/domain.fqdn' angefragt werden, und das passiert auch, wenn Du auf einen Namespace zugreifst.

Und die RDS-Lizenzserver-Rolle, in die Du dann diese CALs einspielen kannst Und es wäre super, wenn der Hersteller der Branchensoftware vorher bestätigt, dass sie a. generell unter Terminalserver lauffähig und supported ist b. unter der Windows-Version, die Du vorhast einzusetzen, lauffähig und supported ist Wenn der Router das kann. Kann er das nicht, musst Du dich mit dem Remote Desktop-Gateway vertraut machen. Ich habe das im IT-Administrator-Sonderheft für Server 2022 ausführlich beschrieben, aber man findet auch Anleitungen im Internet. Machst Du das über VPN, musst Du ganz genau schauen, welches Protokoll es nutzt. Ist es ein SSL-VPN und nutzt daher TCP, solltest Du für RDP den UDP-Zugriff deaktivieren (obwohl er gerade in WAN-Szenarien eigentlich wünschenswert wäre). Und der letzte Punkt: Haben sie Active Directory am Start und werden diese User aus diesem Active Directory kommen? Falls ja, kannst Du mit User CALs arbeiten. Falls nein, brauchst Du zwingend Device CALs, und zwar ACHTUNG! so viele, wie verschiedene GERÄTE auf die Umgebung zugreifen werden. Wenn sie kein AD haben, tu bitte eins NICHT: AD auf demselben Server installieren und praktisch alle per RDP auf einem Domain Controller über VPN oder RDG arbeiten lassen...

Den NTLM Traffic musst Du zum Domain Controller nicht aktivieren, weil auf die Dienste, die er anbietet, nicht zugegriffen wird Was das andere angeht, muss ich noch kurz, aber scharf nachdenken.

Moin, in den meisten Fällen ist es OK. Der Verweis auf den Performance Impact stammt aus der Zeit, wo ein typischer Domain Controller physisch war und 512 MB RAM hatte und man die ganzen Network Offload-Features in Windows abschalten musste, weil der 3Com-Treiber damit nicht klarkam. Was ich allerdings bereits in der "Neuzeit" gesehen habe, waren RPC-aware Firewalls, die sich verschluckt haben, wenn zu viele nicht miteinander verwandte Sessions auf demselben Port beobachtet werden mussten. Ich werde jetzt keine Namen nennen, aber es war ein namhafter Hersteller, der normalerweise das RPC-Business eigentlich ganz gut beherrscht. Vermutlich mal wieder mit 'nem Long Integer für einen Index gegeizt und nur 65534 Sessions per Port vorgesehen, oder sowas in der Art. Es kann also knallen, aber vermutlich nicht an den Stellen, wo man es erwartet. Aber: Was versuchst Du mit der Maßnahme zu erreichen? Um welche Protokolle geht es Dir hier, die DCs untereinander praktizieren sollen, nicht jedoch von anderen Maschinen aus? Denn die Einschränkung von RPC und SMB auf einzelne Ports hat ja aus Security-Sicht den Nachteil, dass der Angreifer immer weiß, auf welchem Port 'ne Session zu suchen ist, ohne mit dem Endpoint Mapper sprechen zu müssen

Das muss eine Fehlkonfig sein. Ich habe hier eine Umgebung, wo - NTLM Auth ohne Ausnahmen blockiert ist - NTLM traffic auf der CA ohne Ausnahmen blockiert ist - der User, der auf der Workstation angemeldet ist, in der Protected Users drin ist und er kann per certmgr.msc aus allen Vorlagen, auf die er Enroll hat, Zertifikate beantragen und erhalten.

Moin, niemand hat das Ende von NTLM angekündigt, nur höchstens den Anfang vom Ende. Was meinst Du mit "Zertifikat-Ausstellung"? Die komische Webseite oder das "normale" DCOM Enrollment-Interface?

Daran ist nichts unerwartet, so funktioniert das Sicherheitssystem in Windows, auch beispielsweise bei NTFS, seit es das gibt. Tatsächlich gibt es noch eine weitere Feinheit, denn das gleiche Recht kann auch von mehreren darüberliegenden Ebenen vererbt worden sein, und dann gilt das Obige für jede Ebene

Genau. Und Deine Kunden brauchen ganz bestimmt kein S/MIME. S/MIME ist des Teufels.

Moin, ad 1. List Object Mode setzt man über dsHeuristics, nicht über die Registry. Wenn man die Sicherheit in seinem AD ernst nimmt, ja, sollte man machen, und man muss auch den Stand erreichen, dass Auth Users aus der PreWin2K raus können. ad 2. Nein, Berechtigungen "muss" man über die Automatisierung setzen. Hat man keine, ist es für DACL egal, für SACL ist LDP.EXE das einzige GUI-Tool, dass das Audit-Recht "Write SACL" offenbart und damit auch setzen lässt. Tatsächlich finde ich persönlich aber die ACL-Anzeige in LDP.EXE besser geeignet als in den MMC-basierten Tools, Hat man kein Bock auf LDP.EXE und keine Automatisierung, empfehle ich stets, ADSIEdit zu nutzen und nicht ADUC, denn auch zwischen den beiden gibt es feine Unterschiede. Shameless Plug: Ich behandle diese Themen in meinem Buch ad 3. Privilegierte Objekte sollte ein nicht privilegierter User/Computer nicht sehen können. Bei nicht-privilegierten ist es aus Elevation-Sicht tolerierbar, aber je nachdem, was das Ziel des potentiellen Angreifers ist, können z.B. Anwendungsgruppen durchaus wertvoll sein...

Moin, solange der Forest keine Vertrauensstellungen unterhält, kannst Du es machen. Wenn Cross-Forest-Operationen nötig sind, muss das Suffix-Routing funktionieren, und da wird es knallen.

Moin, legt die iCloud-App einem Eintrag unter "Datendateien" (Datei --> Konten) an? Dann kannst Du versuchen, diesen Speicher als Standard zu setzen, das wäre dann Dein Standard -Kender.

https://binarynature.blogspot.com/2013/01/reset-active-directory-administrator-password.html ab "Directory Services Repair Mode (DSRM)"

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.