18

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.

3
  • 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?) Jul 31, 2012 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, 2012 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, 2015 at 10:24

12 Answers 12

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.

5
  • This did not work for me, throws an error saying it can not be done.
    – htm11h
    Feb 7, 2018 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, 2018 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, 2019 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. Aug 28, 2020 at 14:02
  • 1
    This worked for me. Thank you @Heinzi
    – teknix
    Dec 5, 2020 at 19:10
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.

2
  • I'm facing the same problem, and this doesn't solve it.
    – Wouter
    Sep 24, 2015 at 13:44
  • This solved it temporarily for me.
    – JukEboX
    Mar 19, 2020 at 13:00
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

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. Sep 23, 2017 at 2: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.

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?

2
  • 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, 2012 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. Aug 1, 2012 at 0: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.

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.

2
  • 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, 2021 at 4: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! Jul 15, 2021 at 14:41
1

I had this happen to a customer today and none of the above fixed the issue.

It turns out some November 2022 patches were the culprit. To fix the issue, I first followed the instructions on this blog: https://dirteam.com/sander/2022/11/09/knowledgebase-you-experience-errors-with-event-id-42-and-source-kdcsvc-on-domain-controllers/

i.e., I did these steps:

Step 1: If the Active Directory Domain Functional Level (DFL) is set to Windows Server 2003, upgrade it to Windows Server 2008, or up. In the process, the password for the krbtgt account is reset, so do not reset the password for the krbtgt account as part of step 2 (within a week’s time span). Skip to step 3.

Step 2: To reset the password for the krbtgt account, use Microsoft’s New-KrbtgtKeys.ps1 PowerShell script from Github and run it on the Domain Controller holding the Primary Domain Controller Emulator (PDCE) Flexible Single Master Operations (FSMO) role.

Step 3: Configure the affected user object(s) to no longer explicitly use RC4_HMAC_MD5.

When people sign out and sign in again after they’ve changed their passwords, their session keys will be AES encrypted and no longer be vulnerable in the context of CVE-2022-37966. When RC4 is needed for the account, turn to Step 3 of the below alternative method.

Step 4: Optionally, when no new errors with event ID 42 occur, configure the Network Security: Configure encryption types allowed for Kerberos setting in a Group Policy object targeting the domain to explicitly disable the DES_CBC_CRC, DES_CBC_MD5 and RC4_HMAC_MD5 encryption types and explicitly enable the AES128_HMAC_SHA1, AES256_HMAC_SHA1 and Future encryption types.


Next, I rotated the computer account password on the affected member server/system(s):

Reset-ComputerMachinePassword -Credential MYDOMAIN\SomeDomainAdminAccount

Finally, I installed one of the following updates on the domain controllers, depending on the version of Windows Server:

Source: https://learn.microsoft.com/en-us/windows/release-health/status-windows-server-2022#november-2022

According to the doc linked above, installing the above updates on member servers/systems is not necessary. I can confirm that I did not need to do so to resolve the issue in this environment.

Once all of the above was done, disabling and re-enabling the NIC (or rebooting) the affected member server/system(s) did the trick.

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.

1
  • 2
    Can you expand on how this could possibly be related to the symptoms described in the question?
    – womble
    Oct 26, 2019 at 0:23
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.

-2

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .