Weingeist

Moin, ok, falsch verstanden. Das bezog ich darauf. Also Kommunikation mit zentralem KDC und LocalKDC selber spielen. Der Punkt wo ich auf dem Schlauch stehe ist der, wo aus Sicht des Clients der Unterschied ist, ob er nun gegen einen zentralen oder einen lokalen KDC authentifziert. Der Ablauf müsste für Ihn ja identisch sein, da gleiche Technik aber andere Maschine. Daher auch meine Missinterpretation Deiner Aussage oben. Aber ja eine gewisse Illusion spielt da sicher mit, da gebe ich Dir vollkommen recht!

Kleine Anmerkung am Rande: An sich ein sehr cooles Gerät mit kleineren Schwächen. Habe selbst mal eines geordert. Die Herkunft ist zumindest "interessant". Es wird einem suggeriert, dass es ein europäisches Produkt ist, aber es kommt vollständig aus China. inkl. der Software und auch dem Cloud-Anbindung. Auch konkrete Anfragen ergeben mitunter interessante Antworten. Gesunde Skepsis dürfte nicht verkehrt sein.

@cj_berlin Also jetzt stehe ich wirklich auf dem Schlauch bzw. verstehe nicht worauf Du hinaus willst. Wozu muss der Drucker ein LocalKDC haben? Er ist ja der "Client" und muss sich ein Ticket holen damit er etwas auf dem Fileserver ablegen kann. Andersum - also wenn ein Windows-Client etwas auf dem Drucker holen will - sieht das natürlich anders aus. Da sind es dann in der Regel Abteilungs-Pins die man eingeben muss. Sofern das überhaupt geht. Normal gibt man für ein Scan-Ziel einen User und einen Pfad pro Ziel an. Sprich man definiert worauf der Drucker zugreifen und mit welchem User/PW er sich anmelden soll. Das Ziel - der Fileserver - sagt ob das mit den User-Creds möglich ist. Wenn es zufällig der gleiche Computer ist, gut, wenn nicht, egal. Zumindest müste es ja so umgesetzt sein mit Kerberos. *hust* Schätze mit NTLM ist es wohl eher so, dass man auf die Ressource zugreifen möchte und die verlangt dann die User-Credentials. Den genauen Ablauf kenne ich nicht. Aber auch da kann man angeben ob es ein Lokales oder ein Domänen-Konto ist. Geht eigentlich immer beides egal ob der Filer in einer Domäne ist oder nicht. Einfach indem User@ComputerFQDN oder User@domäneFQDN angegeben wird. Aktuelle mache ich das so: Separater Scan-Fileserver der in der Domäne ist Lokales Dienst-Konto auf dem Fileserver welches im Drucker angegeben wird (ich mag für Dienskotos üblicherweise lieber lokale Konten, sofern möglich) NTLM für Domänenkonten AD-Weit gesperrt Ausnahme für NTLM auf diesem Fileserver Nur ein spezielles Admin-Konto das sonst nirgends verwendet wird, hat auf dem Filer Anmelderechte mit einem Domänenkonto, sonst niemand, also alle explizit verboten Heisst der Drucker greift mit einem Konto zu, dass nur auf dem Scan-Server existiert. Aktuell verwendet z.B. ein Canon Drucker NTLM um sich zu authentifizieren. Versucht sich jemand mit NTLM gegen ein Domänenkonto via dem Scan-Filer zu authentifzieren, schlägt es fehl obwohl der Filer selbst ein NTLM-Ausnahme hat. Verwendet er ein lokales Konto des Filers, ist es dagegen möglich. -->Schön wäre nun, wenn das ganze über den LocalKDC laufen würde und keine Ausnahme notwendig wäre. Inwiefern es tatsächlich ein Sicherheitsgewinn ist, keine Ahnung. Aber das NTLM nicht sicher ist, wurde bereits bewiesen. ;) Bei den Adresslisten die von einem Server gestellt werden, sieht das anders aus. Da geht oft Druckerweit nur eine Anmeldung an einem Verzeichnisdienst. Da können eigentlich auch alle Kerberos. Selbst Canon. Insofern wüssten die schon wie das geht.

