0

We have a situation where a software application cannot be installed because the admin account used during installation gets locked out during prerequisite checks. After some investigation, we found the cause: The prerequisite check looks at remote registry settings of other servers by RPC call to the server's IP address rather than its FQDN, and for some reason this causes authentication to fail and lock out the account.

We validated this by doing the following:

  • When using regedit and attempting to connect to another AD server's registry using the server's FQDN, it connects without issue.
  • When we attempt the same connection using the server's IP address, it prompts for new credentials.
  • All AD credentials will fail and eventually lockout the account being used, but using a Local Admin account has no problems.

We performed this test from other servers in the environment as well, but they had no issues with connecting and authenticating by IP. We compared NIC/DNS/WINS settings, but there was no notable difference. We're at the point of cross-checking GPO settings, but we don't expect to find anything.

We could obviously just use Local Admin accounts, but we want to understand why an RPC call using an IP address rather than the FQDN causes AD authentication to fail and lock out AD accounts. Any ideas?

Kyle C
  • 3
  • 2
  • 2
    Likely kerberos; you can't use kerberos authentication with IP addresses, as there are really only hostnames or FQDNs in Kerberos Service Principal Names. That's my guess - the account lockout issue seems to point elsewhere. – Semicolon Jan 14 '21 at 03:59

1 Answers1

0

If it locks the account out, you're definitely having a password problem. Otherwise it may be because Kerberos won't be used and NTLM is disabled or something. You need to check the Security Log of the source and target server and provide any log entry that may be related to the authentication issue.

You can also try this. However, changing things when you don't even know the reason why something doesn't work isn't very efficient and may break other things.

Beginning with Windows 10 version 1507 and Windows Server 2016, Kerberos clients can be configured to support IPv4 and IPv6 hostnames in SPNs.

By default Windows will not attempt Kerberos authentication for a host if the hostname is an IP address. It will fall back to other enabled authentication protocols like NTLM. However, applications are sometimes hardcoded to use IP addresses which means the application will fall back to NTLM and not use Kerberos. This can cause compatibility issues as environments move to disable NTLM.

To reduce the impact of disabling NTLM a new capability was introduced that lets administrators use IP addresses as hostnames in Service Principal Names.

Read more at

https://docs.microsoft.com/en-us/windows-server/security/kerberos/configuring-kerberos-over-ip

Daniel
  • 6,780
  • 5
  • 31
  • 60
  • 1
    Thank you. I ended up resolving this by doing cross-comparisons of GPO settings, but this was very much the reason. AD servers had a network security GPO set to "Accept NTLMv2, reject LM and NTLM" while the server running the application was not set at all. This resulted in LM requests getting sent and rejected by the AD server, which counts against the failed login attempts leading to lockout. – Kyle C Mar 09 '21 at 22:18