FAQ and troubleshooting information about NTLM/NTLMv2

The Support NTLMv2 (Experimental) option lets LDAP Broker validate PEAP-MSCHAPv2 credentials when Active Directory allows only NTLMv2. During MSCHAPv2 authentication, the client always creates its challenge response using the NTLMv1 algorithm. You can’t change this on the client.

By default, LDAP Broker validates this response using the Windows LsaLogonUser API. If Active Directory allows only NTLMv2, this validation fails. When you enable the option, LDAP Broker reads the user’s password hash from Active Directory instead. It calculates the expected response itself and compares it with the response from the client.

The option does not force LDAP Broker to use NTLMv2, and it does not change how LDAP Broker connects to Active Directory. It also does not increase authentication security.

Enable it only if both of the following are true:

• You use PEAP-MSCHAPv2 for credential-based 802.1X authentication.
• Active Directory allows only NTLMv2.

If you don’t use PEAP-MSCHAPv2, the option has no effect. Certificate-based authentication (EAP-TLS) does not use it.

To read password hashes, the LDAP Broker service account needs one of the following: membership in the Domain Admins security group, or the DS-Replication-Get-Changes and DS-Replication-Get-Changes-All permissions. Both options grant sensitive Active Directory privileges. Review them with your AD security team before you enable the option.

Without these permissions, PEAP-MSCHAPv2 authentication fails when the option is enabled.

With the option enabled, LDAP Broker reads password hashes from Active Directory to validate PEAP-MSCHAPv2 credentials. This requires permissions that the default configuration does not need.

To troubleshoot:

• Verify that you use PEAP-MSCHAPv2 and that Active Directory allows only NTLMv2. If not, disable the option.

• Verify that the service account is a member of the Domain Admins group or has the DS-Replication-Get-Changes and DS-Replication-Get-Changes-All permissions delegated to it.

The Active status only confirms that LDAP Broker can retrieve its configuration from Portnox Cloud, establish relay communication, and communicate with the configured LDAP directory. The Active status does not verify that the service account has the permissions required by the Support NTLMv2 (Experimental) option.

To troubleshoot:

• Verify that you need the Support NTLMv2 (Experimental) option. Certificate-based authentication deployments do not need it.

• Verify that the service account is a member of the Domain Admins group or has the DS-Replication-Get-Changes and DS-Replication-Get-Changes-All permissions delegated to it.

• Review the LDAP Broker logs for authentication, permission, or LDAP-related errors. For more information, see the following topic: Where to find the LDAP Broker logs and status.

The Support NTLMv2 (Experimental) option is not the cause of this issue. EAP-TLS authentication does not use NTLM. During EAP-TLS authentication, LDAP Broker only queries LDAP to verify that the account exists.

To troubleshoot:

• Verify that the client certificate is present on the device, valid, and issued by a trusted certificate authority.

• Verify that the account referenced by the certificate in the Subject and/or SAN fields exists in the integrated Active Directory.

• Verify that LDAP Broker can communicate with the configured LDAP servers to verify that the account exists. For more information, see the following topic: How to check if the LDAP Broker connects to the LDAP server.

• Verify that LDAP Broker can communicate with Portnox Cloud. For more information, see the following topic: How to check if the LDAP Broker connects to the cloud.

• Review the LDAP Broker logs for LDAP lookup or directory connectivity errors. For more information, see the following topic: Where to find the LDAP Broker logs and status.