Configuring 802.1x Authentication for Windows Deployment – Tips and Tricks

This is the Tips and Tricks section of my Configuring 802.1x Authentication for Windows Deployment series. Be sure to check out all of the other parts here.

These are just some random things I found while going through this.

File and Registry Locations

Profiles
C:\ProgramData\Microsoft\dot3svc\Profiles
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\dot3svc

Policies
C:\Windows\dot3svc\Policies*.TMP (rename TMP to XML to see the Policy and Profile)
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WiredL2\GP_Policy

Migration Data
C:\ProgramData\Microsoft\dot3svc\MigrationData
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\dot3svc\MigrationData

Quickly Remove 802.1x Group Policy for Testing

  1. Rename the .TMP file located in C:\Windows\dot3svc\Policies to .OLD.
  2. Restart the Wired Autoconfig (dot3svc) service

That’s it. You should be able to configure a local 802.1x Authentication Policy. Reverse steps to re-apply GPO.

Use the Event Viewer

The Windows Event Viewer has a Wired-AutoConfig log buried in the logs. Take a look at it as you restart dot3svc and you can see the policy or profile get applied and trigger client authentication. It can be found under Applications and Services Logs > Microsoft > Windows > Wired-AutoConfig.

Windows 7 Has a Bug!

While this doesn’t appear to affect all of the items I’ve covered on 802.1x for OSD, I found a Windows 7 hotfix that fixes an issue where our clients will attempt to authenticate with the local 802.1x profile first, then attempt the Group Policy profile (local is user, GPO is computer) and the machines will get locked out. You can see the events in the Wired-AutoConfig event log to verify. The issue appears to go away in Windows 10 1709.
KB2481614 – the description doesn’t fully match what we are seeing, but it certainly fixes the issue.

Random Things

  • If you apply a local profile during OSD, that profile will stay on the computer. If the computer ever loses it’s Group Policy, the LAN interface will revert to the previous profile. If you used a user authentication profile and embedded credentials in it, you run the risk of locking the account if the password has changed.
  • Post-Upgrade, the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\dot3svc\MigrationData registry key will have a value of dot3svcMigrationDone = 1 if the 802.1x migration has been complete. If the key is missing but the MigrationData folder and registry keys exist, restart dot3svc. The key should appear and the previous GPO or profile will be applied to your LAN interfaces.

You Might Also Like

2 Comments

  • Reply
    Cristopher
    August 9, 2018 at 8:01 am

    “If you apply a local profile during OSD, that profile will stay on the computer.” Will deleting C:\Windows\dot3svc\Policies*.TMP at the end of the Task Sequence permanently remove the local profile? I really can’t have computers reverting to this if they lose Group Policy.

    • Reply
      Adam Gross
      August 9, 2018 at 1:41 pm

      No. That will delete the GPO and revert to the local profile. The trick is to make them match so that you never revert to an unsupported profile apparently. If you delete the local profile, you will get a default profile applied then GPO will override that, unless GPO is removed. There’s no way to NOT have a local profile as far as I can tell.

    Comment

    This site uses Akismet to reduce spam. Learn how your comment data is processed.