AD Connect passthrough authentication fails for some users

[mark1nh]

Hi

with Azure AD Connect passthrough authentication we see "50126 InvalidUserNameOrPassword" for some users.

In C:\ProgramData\Microsoft\Azure AD Connect Authentication Agent\Trace\AzureADConnectAuthenticationAgent_....

I can see the corresponding error: 

"Passthrough Authentication request failed....  Reason: '1326'."

The majority of users authenticates ok in azure.

In the trace Log I see many System.OperationCanceledException

At the AD Domain Controllers I see no "badpassword". I guess at some point Azure AD Connect decides the username is wrong - but there is no differnce in UPN compared to working users.

where can i find a solution?

best regards

Markus

[#2]

answering my own question:

the onpremisesuserprincipalname has to be set to the correct value in Azure AD. We did not know about this attribute. Our Azure UPN does not match the one premises one.
It seems PTA uses the onpremisesuserprincipalname to authenticate.

[#3]

@mark1nh 

Thank you for your information on the behavior. The same seems to affect us. Where do you put the on-prem upn in the azure ad? The corresponding field is deactivated and already filled with the on-prem upn. Wasn't that the case with you?

Users can no longer log in here unless I change the azure upn to the email address instead of the onmicrosoft.com address.
I think we have the same problem but different causes. We have a not routable on-prem domain "cpny.local" and a routable mail domain "company.com". Only when I select the "company.com" domain in the on-prem AD user settings and change the Azure-AD UPN to the email address login work. Curiously, that was not the case at the beginning, since onmicrosoft.com could remain as Azure UPN.

Regards

Kriz

[#4]

The field onpremisesuserprincipalname is filled during Azure AD Sync. We have a transformation for the correct value since Azure UPN ist not the right one in our case.

As far as I know Passthrough Authentication uses the onpremisesuserprincipalname mainly if "Alternate Login" Feature is enabled. In other cases it might not use this field.

Check what you have as UPN in your Azure AD and what your AD Controllers understand as valid login-Name(s).