@cj_berlin Sehe noch nicht ganz die Problematik. Entweder meldet man sich mit EINEM User an EIN Ziel und somit EINEN lokalen KDC an oder man verwendet EIN Domänenkonte wo die Authentifzierung gegen MEHRERE Ziele (DC's) möglich ist. In beiden Fällen liefert der DNS doch die entsprechenden IP's der bzw. des Anmeldeservers für einen externen Zugriff. Bedingt natürlich, dass der zugreifende User nicht einfach ein Username sondern eben der vollständige Anmeldename ist. Also "user@domänexy.xy" oder "user@computer.domäne.xy". Oder "User@computer.xy". Ist kein DNS vorhanden müsste man eben die IP händisch mit angeben. So wie auch für NTLM wo sie einfach via Broadcast oder auch mit DNS ermittelt wird. Mit der Ressource selbst hat das ja erstmal nichts zu tun, das ist ja immer eine separate Angabe. Oder stehe ich auf dem Schlauch? Wie die ganze Vortrauenssache aussieht damit überhaupt eine geschützte und sichere Authentifizierung vorgenommen werden kann, steht wieder auf einem anderen Blatt. Aber da wird ja MS schon eine Idee haben wenn sie das implementieren. Dazu habe ich mich noch zu wenig damit beschäftigt. Vielleicht weiss ja Du dazu mehr? Ansonsten bin ich mal gespannt wie lange es geht bis die Malware-Entwickler so kreativ werden und die integrierten KI-Funktionen gleich für den Angriff zu nutzen. Könnte "interessant" werden. Hat etwas von der Büchse der Pandora. Ich würde jedenfalls lieber die Lizenzgebühren für ein reines, stabiles, sicheres OS bezahlen. Vielleicht lässt es sich dann ja auch easy entfernen. MS hat ja mittlerweile eine sehr gute Kapselung der Komponenten.

Ja, sobald der geht, kannst im Grunde NTLM komplett in Rente schicken. Wie stark es tatsächlich ein Sicherheitsgewinn ist, kann ich nicht beurteilen, aber immerhin musst dann keine Ausnahmen mehr machen für NTLM. Zumindest solange andere Software-Hersteller zeitnah nachrüsten. Bis dahin kann bzw. sollte man es für Domänen-Konten deaktivieren und auf einzelnen Maschinen für lokale Konten zulassen.

Glatt überlesen: Nope, nochmals die Logik aktiviert: Die Binary vom halben OS austauschen geht nur, wenn Du in der Hälfte des Codes etwas nachrüstest und somit alle Files ersetzen musst. Denke so extrem viel neuer Code wirds wohl nicht sein aber ne Menge Datein denen was nachgerüstet wurde. Ich vermute es wird tendenziell nicht Local KDC sein, auch wenn das Cool wäre, könnte ich Canon mal wieder schreiben, dass es nun sogar mit "normalen" Computern geht... (die können immer noch kein Kerberos....)

mhua mhua.... in Grenzen mit 1.2 GB, der war gut. Das erste Update war schon grösser als alle Server 2022 bis Stand heute (May 2025: 392,6 MB)

Ich finde es nur irgendwie schräg, dass ein LTSC-Build solch grundlegenden Kram nachträglich eingebaut bekommt. 4GB Updates nach wenigen Monaten klingt eher nach short-release und insider build als Security Fix. Vielleicht schieben sie ja kurzfristig ein R2 nach. Als Vergleich: Bei Server 2022 war das im Mai 2022 um die "243,2 MB" ende Jahr dann "316,3 MB"

Nun, gemäss verschiedenen Blog-Quellen ist es aber wohl so, dass die ganzen AI-Funktionen im Mai-Update eingebaut wurden. Vielleicht plappern aber auch alle einander nach und ich bin drauf reingefallen. Logisch gedacht, was sonst soll bei einem Cumulative Update soviel Speicherplatz brauchen? Wäre in 20 Jahren das erste mal das über 3GB an zusätzlichen updates in einem Monat reinflattern. Sehr unrealistisch. Muss ja jetzt nicht heissen, dass die ganzene Fotoaufnahmen erstellt werden. Oder sonstige automatischen Übermittlungen an MS gleich mit aktiviert werden. Das passiert dann vermutlich wieder aus versehen.

Ja klar könnte man. VDI entpannt aber auch nur bedigt. Wird das Profil gelöscht, sind die Einstellungen auch weg. Gleiches gilt bei der Golden-Image erneuerung. Ist zudem halt wieder etwas zusätzliches das allenfals nach einem Update nicht mehr geht. FSLogix entspannt da zwar einiges gegenüber klassichen servergespeicherten Priflen, ist aber auch nicht zwingend ohne mit den Versions-Updates. Gab da auch schon Ärger. Und ist etwas zusätzliches. Sofern irgendwie machbar löse ich alles nur noch per Script und/oder GPO. Ist auf lange Sicht einfach schmerzfreier und weniger Arbeit. Ich mags wenn ich wenig Support-Arbeit habe. Und es durch weniger zusätzlichen externen Komponenten tendenziell auch sicherer ist.

Gibt noch einen Punkt. Copilot etc. wird wohl mit den Mai-Updates auf allen Maschinen ausgerollt. Unabhängig davon, dass ich das nicht möchte, heisst das auch, dass das kumulative Update für W11 24h2 und Server 2025 bereits ein paar Monate nach dem Release rund 4GB gross sind! Sprich es braucht enorm viel freien Speicherplatz für die Installation des Updates. Wahnsinnig toll für schmale VM's. Meine Fresse, Windows Server ist ein LTSC-Build, da gehört sich so ein enormes "Feature-Update" nicht. Gehört in einen neuen Release. Aber der Persilschein für die Techbranche von Trump zeigt wohl seine Wirkung und MS setzt sich über nationale Bedenken anderer Länder hinweg. *hmpf* Für mich macht es den anschein wie damals Server 2016. Noch nicht wirklich ausgereift.

Ein Lösungsansatz: Nimm einen User, lösche sein lokal zwischengespeichertes Profil (Neustart des Computers - damit sauber gelöscht werden kann -, anmelden mit anderem User, Profil des anderen Users über erweiterte System-Einstellungen löschen). Wenn er sich erneut anmeldet und dann alles gut ist, hast einen Lösungsweg. Wenn nicht, machst das gleiche mit einem User der kein servergespeichertes Profil hat. Klappts dann, weisst es liegt am servergespeicherten Profil und Deine zweite Aussage trifft nicht zu. Eben weil ihr Probleme habt. Auch wenn ihr bis anhin keine hattet. Das ist ein gängiges Szenario bei servergespeicherten Profilen, irgendwann krachts, weil MS mit jeder Build irgendwas an den Profilen schraubt und für sie servergespeicherte Profile eigentlich tot sind und somit nur stiefmütterlich testet. Der zweite Lösungsansatz ist wie von BOfH_666, Link auf Desktop. Warum Alt + F4 nicht gut sein soll, werde ich nie verstehen. Ist viel schneller und Programme werden sauber geschlossen. Auch wenn ich mich wiederhole: Plane die die Ablösung von servergespeicherten Profilen und ersetze es mit Scripts und GPO's. Falls Du das - aus Gründen - nicht willst, nimm wenigstens durchgängig den gleichen LTSC-Build von Windows auf allen Maschinen wo das Profil geshared werden soll und verhindere das servergespeicherte Profil auf anderen Maschinen. So hast getan was getan werden kann damits nicht kracht.

Seit Windows 8 (oder wars sogar 7?)tue ich mir servergespeicherte Profile nicht mehr an. Selbst Ordnerumleitung habe ich abgeschafft und durch simple Links auf Fileserver ersetzt. Wie das geht? User beeinflussen. Arbeitet mit dem Standard, rechnete jeden Tag mit einem neuen. Schieb die Schuld auf MS dass dies notwendig ist und jeder begreift es. Nicht vollständig fair, aber zweckmässig. Schau gleichzeitig, dass sich möglichst wenig ändert. Die User gewöhnten sich zu meinem erstaunen sehr schnell an diese arbeitsweise. Seither ist der Supportaufwand unglaublich tief geworden. Natürlich mache ich auch Anpassungen die müssen dann aber per Script oder GPO umsetzbar sein und sind so in der Regel auch Versionsresistent.

Dann ist es grässlich. Cloud und MS-Konten werden quasi erzwungen. Über den (günstigen) Preis geregelt. Was genau MS übermittelt, weiss niemand. Es wird nicht offengelegt. Selbst Windows analysiert extrem genau wie ein Computer von wem genutzt wird. Dazu dann noch Copilot, KI etc. in Windows und Office. Das ist eine herrliche Spielwiese. Von der US-Regierung haben sie quasi einen Freipass. Unsere werden soweit erpresst, dass wir die Gesetzte anpassen. Ist ja bereits im Gang. Aber ich gebe dir recht, nicht ganz der richtige Ort. Aber gehört halt trotzdem dazu. Ist immerhin unser Nachwuchs @lizenzdoc Gibt es super-günstig Programme auch für die lokale Installation im Bildungswesen? Kaum oder? =)

