NTLM für Systemkomponenten abgelöst in Server 2025? (insbesondere Zeritifikatsdienste)

[Weingeist 159]

Hallo Leute,

 

MS propagiert ja seit längerem grossspurig das Ende von NTLM in Windows. Hat es den MS schon selbst hingekriegt in Server 2025? So wie mal 2023 angekündigt?

Konkret: Zertifikat-Ausstellung mit Kerberos statt NTLM möglich? Wäre ein Upgrade-Grund.

Der Vollständigkeitshalber, Cluster?

 

By the Way, jemand schon Erfahrung mit LocalKDC bei Nicht-Domain-Maschinen/Konten? Müssen zugreifende Clients das explizit unterstützen oder ist das Ganze so gelöst, dass es transparent zu NTLM ist? Infos sind irgendwie noch etwas spärlich. Oder ich finde es mal wieder nicht. Gehe aber stark davon aus, dass es nicht transparent zu NTLM ist. Würde ja sonst keinen Sinn machen.

 

Dezember Updates schmecken dem LocalKDC übrigens nicht: https://learn.microsoft.com/en-us/answers/questions/2136070/windows-server-2025-kerberos-local-key-distributio

 

Grüsse und Danke

[cj_berlin 1.358]

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?

[Weingeist 159]

Moin,

 

Danke für den Input. Je nach Artikel die man liest klingt es schon fast wie die Beerdigung. Aber mir ist natürlich klar, dass dies erst der Anfang vom Ende ist.  

 

Was ich meine: Damit z.B. Server 2022 (oder auch die Vorgänger) ein Zertifikat ausstellen kann wenn ein Client eines anfragt, checken die Zertifikatdienste irgendwas mittels NTLM und nicht via Kerberos. Warum, keine Ahnung. Möglicherweise auch eine Fehlkonfiguration. Den Klassiker wie einen Servernamen statt einer FQDN in irgendwelchen Settings konnte ich nirgendwo finden obwohl ich schon oft gesucht habe. Auf alle Fälle funktioniert die Ausstellung von Certs nicht wenn Domain Accounts für NTLM auf einem CertServer blockiert werden. Weder Manuell noch mittels AutoEnrollments noch direkt mit der MMC. Die Mühe mit Server 2025 habe ich mir aus Zeitgründen bis jetzt noch nicht gemacht. Hoffe immer noch, dass schon jemand darauf hochgzogen hat und das bestätigen kann obs klappt oder nicht.

 

Aktuell ist das etwas lästig, muss immer aktivieren/deaktivieren wenn jemand Certs möchte. Ist zwar handelbar in Kleinumgebungen aber dennoch mühsam.

 

 

NTLM würde ich gerne mindestens für Domain Accounts nicht nur in das geschaufelte Grab werfen, sondern das Grab auch wieder zudecken. Aktuell stehen mir fast immer nur die Cert Services im Weg, die restlichen Krücken habe ich auf LocalAccounts und spezielle Maschinen gebogen.

 

Grüsse und Danke

 

 

 

Quelle der Ankündigung z.B.  https://techcommunity.microsoft.com/blog/windows-itpro-blog/the-evolution-of-windows-authentication/3926848

Zitat

For Windows 11, we are introducing two major features to Kerberos to expand when it can be used—addressing two of the biggest reasons why Kerberos falls back to NTLM today. The first, IAKerb, allows clients to authenticate with Kerberos in more diverse network topologies. The second, a local KDC for Kerberos, adds Kerberos support to local accounts.
....
In addition to expanding Kerberos scenario coverage, we are also fixing hard-coded instances of NTLM built into existing Windows components. We are shifting these components to use the Negotiate protocol so that Kerberos can be used instead of NTLM. By moving to Negotiate, these services will be able to take advantage of IAKerb and LocalKDC for both local and domain accounts.

All these changes will be enabled by default and will not require configuration for most scenarios. NTLM will continue to be available as a fallback to maintain existing compatibility.

bearbeitet 7. Januar von Weingeist

[cj_berlin 1.358]

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.

[Weingeist 159]

Hmm interessant. Hast Du grad eine Idee wo ich ansetzen könnte?

 

Auch interessant ist, dass ich NTLM Traffic eingehend/ausgehend für Domain Konten nur auf der CA aktivieren muss nicht jedoch auf dem DC.

 

Wenigstens lohnt sich die erneute Suche, wenn ich weiss, dass es mit Kerberos gehen müsste.

[cj_berlin 1.358]

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.

 

[Weingeist 159]

DC: Ja das ist mir im Grunde schon klar. Aaaaber ganz logisch ist es mir dan doch nicht, dass ich es nur auf dem Zertserver aktivieren muss.

 

Wie läufts mit der Schärfe? =)

 

Mal noch die Details der Fehlermeldung:

Auf der CA:

lsass.exe

TargetServer: ldap/dcFQDN/domainFQDN@domainFQDN

UserIdentityOfClientProcess: Computerkonto des Clients welches das Cert erneuern möchte nicht FQDN (sollte üblich sein?)

Domain name of  user identity of client process: DomainName nicht FQDN (sollte üblich sein?)

 

--> Fehlt vielleicht für LDAP ein Kerberos Ticket?

 

Auf dem Client:

Fehlermeldung:  bla bla konnte nicht registrieren.

 

Fehler: Die Anforderung wird nicht unterstützt. 0x80070032 (WIN32: 50 ERROR_NOT_SUPPORTED)

 

