Get access to immediate incident response assistance.
Eliminate active threats with 24/7 threat detection, investigation, and response.
Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.
Advance your cybersecurity program and get expert guidance where you need it most.
Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.
Prevent unauthorized access and exceed compliance requirements.
Stop email threats others miss and secure your organization against the #1 ransomware attack vector.
Prepare for the inevitable with 24/7 global breach response in-region and available on-site.
Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.
There are two main methods of dealing with this issue. The first is to try adding the parameter "NP[1]" to whatever other authenticat.exe parameters are in use. This will cause authenticat.exe to only try to authenticat whichever IP is deemed the primary IP by Windows - in general, this should usually be the workstation's main network connection.
The second method is to add (or modify) the RR[x] parameter. This parameter sets the delay between attempts to re-connect to the virtual IP after a connection attempt fails. This parameter is measured in milliseconds. The default value is 30000, which equates to 30 seconds. The parameter can accept a value up to 4 billion, which should easily prevent authenticat.exe from making more than one error per login session from the NICs which cannot reach the virtual IP.
To contact Trustwave about this article or to request support: