You disabled NTLM across all of your workstations. What problems did you not account for?

[-]

maryteiss@reddit

A few things people typically miss even in clean environments:

Printers and MFDs. Scan-to-folder and scan-to-email workflows that authenticate against a share or SMTP relay. Vendors hardcode NTLM and haven't updated firmware in years.

Monitoring and backup agents. Agents running under local service accounts hitting UNC paths. Easy to miss in log review if the backup window doesn't fall in your 30-day sample.

Line-of-business apps phoning home to internal shares. Even in Entra-only shops, some apps were written assuming Windows auth = NTLM and never got updated.

Local admin tools. Anything using net use or mapped drives under a local account rather than an Entra identity.

[-]

databeestjegdh@reddit

So I tried this (small), and promptly lost access to the shared drive, and, "ntlm authentication is disabled".

If you have AAD joined clients and attempt to access a on-prem DFSN shared drive, with a setup where the the DFS Namespace is \\domain.tld\sys pointing to both DC's the client will fall back to NTLM. Point AAD client to direct hostname and a ticket is generated and it works. AD joined clients have no issue to access the domain.tld namespace and generate a kerberos ticket.

So we tried other methods suggested on Reddit and elsewhere to run the DFSN service under a gmsa service account with permissions. But alas, didn't work for us.

Generate a SPN for cifs/domain.tld pointing directly to a DC, works, but is now dependent on single server.

the moral of the story is, we thought all our clients were doing kerberos, and instead they are all doing NTLM to the DFS root. The upside is that it does actually use kerberos to the underlying servers when populated with the FQDN in DFSN.

[-]

Important_Candy_8048@reddit

In the same boat here. I have found that this is true for both AADJ joined and hybrid joined clients. Running DFSN with a gMSA did not work for us either. Adding cifs/domain.tld SPN to a DC does work, but does indeed limit you to a single server. It's just hard for me to believe that domain-based DFS referrals just can't/don't work with NTLM disabled, but that does seem to be the case.

[-]

ReputationOld8053@reddit

Hi,
just wanted to check after some months if you have found a solution for this issue. Adding the SPN to all DCs or found a way with the gMSA account?

[-]

Important_Candy_8048@reddit

Hi u/ReputationOld8053 I did not find a way around it. In our case we just went down to a single domain controller to host domain-based DFS across all of our sites (in other words, went down to a single site in AD Sites and Services encompassing all the subnets for our different offices) since our roadmap is to work to shut down ADDS over time anyway in favor of Entra. That's not a very satisfactory solution, I admit. If others have figured out a way around this wrinkle, I would be interested as well.

[-]

TacoSmiff@reddit

The same team that disabled NTLM was also bringing in a PAM solution that relied heavily on… NTLM.

[-]

Affectionate_End1412@reddit

Gotta love the security wonks.

[-]

shipsass@reddit

Remote Desktop Gateway depends on NTLM.

[-]

xxbiohazrdxx@reddit

sorta

Mstsc supports Kerberos proxy through the gateway but you know what doesn’t? The new store based Remote Desktop clients.

Why does the old client work with it and not the new clients? Because Microsoft!

[-]

tankerkiller125real@reddit

If you're referring to the orange logo one, from MS Store it was discontinued and no longer available. You can still get the MSI installer version from what I can tell, and from what I remember it does support Kerberos.

I believe the replacement Windows App (Microsoft loves to make shit confusing) does support Kerberos based on my own experience with it.

[-]

xxbiohazrdxx@reddit

I'm referring to windows app, I tried it as recently as a month or so ago and it would not proxy Kerberos through rdgateway

[-]

tankerkiller125real@reddit

From what I can find it defaults to NTLM (what the fuck Microsoft) but

gatewayhostname:s: gatewayusagemethod:i:1 rdgiskdcproxy:i:1 kdcproxyname:s:

In an RDP/Connection Settings (should) get it working properly with Kerberos assuming that the KDC Proxy is configured and working.

I do know for sure that it uses Kerberos when connecting to AVD hosts and stuff. So the App itself does have Kerberos capabilities.

[-]

JewishTomCruise@reddit

Correct, it can work for sure. https://learn.microsoft.com/en-us/azure/virtual-desktop/key-distribution-center-proxy

The main issue is that on prem RD Gateways don't deploy a KDC Proxy, so iirc you still have to deploy one yourself. Mstsc doesn't default to NTLM, it defaults to using the gateway as the kdc proxy, and if that fails it falls back to NTLM, leading to the experience you're describing.