Habe auch nochmals die die ganze Registry und Konfig-Einstellungen geprüft, es sind eigentlich überall FQDN's drin wo ich das erwarten würde das welche rein müssen. Auch im Konfig-File der CA. Hast allenfalls eine Idee?

bearbeitet 9. Januar von Weingeist

[MurdocX 957]

Am 7.1.2025 um 16:38 schrieb Weingeist:

MS propagiert ja seit längerem grossspurig das Ende von NTLM in Windows.

 

Microsoft hat beim Server 2025 NTLMv1 entfernt. Mehr auch nicht ;) Vermutlich meintest du das.

Features removed or no longer developed starting with Windows Server 2025 | Microsoft Learn

 

 

VG,

Jan

[Weingeist 159]

vor 8 Minuten schrieb MurdocX:

Microsoft hat beim Server 2025 NTLMv1 entfernt. Mehr auch nicht ;) Vermutlich meintest du das.

Features removed or no longer developed starting with Windows Server 2025 | Microsoft Learn

Ne hat nix mit dem Artikel zu tun. Wie gesagt, mir ist durchaus bewusst, dass es erst die Ankündigung vom Ende ist. War ja bei den ganzen Ankündigen für SMB, RPC, Printer- und Laufwerksverküpfungen, Printertreiber-Rechten, Zertifikatserweiterungen etc. nicht anders. Konnte man alles schon frühzeitig machen umstellen und man fiel nicht auf die Nase wie sehr viele andere als MS das scharf geschaltet hat.  War ja auch sinnvoller/sicherer ist. Printer- und Laufwerksmappings waren der reinste Horror auf den Testclients. Bis ich geschnallt habe wo die Ursachen der Probleme liegen. Danach war alles komlett entspannt, inklusive der Updates als MS den Kram scharf geschaltet hat.

 

Für NTLM ist es ja ebenso sinnvoll das abzudrehen. Also auch VOR dem offiziellen Ende (das vermutlich noch SEHR lange dauern wird). Und es gibt die Reg Flags dazu. Die Blog-Einträge von MS-Mitarbeitern (z.B. Link oben) in 2023 legen nahe, dass man man gewillt war für Windows 11 und das Serverderivat die hart-codierte Abhängigkeit von NTLM herauszuprogrammieren. Wenn der das so schreibt, dann dürfte es wohl auch der Fall sein. Entweder also exklusiv für die neuen OS oder es ist eben auch ohne Ankündigung für ältere OS so. Meines Wissens war das bei gewissen Clusterdiensten noch der Fall und eben bei den Zertifikatdiensten. Wobei ich bei letzterem nicht mehr so sicher bin auch wenn mir auch schon andere das Verhalten bestätigt haben.

 

Wenn also Evgenij Recht hat - wovon ich ausgehe - dann sollte das für den Zert-Server nicht gelten, dass eine zwingende Abhängigkeit besteht. Normal ist NTLM ja nur der Fallback wenn Kerberos nicht klappt. Ausser eben MS hat Kerberos nicht vorgesehen und nutzt hart-codiert ausschliesslich NTLM.

[zahni 561]

Falls jemand das CA Web Enrollment benutzt: Das verwendet tatsächlich NTLM, und zwar so, dass  sich gute Penetrationstester darüber freuen.

Vom Uwe Gradenegger gibt es eine Lösung für Kerberos unter einem Domain-Konto.

 

https://www.gradenegger.eu/en/configure-the-certification-authorities-web-registration-cawe-for-use-with-a-domain-account/

 

 

[cj_berlin 1.358]

Allerdings, und das meine ich ernst, muss mir jemand mal zeigen, WIE er diese Website heutzutage noch benutzt, basiert die Ausstellung von Zertifikaten doch auf ActiveX-Controls...

[Weingeist 159]

Also "Zertifikatregistrierungs-Webdienst" ist definitiv nicht installiert.

 

@cj_berlin Und magst mir sagen wo ich ansetzen soll?

[cj_berlin 1.358]

Wegen NTLM im normalen Registrierungsprozess mit certmgr.msc? Ich würde das NTLM-Logging auf beiden Seiten hochdrehen und schauen, was da aufgerufen wird, evtl. fehlt doch ein SPN...

[Weingeist 159]

Webregistrierung von Zertifikaten habe ich nicht wirklich installiert. Das Log ist auf beiden Seiten hochgedreht, aber mehr als das was ich oben bei der Fehlermeldung angegeben habe, kommt leider nicht.

Die Art der Anforderung spielt keine Rolle. Kein Unterschied zwischen Autoenrollment oder MMC. Weder auf der Cert selbst noch auf dem Client.

 

Vielleicht fehlt wirklich eine SPN. Fragt sich welche. Dagegen spricht aber, dass normale Anmeldungen ja funktionieren. Ist es möglich, dass Zertdienste auf Domänen-Dienstkonten laufen müssen? Bei mir ist das alles auf Standard. Warum es dann aber mit NTLM klappt, würde sich meiner Logik dann verschliessen. ;)

 

Grüsse und Danke.

[cj_berlin 1.358]

vor einer Stunde schrieb Weingeist:

Vielleicht fehlt wirklich eine SPN. Fragt sich welche. Dagegen spricht aber, dass normale Anmeldungen ja funktionieren.

Das steht im Client-Log, Event 8001, Feld "Target Name". Vielleicht