An der Stelle von MS würde ich das auch tun, nur schon um Office in die Köpfe zu pflanzen. Aber ist es zu schön um wahr zu sein oder gilt die Lizenz auch für lokale Installationen ohne MS-Konto? Weil wenn nicht, finde ich das grässlich. Nicht die Tatsache, dass es günstig ist, sondern zu welchem Preis. Ich finde es allgemein höchstgradig bedenklich wenn bereits Schüler in grossem Ausmass durch Techfirmen "telemetriert" werden. Einstufung von Mensch quasi bereits auf Schulniveau. Gilt auch für die ganzen Prüfungen etc wo Reaktionszeiten, Verweildauer etc. gemessen werden. Vielleicht bin ich diesbezüglich für manche ein Schwurbler aber ich kann dem gar nichts abgewinnen.

Oh wow, dann ist das aktuell ein K.O Kriterium. Ich nutze ReFs/Storage Spaces sehr oft und gerne. Scheint ja doch recht heftig zu sein, waren nicht mal nur migrierte Volumes (was ich nicht machen würde) oder iSCSI,

Ich nehme alles zurück und behaupte das Gegenteil. Aber im Ernst, so ganz kann ich das noch nicht glauben, dass NlaSvc nicht mehr beteiligt sein soll. Netprofm/NLS hängt - zumindest was Dienstabhängigkeit angeht - am Tropf von NLA, auch wenn netprofm wohl für die eigentlichen Reg-Einträge zuständig ist. Oder wurde diese Abhängigkeit technisch gekappt oder sogar die abhängigkeiten vergessen? Könnte eine Erklärung sein, warum das bis jetzt nie zuverlässig geklappt hat. BFE verliess sich für die Profilwahl auf NLA und NLA müsste durch NLS/netprofm getriggert werden, tut es aber nicht wenn die Daten identisch sind. Wenn aber beim Reboot DNS vor NLA oben war, hat NLA funktioniert weil sich NLA (wohl je nach Build) auf DNS verlies. Oder wenn die Einträge in den Neztwerklisten gelöscht wurden, erfolgte der Trigger (über welche Umwege auch immer) weil der Dienst nach NLA gestartet wurde (abhängigkeit). Allerdings nur bei einmalig bei einem Reboot. Interessant wäre nun, ob die Abhängigkeit eigentlich anders rum sein müsste. Sprich was passiert, wenn man NLA von netprofm abhängig macht, also ob dann Nla auch Infos von den Netzwerklisten holt. Oder nur DNS den man wiederum als voraussetzung für netprofm nehmen könnte. Muss ich die Tage mal testen. Schöner wäre es wenn MS das Problem endlich mal nachhaltig und zuverlässig lösen würde bevor wirklich 20 Jahre rum sind. Wie auch immer, in Horizon-Umgebungen werde ich wohl wegen der AD-Integration noch mit 2025 warten bis andere andernorts keine mehr haben. Spare ich mir aktuell den Aufwand für Tests. Danke für die Info!