[-]

hurkwurk@reddit

my life experience with MS products in the enterprise is that they are designed to fail out of the box, and that you have to find someone elses guide on how to clean up the product to work as anyone in an actual enterprise would expect, because MS will never actually give any real advice on how to make a working system, instead their guides always just tell you about settings, and never make any practical recommendation on what the hell to set.

like in your statement... out of the box, its missing a key component, KDC Proxy, to work in the expected manner. its so frustrating.

I miss the late 90s/early 2000s where i could actually install a product off a CD and it worked properly and included all the required components and stuff.

[-]

PowerShellGenius@reddit

Remote access from the internet is a big deal. If you understand how the authentication processes work, or want to understand, the Microsoft documentation is more than sufficient.

If you don't understand and don't want to, and want a step by step "follow these steps and it will work" process - there are subscription cloud solutions meant for you.

On prem = you have full control but security is fully uour responsibility. If you are qualified to have that on a web facing RD gateway today, the docs make sense. Since you need to either roll in some sort of MFA product or use certificate-based auth with a PKI, you need advanced technical skills in house to safely run RD Gateway & people who need it dumbed down are the ones who are trying to expose a small business network to ransomware through a password-only internet facing RD gateway.

If you are looking for a "skip to the finish line, step by step, I don't need to understand how it works" solution, Windows 365. You can secure it with MFA by easy point and click admin console settings same as the rest of Microsoft 365.

[-]

hurkwurk@reddit

You have completely missed the point and forgotten what reddit you are in.

I don't need yet-another-product to assume that i have the same 5 to 10 years of experience their internal staff do in figuring out their specific syntax, idiosyncrasies, etc.

an example of what im talking about from another product, a couple new staff learning Splunk on windows, and when running it on windows, instead of it using /etc/auth/certname in the conf files, when you setup in windows, it wants the windows path instead for the cert only... so c:\program files\splunk\etc\auth\certname but not with quotes like you would expect with a space because, no reason at all, just because.

Thats the kind of shit im talking about, usually i see that with MS. they might tell you about some setting. but they will never provide a real world working example that will help you figure out that proper syntax, especially in some case like where maybe it allows multiple values... is it a comma? is it a simicolon? is it a space? nevermind something like LDAP, that is sometimes in AD notation, sometimes in LDAP notation, and sometimes just a single entry with no notation at all.

[-]

Nysyr@reddit

RD Gateway role has the KDC proxy functional on it, you can see it listening with netsh show urlacl

[-]

xxbiohazrdxx@reddit

Interesting, I wonder if there's an easy way to set those options directly in the gateway config in the new app.

[-]

tankerkiller125real@reddit

You can push it via GPO (Kinda).

From memory (I could be off here):

Computer Configuration > Administrative Templates > System > Kerberos

"Specify KDC proxy servers for Kerberos clients"

And then Value Name is the Realm, and value is the KDC Proxy with < and /> around it.

[-]

xxbiohazrdxx@reddit

Windows App/new RDP client exists for many non-Windows operating systems. GPO is not a valid solution for MDM/cloud first deployments

[-]

mirrax@reddit

If your MDM system can't set a policy or the corresponding reg key on a Windows system, you need a better MDM.

[-]

tankerkiller125real@reddit

I only work with Windows devices where I work, there is no universal "covers all endpoint client" method.

Some quick research shows that for Macs you can apparently use the Enterprise SSO Extension (apparently, again zero experience)

And your shit out of luck on Android and iOS.

[-]

xxbiohazrdxx@reddit

But that's exactly my point. NTLM is going away but MS is still shipping software that only supports NTLM

[-]

neferteeti@reddit

Shipping as in releasing? Or do you mean they haven't updated older software to support it?

[-]

tankerkiller125real@reddit

How is it Microsofts fault that these operating systems don't have native Kerberos implementations to hook into?

And before you suggest they embed their own implementation into the application, just remember how many bugs and security holes that would likely result in when an engineer doesn't quite understand the specs of some OS credential protection system or whatever.

[-]

xxbiohazrdxx@reddit

Microsoft is a multi trillion dollar company. Maybe they should fucking figure it out.

"but its haaaaard" isn't a valid excuse.

[-]

marklein@reddit

You need to get the copilot version /s

[-]

hurkwurk@reddit

the people that name things at microsoft need to be put out to pasture and replaced with Humans that think.

