User Provisioned from Azure AD fails to authenticate

rmarksliq0
Kilo Explorer

We are looking to use Azure AD for authentication with user provisioning to be done by Azure AD.

Having set this up in a test secondary AAD directory, we have found that users in that AAD cannot authenticate.

What we get returned when testing the authentication is:

User: rcs52J3Ezuc9_vMDuR6K0Zm8KYudcCqUrc2QFKdyu-c not found Ensure that the user you are trying the test connection with is present in the system. Ensure that 'User Field' property value corresponds to the value set in the IDP returned through 'Subject NameID' in the response.

I can see the user object is being provisioned in ServiceNow, so I'm note sure what is causing this.

1 ACCEPTED SOLUTION

corina
ServiceNow Employee
ServiceNow Employee

Hello Robert.




Thanks for the print screen.


NameID policy is unspecified . It is the same on the IDP side?




What do you have on advanced tab and Properties?




The idea should be that the IDP is trying to match upon something different that what you specified in the   SN side for   idp settings.


So if you check the response coming from the IDP , the   Subject NameID comes as   rcs52J3Ezuc9_vMDuR6K0Zm8KYudcCqUrc2QFKdyu-c ?




Usually these gets resolved with changing claiming rules on the IDP side, however, if there is something suspicious in the settings themselves we could let you know, should you be able to provide the other pritnscreeens as well


View solution in original post

6 REPLIES 6

corina
ServiceNow Employee
ServiceNow Employee

Hello Robert.




Maybe you could post a print screen with the IDP configuration ?


Hi IDP is configured as below:


SSO Issue.png


SSO Issue 2.png


corina
ServiceNow Employee
ServiceNow Employee

Hello Robert.




Thanks for the print screen.


NameID policy is unspecified . It is the same on the IDP side?




What do you have on advanced tab and Properties?




The idea should be that the IDP is trying to match upon something different that what you specified in the   SN side for   idp settings.


So if you check the response coming from the IDP , the   Subject NameID comes as   rcs52J3Ezuc9_vMDuR6K0Zm8KYudcCqUrc2QFKdyu-c ?




Usually these gets resolved with changing claiming rules on the IDP side, however, if there is something suspicious in the settings themselves we could let you know, should you be able to provide the other pritnscreeens as well


We set the NameID Policy to: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress



This then works and allows authentication correctly.