OK, das Probleme dürfte ich hoffentlich nicht haben, da ich üblicherweise keine MS-fremde Software auf DC's installiere. Das bezweifle ich mal stark, weil es immer die gleiche Laier ist mit dem Teil. Seit Vista. Also 20 Jahre. NlaSvc startet bevor die Dienste, Verbindungen etc. die es zur zuverlässigen Erkennung braucht, oben sind. Den Bug gibts seit Vista. Mit DHCP gabs ihn lange nicht, mit fixen IP's - insbesondere IPv4 - war er noch nie zverlässig weg. Ständig wird irgendwas dran rumgebastelt. Manchmal tut es wieder irgendwann nicht mehr oder der Lösungsweg wird anders. Der einzige Weg der immer funktioniert ist Adapter deaktivieren und wieder aktivieren oder z.B. ein Protokoll zu aktivieren/deaktivieren damit NlaSvc getriggert wird. Wenn DHCP aktiv ist, reicht ein ipconfig /Renew. MS müsste nur mal nen Trigger einbauen den man anstossen kann, sie kriegen es ja sowieso seit 20 Jahren nicht gebacken. Weil so muss man immer nen Script basteln und mit Admin-rechtne ausführen.

Meinst den ***ischen Bug den es eigentlich in jeder Windows Version gibt, mal auftritt und mal nicht aber bei DC's noch viel peinlicher ist? Also dass der NlaSvc seine eigene Domäne nicht erkennt? Ode hab ich was verpasst?

