Server 2025 schon ausgereift?

[testperson 1.789]

Oh mein Gott  Der erste Kaffee ist noch nicht verarbeitet. Aber ich bin mir sicher, diese genau Bestimmung der Zeit umschreibt den Release seitens MS bestens. :-D

[NorbertFe 2.206]

War bestimmt die KI, die den genauen Zeitpunkt bestimmt hat.

[Weingeist 174]

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"

 

vor 29 Minuten schrieb testperson:

kommt auch noch in der dritten Hälfte des Jahres

[testperson 1.789]

Bis zum März Update scheint das noch in Grenzen zu sein: Microsoft Update-Katalog

Im April wächst das Win 11 Update recht stark: Microsoft Update-Katalog

Im Mai legt dann Server 2025 nach und Win 11 wächst weiter: Microsoft Update-Katalog

 

[Weingeist 174]

vor 1 Stunde schrieb testperson:

Bis zum März Update scheint das noch in Grenzen zu sein: Microsoft Update-Katalog

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)

[Weingeist 174]

vor 12 Stunden schrieb testperson:

Es gab aber meine ich noch weitere Features. Ob die aber soviel Code beinhalten -> Keine Ahnung.

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

[BOfH_666 585]

vor 2 Stunden schrieb Weingeist:

Ich vermute es wird tendenziell nicht Local KDC sein,

Hmmm ... na, zumindestens gibt es auf einem Server 2025 einen Dienst der sich "Kerberos Local Key Distribution Center" nennt. Meinst Du das?

[cj_berlin 1.435]

Ja, aber der macht ja im Moment noch nix...

[Weingeist 174]

Am 16.5.2025 um 22:52 schrieb BOfH_666:

Hmmm ... na, zumindestens gibt es auf einem Server 2025 einen Dienst der sich "Kerberos Local Key Distribution Center" nennt. Meinst Du das?

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.

[cj_berlin 1.435]

vor einer Stunde schrieb Weingeist:

Ja, sobald der geht, kannst im Grunde NTLM komplett in Rente schicken.

Das ist eine Illusion. Dafür ist es ja notwendig, dass ein zugreifendes System davon ausgeht, dass der KDC identisch mit der Zielressource ist. Wenn IAKerb sich irgendwann herumgesprochen hat, werden manche Hersteller das als Standard oder als Konfigurationsoption übernehmen - Quasi Kerberos ohne explizite KDC-Angabe und ohne einen KDC Locator-Algorithmus. Bis dahin wird es auf Kommunikationsbeziehungen beschränkt bleiben, wo man EIN Ziel und EINEN KDC eintragen kann, dann ginge das.

[Weingeist 174]

@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.

[cj_berlin 1.435]

@Weingeist Du stehst evtl. auf dem Schlauch, denn bei NTLM ist die Ressource dafür zuständig, die Authentifizierung durchzuführen, und sie sucht dann einen DC, falls es sich um einen Domänen-User handelt. Bei Kerberos spricht der Client ja *zuerst* mit dem KDC und besorgt sich ein TGT und dann daraus ein Service-Ticket, und erst dann tritt die Ressource in Aktion.

Somit muss bei LocalKDC ja erst mal der Client überhaupt wissen, dass er die Ressource nach dem TGT fragen muss. Bei Windows werden sie es vielleicht irgendwie hinbiegen, als Fallback oder so, was dann vermutlich irgendeinen Angriffsvektor öffnet, an den vorher niemand gedacht hat. Bei einem Scan-To-Folder-Gerät hast Du vielleicht nur einen Fileserver und kannst ihn explizit als KDC eintragen. Was aber, wenn Du mehrere Fileserver hast, aber nur einen Eintrag für den KDC im Client-System, weil der Hersteller davon ausgeht, dass das ganze im AD steht, wenn es schon Kerberos machen will?

Alles lösbare Probleme, die aber nicht einseitig durch MSFT gelöst werden können. Da muss die ganze Branche mit anpacken. Und dass Canon, die heute gar kein Kerberos können, morgen neben einem zentralen KDC auch noch LocalKDC spielen, ist eben illusorisch.

Insofern wäre IAKerb meines Erachtens erst mal wichtiger, und wenn die ganzen Dritthersteller es sich angewöhnt haben, die Zielressource nach Kerberos zu fragen (IAKerb), *dann* könnte man für Workgroup-Ressourcen auch LocalKDC implementieren.

[Weingeist 174]

@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.