MicrosoftI enumerated the definite and possible uses of NTLM Auth on our network. These won't show up on your data-driven approach (mostly) unless you push the data collector out to older windows versions.
1) We depend on the fact that two local accounts with the same username and password authenticate as the same account across workstations on the domain. This was done on purpose to reduce attack surface area by eliminating domain accounts with non-expiring passwords as much as possible. Creating the local accounts where they're needed is a reduced-privilege model.
2) When connecting between machines with RDP we depend on .\username resolving on the remote machine without knowing its name. The saved username by RDP says it's the local machine name but somehow it works. Should be fixable on your side because the remote hostname is passed back to RDP. The production servers are *not* domain joined. This isn't a mistake, and won't be changed. (They're more hardened than the domain controller.)
3) There's a highly isolated XP box in manufacturing (because the drivers for the hardware it controls) that remains network joined solely so it can talk to the network printer. Network disks don't work anymore due to no SMB protocol version in common, and this isn't a problem. It's possible its domain binding has fallen back to NTLM long ago due to no TLS version in common with the domain controller.