Salut zusammen, Gibt es irgendwelche gröberen Dinge abseits von den Issues die bei MS gelistet sind? Die gemeldeten Probleme scheinen mir extrem überschaubar zu sein. RDS scheint etwas zu nerven aber sonst hört man im Gegensatz zu W11 extrem wenig. WSUS gabs mal noch eine Installations-Verhinderung nach einem Update, aber das haben sie auch schon früher immer wieder mal hingekriegt. Älteren Build nehmen, Rolle installieren, Updaten und gut ist. Grüsse und Danke

Per GPO... Puuuh das ist schwierig. Problem ist, Du musst System die Rechte in Registry-Schlüsseln und/oder Ordner der Apps entziehen. Dann können diese Apps nicht mehr in einem neuen User-Profil installiert werden. Bestehende laufen laufen aber weiter im User-Kontext und können ausgeführt werden. Im Grunde reicht es aus, dem System die Schreibrechte auf Firewall-Regeln zu entziehen, die auf App-Basis erstellt werden. Das verhindert die Installation der Apps sowie die vielen Firewall-Ausnahmen die für jedes Profil/App erstellt werden. Ist etwas tricky das ganze. Und halt doof wenn es jemand anders als Du es betreut .--> Doku. Sofern möglich, darauf verzichten. Meistens stört das Startmenü ja nicht. Ich benutze das manchmal für Industriemaschinen wo dann eine eine eigene App läuft weil es flexibler ist als der Kioskmodus. Die Komponenten sind leider undokumentiert. Ich kann Dir nur sagen wie Du dich herantasten kannst. Ist aber mit viel Aufwand verbunden der sich grundsätzlich nicht lohnt. Für den Spieltrieb ganz nett, produktiveher nicht. Es gibt Komponenten die lassen sich problemlos entfernen ohne spätere App-Crashes etc, andere wiederum nicht. Im Grunde erreicht man ähnliches wie früher mit N-Lite.

Auch wenn die Kiste in der Domäne ist, kann man sich grundsätzlich auch mit einem Lokalen Konto anmelden. Hast Dann einfach keinen Zugriff auf Domänen-Ressourcen. Würde aber reichen für das surfen und die Kiste ist dennoch zentralt verwaltet. Aber auch ein Domänen-Konten welcher explizit jede Anmeldeberechtigung (Lokal/Remote) auf alle anderen Comuter in der Domäne verweigert wird, ist machbar. Mit den jeweiligen Vor- und Nachteilen. Die Aufnahme in die Domäne würde ich persönlich grundsätzlich bevorzugen wenn die Kiste nicht "öffentlicher" ist, als andere auch. Wenn sie wesentlich öffentlicher ist, würde ich eh nicht wollen, dass sich Leute mit RDP auf ihre VM verbinden können und das ganze würde sich erübrigen. Für Schulen gibts übrigens noch extra so Wächter-Computer die sich automatisch zurücksetzen. Musst mal im Bord suchen. Ansonsten: Die "Schmerzen" - eimalige, chronische, wiederkehrende - die mit dem Kiosk-Modus verbunden waren, lohnten sich früher eher nicht. Den Kiosk-Mode behandelte MS in der Vergangenheit nur sehr stiefmütterlich. Ich befürchte, dass gilt heute noch. Ausser auf LTSC-Releases würde ich den sowieso nirgendwo einsetzen. Ansonsten lieferte MurdocX bereits ein paar wichtigste Tipps. Ich bevorzug es, mit sonstigen Bordmitteln wie AppLocker granular dicht machen. Selbst die ganze GUI mit Taskleiste, Benachrichtigungen etc. bringt man komlett weg, so dass nur noch der Desktop selbst funktioniert. Back to the Roots quasi. Entweder tatsächlich deinstalliert mit dism (experimentell, nicht reversibel, viele Tests notwendig, keinerlei Support) oder per Verweigerung der Userbasierten Installation indem dem System und TI gewisse Rechte entzogen werden. Das UserProfil ist dann quasi GUI-los, so ähnlich wie früher die minimale MMC-Variante (Name fällt mir grad nicht mehr ein). Ein Vorteil der immer besseren "Kapselung" der Komponenten im Unterbau von Windows. Angenehmer Nebeneffekt: Auch der Wildwuchs an unerwünschten Firewallfreigaben auf Apps werden nicht mehr erstellt und keinerlei Bloat-Apps installiert. Je nach dem wie weit man das treibt, ists dann eine aufgebohrte Core mit den wichtigsten grafischen Bibliotheken für Server-Tools von anderen Herstellern oder Industrie-Computer.

