- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
17m ago - edited 15m ago
Microsoft has been phasing out NTLM. It is an older challenge-response authentication protocol, and Microsoft is steadily restricting it by default, starting with the weakest variants. For most organizations, this won't be a single switch-off day. It will be a gradual tightening, where environments that quietly depend on NTLM start failing one setting at a time. Think of NTLM like that old family WhatsApp group: nobody wants to admit they still use it, but everyone is still in it.
Why should you care about Discovery?
For ServiceNow Discovery, this matters a lot. Discovery reaches Windows hosts through WMI, WinRM, and related protocols. By default, when you configure Discovery schedules with IP ranges, it authenticates against each IP using the relevant Windows credentials. If NTLM is still enabled in your environment, everything works as usual. But once NTLM is disabled and authentication falls back to Kerberos, Discovery can fail. Discovery also doesn't send a polite email before it breaks. It fails quietly, like a dishwasher that stops mid-cycle and says nothing.
The good news is that there is a fix. Many Discovery deployments were built around credentials that worked with NTLM and were never reviewed afterward. Service accounts often have no Kerberos Service Principal Names. Discovery also covers large estates, so one policy change can affect thousands of CIs in a single scheduled run.
What to do now?
Start with visibility, not configuration. Enable NTLM auditing on your servers so you can see which hosts and accounts still authenticate with NTLM. The NTLM operational log (events 8001 to 8004) shows where NTLM is in use. Use that data to set priorities instead of guessing which MID Servers or credentials are affected.
Next, move Windows Discovery toward Kerberos wherever your environment allows it. Confirm that each Discovery service account has correct SPNs and that the MID Server host is healthy in the domain. When we relied on NTLM, Discovery worked fine with IP addresses. With Kerberos, the IP must resolve to an FQDN, so update the MID Server configuration parameters as follows:
If you use WMI (port 135 and the DCOM range), set this to true: mid.powershell_api.wmi.use_reverse_dns_lookup (Use FQDN for IP in WMI. Default: false.)
If you use WinRM (port 5985/5986), confirm this is set to true: mid.powershell_api.winrm.use_reverse_dns_lookup (Use FQDN when the IP is not in the WinRM TrustedHosts list. Default: true.)
Apply these changes in a test environment first. Run a targeted Discovery scan against a known set of Windows hosts and confirm the results before rolling out to production. Your Discovery may be fine, but test before you assume.
Don't wait for the failures
Teams that treat NTLM deprecation as a future problem end up spending their time on incident triage instead of planned change. A short assessment now, covering audit data, service account review, MID Server configuration, and a test scan, will prevent most Discovery roadblocks when clients disable NTLM.
If your organization is already planning Discovery work for next quarter, add an NTLM readiness check to the plan. It is much cheaper to find the dependency now than during a production outage.
Helpful resources:
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1116898
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1156845
