cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
sw41
Level 10
Report Inappropriate Content
Message 1 of 7

Not updating SSO data because user names do not match

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.

6 Replies
cross
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 2 of 7

Re: Not updating SSO data because user names do not match

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
Level 10
Report Inappropriate Content
Message 3 of 7

Re: Not updating SSO data because user names do not match

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
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 4 of 7

Re: Not updating SSO data because user names do not match

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
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 5 of 7

Re: Not updating SSO data because user names do not match

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
Level 10
Report Inappropriate Content
Message 6 of 7

Re: Not updating SSO data because user names do not match

trying to get an update on our case

cross
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 7 of 7

Re: Not updating SSO data because user names do not match

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.

 

You Deserve an Award
Don't forget, when your helpful posts earn a kudos or get accepted as a solution you can unlock perks and badges. Those aren't the only badges, either. How many can you collect? Click here to learn more.

Community Help Hub

    New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.

  • Find Forum FAQs
  • Learn How to Earn Badges
  • Ask for Help
Go to Community Help

Join the Community

    Thousands of customers use the McAfee Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership:

  • Get helpful solutions from McAfee experts.
  • Stay connected to product conversations that matter to you.
  • Participate in product groups led by McAfee employees.
Join the Community
Join the Community