15

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.

gareth89
  • 161
  • 1
  • 1
  • 5
  • 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

11 Answers11

18

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.

Heinzi
  • 2,138
  • 5
  • 30
  • 51
5

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.

Jose Ortega
  • 51
  • 1
  • 2
2

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

rickyttt
  • 21
  • 1
  • +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 02:58
2

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.

Andrew Schulman
  • 8,561
  • 21
  • 31
  • 47
Greg
  • 21
  • 1
1

I just had this issue and found this on a google search. Nothing here fixed my problem, but I discovered the workstation service was not started for some reason. I started it, released and renewed the IP and all was well.

  • please dont past only 2 lines, show us the COMPLETE way. the Answer seems to be great, but the WAY is missing! .-) – djdomi Jul 15 '21 at 04:54
  • @djdomi The most basic stuff probably doesn't need a detailed explanation. I'm a Linux admin and even I know how to use services.msc! – Michael Hampton Jul 15 '21 at 14:41
1

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?

justin0
  • 551
  • 3
  • 7
  • 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 01 '12 at 00:03
1

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.

sippybear
  • 2,997
  • 1
  • 12
  • 12
0

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

0

I know old thread but nothing above worked. The problem started after we replaced the Cisco switch with a HP one. Setting IPv4 static worked for a while but going back to DHCP failed etc. Unable to disjoin and join. "The selected server was unable to perform requested operation" USB WIFI worked a treat but not the long term solution but that gave me a clue that it must be something with this particular Intel Card on several PCs in the office. What worked is changing the Network Card settings: Jumbo Packets: Disabled (was set previously to 9024) Large Send Offload V2 (IPv4) and also (IPv6): Disabled Now the connection to the network shares and Exchange server worked perfectly fine.

Dave M
  • 4,494
  • 21
  • 30
  • 30
Peter
  • 1
0

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.

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

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.

Cory Knutson
  • 1,866
  • 12
  • 20