Broken Profiles

Question

Hello! So, I've been running into an issue where on Azure AD joined machines, when a user attempts to log into their Azure AD account, it will tell them their password is wrong. If this was just one user, I would brush it off, but it is multiple, they are all reporting they didn't initiate a password change, and the logs in AAD show they are being honest. No password change attempts were made.

All computers are Windows 11 AAD joined machines. All effected machines are laptops so far but we don't have many desktops on our domain. If a computer is hit with the issue, and another user attempts to log in, they will also have a broken profile.

When I initiate the password change, or the user does it on their own, or they go back to "other user" and log in from scratch again - however it is done, once they log into their profile, explorer.exe stops working correctly, and the task bar stops functioning. When attempting to manually launch explorer.exe, it throws the error below:

"No mapping between account names and security IDs was done."

This is effectively breaking all usage of AAD profiles on AAD machines. The only fix we have isn't a fix, it's a workaround of making a local profile on the computer and hoping the user was actively signed in to OneDrive so their files sync correctly.

Thank you for any and all help, and I will be happy to post any additional information needed.

Answer 1

Hello @Khord T!

I understand your Win11 Azure AD Joined Laptops are falling under a Password Error, and even if you initiate a Password change the laptop is not reacting well wih File Explorer Error

Could you please share some info :

Is there a Hybrid AD Connect ?

Are there any relevant GPOs on the Active Directory ?

Are these laptops also Domain Joined ? WIndows and which functional level are your Servers ?

When did this started ? Was some change that triggered it?

Are you using Intune or any MDM ?

Thank you !

Answer 2

Hello Hello @Khord T!

Thank you for the info!

So i am giving you a list to check , dont be hasty , take your time and please be careful if your users data is not backed up beforehands

Check AD Connect for Sync errors , is there Password Writeback Enabled ?

Check your 365 Subscription is not expired - out of licenses

I suppose the users are able to connect to 365 without problems right ?

Which Sync method are you using ? If it is Password Through Authentication verify Agents are working correct , if its Password Hash check thoroughly AD Sync Logs and that the Connector Account is healthy

https://learn.microsoft.com/en-us/azure/active-directory/hybrid/connect/how-to-connect-configure-ad-ds-connector-account

https://learn.microsoft.com/en-us/azure/active-directory/hybrid/connect/tshoot-connect-password-hash-synchronization

https://learn.microsoft.com/en-us/azure/active-directory/hybrid/connect/tshoot-connect-pass-through-authentication

I am concerned that your devices a you say are AAD Joined . Are you sure ? Go to Azure AD and on the Devices tab how do they appear ? Registered or Joined ? Because i see there is Windows AD also ! In this case cant be both, we need Hybrd AD Join

I hope this helps!

Kindly mark the answer as Accepted and Upvote in case it helped!

Regards

Answer 3

Thank you for the list!

Our subscription is not expired, we have available licenses, and yes users can log into 365 without issue.

Password Writeback is enabled, and there are no directory sync errors.

We are using Password Hash, connector account is healthy.

For the last question, maybe I'm using terminology wrong and I apologize. I can see in the Microsoft Azure console that the device(s) are listed as "Azure AD Joined" under the "Join Type" field/header. Could you please elaborate or link to an article on Hybrid AD Joined? I assumed it meant the machine is listed under Azure AD and our local AD domain both. The computers in question are part of our local domain, only Azure.

Answer 4

Hello @Khord T!

So , Password Write-back is enabled right ?

I am really intrigued by this setup , with no Windows AD Joined PCs!

Because we know that the Passwords have to be written BACK to the Windows AD!

As we read from Microsoft Docs :

Prerequisites

To complete this tutorial, you need the following resources and privileges:

• A working Azure AD tenant with at least an Azure AD Premium P1 or trial license enabled.
• If needed, create one for free.
• For more information, see Licensing requirements for Azure AD SSPR.
• An account with Hybrid Identity Administrator.
• Azure AD configured for self-service password reset.
• If needed, complete the previous tutorial to enable Azure AD SSPR.
• An existing on-premises AD DS environment configured with a current version of Azure AD Connect.
• If needed, configure Azure AD Connect using the Express or Custom settings.
  • To use password writeback, domain controllers can run any supported version of Windows Server.

I suggest as a first step

Either Join 1-2 PCs on the Local Domain and see what happens

Or disable Password Write-back by running again the Azure AD Connect and change that parameter.

If you don't see it enabled please check this on Azure :

Azure AD - Password Reset - On Premises Integration - Password Writeback

I suggest also to read this and take the appropriate steps to configure it correctly

https://learn.microsoft.com/en-us/azure/active-directory/authentication/tutorial-enable-sspr-writeback?WT.mc_id=Portal-Microsoft_AAD_IAM#configuring-password-writeback

It does not make sense to NOT join on the Local AD so please Join 1 or 2 Laptops and verify that you are not getting the Errors

Once everything looks fine i will assist you to Hybrid AD Join them

Also can you please verify AD Connect is updated ?

https://learn.microsoft.com/en-us/azure/active-directory/hybrid/connect/how-to-upgrade-previous-version

Finally how is this looking on your Tenant :

Waiting for your feedback !

I hope this helps!

Kindly mark the answer as Accepted and Upvote in case it helped!

Regards

Answer 5

Thank you for all that!

As the screenshot below shows, we do have Password Writeback enabled:

I'm perhaps a little confused on why this one would matter at all though. Please forgive me on this one, I'm not saying you're wrong at all, just my personal ignorance on the subject. Password writeback should only matter for user passwords on the domain correct? The users are in Windows AD, the computers aren't. Would this just take the users Azure AD password and write it back to Windows AD as their user account password?

Unfortunately, we can't join all the machines to Windows AD, as the users work remote and do not require VPN, so the machine will never talk to Windows AD anyway. They're spread all over the country. Wouldn't this cause issues in the long run when the machine hasn't checking in on the local domain in forever?

We also can't disable the setting - again unless I'm wrong on what it does - because the few users that do get on the VPN in order to access file shares, and we want their passwords to be synchronized when they access those if they've changed their password in Azure AD.

Again, I'm not saying you're wrong by any means, I'm just trying to understand because it's clearly something I'm lacking knowledge on.