Hey Dude, Where’s My Winlogon.log?

Hi this is Michael from the PMC PFE Team, I recently helped a customer during the implementation of their Windows Server 2016 systems.

When checking the Event viewer, we spotted a well-known Event ID:

Log Name:      Application

Source:        SceCli

Date:          08.03.2017 17:49:21

Event ID:      1202

Task Category: None

Level:         Warning

Keywords:      Classic

User:          N/A

Computer:      test2016.mydomain.com

Description:

Security policies were propagated with warning. 0x534 : No mapping between account names and security IDs was done.

Advanced help for this problem is available on http://support.microsoft.com. Query for “troubleshooting 1202 events”.

Error 0x534 occurs when a user account in one or more Group Policy objects (GPOs) could not be resolved to a SID.  This error is possibly caused by a mistyped or deleted user account referenced in either the User Rights or Restricted Groups branch of a GPO.  To resolve this event, contact an administrator in the domain to perform the following actions:

1. Identify accounts that could not be resolved to a SID:
   1. From the command prompt, type: FIND /I “Cannot find”  %SYSTEMROOT%SecurityLogswinlogon.log
   2. The string following “Cannot find” in the FIND output identifies the problem account names.
   3. Example: Cannot find JohnDough.
   4. In this case, the SID for username “JohnDough” could not be determined. This most likely occurs because the account was deleted, renamed, or is spelled differently (e.g. “JohnDoe”).

1. Use RSoP to identify the specific User Rights, Restricted Groups, and Source GPOs that contain the problem accounts:
   1. Start -> Run -> RSoP.msc
   2. Review the results for Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesUser Rights Assignment and Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesRestricted Groups for any errors flagged with a red X.
   3. For any User Right or Restricted Group marked with a red X, the corresponding GPO that contains the problem policy setting is listed under the column entitled “Source GPO”. Note the specific User Rights, Restricted Groups and containing Source GPOs that are generating errors.

1. Remove unresolved accounts from Group Policy
   1. Start -> Run -> MMC.EXE
   2. From the File menu select “Add/Remove Snap-in…”
   3. From the “Add/Remove Snap-in” dialog box select “Add…”
   4. In the “Add Standalone Snap-in” dialog box select “Group Policy” and click “Add”
   5. In the “Select Group Policy Object” dialog box click the “Browse” button.
   6. On the “Browse for a Group Policy Object” dialog box choose the “All” tab
   7. For each source GPO identified in step 2, correct the specific User Rights or Restricted Groups that were flagged with a red X in step 2. These User Rights or Restricted Groups can be corrected by removing or correcting any references to the problem accounts that were identified in step 1.

So, okay Event 1202 Sid-to-Name mapping issue. Sure enough there was some security principal in either one of the settings or at the delegation tab on one of the policies which couldn’t get resolved.

So let’s have a look at the Winlogon.log as called out in the event description. We went to %SYSTEMROOT%SecurityLogs and then “Dude, where’s the Winlogon.log!”

We quickly checked if the path may have changed in Server 2016 but couldn’t find the log in any other directory. Then we checked how this was enabled / disabled on earlier OS versions.

https://msdn.microsoft.com/de-de/library/cc775423(v=ws.10).aspx

HKLMSoftwareMicrosoftWindowsNTCurrentVersionWinlogonGPExtensions{827D319E-6EAC-11D2-A4EA-00C04F79F83A}

Key name: ExtensionDebugLevel
Typ: DWORD
Data: 0x2

Okay, so it is not enabled by default on Windows 10 and Server 2016. We enabled the debug log but still after a “gpupdate / force” and a reboot NO winlogon.log file was present. What’s wrong? Well actually nothing….

Here’s why…

We are talking about a CSE (Client side extension) which is repented by that GUID “{827D319E-6EAC-11D2-A4EA-00C04F79F83A}” ; We did a change in the registry which is only triggers when the CSE is run the next time…. But when there are NO changes to the GPO why should the CSE re-run the respective policy? Exactly,…there is no reason. This has always been the case, the code apparently didn’t change since 2008 but the log just happens to be enabled by default.

So, dude what do we have to do to get the Winlogon.log file back?

There are a few methods available and I’m listing them in the preferred order of applicability:

1. use the NoListChanges = 0
   1. This triggers the CSE to re-evaluate and trigger the policy even though there were no changes to the policy.
   2. References:
      1. https://technet.microsoft.com/en-us/library/cc978250.aspx
      2. http://www.thewindowsclub.com/disable-background-processing-registry-policy

1. Make a change to a policy in the security section, that’s the piece the CSE is responsible for and triggers a re-run which then creates the Winlogon.log

In any case, please make sure you undo the changes you’ve done for troubleshooting!

Winlogon.log is a debugging file which you should enable if needed to find and fix your issues but then disable it later again. Same for the NoListChanges, please make sure that you revert this change back!

Hope you enjoyed the post and it saves you some time in finding the Winlogon.log file now.

Regards,

Michael