Stimmt, auch wieder wahr. Wieder VmWare?

Vielen Dank für die zahlreichen Antworten. Probleme ist übertrieben, aber die gefühlt 27 verschiedenen Orte wo die ganzen Einstellungen gespeichert waren, fand ich super lästig. Änderungen auch. Auch mit verschiedenen vLANs auf dem gleichen Adapter war das irgendwie grottig gelöst. Soweit ich mich erinnere was das alles irgendwie verschachtelt. Bei VmWare war bzw. ist der Netzwerkstack extrem geradlinig. Kann mich so vage daran erinnern, dass ein Path-Down ein riesiges Theater war bzw. nicht selber wieder aufgenommen wurde. Multipathing eher mässig funktioniert hat bzw. gräuslich einzurichten war weil hälftig MS-Einstellungen und hälftig irgend nen Vendor-Treiber damit die Bandbreite nicht auf einen Adapter beschränkt war (heute wäre das nicht mehr so dramatisch mit 10Gbit und mehr). Die Updates einspielen der Hersteller für das Multipathing war dann das Tüpfelchen auf dem i. Aber eben, meine Erfahrungen liegen da ungefähr 15 Jahre retour oder so. Seither nie mehr iSCSI mit Windows benutzt. Bei VmWare war bzw. ist das ultra trivial auch wenn Active-Active früher auch je nach Vendor etwas spezieller in der Konfig war. Oder eben auch easy NFS für Datengräber oder sonstiges. Meine Umgebungen sind immer klein und müssen relativ statisch sein. Sonst gebe ich sie ab. Rollentrennung mache ich trotzdem. Sprich eigentlich Overkill aber halt auf lange Sicht trotzdem einfacher. Spart Stunden und somit Geld und ich kanns problemlos abgeben wenn es mir zu umfangreich wird. VmWare läuft halt alles drauf, egal was kommt. Auch altes Windows-Zeugs oder Unix. Ist aber mittlerweile fast alles ausgemustert, ausmusterbar oder beschränkt sich auf einen Offline Arbeitsplatz. Mit View/Horizon/Ominissa/Teradici kenne ich mich aus. Habe ich quasi seit der ersten (brauchbaren) Stunde benutzt. Mit dem Verkauf starben aber die alten "Rechte". Irgendwo hat der Komfort eine Kostengrenze, diese gehen mittlerweile schon in der Bereich von nicht lustig. Daher tendiere ich eher auf einen Rückschritt. Auch der Grafikteil wurde immer lästiger nur mit CPU-Cycles, weil viele neue Oberflächen mehr Grafikintensive Funktionen haben obwohl imho unnötig. Nvidia ist da viel zu teuer. Ansonsten: Die ganzen Cluster-Funktionen brauche ich eigentlich nicht. Weder bei HyperV noch bei VmWare. Viel zu viel Komplexität und ich mag es, wenn Hosts unabhängig sind und ihre eigene Rechteverwaltung haben. Hat zwar klar auch Nachteile aber die sind jetzt in kleinen Umgebungen nicht wirklich gravierend. Ausser eben mit vTPM, da wird es lästig. Wenn auch machbar mit VmWare. Windows habe ich mich noch nicht schlau gemacht. Aktuelles Fazit: Keine Ahnung. Ausprobieren muss ich HyperV wohl oder übel sicher.