User name and password not recognized error after Intune/Autopilot Device Provisioning Process

[CGunter]

Hi All,

I am currently in the middle of rolling out an Intune deployment strategy using Azure AD Joined rather than Hybrid Azure AD Joined. Everything is working as intended with the exception of an issue I am having after the device is provisioned during the Autopilot/OOBE process.

Before I reach the ESP page, I authenticate using MFA with Ping Identity. After I am authenticated, I am taken to the ESP page where the Device Preparation, Device Setup, and Account Setup are completed successfully. After the Account Setup stage is finished, I am taken directly to the workstation desktop where I am able to use the computer. The issue occurs if the computer is locked or restarted. I try to use the username and password that is associated to the user that was created in AD, but I receive the "User name or password is incorrect" message. The only way that I've been able to resolve this issue is change the domain part of the UPN of my user in AD. I'm not sure if the issue is that the user info is not getting cached after the OOBE, or if the issue is with WS-Trust or something completely different.

What am I missing? Any help would be greatly appreciated.

[#2]

Is the UPN different of the enrolling user than what you are trying to use for windows sign-in?

[#3]

What do you mean with „change the domain part of the UPN of my user in AD“

You can configure a device restriction policy and set the setting Password\Preferred Azure AD tenant then it is not longer needed to login with upn then the user id is sufficient after the enrollment.

[#4]

Could PingID be a factor here? If I remember correctly (it's been a while), it requires the installation of an additional credential provider for integration with Windows sign-in.

[#5]

Thanks for the response! The username that I enter at the welcome screen is the same UPN value of the user in AD. As an example, the UPN is email address removed for privacy reasons and that's the same value I enter at the welcome screen before it takes me to the MFA page.

What I found during my testing is that if I have the UPN and the primary email address of the user in AD match exactly, then I'm able to log in after the provisioning process without issue.

[#6]

Hey Jannik, in regards to your question about the UPN, the UPN of my test user in AD is something like email address removed for privacy reasons and the primary email address of my user is email address removed for privacy reasons. What I found during testing was that if I have those two values match in AD, I'm able to log in after the provisioning process without issue.

This is interesting information. I'll have to look into this to see how to properly configure this policy and if that would resolve my issue.

[#7]

Hey Niels, that could definitely be a factor and that's been the route that I've been going down to figure out what's going on. What I found during my testing yesterday was that if I set my UPN and Primary Email for the user in AD to match exactly, I'm able to log into my desktop without issue after the provisioning process. Because of this, it makes me wonder if the issue is with the credential validator in Ping Federate and what it's trying to match on.

[#8]

@CGunter 

Hello Gents,

Was a solution to this ever found? I am experiencing this same scenario at the moment with my Azure Joined test device.

Thanks,

[#9]

@David256 also interested on the resolution of this one as it’s happening in my environment that uses 3rd party  IDP