what do we call the chromium replacement for Edge? EDGE!

what do we call the webview2 replacement for Teams? TEAMS!

no you ninnies... you call them 2.0 at LEAST.

[-]

FearIsStrongerDanluv@reddit

lol, that Microsoft Windows App that works better on a Mac than on a Windows laptop. Smh

[-]

Savings_Art5944@reddit

The old remote desktop app could access debian clients over RDP like it was console.

MS is their own enemy.

[-]

1996Primera@reddit

liking the new windows app now.

but for a while, it caused me so many issues with avd and w365 pcs ...due to adfs hybrid setup and in Gcc High. We had everyone using the browser access and that was terrible bc they supplied everyone w/ underpowered devices & edge along w/ teams is a resource monster (swear there are memory leaks.....)

[-]

pdp10@reddit

It's called "Windows App" because you're going to be using it to access Windows from your non-Windows device.

[-]

tankerkiller125real@reddit

It's called Windows app because it's used to access Windows 365 (originally it's only capability/purpose), your giving way too much credit to Microsoft when it comes to naming things.

[-]

pabskamai@reddit

Don’t you have to now log in with a silly ass Microsoft account to use that thing?

[-]

JewishTomCruise@reddit

I have to wonder, why are you trying to use the new clients with an on prem rds deployment? I'm not really aware of any advantages.

[-]

xxbiohazrdxx@reddit

Well if you're on MacOS there's literally no other option besides "Windows App" (insert barf emoji here)

[-]

pdp10@reddit

FreeRDP supports macOS.

[-]

JewishTomCruise@reddit

Other than a terrible name, I actually find the Windows app to be a significant improvement over msrscw. I just can't wait for some semblance of unification, so I can use the Windows app to launch custom/local rdp sessions

[-]

Beznia@reddit

At least they ditched "Remote Desktop". THAT was a terrible name.

[-]

xxbiohazrdxx@reddit

I'm mostly in the same boat. The name is peak Microsoft naming failure but the functionality is...fine

[-]

JewishTomCruise@reddit

Mostly I just want the teams slimcore shims to work on my local rdp connections. Its so much better performance than teams over rdp, but I can only get the legacy teams media optimization to work, which kinda sucks

[-]

pdp10@reddit

Interesting. Almost all of our RDP use is with FreeRDP, which does still support Win32. We haven't tried it with RDG, but that's what I'd reach for first.

[-]

bittertrundle@reddit

And if you are forced to use Parallels RAS, the RAS client requires NTLM, even if you aren't using your local on-premised domain (this hosted app has it's own Azure domain separate from us). Fortunately I tested with only a few people first.

[-]

PowerShellGenius@reddit

Broke a couple of applications that use Windows integrated authentication.

One was a records management system (Laserfiche) that does use Kerberos, but was using NTLM due to not having the proper SPNs set up (its installation pre-dated me or anyone else who understands AD in any depth being there). Adding the needed SPN to the service account the service on the Laserfiche server runs as fixed this easily.

The other was an old program that is part of a K-12 specific product (the Skyward SMS 2.0 Student Information System). This uses NTLM. It does not attempt Kerberos. It needed an exception to NTLM disablement.

There were a few other niche things. We ended up accepting an exception for outbound NTLM from workstations being allowed to the servers VLAN (via an IP address with a wildcard). We still do not have NTLM in, or out to arbitrary addresses.

[-]

Certain-Community438@reddit

In a cloud only M365 environment, with NO on premise?

There is no classic "client <-> server" communication, cos... you have no servers (here I'm including no reason for workstations to offer network services).

NTLM is for AuthN & AuthZ to Windows servers / services.

So if you're wondering what you might miss, you find your exceptions to the above logic.

[-]

MrSuaveUK@reddit

Sage 200 on prem. App server can’t communicate with the DB server 😩

[-]

IconicPolitic@reddit

CIFS pin not present on windows file server caused sporadic authentication failures to the shares.

[-]

LaurenzVonArabien@reddit

Oh, that sounds interesting and actually fits one of my current problems. Could you tell me more about it?

[-]

techvet83@reddit

We disabled NTLMv1 with no pain (after looking at the logs) but disabling NTLMv2 altogether will be a major project because of non-domain-joined machines, people using IP addresses for RDP and for drive mappings (to work around a separate issue), and so on.

[-]

BoringLime@reddit

We have run into a couple of gotchas. From the workstation side we haven't hardly experienced any issues other than authenticate vulnerability scanning. Server side we have one windows server that basically runs file share as an active - active pair for high availability. Proprietary print generating application. You can't run file share service as a service account and only one machine or service account can register the Kerberos spn. Service accounts is how SQL server and iis clustering gets around this issue. So no simple way to make this work without something like a f5 or higher end load balancer that can load balance Kerberos.

You have to check everything running sql server or iis that it has the spn registered properly to the machine or service account. Dev workstation might run into this.

If you use something like tenable to scan your workstations, and do authenticated scans, you have to switch from IP based scans to dumping out a list of hostnames and scan by hostnames. You can't normally use Kerberos with IP addresses. There is a way to register an IP as spn but it's not a default.

[-]

JewishTomCruise@reddit

That sounds super bizarre. Smb absolutely supports Kerberos auth, and I'm not sure how you'd have an active active windows file share in a supported way without DFS-N, which 100% supports kerb

[-]

BoringLime@reddit

Correct smb supports Kerberos. The issue is the spn have to register to a single ad account, they are unique in active directory. This case we have server1 and server2, that both listen for server-alpha name, which is windows load balanced. Only one of the machines can register server-alpha spn. SQL server and iis gets around this by running the respective services under the same service account and assigning the shared Kerberos spn to the service account. For Kerberos it's very important that the machine you sent the request too, this example aerver-alpha be able to use that requested spn service, to do auth. It can not sign the response with.the server1 or server2 Kerberos ticket. Smb can't be run under service account.

It's not a huge deal, as you can set up ntlm exceptions, server names that can still use ntlm and block the majority. But ntlm is rather difficult to totally disable in a mature environment that never looked at disabling ntlm before.

[-]

JewishTomCruise@reddit

You should consider why it takes so many extra settings to make these hacky solutions work.

Instead of doing things like this, just look into what it takes to deploy a supported solution instead. You should be using DFS-N for this, not trying to hack together a solution that uses a stateless load balancer for a stateful technology.

[-]

BoringLime@reddit

That isn't a support solution in this case. This is very typical answer in the IT world, no drop in replacement products are rarely 100% compatible for all situations. We use a legacy printing system that runs as a print driver(virtual) and has several server service processes monitoring the queue for files to process. While we copy the text and pdf files to the shared printer, dfs does not support printers, in this case smb shared printer. The solution has been in place for around 25 years, and it hard to get buy in or show return on investment to replace a product that is still supported, sold today and the replacement will do the exact same thing. Which is to take a text file, reformat to look pretty, add logos, add barcodes and then print, fax and/or email the output. As you can guess it being stateful isn't all that important, either. This system is active - active, so load can be horizontally distributed, just add more machines. This system is super critical for us, has high volumes of jobs run through it at all times and that it is not down. Losing a print job is not important, if it's just brief disruption, as it will be resubmitted.

The only true fix for this would be to use a f5 or netscaler that can do Kerberos proxying or Microsoft let the smb system run under a service type account, which from what I have seen has kernel limitations that makes that a hard change, because it has a lot of shared resources with just machine authentication processes. So just adding the ntlm exception for this has been the most economical solution. Ntlm is not simple to remove from a mature IT environment. You are going to run into these types of edge cases. Thanks again.

[-]

disclosure5@reddit

Many of these "security" products basically just port scan an IP range for an open port 443 and where they find it, logon with given creds. It's the worst kind of password spray and is easily abused to obtain an admin credential.

[-]

BoringLime@reddit

If it a windows machine and you have ntlm disable inbound and the port is secured, auth needed. Normally it's not going to work, as the machines only have spn registered for there hostname and hostname plus domain name. Even iis and SQL server you might have to add to the machine account manually, for the 1433 or 443 ports. So it can't work with a Kerberos request for IP address, doesn't have a ticket for ip and the machine is not setup to allow auth fallback to a non Kerberos auth. We ran into this with our nessus authenticated vulnerability scans. We scan by ip and hostname to cover all our bases. Something that uses local agent is probably better.l in this environment.

You can spn register an IP, it's just not normal operation. Requires some registry settings to use it.

[-]

JewishTomCruise@reddit

Yeah I'm just talking about their "print generating application"

[-]

DrunkMAdmin@reddit

Did you find a workaround for authenticated vulnerability scanning? I'm having similar issues with PDQ Deploy and Inventory.

[-]

spydum@reddit

One option is to Deploy agents, not network scan. Let network scan just be discovery (for your non AD things)

[-]

BoringLime@reddit

We dump all the possible hostnames from a computer account to a text file and have nessus scan the hostnames in the text file. You could automate this with a normal ad user account with no special permission and powershell. By default an ad user account can list out most of the basic information from ad domain, which this case is the name.

I believe we do the same thing with pdq. I don't really work with that product, and the person that does the nessus scans manages it too. So he would have already known about the ip scan issues.

[-]

HunnyPuns@reddit

NTLM is finally dead! I love it! That bitch needed to gtfo decades ago.

[-]

NicJames2378@reddit

Only issue I remember from our migration about 4 years ago was that the NetApp shares all broke. I think we had to run some CLI commands for each SVM to fix it, but I'm not near a PC to access their docs right now to link sources. I just remember it was the one thing I overlooked, and boy did it cause some issues!

[-]

disclosure5@reddit

Entra joined with no on prem really takes out the majority of auth in general - Entra logon never used NTLM, and if you have no on prem you're avoiding the many places this could be a risk.

[-]

MortadellaKing@reddit

Congrats, you probably have a super simple environment if you are only using Entra.

Most people, this is not the case and won't be, probably ever.

[-]

FuckingSteve@reddit

I haven't encountered an org yet where we couldn't do full Entra join and find fixes or workarounds for the stuff that broke.

[-]

gandhinukes@reddit

SQL auth is not supported by entra. No supporting dozens of local accounts isn't an improvement.

[-]

r-NBK@reddit

But you can do Entra ID auth to SQL Server 2019 and newer now.

[-]

Frothyleet@reddit

Works fine in Azure Managed SQL instances :)

