cj_berlin

Moin, ist "http://" ohne S da oben in der URL ernst gemeint, also aus einem tatsächlichen Browser rauskopiert? Dann ist es genau das, wonach ich suchen würde

Moin, bleibt die ganze Maschine, also ALLE Sessions, stehen, oder nur einzelne Sitzungen, während andere normal weiter laufen?

Moin, ich gehe jetzt nicht davon aus, dass "die Nutzer" das PowerShell-Modul für AD verwenden oder irgendeine andere Applikation, die explizit auf ADWS zugreift. Wenn diese Annahme zutreffend ist, dann ist es Dein AD (NTDS), das aufhört zu funktionieren, denn ADWS kannst Du normalerweise abschalten und keiner merkt's. Somit ist die zitierte Fehlermeldung zwar zutreffend, aber der Fehler liegt in einem anderen System

Moin, danke für die Rückmeldung. Unter \\domain.fqdn sieht man ja, außer SYSVOL und NETLOGON, nicht Freigaben, sondern erst mal Namespaces. Habt ihr tatsächlich um die Hundert Namespaces, und unterscheiden sie sich auch wirklich voneinander (Namespace Server und Version)? Wieviele Ordner hat denn jedes Namespace? Vielleicht wäre ein Zusammenfassen von 100 Namespaces zu deutlich weniger, vielleicht sogar nur einem, eine Option? Dann könnte man auf \\domain.fqdn\ingloriousfolders gehen und den vollständigen Überblick (minus NETLOGON und SYSVOL, aber die kennt man ja) bekommen?

OK, aber funktioniert ADWS nach dem Neustart bis der Fehler kommt? Vielleicht ist das Problem ja nicht in ADWS, sondern in NTDS zu suchen...

u.a. weil andernfalls sich auch die Koexistenz mit Exchange 2019 schwierig gestalten würde

Moin, schau mal ob der Fehler nach einem Neustart von ADWS wieder kommt, ansonsten: https://techcommunity.microsoft.com/blog/askds/active-directory-web-services-event-1202/1514401

Moin, da Desktop Experience mit Server 2016 abgeschafft wurde, ist es sehr unwahrscheinlich, dass jemand damit einschlägige Erfahrungen unter 2019 oder 2025 gemacht hat. In 2025 sind zumindest Teile der ursprünglichen Desktop Experience wie Microsoft Store und somit die Unterstützung für Windows Apps in das Server OS zurückgekehrt, aber nicht als Sammel-Feature, sondern einfach als Mainstream.

RemoteFX ist ein separater Channel und wird nur durch die dortigen GPOs gemanagt.

Moin, spannende Diskussion - MTBF-Theorie trifft jahrzehntelange Praxis Meine Erfahrung ist, zumindest im Bereich der drehenden Spindel, auch die, dass die Controller die Platten meistens deutlich überleben, Markenhersteller die Controller durch baugleiche binnen 4-8h ersetzen, wenn der Supportvertrag das vorschreibt (hatte mal einen DELL-Mitarbeiter in einem 7er BMW an Heiligabend auf den Hof fahren - war das einzige Auto im Pool), und die besseren Controller die Config auch auf den Platten verewigen, so dass der neue baugleiche Controller sie automatisch erkennt und anwendet. Davon abgesehen: Eine MTBF von 300.000h läuft auf 34 Jahre hinaus. Klar, "M"="Mean", aber ein Mittelwert dieser Größenordnung bedeutet doch, dass dies niemals empririsch bestimmt worden ist und eher aus dem Kaffeesatz gelesen wurde es mehrere Möglichkeiten gibt, diesen Wert zu erreichen. Bei Elektronik (Controller oder SSD) würde ich eher auf "entweder geht sofort kaputt oder hält ewig" tippen, bei drehenden Platten evtl. doch auf eine etwas gleichmäßigere Verteilung.

Moin, die Datei ist nicht bearbeitbar, weil sie signiert ist, und eine Änderung des Inhalts würde die Signatur ungültig machen. Du musst es also auf dem Connection Broker einstellen. Dafür gibt es das folgende Cmdlet: https://learn.microsoft.com/en-us/powershell/module/remotedesktop/set-rdvirtualdesktopcollectionconfiguration?view=windowsserver2025-ps Du brauchst die Option 8: Das ist allerdings additiv, daher, wenn Du auch Clipboard, Laufwerke usw. weiterleiten möchtest, die entsprechenden Werte dazu addieren (die Zahlen oben sind hexadezimal).

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)"