Qualys IP-based scanning: Kerberos after reverse DNS, and impact of NTLM deprecation.

Question

Qualys IP-based scanning: Kerberos after reverse DNS, and impact of NTLM deprecation.

Nazim Shaikh 20

While evaluating NTLM deprecation for our environment, have a question regarding Qualys authenticated scanning.

Our Qualys Scanner Appliance is not domain-joined, while the scan targets are domain-joined Windows Server 2016/2019/2022/2025 systems. The Qualys Windows authentication record has Kerberos and NTLMv2 configured.

Currently, our scan targets are defined using IP addresses.

During testing, we observed that Qualys performs reverse DNS/PTR lookup for the IP and obtains the target's FQDN. When the PTR and required SPNs are available, authentication succeeds using Kerberos. When the reverse DNS/PTR or required SPN is missing, we observe NTLM in enhanced NTLM logging.

This raises a few questions:

If NTLM is disabled, will the IP → PTR → FQDN → Kerberos flow continue to work, or can the initial IP-based target cause authentication to fail?

Should we configure Qualys targets using FQDN instead of IP addresses to ensure Kerberos authentication and avoid NTLM fallback?

For large scans (e.g., ~1,000 servers), does using FQDN directly provide any performance benefit by avoiding the reverse DNS/canonicalization step?

Is there any Qualys-specific guidance or Microsoft recommendation for IP-based authenticated scanning when NTLM is disabled?

Any documentation or real-world experience with Qualys + Kerberos + NTLM deprecation would be appreciated.

Environment: Windows Server 2016/2019/2022/2025 | Qualys Scanner Appliance | Kerberos + NTLMv2 authentication.

0 comments

1 answer

Your answer

Answer 1

Hello Nazim,

Thank you for posting question on Microsoft Windows Forum!

The following are the plausible explanation to your query of NTLM deprecation.

If NTLM is disabled, the IP-to-PTR-to-FQDN flow will continue to work, provided that reverse DNS (PTR records) is 100% accurate, healthy, and accessible from the scanner appliance network. Qualys uses the resolved FQDN to request a Kerberos service ticket (host/fqdn) from the Active Directory Domain Controller. Please note: If a PTR record is missing, misconfigured, or slow to respond, Qualys cannot map the target IP to an FQDN, which prevents Kerberos ticket acquisition and results in authentication failure once NTLM is fully disabled.

Configuring your Qualys scan targets and Windows authentication records using FQDNs instead of raw IP addresses is strongly recommended for NTLM deprecation readiness. It aligns with how Kerberos is designed to work and eliminates the dependency on reverse DNS and the PTR lookup step. When you target server01.corp.local, Qualys can directly construct the SPN HOST/server01.corp.local and attempt Kerberos authentication without needing to resolve an IP first. This ensures Kerberos is used whenever possible and NTLM is not needed as a fallback.

Regarding the guidance on NTLM deprecation which emphasizes eliminating hardcoded IP addresses in favor of hostnames and FQDNs to ensure applications utilize the Negotiate security package (which defaults to Kerberos) rather than falling back to NTLM. On the other hand, Qualys documentation similarly specifies that Active Directory-integrated Windows authentication records handle target canonicalization much more cleanly when assets are mapped via domain names or FQDNs. For more information https://techcommunity.microsoft.com/blog/windows-itpro-blog/retiring-ntlm-frequently-asked-questions/4550522

Hope the above information is helpful! If it is. Free feel to hit "Accepted" for benefitting others in community having the same query too.