[-]

calculatetech@reddit

I'll never understand how implementing a platform that requires fixes and workarounds is somehow acceptable. Not to mention the fact end users hate it. Local AD is here to stay and has been working fine since the 90s. Entra is a solution looking for a problem.

[-]

disclosure5@reddit

In the late 90's everyone worked from an office onsite with the domain controllers. It's a changed world.

[-]

MortadellaKing@reddit

Our ZTNA system ensures users always have line of site to a DC. Same system they have to have running for O365 to function.

[-]

RiceeeChrispies@reddit

Nah mate, users hate Entra Joined machines - because they are massively different /s

[-]

disc0mbobulated@reddit

Not if it's up to management. Wouldn't want those big office buildings with hundreds of cubicles go empty now, would we..

[-]

pdp10@reddit

Local MSAD is now as much legacy as NIS, an IBM mainframe or AS/400. Microsoft has been pushing organizations away from it for a long time, the fact that they'll make money from MSAD for a long time notwithstanding.

Going forward, auth is about roaming, offline-first, and open protocols like OIDC and SAML. Entra is Microsoft's take on that.

[-]

MortadellaKing@reddit

and open protocols like OIDC and SAML. Entra is Microsoft's take on that.

Have you never used ADFS? Which is what entra was built on. Hell 5 or 6 years ago it was practically the same thing. Of course now they just leave on prem customers with no feature development yet still charge us out the ass for licensing.

[-]

calculatetech@reddit

I respectfully disagree with your prediction. AD can SSO to virtually anything, and solutions like FireCloud and zerotier mean there's no such thing as remote. Entra itself is ok, but when you start mixing in the rest of the 365 stack it goes south really fast. AD is 100% still relevant and the more important part is everyone understands it.

[-]

FuckingSteve@reddit

It’s the decades old bullshit that companies needed to move on from 10 years ago that requires the workaround. Entra works great and isn’t the issue.

And sorry, end users hate what?

[-]

MortadellaKing@reddit

We are not in the US so putting our "identity" in the hands of a US based org since the cloud act became a thing is a no go for us.

[-]

RiceeeChrispies@reddit

What are you doing for your end users to notice the difference between Entra Joined and Active Directory machines? It should be transparent.

For deployments I’ve done, the only difference is the login requiring UPN. That’s a one-time thing and users are moving to Windows Hello for Business PIN/Biometrics.

[-]

TheJollyHermit@reddit

Manufacturing, process control, scada, r&d and quality lab systems....

[-]

DestinyForNone@reddit

Laughs in Keyence

[-]

QuantumWarrior@reddit

I think he's just quoting the part of OPs post where they say their environment is Entra joined, no on-prem, no hybrid.

[-]

disclosure5@reddit

