Not updating SSO data because user names do not match

[sw41]

We are getting that error when trying to setup a new user on a new machine for the first time, happening on a bunch of machines.

I found in the MFE log this:

2020-08-26 19:20:53,853 INFO FirstUserRegistryListener Detected registry change in FirstUser key.
2020-08-26 19:20:53,854 INFO FirstUserRegistryListener Detected registry change in FirstUser key.
2020-08-26 19:20:53,854 INFO OsLogon Successful Windows logon (MdeUserID=9385C5D22D9C4C65A9474F436099A1B8,WinUser=HPS\John.Doe,WinSID=S-1-1-11-1111116045-911111112-4136102498-198978,SSO=Yes,PwdSync=Yes,IsCurrentWinUser=Yes,RecordUserMapping=No,IsCertLogon=No)
2020-08-26 19:20:53,854 INFO OsLogon Current Windows user (Name=HPS\John.Doe,SID=)
2020-08-26 19:20:53,854 INFO FirstUserRegistryCopier Copy operation started
2020-08-26 19:20:53,854 INFO FirstUserRegistryCopier Copy operation started

It matches the names for the CurrentWinUser but that seems to not see the SID.

So what is the trick to make the CurrentWinUser match what DE pulls back from EPO to see it is a match and add the user to the pre-boot?  

We have tried locking/unlocking the machine with the current user 20x and no joy.

[cross]

Is your policy configured with the option that it must match Windows user name?  

Is the actual name of the MDE user that is used in preboot the exact same as what is entered in Windows?  Assuming that there is no other impedance, after you log on to MDE preboot with the user, select the option to log in to Windows as an "other" user and make sure to input the user name exactly as it is for MDE preboot.  

To the mention of other impedance above, what I'm referring to would be things like having a third-party credential provider and more particularly a third-party credential provider filter.  I would definitely recommend checking to see if you have any in the equation as they can cause password synchronization issues.

[sw41]

We don't tell preboot what the username is, we rely on CAD L/UL putting the name into preboot, so it should match (it has for the other 4000 users over the last 5 years).  We log into a machine as the new user then kick off encryption.

Nice tip with the 3rd party.  We do have GSuite and google authentication but that is not in the middle here.  EPO is linked to AD so when we log into a new computer as a new AD user, the info should match and does not go thru a 3rd party.

We are on a newly turned up network that does not have a direct path to EPO and is instead going thru our Agent handler in the DMZ.  Not sure if there is some port missing but watching some machines with users authenticate and the one next to it not makes me thing this is not a network port issue.  Seeing in the log the returned value of the SID and the policy settings also makes me think we are ok on ports thru the DMZ.

A ticket and webmer have been opened up incase I am missing details

[cross]

I'm sorry, I may not have been very clear initially on the first item of discussion. The user name is created for preboot based on the attribute selected in the server settings for MDE within ePO. The default for the user name is samaccountname. As an example if John Doe is the user and the samaccountname for John Doe is jdoe, then under the default configuration, the MDE account would be named jdoe. To log in to Windows, it will accept various attributes for the user name besides that samaccountname value, like **personal information omitted** or domain\jdoe. Neither of those two will match to the MDE user name in this example, jdoe. I hope that clears it up a bit from what I tried to say earier. If the user is already pre-populated when you hit CAD then it may be using a different attribute for the logon to the OS than that which the MDE preboot user name is.  Depending upon the policy settings, the issue could lie here.  

On the networking aspect, I agree, it is not probable to be a network related issue. The credential capture happens on the local system and if your users were impacted by a networking issue it would almost certainly manifest differently.

I believe I found the SR you put in. I don't see the MER data yet but I'll check in with the person that it is assigned to shortly.

[cross]

I spoke with the case owner and we looked over the MfeEpe.log.  Too keep things simple, we'll focus in the case and circle back here for the conclusion.

[sw41]

trying to get an update on our case

[cross]

I'm sorry for the inconvenience, it looks like the case owner tried to call but missed on the timing and there should be an email on the way.  Overall, the situation appears that the logged on MDE preboot user and the logged on Windows user are not the same from the information in the MfeEpe.log.  

The applicable lines in the log file that we are seeing show:

OsLogonAuth Matching user names (MDE=<USER_A, Windows=USER_B)
OsLogonAuth Not synchronizing password because user names do not match

Of course, we have changed the actual user names in the messages above but it appears that the user that is logged in to preboot is not the same user that is logged in to the OS.

If the logged on preboot user is not the same as the logged on Windows user then the password synchronization should not take place.

The wording of the first message may be something that could be re-worded better but it ultimately means that it is attempting to see if the user for preboot and the Windows user match and then the subsequent line confirms they do not match.