I have seen various different questions for this problem floating around but either the circumstances arent the same or the solution doesnt work so thought i would post it to see if anybody has any suggestions.

Various domain PCs and laptops appear to randomly give the connection name of "lewis.local 2(Unauthenticated)" - lewis.local being our domain - and provides an exclamation mark where the network type logo is normally shown.

This also appears to happen every time connecting via vpn.

Our setup is:

  • 2 servers both running windows server 2003 R2 (x32)
  • main server has AD, DNS and DHCP installed
  • IPv4 on approx 30 client machines (some wired, some wireless)

If anybody has any thoughts on solutions i would appreciate it. I have tried removing all but AD server roles, resetting all of the systems and nothing.

It doesnt prevent anything from working just like a domain connection most of the time however it is getting fustrating!

Also dont know if it could have anything to do with it but the DHCP server seems to have quite a long lead time on issuing the IP address to the client.

  • Needs more details. I'm thinking most notably about the Event Logs and the solutions that "didn't work." (Oh, and it's not the client's Windows Firewall profile changing from domain to public when connecting over the VPN, is it?) – HopelessN00b Jul 31 '12 at 21:16
  • the solutions i have tried are rejoining from the domain (worked for a while but not long term), reset dns/dhcp and running these commands: netsh winsock reset catalog, netsh int ipv4 reset reset.log, netsh int ipv6 reset teset.log – gareth89 Jul 31 '12 at 21:29
  • I found that the time was different between DC's by about 10mins correcting the time corrected the issue. – Buffycs Jun 17 '15 at 10:24

One possible reason for this issue is when the machine account password gets out of sync with the domain controller.

This can happen, for example, if the computer account in Active Directory is manually removed and re-added, or if the client machine has been restored to an earlier point in time (machine account passwords are automatically changed every 30 days).

What worked for me was to reset the machine account password manually by executing Reset-ComputerMachinePassword in an elevated(!) PowerShell:

PS> Reset-ComputerMachinePassword -Credential MYDOMAIN\SomeDomainAdminAccount

After rebooting (or disabling and re-enabling the network card, if you don't want to reboot), the (unauthenticated) note should be gone.

  • This did not work for me, throws an error saying it can not be done. – htm11h Feb 7 '18 at 17:44
  • 1
    This did work for me, and did not actually require a reboot: I disabled and re-enabled the network card. – Daniel K Mar 7 '18 at 11:09
  • @DanielK: Thanks, I can confirm that disabling/re-enabling the NIC is enough. I have added that information to my answer. – Heinzi Aug 21 '19 at 12:44
  • 1
    This worked for me immediately after typing the command, without even needing to disable and re-enable the NIC! Win10 1809. – Dan Henderson Aug 28 '20 at 14:02
  • 1
    This worked for me. Thank you @Heinzi – teknix Dec 5 '20 at 19:10

Run these commands on each computer with the problem:

netsh winsock reset catalog

netsh int ipv4 reset reset.log

netsh int ipv6 reset reset.log 

Restart the PC then rejoin the computer to the domain.

  • I'm facing the same problem, and this doesn't solve it. – Wouter Sep 24 '15 at 13:44
  • This solved it temporarily for me. – JukEboX Mar 19 '20 at 13:00

Just remove the TLD from domain name and reboot, it will add it back after the reboot and all should be good.No fuss, no muss

ex: company.local remove the local and reboot, it will be added back after the reboot

  • +1 This worked immediately for me (rename via system properties sysdm.cpl), before the required reboot even. Interesting that you can re-join a domain in this fashion. For me, "(Unauthenticated)" appeared after a system restore. – Christopher Galpin Sep 23 '17 at 2:58

I had the same problem and it turned out to be that a firewall between the pc and the DC was blocking 135,389, etc back to the pc.

To find that problem I ran Wireshark on the pc and did a gpupdate /force. In wireshark I saw a bunch of syn packets going out to the DC with no response.

Once the firewall was fixed, we rebooted the pc and it was able to contact the DC properly and the problem was solved.


Sounds like something messed up the trust between the computer and the domain. You should try removing the computer from the domain, and readding it.

It's hard to say why this happened. Are there any error messages in the event logs on the DC now or around the time this started occurring? Were any network changes made?

  • i have tried rejoining and it appears to sometimes fix it short term and sometimes not at all. There are no errors in the log on the DC which is part of the oddness of it – gareth89 Jul 31 '12 at 21:41
  • @gareth89 What do the client Event Logs say? They'll probably be more useful, since this is an issue the client's seeing, that the DC may not be. – HopelessN00b Aug 1 '12 at 0:03

A couple potential solutions:

  1. Check your DHCP leases and reservations on your DC. If you've got multiple entries for the offending machines, pare it down to one entry each. Then run ipconfig /release && ipconfig /renew on those machines.
  2. Remove the network adapters from Device Manager, then Scan for new hardware to re-install the NICs.
  3. Restore your Windows Firewall Profiles to defaults: Run wf.msc and click "Restore Default Policy"
  4. Disable any and all firewalls completely. For Windows Firewall, run wf.msc then click "Windows Firewall Properties" and set the Firewall state to "Off" for each profile tab (Domain, Private, Public).

The last option isn't really a fix, but it may help troubleshoot the issue.


Maybe this will help someone along the way. I had this issue and the reason was there was a VLAN mismatch on a Riverbed Steelhead appliance. The In-Path interface on the Riverbed connected to the LAN port of the router, and the In-Path interface was configured for "VLAN Tag ID" of "0". This caused the issue. The router LAN interface is in a subinterface configuration (one for voice VLAN 40, and one for data/native VLAN 1), I was able to resolve this issue by assigning the VLAN Tag ID to "1" (data/native) and the issue resolved immediately.

  • 1
    Can you expand on how this could possibly be related to the symptoms described in the question? – womble Oct 26 '19 at 0:23

I had the same problem, I accidentally deleted the server computer from the domain controller and all client computers were unable to read the server, and network discovery option was no longer working on the server, but I tried removing the .local and rebooted the server hence rejoined the domain and it worked for me but otherwise I was stuck


For me nothing worked.

The laptop could connect to any other WiFi station, but not the company's. So after checking that the DHCP leases weren't duplicated, re-joining the laptop, running lots of commands, the following fixed the problem.

Then I went to the WiFi settings on the router and changed from AUTO to LONG GUARD. It fixed the issue straight away.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.