Hello Syed Ishmam Ahmad,
The behavior you are describing points to an authentication mismatch between the affected clients and the wireless infrastructure. Since other users connect seamlessly with their AD credentials, the issue is not with the Wi-Fi itself but with how those specific machines are handling 802.1X authentication.
The first thing to verify is the wireless profile configuration on the affected laptops. Go into Settings > Network & Internet > Wi-Fi > Manage known networks, select your corporate SSID, and check the security settings. For enterprise Wi-Fi, the profile should be set to WPA2-Enterprise or WPA3-Enterprise with Microsoft: Protected EAP (PEAP) as the authentication method. Inside PEAP settings, “Validate server certificate” should be enabled and the correct root CA certificate installed. If the certificate is missing or the wrong EAP type is selected, Windows will prompt repeatedly for credentials and fail with “incorrect credentials.”
Next, confirm that the affected users have valid Kerberos tickets and can authenticate against the domain. Run klist in a command prompt after logging in. If no tickets are present, the machine may not be properly joined to the domain or the user profile is corrupted. In that case, rejoin the machine to the domain (netdom reset or remove/re-add to domain) and test again.
Another common cause is cached credentials interfering with wireless authentication. On the affected laptops, clear stored credentials with cmdkey /list and delete any entries for the Wi-Fi SSID. Then delete the wireless profile entirely using netsh wlan delete profile name="<SSID>" and recreate it fresh.
If the prompt persists, check Group Policy. Many organizations push Wi-Fi profiles via GPO under Computer Configuration > Windows Settings > Security Settings > Wireless Network (IEEE 802.11) Policies. If the affected machines are not receiving the correct policy, they will fall back to manual credential prompts. Run gpresult /h report.html and confirm the wireless policy is applied.
Finally, ensure the system clock is synchronized. Kerberos authentication is time-sensitive, and if the client clock drifts more than 5 minutes from the domain controller, authentication will fail even with correct credentials.
In short, the issue is almost certainly tied to either a misconfigured wireless profile, missing root CA certificate, cached credentials, or domain trust problems on those specific machines. Rebuilding the wireless profile with the correct EAP settings and confirming domain membership usually resolves it.
I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!
Domic Vo.