That's kind of what I'm getting at - these "Disabling NTLM is actually easy" posts describe very simple environments.

[-]

TheJesusGuy@reddit

and if I'm only on-prem? Lol.

[-]

disclosure5@reddit

You will likely find NTLM harder to disable than you would like.

[-]

tangential-note@reddit

I’ve done this in more than one environment, and there are definitely a few pitfalls to watch out for on endpoint. I’d summarise my experience as follows (With apologies for length)

Audit everything, and if you have any 25H2 clients, use the auditing on those in particular to assess, as the new NTLM events added in the last 6 months (Overview of NTLM auditing enhancements in Windows 11, version 24H2 and Windows Server 2025 - Microsoft Support) are significantly more useful than the old ones.

Blocking NTLM inbound to the endpoints (That is, setting “Network security: Restrict NTLM: Incoming NTLM traffic” to “Deny All Accounts”) has been pain-free in every environment. Inbound authenticated network connections to endpoints are fairly rare, and when they do happen are usually via RPC or SMB, which support Kerberos without issues.

Blocking NTLM outbound (“Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers” -> “Deny All”) from endpoint can be more of an issue depending on what is in your environment. This is a non-exhaustive list of cases we’ve encountered:

1. Access to geriatric NAS devices that do not support Kerberos. Provided access was by name, this can be added as an exception in “Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication”.

2. Legacy apps that don’t support Kerberos. Again you can sometimes add these to the exception list, but some apps do not provide an SPN to the authentication package at all. (An example is any app that calls the .Net NegotiateStream.AuthenticateAsClient method without specifying a targetName). If you have one of these that is still required, you can’t add an exception, and will not be able to apply the block to any device that uses it. (There is no way with the current policy to say “Block NTLM in all cases where an SPN is provided, but still allow it if and only if you have no SPN at all”)

3. Clients that use IP addresses to access resources. There’s a workaround here in that the Kerberos client can be configured to attempt the IP address as an SPN if it is unable to use a hostname. This is done with the TryIPSPN registry key, documented here: Configuring Kerberos for IP Address | Microsoft Learn.

4. As others have said, some remote desktop scenarios are a challenge. The specific issue we’ve encountered is Remote Desktop Gateways, which in their default configuration have a KDC proxy that does not support password authentication. The mstsc client will never use the system Kerberos configuration in this case, and if the KDC proxy fails, will fall back to NTLM. The fix is to enable password authentication for the proxy. The required registry keys can be found in this article from u/SteveSyfuhs: KDC Proxy for Remote Access. Once HttpsClientAuth and DisallowUnprotectedPasswordAuth are set as per that article, NTLM is no longer needed.

A couple of other notes for when you move on to servers:

1. It’s worth applying outbound NTLM blocking on all Tier 0 assets quickly if you possibly can, as it’s rare for them to be needed, and it means the next time someone finds an authentication coercion bug that impacts DCs or similar, it won’t be possible to trigger NTLM.

2. As far as we’ve been able to determine, the Windows app on mac is not capable of Kerberos, so if you have mac clients connecting to RDS you’ll have to allow it on the RDS servers (though if anyone knows a way to get the mac client to do Kerberos that would be really helpful).

[-]

sieb@reddit

2. As far as we’ve been able to determine, the Windows app on mac is not capable of Kerberos, so if you have mac clients connecting to RDS you’ll have to allow it on the RDS servers (though if anyone knows a way to get the mac client to do Kerberos that would be really helpful).

Are you using the Ticket Viewer to request a kerberos ticket in MacOS? I have to do this every day to request a new ticket in order for Remote Desktop Manager to connect to its SQL backend with user auth.

[-]

vane1978@reddit

I could wrong but if NTLM is disabled, you cannot RDP from an Entra id joined computer to a domain-joined computer.

[-]

bfodder@reddit

I could be wrong

You are.

[-]

extremetempz@reddit

You will need to do user@domain.com instead of domain\user

[-]

InfiniteSheepherder1@reddit

We nuked it with the exception of like 2 servers, did this like 5-6 years ago or started with workstations.

Really more found stuff my coworkers failed to setup the spn and kerberos right on. Was not bad though I had bene working on finding a way to kill NTLM as much possible since 2016 or so.

Technically we have it on our remote server with apache quacamole. I paid a bug bounty some years back for full kerberos support in freerdp and waiting on that was the biggest roadblock as I use a Linux Workstation.

[-]

Kuipyr@reddit

They were originally going to have Kerberos support in 1.6.0, but I think there was issues with Hyper-V or something. You can build your own docker image with FreeRDP 3 enabled. I’ve done such and Kerberos auth has been working well.

[-]

InfiniteSheepherder1@reddit

It is on my to-do list I tend to stick to officially supported. Probably will be a new year project to get it working and tested. Would love if it could use our smartcards too but that is a big more work I think. It's not a big risk having it in one spot besides it being permitted for ADCS as it can still have issues without ntlm last I checked.

[-]

Brief_Regular_2053@reddit

You would be surprised how many apps still rely on NTLMv1 to function correctly. We use Solidworks and they only now in their 2026 version no longer require v1.

[-]

pdp10@reddit

I wonder why and how they managed to hardcode that dependency.

[-]

notHooptieJ@reddit

its probably buried in a SQL or powershell change.

we have an LOB app that needs powershell 2 To install, and it was a couple of weeks before they caught up with the 'anything older than 5 is eol as of yesterday' announce.

[-]

itdev2025@reddit

What do you achieve by joining Microsoft Entra ID, instead of housing your own AD on-prem? Delegating auth services and environment management to a third party cloud platform does not seem like a good idea, especially for critical services.

[-]

FrecciaRosa@reddit

It completely torpedoed some older scanners. And when I say “scanners” I mean “stand-up MFCs”, big units from Ricoh that we primarily use for scanning blueprints and occasionally trying to print and discovering that the print heads are clogged and then giving up. So … yay?

[-]

rosseloh@reddit

Reviewing past 30 days of logs shows NTLM being used on those 10 workstations only.

I enabled those logs, got overwhelmed by how much crap was using it, got distracted by 30 other projects, and haven't touched it for 2 years.

Yay.

[-]

pdp10@reddit

Maybe you'll get lucky and the current logs will be much smaller.

[-]

Biohive@reddit

Same

[-]

Independent_Yak_6273@reddit

I have it disabled it on WKS and Servers but not Domain Controllers

Set LAN Manager authentication level to 'Send NTLMv2 response only. Refuse LM & NTLM'

[-]

Aznflipfoo@reddit

Why would you disable NTLM?

[-]

Kuipyr@reddit

Microsoft has deprecated it, NTLMv1 was nuked from 24H2 and we can assume NTLMv2 will follow soon.

[-]

Mogster2K@reddit

What's wrong with v2?

[-]

SnakeOriginal@reddit

Everything

[-]

Emiroda@reddit

to slow down ONE method of lateral movement.

sniff a hash and you've got the password: https://ntlm.pw

[-]

FuckingSteve@reddit

It’s a huge security risk leaving it enabled, for one.

[-]

Pub1ius@reddit

Discovered that RDP from my admin workstation to servers randomly fails via Kerberos, but that's probably a misconfiguration somewhere on my end.

[-]

randomugh1@reddit

Failover cluster manager VM Console and configuring cluster aware updating needs NTLM

[-]

randomugh1@reddit

I’ll also add anything that uses a plain hostname breaks; you have to use fqdn everywhere (this is the main problem with FCM). Even adding a host to Hyper-V console requires a FQDN. Interesting side note, when you forget to use the fqdn when adding a host to Hyper-V Management console you have to remove the host and close and re-launch the console before the FQDN will start working.

Also, no more \host\share, that breaks when NTLM is disabled (or when your account is added to the Protected Users group in AD). When troubleshooting you’ll try \ip\share and it will work and then you’ll remember to use \host.domain\share

[-]

ajf8729@reddit

This doesn’t make any sense. Short name should work as all computers have a default HOST/shortname SPN registered. And using IP while in Protected Users shouldn’t work since that cannot use Kerberos.

[-]

randomugh1@reddit

You’re right, the ip address doesn’t work, but with my Protected Users admin account I just tried \host\c$ and it failed but \host.domain\c$ works.

[-]

ajf8729@reddit

Does running “klist get HOST/shortname” get you a service ticket?

[-]

bionic80@reddit

standalone DFS namespaces break.... and if you use a standalone DFS namespace in 2026 you should be taken out back and flogged with a parallel printer cable.

[-]

poncewattle@reddit

I don't get that. Why can't it just append the .domain to the hostname if it fails NTLM resoultion and try again?

[-]

poncewattle@reddit

Are you sure about that? Or am I missing some nuance?

https://learn.microsoft.com/en-us/windows-server/get-started/whats-new-in-windows-server-2019

That article claims that changed in 2019 server.

[-]

randomugh1@reddit

The failover cluster itself works fine without NTLM, but if it’s a Hyper-V cluster you can’t open a vm’s console from FCM because it launches referencing the node’s plain host name. That’s also what happens if you try to configure CAU via FCM.

[-]

ccsrpsw@reddit

2 biggest ones:

Older Windows machines that you didnt know were out there. You probably think you know them all. But there are those ones hidden away somewhere "that do really important things" (at least according to the business) and suddenly cant access "that one important file". Hint: they need to upgrade or use some other way to access the network data. Hold firm!
Some non-Windows devices (usually embeded OSes) that use NTLM for some reason (usually C&C systems). Not a big deal as they can usually be configured back to NFS and you can create some form of relay.

[-]

Unable-Entrance3110@reddit

RDP as well as SMB access to certain shares over VPNs without direct LoS to domain controllers is where we have had to add exceptions.

[-]

HumbleSpend8716@reddit

enable ntlm auditing on ur dcs and wait 2 weeks, you will quickly understand the blast radius

if you don’t do this youll fuck your org

[-]

JKL213@reddit

Yeah I had it on and was surprised by the amount of NAS devices one of our office had running.

[-]

collinsl02@reddit

At least 2 weeks. If possible try and do a month in case of any month end activities. The gold plated standard would be across calendar year end and financial year end too but often that's not possible.

[-]

Significant_Sky_4443@reddit

RemindMe! -18 day

[-]

Significant_Sky_4443@reddit

I have found some Veeam Server problems in the auditing logs anyone too?

[-]

NoPossibility4178@reddit

If you do WMI monitoring, probably gonna break that.

[-]

Jezbod@reddit

Remote access app (RealVNC) now need domain-name\username to logon to remote PC / laptop.

Used by users to connect to PCs with legacy software, soon to be nuked when the relevant legacy system goes "in to the cloud" and is all web based.

I'm in a hybrid system.

[-]

laddixvs@reddit

Auditing on ntlm on DC on writing a report why its not possible because x app

[-]

jdptechnc@reddit

Being taken over by a larger IT department that forces usage of NTLM.

[-]

Leather-You47@reddit

what logs are you reviewing?

[-]

TheJesusGuy@reddit

Nah. Not doing that.

[-]

QuantumWarrior@reddit

RDS took some tweaks like adding DNS suffixes and a bit of user training on using their full domain username, but that's because we had Entra-only machines and Domain-joined RDS servers and it's easy for that connection to fall back to NTLM (e.g if you don't use domain\username format, or if you try to use the machine IP or any hostname that isn't the FQDN).

Your environment sounds well suited for it if legacy apps are already being targeted. We have a similar environment and it went pretty smoothly.

[-]

Zer0Trust1ssues@reddit

The NPS service cannot be started or restarted when ntlm is deactivated.

[-]

Maximum-Instruction2@reddit

We have a few apps that rely on NTLM so we ended up moving to NTLMv2. as we're stuck with it for now but atleast the v2 has better security, not perfect, still vulnerable, but better than before until we can fully phase it out.

[-]

Leather-Tour-7288@reddit

No more access to our smb shares that were mounted with an IP instead of fqdn.

[-]

Full-Contribution931@reddit

Defender for Identity used it for NNR…so tough to deprecate it if you rely on it for NNR.

https://learn.microsoft.com/en-us/defender-for-identity/nnr-policy

[-]

JustinHoMi@reddit

Had zero issues here.

[-]

schporto@reddit

Dfsr management console. Random NAS we have to allow to be used. Print servers, but that's just effort to work through. Rdp to ip addresses.

[-]

xxdcmast@reddit

I think DFS-n management as well.

[-]

pokebud@reddit

On prem small businesses still using server 2016 essentials as a file server might have an issue. I remember there was a thing a while back where if the connector software was uninstalled it would throw an NTLM error.

Generally they keep these around to bypass old copy machines that don’t support cloud integration. They scan to a folder linked to one drive on the server.

[-]

davy_crockett_slayer@reddit

Honestly, nothing. I’ve done it.

[-]

Infninfn@reddit

Aside from old apps with networking elements, you will want to check NAS and printer shares. You may not have any old Windows servers but the appliances will be running Samba for shares and it was rare for any of the vendors to make kerberos the default protocol. Also applies to any other Windows authenticated connections to Linux machines.

[-]